☰
Tegaki笔顺引擎解析:KanjiVG、Hershey参考匹配如何让书写顺序自然如手
2026/9/29 2:31:35 网站建设 项目流程

Tegaki笔顺引擎解析:KanjiVG、Hershey参考匹配如何让书写顺序自然如手

【免费下载链接】tegakiHandwriting animation for the web. Supports any font or text.项目地址: https://gitcode.com/gh_mirrors/teg/tegaki

Tegaki 是一个为 Web 打造的手写动画库,它把任意字体的文本拆解成带时间的笔画,让文字像被人一笔一划写出来。而让书写顺序自然如手的关键,正是它的笔顺引擎——Tegaki 不依赖字体自带信息(字体其实不含笔顺数据),而是从 KanjiVG、Hershey 等权威笔顺参考数据中"借来"标准笔顺,再与字体自身的墨迹做几何匹配,自动决定每一笔"先写谁、往哪个方向运笔"。下面带你拆解这套引擎的 5 个核心环节。

参考数据源:从 KanjiVG 与 Hershey "学会"笔顺

Tegaki 的笔顺引擎采用"数据集驱动"策略:每个参考数据源只需回答三个问题——有几笔、按什么顺序写、笔往哪个方向走,而真正渲染的几何形状始终来自字体本身。参考折线只影响顺序与方向决策,不会进入生成的动画数据,因此也无需把数据集的版权绑定到产物上(见 types.ts 顶部注释)。

KanjiVG:汉字与日文的"教科书笔顺"

汉字、日文假名的参考数据来自 KanjiVG 数据集。每个字符是一份 SVG,其中的<path>元素本身就是按书写顺序排列的笔迹中心线,路径方向即运笔方向,画布为 109×109、y 轴向下。Tegaki 固定使用某个发布版本(KANJIVG_RELEASE = 'r20250816'),保证生成的数据可复现,并优先信任路径 id 中-sN后缀标注的笔顺编号,而非文档顺序。整个解析是纯字符串实现,Bun CLI 与浏览器内管线都能跑,IO 通过注入的 loader 完成(kanjivg.ts、kanjivg-fetch.ts)。

Hershey:手写体与印刷体两套拉丁字母笔迹

拉丁字母的处理更微妙。KanjiVG 里的拉丁参考是印刷风格——大写的 M 拆成 4 笔、m 拆成 3 笔——但 Caveat 这类手写体的 m 明明是一笔连贯的轨迹。为此 Tegaki 引入 Hershey 字体作为补充:它是美国国家标准局博士 A. V. Hershey 数字化的逐字母运笔轨迹,天然贴合书写习惯。Tegaki 同时加载两个风格变体(hershey.ts):

  • hershey-script:正式手写花体,覆盖拉丁字母;
  • hershey-simplex:朴素印刷体,同时是唯一可靠的数字笔顺参考(Script 体的数字是双笔装饰字形,被排除在外)。

多个变体并存、让"最贴合当前字体"的那一套胜出,是整台引擎的设计精髓,后文详述。

注册对齐:把参考笔迹"套"到真实字体上

参考数据生活在自己的坐标系(KanjiVG 是 109×109),而字体墨迹在字体单位里。注册(registration)步骤就是把两者对齐成同一坐标空间。

直接按包围盒缩放对"饱满"的字符没问题,但对细长字符会翻车:比如"一"字的参考高度只是中心线的几像素抖动,把它拉伸到字体笔画的整个粗细会严重失真。Tegaki 的对策是:某轴上的参考跨度若不足数据集画布的 20%(THIN_SPAN_RATIO),就判定该轴"太薄",借用另一轴的缩放系数,只对齐中心点。点和顿号这类两侧都极小的标记则整体等比缩放(register.ts)。

笔画匹配算法:一次判定"是哪笔 + 往哪写"

对齐之后,核心问题是:字体提取出的每一笔,对应参考里的哪一笔?运笔方向是否相反?Tegaki 的匹配算法(match.ts)做了三个关键简化:

  1. 弧长均匀重采样:两条折线都重采样为 24 个等弧长样本。笔画是短而单调的曲线,重采样后"下标即对应关系",无需昂贵的 DTW(动态时间规整);
  2. 正反向各评一次:每对笔画同时计算正向与反转方向的距离,取较小者——于是哪条参考笔画与运笔方向在一次比较里同时确定;
  3. 匈牙利算法精确求解:全局分配用 Kuhn-Munkres 算法(O(n³))求得最小总成本的一对一分配,保证结果确定且全局最优,而不是贪心式的近似。

匹配成本以字形对角线归一化,实测中"匹配正确"的成本在 0.01~0.06,错配普遍 ≥0.15,中间留了充足的判断余量。

连笔字体的兜底:引导式排序(Guided Ordering)

问题在于:手写体常常不按参考拆笔。韩文手写字体 Nanum Pen Script 会把 ㅎ 的横与圈一笔写完,把 ㄹ 写成一条之字形——笔画数对不上,1:1 匹配自然失败。

此时登场的是引导式排序(guide.ts)。它放弃"逐笔配对",改为投影定位:把提取笔画的样本点投影到参考笔画上,得到"参考笔画序号 + 沿弧长比例"的位置;用 35% 分位数作为该笔的"起点位置"(对个别漂到邻近笔画的样本更鲁棒),再按起点先后决定书写顺序;运笔方向则比较笔画弦向与参考弦向,闭合笔画(如 ㅇ)比较环绕方向。参考还先经过"分组再拟合"(refit),把每个字母整体平移到其墨迹实际所在处——因为手写体摆放字母的位置和教科书布局往往差得很远。

变体择优:Tegaki 如何自动选择最自然的写法

回到多变体设计。对于每个字符,管线(pipeline.ts)会独立评估每一个参考变体:注册 → 匹配 → 若不干净,尝试按参考重新切分/合并笔画(regroup)→ 重匹配。然后按如下优先级排序择优:

  • 干净匹配(笔画数一致且平均成本 ≤ 0.15)优先;
  • 若存在"按字体原样笔画即匹配成功"的变体,惩罚需要切割字体笔画的变体——Dancing Script 的连笔 w 会采用 Hershey 两笔的手写 w,而不是把 KanjiVG 印刷 w 硬切成四笔;
  • 同等条件下比笔画数一致性,再比平均成本。

最终赢家决定书写序列:干净则完全采用数据集顺序(strokeOrderSource = 'dataset');不干净但字符属于"笔顺有标准"的类别(如韩文)则用引导式排序;否则回退到启发式规则(上→下、左→右、点画最后)。整条决策链在 createReferenceSet 中组装:汉字数据集按hanLocale调整先后(中文语境 Make Me a Hanzi 优先,日文语境 KanjiVG 优先),随后是 Hershey 花体、Hershey 印刷体与韩文合成音节;带音符的字母(如 é)查不到时自动回退到基字母(e)的参考。时序最后由 ordering.ts 按笔画长度与书写速度换算出每笔的 delay 与 duration。

小结:三件事让"自然如手"成立

  • 数据只借顺序,不借形状:参考折线决定"先写谁、往哪走",墨迹几何始终来自字体,版权也解耦;
  • 双向重采样 + 匈牙利精确匹配:便宜、确定,且方向与配对一次求解;
  • 多风格变体择优 + 引导式兜底:印刷字体拿到印刷笔顺,连笔手写体拿到连笔笔顺,无需为每个字体做任何配置。

想动手体验,可克隆仓库git clone https://gitcode.com/gh_mirrors/teg/tegaki后运行生成器 CLI(cli/index.ts)查看每个字形的笔顺来源与匹配成本,报告命令stroke-order-report还会输出逐字的匹配明细(stroke-order-report.ts)。这套"参考数据 × 几何匹配"的笔顺引擎,正是 Tegaki 支持任意字体与任意文字手写动画的底气所在。

【免费下载链接】tegakiHandwriting animation for the web. Supports any font or text.项目地址: https://gitcode.com/gh_mirrors/teg/tegaki

创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考

需要专业的网站建设服务?

联系我们获取免费的网站建设咨询和方案报价,让我们帮助您实现业务目标

立即咨询