功能导航
搜索
导航
热榜
快讯
工具箱
知识库
新手指南
搜索
导航
热榜
快讯
工具箱
知识库
新手指南
咨询
官方客服
扫码添加,立即咨询
加群
官方微信群
扫码添加,拉你进群
订阅
微信公众号
欧洲跨境之路
回顶部
✕
热门工具
▼
汇率换算器
词云
人民币外汇牌价
在线汇率换算
可视化编辑器
文本去重
搜索链接
翻译聚合
数字转英文
stripe费用计算器
两步链接
时间单位转换
购物链接
大小写转换
在线拉美汇率换算
长度单位转换
关键词优化
▼
亚马逊常规
▼
搜索链接
购物链接
两步链接
权威链接
好评链接
stripe费用计算器
Fiverr费用计算器
汇率换算
▼
人民币外汇牌价
汇率换算器
在线汇率换算
在线拉美汇率换算
在线东南亚汇率换算
单位换算
▼
长度单位转换
重量单位转换
面积单位转换
体积单位转换
压强单位转换
功率单位转换
温度单位转换
时间单位转换
角度单位转换
电容单位转换
速度单位转换
文本处理
▼
文本去重
数字转英文
大小写转换
词云
文本列合并
文本空行清理
翻译聚合
可视化编辑器
随机密码生成
欧洲123 - 跨境卖家第一入口
›
词云
复制您的文字到下面文本框中
How the Word Cloud Generator Works The layout algorithm for positioning words without overlap is available on GitHub under an open source license as d3-cloud. Note that this is the only the layout algorithm and any code for converting text into words and rendering the final output requires additional development. As word placement can be quite slow for more than a few hundred words, the layout algorithm can be run asynchronously, with a configurable time step size. This makes it possible to animate words as they are placed without stuttering. It is recommended to always use a time step even without animations as it prevents the browser’s event loop from blocking while placing the words. The layout algorithm itself is incredibly simple. For each word, starting with the most “important”: Attempt to place the word at some starting point: usually near the middle, or somewhere on a central horizontal line. If the word intersects with any previously placed words, move it one step along an increasing spiral. Repeat until no intersections are found. The hard part is making it perform efficiently! According to Jonathan Feinberg, Wordle uses a combination of hierarchical bounding boxes and quadtrees to achieve reasonable speeds. Glyphs in JavaScript There isn’t a way to retrieve precise glyph shapes via the DOM, except perhaps for SVG fonts. Instead, we draw each word to a hidden canvas element, and retrieve the pixel data. Retrieving the pixel data separately for each word is expensive, so we draw as many words as possible and then retrieve their pixels in a batch operation. Sprites and Masks My initial implementation performed collision detection using sprite masks. Once a word is placed, it doesn't move, so we can copy it to the appropriate position in a larger sprite representing the whole placement area. The advantage of this is that collision detection only involves comparing a candidate sprite with the relevant area of this larger sprite, rather than comparing with each previous word separately. Somewhat surprisingly, a simple low-level hack made a tremendous difference: when constructing the sprite I compressed blocks of 32 1-bit pixels into 32-bit integers, thus reducing the number of checks (and memory) by 32 times. In fact, this turned out to beat my hierarchical bounding box with quadtree implementation on everything I tried it on (even very large areas and font sizes). I think this is primarily because the sprite version only needs to perform a single collision test per candidate area, whereas the bounding box version has to compare with every other previously placed word that overlaps slightly with the candidate area. Another possibility would be to merge a word’s tree with a single large tree once it is placed. I think this operation would be fairly expensive though compared with the analagous sprite mask operation, which is essentially ORing a whole block.
点击生成
重置
Copyright©2025 All rights reserved.
欧洲123 - 跨境卖家第一入口
(
粤ICP备2025490062号
)
返回顶部