2026/9/19 22:54:34
FEATURED · 精选文章 
深度揭秘source-han-sans-ttf构建流水线4段式verda构建流程逐行解析【免费下载链接】source-han-sans-ttfA (hinted!) version of Source Han Sans项目地址: https://gitcode.com/gh_mirrors/so/source-han-sans-ttfsource-han-sans-ttf 是一个把思源黑体Source Han Sans重新打包为带字形提示hintedTTF 版本的开源构建项目。它的核心是一条基于 verdafile.js 定义的4 段式Pass 1 ~ Pass 4verda 构建流水线先拆字体、再改名、后加提示、最后打包发布。本文将带你逐段拆解这条字体构建流水线的每一步在做什么、为什么这样做适合刚接触字体工程的新手快速上手。️ 项目全景一条流水线做了什么整个项目结构非常精简所有魔法都写在构建脚本里目录 / 文件作用src/输入素材7 个字重的SourceHanSans-*.ttc合集字体verdafile.js构建流水线主脚本定义 Pass 1 ~ Pass 4 全部任务config.json全局配置字重列表、地区后缀、字体命名renaming/index.js字体重命名模块负责改写 name 表hint-config/7 个字重的 hinting 提示参数配置JSONpackage.json依赖与npm run build构建入口用一句话概括它的目标把 Adobe 官方发布的 CFF 格式OTF/TTC思源黑体转成 Windows 下显示更锐利的 TrueTypeTTF格式并写入精细的字节码提示指令。 开始构建前环境与依赖根据 README.md构建只需要两样东西最新版本的AFDKO提供otf2otc、otc2otf、otf2ttf、ttfautohint等命令行工具Node.js环境然后在项目根目录执行npm install npm run build all其中npm run build实际调用的是verda -f verdafile.js见 package.json 中的 scripts 定义。verda 是一个声明式构建工具verdafile.js 用task任务、file文件产物、oracle外部事实源三种规则类型把整条流水线声明出来依赖关系自动推导支持增量构建。 小贴士构建全部字重可能需要数小时请耐心等待这也是 verda 增量机制的价值所在——重跑时只构建变化的部分。 Pass 1拆解 TTC 合集并重命名Pass 1 的目标是把每个字重的全家桶TTC文件拆开变成按地区划分的独立字体文件。流程分三步第一步拆分合集字体。调用 AFDKO 的otc2otf工具把 src/SourceHanSans-Bold.ttc 这类合集文件拆成一堆单字体OTF对应 verdafile.js 中BreakTtc任务。第二步逐地区重命名。拆分出的每个地区字体如日文版 K、简体中文 SC、繁体中文 TC、传统中文 HC 等都会调用 renaming/index.js 模块用ot-builder库读取字体、整体重建 name 表家族名统一改为SHSTTF可在 config.json 的naming.familyName修改按语言en_US、zh_CN、zh_TW、ja_JP、ko_KR等分别写入 PreferredFamily / LegacyFamily / PostScript 名处理 ExtraLight 等长字样的名称溢出兼容问题缩写为 XLight附加版权、版本号等元信息来自 config.json 的naming.copyright、naming.version第三步格式转换。再用otf2ttf把每个OTF转成真正的TTFCFF 轮廓 → TrueType 轮廓产物落在.build/pass1/目录。地区清单由 config.json 控制regions定义了最终发布的 4 个地区含无后缀的混合版allRegions则包含 HW华为定制系列共 10 个变体——Pass 1 会把 10 个都拆出来处理。⚙️ Pass 2回合成 TTC 并做首轮自动提示Pass 2 干两件合并的事重新打包 TTC把 Pass 1 产出的 4 个地区TTF通过otf2otc合并成临时 TTC写入基础提示调用ttfautohint对临时 TTC 做自动 hinting然后再用otc2otf拆回单字体 TTF为什么不直接对 4 个 TTF 分别跑ttfautohint因为ttfautohint天然支持 TTC 输入一次处理合集比逐个处理更快产物也保持一致性。这一轮提示相当于打底为 Pass 3 的高级提示做准备。✏️ Pass 3Chlorophytum 精细 Hinting核心环节Pass 3 是整条流水线技术含量最高的一段使用chlorophytum/cli命令行工具完成两阶段处理见 package.json 依赖列表阶段一hint任务 —— 生成提示缓存。按字重执行group-hint并行度由JHintoracle 自动取 CPU 核心数。每个字重的具体参数来自 hint-config/ 下对应的 JSON 文件例如 hint-config/Bold.json用hm-select-glyphs按 Unicode 区段筛选需要精细提示的字形康熙部首、CJK 统一表意文字含扩展 A~F 区、韩文音节等跟踪locl、trad、jp78、jp83等 OpenType 特性保证不同地区的替换字形也能获得正确提示命中范围内的字形交给hm-ideograph提示器参数如CANONICAL_STEM_WIDTH: 0.097标准笔画宽度、DoOutlineDicing: true轮廓切分等都是针对汉字笔画特征调校的阶段二instruct任务 —— 写入字节码。对每个字重执行instruct将提示参数与 Pass 2 的基础提示合并把最终的字节码提示指令写入 TTF产物输出到out/ttf/目录。每个字重都有独立配置文件ExtraLight.json、Light.json、Regular.json、Medium.json、Heavy.json 等因为不同字重的笔画粗细不同最佳提示参数也各不相同。 Pass 4最终打包与发布归档Pass 4 最简洁就是合成 压缩TTC 打包用otb-ttc-bundle把同一字重的 4 个地区 TTF 重新打成一个out/ttc/ShsTtf-字重.ttc这就是最终交付的合集字体7z 归档release任务把所有字重的 TTC / TTF 分别压缩成release-ttc-版本.7z和release-ttf-版本.7z压缩参数为LZMA:a0:d1536m:fb2561.5GB 词典、多线程版本号取自 package.json当前 2.004 4 段式流水线总览阶段输入关键工具输出Pass 1src/*.ttcotc2otf、renaming 模块、otf2ttf.build/pass1/*-地区-字重.ttfPass 2Pass 1 TTFotf2otc、ttfautohint、otc2otf.build/pass2/*-字重.ttfPass 3Pass 2 TTF hint-config/chlorophytum/clihint instructout/ttf/*-字重.ttfPass 4Pass 3 TTFotb-ttc-bundle、7zout/ttc/*.ttc 发布 7z 包❓ 常见问题Q能只改字体家族名吗A可以。修改 config.json 的naming.familyName菜单显示名和prefix文件名与 PostScript 名后重新构建即可。Q构建产物放在哪里A中间产物在.build/下按 pass 分目录最终 TTF 在out/ttf/、TTC 在out/ttc/发布压缩包为out/release-*.7z。Q为什么 TTF 版本值得要AOTFCFF 格式在部分 Windows 环境小字号下显示偏粗或发虚带精细 hint 的 TTF 在低分屏和旧系统上锐利度更好。本项目的 Chlorophytum 提示参数针对中日韩汉字笔画深度调校效果优于单纯ttfautohint的通用结果。 总结source-han-sans-ttf 用一份 verdafile.js 把字体工程中最繁琐的拆包 → 改名 → 转格式 → 双重 hinting → 打包发布流程变成了可增量、可复现的声明式流水线。理解这 4 个 Pass 的职责分工你不仅能复现构建还能照着模板改造出自己的字体发布流水线。项目遵循 LICENSE 开源协议可放心学习与二次开发。【免费下载链接】source-han-sans-ttfA (hinted!) version of Source Han Sans项目地址: https://gitcode.com/gh_mirrors/so/source-han-sans-ttf创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
深度揭秘source-han-sans-ttf构建流水线：4段式verda构建流程逐行解析
深度揭秘source-han-sans-ttf构建流水线4段式verda构建流程逐行解析【免费下载链接】source-han-sans-ttfA (hinted!) version of Source Han Sans项目地址: https://gitcode.com/gh_mirrors/so/source-han-sans-ttfsource-han-sans-ttf 是一个把思源黑体Source Han Sans重新打包为带字形提示hintedTTF 版本的开源构建项目。它的核心是一条基于 verdafile.js 定义的4 段式Pass 1 ~ Pass 4verda 构建流水线先拆字体、再改名、后加提示、最后打包发布。本文将带你逐段拆解这条字体构建流水线的每一步在做什么、为什么这样做适合刚接触字体工程的新手快速上手。️ 项目全景一条流水线做了什么整个项目结构非常精简所有魔法都写在构建脚本里目录 / 文件作用src/输入素材7 个字重的SourceHanSans-*.ttc合集字体verdafile.js构建流水线主脚本定义 Pass 1 ~ Pass 4 全部任务config.json全局配置字重列表、地区后缀、字体命名renaming/index.js字体重命名模块负责改写 name 表hint-config/7 个字重的 hinting 提示参数配置JSONpackage.json依赖与npm run build构建入口用一句话概括它的目标把 Adobe 官方发布的 CFF 格式OTF/TTC思源黑体转成 Windows 下显示更锐利的 TrueTypeTTF格式并写入精细的字节码提示指令。 开始构建前环境与依赖根据 README.md构建只需要两样东西最新版本的AFDKO提供otf2otc、otc2otf、otf2ttf、ttfautohint等命令行工具Node.js环境然后在项目根目录执行npm install npm run build all其中npm run build实际调用的是verda -f verdafile.js见 package.json 中的 scripts 定义。verda 是一个声明式构建工具verdafile.js 用task任务、file文件产物、oracle外部事实源三种规则类型把整条流水线声明出来依赖关系自动推导支持增量构建。 小贴士构建全部字重可能需要数小时请耐心等待这也是 verda 增量机制的价值所在——重跑时只构建变化的部分。 Pass 1拆解 TTC 合集并重命名Pass 1 的目标是把每个字重的全家桶TTC文件拆开变成按地区划分的独立字体文件。流程分三步第一步拆分合集字体。调用 AFDKO 的otc2otf工具把 src/SourceHanSans-Bold.ttc 这类合集文件拆成一堆单字体OTF对应 verdafile.js 中BreakTtc任务。第二步逐地区重命名。拆分出的每个地区字体如日文版 K、简体中文 SC、繁体中文 TC、传统中文 HC 等都会调用 renaming/index.js 模块用ot-builder库读取字体、整体重建 name 表家族名统一改为SHSTTF可在 config.json 的naming.familyName修改按语言en_US、zh_CN、zh_TW、ja_JP、ko_KR等分别写入 PreferredFamily / LegacyFamily / PostScript 名处理 ExtraLight 等长字样的名称溢出兼容问题缩写为 XLight附加版权、版本号等元信息来自 config.json 的naming.copyright、naming.version第三步格式转换。再用otf2ttf把每个OTF转成真正的TTFCFF 轮廓 → TrueType 轮廓产物落在.build/pass1/目录。地区清单由 config.json 控制regions定义了最终发布的 4 个地区含无后缀的混合版allRegions则包含 HW华为定制系列共 10 个变体——Pass 1 会把 10 个都拆出来处理。⚙️ Pass 2回合成 TTC 并做首轮自动提示Pass 2 干两件合并的事重新打包 TTC把 Pass 1 产出的 4 个地区TTF通过otf2otc合并成临时 TTC写入基础提示调用ttfautohint对临时 TTC 做自动 hinting然后再用otc2otf拆回单字体 TTF为什么不直接对 4 个 TTF 分别跑ttfautohint因为ttfautohint天然支持 TTC 输入一次处理合集比逐个处理更快产物也保持一致性。这一轮提示相当于打底为 Pass 3 的高级提示做准备。✏️ Pass 3Chlorophytum 精细 Hinting核心环节Pass 3 是整条流水线技术含量最高的一段使用chlorophytum/cli命令行工具完成两阶段处理见 package.json 依赖列表阶段一hint任务 —— 生成提示缓存。按字重执行group-hint并行度由JHintoracle 自动取 CPU 核心数。每个字重的具体参数来自 hint-config/ 下对应的 JSON 文件例如 hint-config/Bold.json用hm-select-glyphs按 Unicode 区段筛选需要精细提示的字形康熙部首、CJK 统一表意文字含扩展 A~F 区、韩文音节等跟踪locl、trad、jp78、jp83等 OpenType 特性保证不同地区的替换字形也能获得正确提示命中范围内的字形交给hm-ideograph提示器参数如CANONICAL_STEM_WIDTH: 0.097标准笔画宽度、DoOutlineDicing: true轮廓切分等都是针对汉字笔画特征调校的阶段二instruct任务 —— 写入字节码。对每个字重执行instruct将提示参数与 Pass 2 的基础提示合并把最终的字节码提示指令写入 TTF产物输出到out/ttf/目录。每个字重都有独立配置文件ExtraLight.json、Light.json、Regular.json、Medium.json、Heavy.json 等因为不同字重的笔画粗细不同最佳提示参数也各不相同。 Pass 4最终打包与发布归档Pass 4 最简洁就是合成 压缩TTC 打包用otb-ttc-bundle把同一字重的 4 个地区 TTF 重新打成一个out/ttc/ShsTtf-字重.ttc这就是最终交付的合集字体7z 归档release任务把所有字重的 TTC / TTF 分别压缩成release-ttc-版本.7z和release-ttf-版本.7z压缩参数为LZMA:a0:d1536m:fb2561.5GB 词典、多线程版本号取自 package.json当前 2.004 4 段式流水线总览阶段输入关键工具输出Pass 1src/*.ttcotc2otf、renaming 模块、otf2ttf.build/pass1/*-地区-字重.ttfPass 2Pass 1 TTFotf2otc、ttfautohint、otc2otf.build/pass2/*-字重.ttfPass 3Pass 2 TTF hint-config/chlorophytum/clihint instructout/ttf/*-字重.ttfPass 4Pass 3 TTFotb-ttc-bundle、7zout/ttc/*.ttc 发布 7z 包❓ 常见问题Q能只改字体家族名吗A可以。修改 config.json 的naming.familyName菜单显示名和prefix文件名与 PostScript 名后重新构建即可。Q构建产物放在哪里A中间产物在.build/下按 pass 分目录最终 TTF 在out/ttf/、TTC 在out/ttc/发布压缩包为out/release-*.7z。Q为什么 TTF 版本值得要AOTFCFF 格式在部分 Windows 环境小字号下显示偏粗或发虚带精细 hint 的 TTF 在低分屏和旧系统上锐利度更好。本项目的 Chlorophytum 提示参数针对中日韩汉字笔画深度调校效果优于单纯ttfautohint的通用结果。 总结source-han-sans-ttf 用一份 verdafile.js 把字体工程中最繁琐的拆包 → 改名 → 转格式 → 双重 hinting → 打包发布流程变成了可增量、可复现的声明式流水线。理解这 4 个 Pass 的职责分工你不仅能复现构建还能照着模板改造出自己的字体发布流水线。项目遵循 LICENSE 开源协议可放心学习与二次开发。【免费下载链接】source-han-sans-ttfA (hinted!) version of Source Han Sans项目地址: https://gitcode.com/gh_mirrors/so/source-han-sans-ttf创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 
