桌面应用图形学【免费下载链接】fontforgeFree (libre) font editor for Windows, Mac OS X and GNULinux项目地址https://gitcode.com/gh_mirrors/fo/fontforge点击查看免费下载本文对应 FontForge 官方教程中的 Special thoughts for special scriptsscriptnotes.rst一章是面向字体设计师与 OpenType 排印开发者的实战指南。文章聚焦于当一款字体需要同时支持 Latin、Greek、Cyrillic、Arabic、Hebrew、Indic、Hangul 乃至 CJK 等不同文字系统时如何在 FontForge 中正确规划 GSUB/GPOS 特性连字、换形、字距、锚点定位理解文本布局引擎Uniscribe、HarfBuzz的真实行为边界并规避因 GPOS/GSUB 表缺失导致字体被拒用的风险。读完本文你将能针对每种脚本给出该做什么、不该做什么的排印特性清单并知道在 FontForge 的 Lookup/Feature 体系中如何落地。背景为什么特殊脚本需要特殊思考现代字体的排印效果并不由字体文件单独决定而是由文本布局引擎shaping engine在读取字体中的 OpenType 表GSUB 字形替换、GPOS 字形定位后实时计算出来的。Windows 平台历史上使用 Uniscribe现代跨平台方案则普遍采用 HarfBuzz——FontForge 当前源码中同时维护了基于 HarfBuzz 的 shaper 与内置的简易 shaper见 fontforge/shapers/其中 harfbuzz.cpp 为 HarfBuzz 路径builtin.cpp 为内置路径。微软在其 OpenType 规范文档中提供了一份文字处理器应对特定脚本默认支持哪些特性的建议清单。这份清单很有参考价值但绝不能照单全收原因有三条原文以醒目的警告warning形式给出是理解整篇文档的前提警告一文档化的特性引擎未必真的启用一个特性被写入规范、看起来也很有用并不代表 Uniscribe 会为你的脚本真正启用它。最典型的例子许多 Latin 字体很想使用init首字母形式、medi中间形式、calt上下文替换等特性但 Uniscribe 对 Latin 脚本一个都不会打开。也就是说为 Latin 字体费心做了calt替换规则在 Uniscribe 环境中可能完全是空转。警告二引擎支持不代表应用会用即使 Uniscribe 本身支持某个特性也不代表某个具体应用程序会使用它。文档给出的例子是截至 2005 年Uniscribe 已支持 Latin 的liga标准连字但 Word 与 Office 仍然不处理liga。这条提醒在今天依然成立——引擎能力与应用策略是两层判断字体效果时必须以目标应用的真实行为为准。警告三GPOS/GSUB 缺一字体可能被整个拒用Uniscribe 可能根据脚本决定忽略 GPOS 或 GSUB 中的某一张表甚至在表内容不完整时拒绝使用整个字体Hebrew 字体必须同时包含 GPOS 与 GSUB缺任一表字体就不被使用Latin 字体可以两者皆无但若只有 GPOS 而没有 GSUB则 GPOS 也不会被使用GSUB 缺失会连累 GPOS 失效。针对这一现实文档明确指出FontForge 在生成字体时如果检测到 GPOS 与 GSUB 只有其一会自动为缺失的那一张生成一个 dummy占位版本从而避免字体被引擎整体拒用。这是 FontForge 主动为引擎兼容性兜底的一个关键行为字体设计师应了解其存在但不应对占位表抱有任何功能期待。Common 脚本与 DFLT 回退数字、标点究竟归属于谁在 Unicode 体系中数字、标点等字符被归入一个特殊的 Common公共脚本——它们不属于任何特定文字系统。而 OpenType 规范并没有 Common 这个概念它最接近的对应物是DFLTdefault默认脚本脚本标签。OpenType 的处理逻辑是Common 脚本中的字符会被引擎指派为相邻文本的脚本。由此引出两个非常实际的后果特性必须跨脚本复制。如果一款字体同时支持 Latin、Greek、Cyrillic那么数字与标点可能被引擎随机指派到这三个脚本中的任何一个。例如9与1之间的字距kerning如果只做在 Latin 脚本下当这串数字出现在 Cyrillic 上下文中时字距规则就不会生效。文档的建议是凡是可能作用于数字、标点的特性尤其是字距Latin、Greek、Cyrillic 三个脚本都要带上。混排场景可能让特性彻底失效。日本排版中常见一种做法正文汉字用甲字体而数字用乙字体的数字字形。此时这些数字虽然来自乙字体却会被引擎指派为相邻汉字的Kanjikana脚本——而乙字体并不支持 Kanji 脚本于是没有任何 lookup 会被应用数字的字距、定位规则全部落空。针对这类问题Adobe 的建议是大多数特性除了在各具体脚本中出现还应同时出现在回退脚本DFLT中。文档作者坦承并不确定其他厂商是否遵循了这一约定——但至少对追求稳妥兼容性的设计师而言把通用特性放进DFLT是一个值得考虑的策略。FontForge 中 DFLT 的落地方式DFLT在 FontForge 的体系里是一等公民从三个层面可以确认SFD 文件层面每个 Lookup 都显式携带脚本与语言列表。以 sfdformat.rst 中的真实格式为例一条同时绑定DFLT与latnLatin的caltlookup 在 .sfd 中长这样Lookup: 6 0 0 calt {calt-1 } [calt (DFLT dflt latn dflt ) ]其中括号内依次为特性标签、脚本标签DFLT、latn、以及尖括号中的语言标签dflt。这正是同一特性挂多个脚本的物理载体。UI 层面FontInfo字体信息对话框中提供Add DFLT script选项其作用是把DFLT脚本添加到所有被选中的 lookup 上见 fontinfo.rst。字体设计师不必手改 .sfd即可一键为全部 lookup 补上回退脚本。代码层面在 lookups.c 中脚本/语言列表处理逻辑专门针对默认脚本做了分支——DefaultLangTagInScriptList()函数接收一个DFLT_ok参数仅在允许时才把DFLT纳入默认语言判定说明源码层面确实将DFLT视为一个需要特殊对待的脚本标签。Latinf 连字、mark-to-base 与小型大写Latin 的排印复杂度在众多脚本中属于较低的一档文档给出的要点如下编码简单Latin 字体通常用单字节编码即可容纳所需字体表极少。变音字形accented glyphs存在大量可预先构建的带音调字形也可以不走穷举组合字形路线而是用mark-to-base 定位让引擎把音调符锚到基字上构建组合字形的完整操作见 editexample4.rst。字距应当为若干字形组合生成 kerning生成与检查方法见 editexample5.rst。连字需要构建少量经典连字即 f 系列ff、fi、fl、ffi、ffl也许还有st。但要注意语言例外——例如土耳其语中不应构建 fi 连字fi 中的 i 带点与 f 相连会造成错误词形。小型大写Small Caps可以作为一个可选功能加入。历史上 Adobe 曾在私用区PUA预留拉丁小型大写的编码块文档明确指出这一做法如今已被弃用deprecated不应再依赖 PUA 编码方案。特定语言要求个别语言有自身特有的排印约定文档以波兰语为例涉及 ogonek/交叉线等字形细节。源码佐证FontForge 的 Small Caps 实现FontForge 内置了完整的小型大写生成管线不是停留在建议层面特性注册lookups.c中登记了smcp特性其名称正是Lowercase to Small Capitals类型为 GSUB 单替换gsub_single_mask生成算法scstyles.c 中SmallCapsFindConstants()负责分析字体的度量常量MakeSmallCapGlyphSlot()为每个大写字形生成对应的小型大写槽位FVAddSmallCaps()则是字体视图层入口——它会同时创建c2sc大写转小型大写与smcp小写转小型大写两条 lookup 链。也就是说设计师在 FontForge 中做小型大写实际是在驱动一套度量分析 字形缩放 lookup 装配的完整流程而非手动逐字造形。Greek现代希腊语与 polytonic 的差异希腊脚本同样不算复杂但现代希腊语与 polytonic带多重音调的古典希腊语的工作量差异巨大现代希腊语通常单字节编码即可容纳只需构建少量带音调字形polytonic 希腊语需要构建大量带音调字形此时 mark-to-base 与mark-to-mark音调符相互定位都是可选方案字距应当生成 kerning连字现代希腊语没有公认的标准连字古典希腊语在部分字形上曾存在连字与变体形式小型大写同样是可选项文档再次提醒——私用区预留方案已弃用。Cyrillic变体字形与 loca 特性Cyrillic 的基线要求与 Latin/Greek 相似单字节编码可容纳少量带音调字形应当生成 kerning没有公认的标准连字。但它有一个特有需求部分语言需要变体字形variant glyphs通过localocalized forms本地化形式特性指定。文档点名的实例是塞尔维亚语 / 马其顿语的 Cyrillic 字形——它们在意大利体与手写体中有一套与标准俄语字形不同的本地化形态必须依赖loca才能在正确语言环境下切换。Arabic四态换形、庞大连字集与元音定位Arabic 是文档中强调的重点脚本之一核心需求可以归纳为五点四态形式需要完整的 initial首、medial中、final尾、isolated独立四套形式——Unicode 已为这些形式预留了编码空间设计者应按 Unicode 预留位组织字形庞大连字集需要大量连字Unicode 已预留不少经典连字的码位但作者判断实际排印中时常还需要额外连字元音定位需要 mark-to-base 与mark-to-ligature音标对连字的锚定两类定位规则把元音符号安置在字母上方字形分解可能需要 glyph decomposition table字形分解表书写方向从右到左RTL。作者还转述了一个来自优秀阿拉伯排印实践的观察高质量阿拉伯字体每个字形往往需要远超 4 种形式涉及上下文更细致的笔画变化但作者明确表示不确定这类需求应如何用 OpenType 机制支持——这是一个留待设计师与引擎共同探索的开放问题而不是既有特性就能覆盖的确定结论。源码佐证组合字形时的自动换形FontForge 在生成复合字形composite时确实会处理阿拉伯四态换形。fvcomposite.c 中的arabicfixup()函数会在组合过程中把普通字符自动替换为对应的 initial / medial / final 形式内部通过isarabisolated()、isarabinitial()、isarabfinal()等判定与arabicform()映射实现。这说明阿拉伯四态在 FontForge 的建模与生成管线中是被显式支持的第一类对象而不只是 OpenType 规范里的抽象概念。Hebrewfinal 形式、元音定位与双表硬约束Hebrew 的需求清单相对克制final 形式只有少量词尾变体final forms且不需要特殊表来支持相比 Arabic 的完整四态换形要轻量得多字距可能需要 kerning元音定位应当有一套 mark-to-base 表把元音符号定位到字母上方注音点/元音点的安置是希伯来排印的核心需求字形分解可能需要 glyph decomposition table连字作者未发现必需的标准连字方向从右到左RTL。必须再次强调警告三的硬约束Hebrew 字体必须同时具备 GPOS 与 GSUB否则字体可能被 Uniscribe 整体拒绝使用——这是希伯来字体设计中最不容忽视的合规底线。Indic 脚本以连字为核心的排印文档对 Indic印度系脚本的描述相对简短Indic 脚本需要一组连字。作者坦诚地补充它们大概还需要更多东西但我不清楚具体是什么。——Indic 脚本如 Devanagari、Bengali、Tamil 等涉及复杂的辅音叠写conjuncts机制其完整排印需求远超一句连字清单所能概括。对有兴趣深入的设计师这正是一个需要以目标语言为基准、结合引擎实测来补全特性的领域。Korean Hangul音节组合爆炸与 CID-keyed 字体Hangul韩文字母是一种音素字母系统音节由辅音、元音字母组合而成。绝大多数字体采用预组合音节precomposed syllables的形式来覆盖全部音节。Hangul 的特殊性来自其音节组合的爆炸性数量字母有限但组合出的音节极多。文档指出这一困难在 PostScript 体系中由CID-keyed 字体按字符 ID 索引的字库来缓解——CID 机制允许用统一的索引管理海量字形而不是依赖一字节一码的简单映射。此外 Hangul 与 CJK 共有一个方向性特征竖排垂直书写与横排水平书写并用且部分字形在竖排时方向会变化最典型的例子是括号竖排时需要旋转 90° 呈现不同朝向。这意味着设计者需要为这类方向敏感字形额外准备竖排变体。日文与中文含韩文 Hanja海量字形与竖排变体文档特别指出微软的规范描述中并未覆盖这些脚本Japanese / Chinese / Korean Hanja 属于 CJK 体系其排印规范主要由 Adobe/Apple 等另一套机制约束而非 Uniscribe 的脚本级特性清单。CJK 的挑战与 Hangul 相似但规模更大海量字形集合需要庞大的字形库PostScript 体系中同样依赖CID-keyed 字体来组织书写方向竖排与横排并用括号等字形在竖排时有不同朝向需要额外的方向变体。从源码侧可以补充一个佐证FontForge 的语言识别/频率统计模块 langfreq.c 中内置了包括 Katakana 在内的多语言词频表说明 FontForge 在文本语言检测层面对日语等 CJK 文本是有原生支持的——这服务于自动判定文本所属语言、进而选择正确脚本/语言 lookup 的场景。在 FontForge 中落地一份按脚本的检查清单把全文要点压缩成可执行清单供在 FontForge 中设计多脚本字体时逐项核对脚本必须项可选项 / 注意项特别警示Common数字/标点数字、标点相关的字距等特性在 Latin/Greek/Cyrillic 全部出现按 Adobe 建议同时放入DFLT回退脚本混排时字符会被指派给相邻脚本lookup 可能落空Latinf 系列连字ff/fi/fl/ffi/ffl可加 st部分组合的字距变音字形或 mark-to-base小型大写smcp/c2sc土耳其语不要构建 fiinit/medi/calt对 Latin 在 Uniscribe 下不生效PUA 小型大写方案已弃用Greek变音字形字距polytonic 需大量字形可用 mark-to-base 与 mark-to-mark小型大写PUA 方案已弃用Cyrillic变音字形字距塞尔维亚/马其顿变体用loca特性无标准连字Arabic四态形式init/medi/fini/isol大量连字mark-to-base 与 mark-to-ligature 元音定位RTLglyph decomposition table超四态的高质量排印仍是开放问题字形数量远超想象Hebrew同时具备 GPOS 与 GSUBmark-to-base 元音定位RTL少量 final 形式无需特殊表kerningglyph decomposition table缺任一表字体可能被 Uniscribe 拒用Indic一组连字文档承认了解有限需结合目标语言实测—Hangul预组合音节海量字形CID-keyed 字体组织字形竖排变体如括号旋转—CJK日/中/韩 Hanja海量字形CID-keyed 字体竖排变体如括号旋转微软规范未覆盖勿依赖 Uniscribe 脚本清单具体操作层面为 lookup 补DFLT回退在 FontInfo 对话框中选中目标 lookup使用Add DFLT scriptfontinfo.rst核对 SFD 中的脚本/语言列表确认每条Lookup:行都写清了(DFLT dflt latn dflt )式的脚本-语言对格式见 sfdformat.rst构建变音字形与连字跟随 editexample4.rst 完成组合字形与连字的逐项搭建处理度量与字距按 editexample5.rst 检查 metrics 并生成 kerning处理变体字形与锚点mark变体与 mark 锚定规则在 editexample6.rst 中有完整演练该章同样覆盖多脚本包括DFLT的场景最后检查并生成用 editexample7.rst 的流程做字体检查与输出并记得 FontForge 会在 GPOS/GSUB 缺一时自动生成 dummy 补全最终产物的表完整性可在生成后通过工具复核。总而言之特殊脚本之所以特殊是因为每一类文字系统的排印都建立在引擎行为、应用行为、字体表三者叠加之上规范写了不等于引擎会用引擎支持不等于应用会用表不完整甚至可能让字体被拒用。以本文的脚本级清单为纲、以 FontForge 的 lookup/feature 体系为器配合引擎与真实应用的双重实测才能交付在每类脚本下都可预期的排印质量。赞分享桌面应用图形学【免费下载链接】fontforgeFree (libre) font editor for Windows, Mac OS X and GNULinux项目地址https://gitcode.com/gh_mirrors/fo/fontforge点击查看免费下载相关推荐Inter 字体 OpenType 特性体系解析src/features 目录的组织机制与实战要点Inter 字体 OpenType 特性体系解析src/features 目录的组织机制与实战要点 导读 本文以 src/features/README.md设计系统Comp AI CRM 前端排版指南变量字体与 OpenType 特性实战variable-fonts-and-opentypeComp AI CRM 前端排版指南变量字体与 OpenType 特性实战variable fonts and opentype 本文是 Comp AI后端前端CRM人工智能AI AgentFontForge阿拉伯字体设计从右到左文字排版技巧FontForge阿拉伯字体设计从右到左文字排版技巧 你还在为阿拉伯字体的连笔处理和从右到左排版烦恼吗本文将带你掌握FontForge中阿拉伯字体设计的核心桌面应用图形学上一篇sherpa-onnx Supertonic 3 TTS 模型 INT8 量化全流程指南从校准数据到 on-device 部署下一篇Unity MCP 结构化脚本编辑指南使用 script_apply_edits 安全地增删改 C 方法创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
桌面应用图形学【免费下载链接】fontforgeFree (libre) font editor for Windows, Mac OS X and GNULinux项目地址https://gitcode.com/gh_mirrors/fo/fontforge点击查看免费下载本文对应 FontForge 官方教程中的 Special thoughts for special scriptsscriptnotes.rst一章是面向字体设计师与 OpenType 排印开发者的实战指南。文章聚焦于当一款字体需要同时支持 Latin、Greek、Cyrillic、Arabic、Hebrew、Indic、Hangul 乃至 CJK 等不同文字系统时如何在 FontForge 中正确规划 GSUB/GPOS 特性连字、换形、字距、锚点定位理解文本布局引擎Uniscribe、HarfBuzz的真实行为边界并规避因 GPOS/GSUB 表缺失导致字体被拒用的风险。读完本文你将能针对每种脚本给出该做什么、不该做什么的排印特性清单并知道在 FontForge 的 Lookup/Feature 体系中如何落地。背景为什么特殊脚本需要特殊思考现代字体的排印效果并不由字体文件单独决定而是由文本布局引擎shaping engine在读取字体中的 OpenType 表GSUB 字形替换、GPOS 字形定位后实时计算出来的。Windows 平台历史上使用 Uniscribe现代跨平台方案则普遍采用 HarfBuzz——FontForge 当前源码中同时维护了基于 HarfBuzz 的 shaper 与内置的简易 shaper见 fontforge/shapers/其中 harfbuzz.cpp 为 HarfBuzz 路径builtin.cpp 为内置路径。微软在其 OpenType 规范文档中提供了一份文字处理器应对特定脚本默认支持哪些特性的建议清单。这份清单很有参考价值但绝不能照单全收原因有三条原文以醒目的警告warning形式给出是理解整篇文档的前提警告一文档化的特性引擎未必真的启用一个特性被写入规范、看起来也很有用并不代表 Uniscribe 会为你的脚本真正启用它。最典型的例子许多 Latin 字体很想使用init首字母形式、medi中间形式、calt上下文替换等特性但 Uniscribe 对 Latin 脚本一个都不会打开。也就是说为 Latin 字体费心做了calt替换规则在 Uniscribe 环境中可能完全是空转。警告二引擎支持不代表应用会用即使 Uniscribe 本身支持某个特性也不代表某个具体应用程序会使用它。文档给出的例子是截至 2005 年Uniscribe 已支持 Latin 的liga标准连字但 Word 与 Office 仍然不处理liga。这条提醒在今天依然成立——引擎能力与应用策略是两层判断字体效果时必须以目标应用的真实行为为准。警告三GPOS/GSUB 缺一字体可能被整个拒用Uniscribe 可能根据脚本决定忽略 GPOS 或 GSUB 中的某一张表甚至在表内容不完整时拒绝使用整个字体Hebrew 字体必须同时包含 GPOS 与 GSUB缺任一表字体就不被使用Latin 字体可以两者皆无但若只有 GPOS 而没有 GSUB则 GPOS 也不会被使用GSUB 缺失会连累 GPOS 失效。针对这一现实文档明确指出FontForge 在生成字体时如果检测到 GPOS 与 GSUB 只有其一会自动为缺失的那一张生成一个 dummy占位版本从而避免字体被引擎整体拒用。这是 FontForge 主动为引擎兼容性兜底的一个关键行为字体设计师应了解其存在但不应对占位表抱有任何功能期待。Common 脚本与 DFLT 回退数字、标点究竟归属于谁在 Unicode 体系中数字、标点等字符被归入一个特殊的 Common公共脚本——它们不属于任何特定文字系统。而 OpenType 规范并没有 Common 这个概念它最接近的对应物是DFLTdefault默认脚本脚本标签。OpenType 的处理逻辑是Common 脚本中的字符会被引擎指派为相邻文本的脚本。由此引出两个非常实际的后果特性必须跨脚本复制。如果一款字体同时支持 Latin、Greek、Cyrillic那么数字与标点可能被引擎随机指派到这三个脚本中的任何一个。例如9与1之间的字距kerning如果只做在 Latin 脚本下当这串数字出现在 Cyrillic 上下文中时字距规则就不会生效。文档的建议是凡是可能作用于数字、标点的特性尤其是字距Latin、Greek、Cyrillic 三个脚本都要带上。混排场景可能让特性彻底失效。日本排版中常见一种做法正文汉字用甲字体而数字用乙字体的数字字形。此时这些数字虽然来自乙字体却会被引擎指派为相邻汉字的Kanjikana脚本——而乙字体并不支持 Kanji 脚本于是没有任何 lookup 会被应用数字的字距、定位规则全部落空。针对这类问题Adobe 的建议是大多数特性除了在各具体脚本中出现还应同时出现在回退脚本DFLT中。文档作者坦承并不确定其他厂商是否遵循了这一约定——但至少对追求稳妥兼容性的设计师而言把通用特性放进DFLT是一个值得考虑的策略。FontForge 中 DFLT 的落地方式DFLT在 FontForge 的体系里是一等公民从三个层面可以确认SFD 文件层面每个 Lookup 都显式携带脚本与语言列表。以 sfdformat.rst 中的真实格式为例一条同时绑定DFLT与latnLatin的caltlookup 在 .sfd 中长这样Lookup: 6 0 0 calt {calt-1 } [calt (DFLT dflt latn dflt ) ]其中括号内依次为特性标签、脚本标签DFLT、latn、以及尖括号中的语言标签dflt。这正是同一特性挂多个脚本的物理载体。UI 层面FontInfo字体信息对话框中提供Add DFLT script选项其作用是把DFLT脚本添加到所有被选中的 lookup 上见 fontinfo.rst。字体设计师不必手改 .sfd即可一键为全部 lookup 补上回退脚本。代码层面在 lookups.c 中脚本/语言列表处理逻辑专门针对默认脚本做了分支——DefaultLangTagInScriptList()函数接收一个DFLT_ok参数仅在允许时才把DFLT纳入默认语言判定说明源码层面确实将DFLT视为一个需要特殊对待的脚本标签。Latinf 连字、mark-to-base 与小型大写Latin 的排印复杂度在众多脚本中属于较低的一档文档给出的要点如下编码简单Latin 字体通常用单字节编码即可容纳所需字体表极少。变音字形accented glyphs存在大量可预先构建的带音调字形也可以不走穷举组合字形路线而是用mark-to-base 定位让引擎把音调符锚到基字上构建组合字形的完整操作见 editexample4.rst。字距应当为若干字形组合生成 kerning生成与检查方法见 editexample5.rst。连字需要构建少量经典连字即 f 系列ff、fi、fl、ffi、ffl也许还有st。但要注意语言例外——例如土耳其语中不应构建 fi 连字fi 中的 i 带点与 f 相连会造成错误词形。小型大写Small Caps可以作为一个可选功能加入。历史上 Adobe 曾在私用区PUA预留拉丁小型大写的编码块文档明确指出这一做法如今已被弃用deprecated不应再依赖 PUA 编码方案。特定语言要求个别语言有自身特有的排印约定文档以波兰语为例涉及 ogonek/交叉线等字形细节。源码佐证FontForge 的 Small Caps 实现FontForge 内置了完整的小型大写生成管线不是停留在建议层面特性注册lookups.c中登记了smcp特性其名称正是Lowercase to Small Capitals类型为 GSUB 单替换gsub_single_mask生成算法scstyles.c 中SmallCapsFindConstants()负责分析字体的度量常量MakeSmallCapGlyphSlot()为每个大写字形生成对应的小型大写槽位FVAddSmallCaps()则是字体视图层入口——它会同时创建c2sc大写转小型大写与smcp小写转小型大写两条 lookup 链。也就是说设计师在 FontForge 中做小型大写实际是在驱动一套度量分析 字形缩放 lookup 装配的完整流程而非手动逐字造形。Greek现代希腊语与 polytonic 的差异希腊脚本同样不算复杂但现代希腊语与 polytonic带多重音调的古典希腊语的工作量差异巨大现代希腊语通常单字节编码即可容纳只需构建少量带音调字形polytonic 希腊语需要构建大量带音调字形此时 mark-to-base 与mark-to-mark音调符相互定位都是可选方案字距应当生成 kerning连字现代希腊语没有公认的标准连字古典希腊语在部分字形上曾存在连字与变体形式小型大写同样是可选项文档再次提醒——私用区预留方案已弃用。Cyrillic变体字形与 loca 特性Cyrillic 的基线要求与 Latin/Greek 相似单字节编码可容纳少量带音调字形应当生成 kerning没有公认的标准连字。但它有一个特有需求部分语言需要变体字形variant glyphs通过localocalized forms本地化形式特性指定。文档点名的实例是塞尔维亚语 / 马其顿语的 Cyrillic 字形——它们在意大利体与手写体中有一套与标准俄语字形不同的本地化形态必须依赖loca才能在正确语言环境下切换。Arabic四态换形、庞大连字集与元音定位Arabic 是文档中强调的重点脚本之一核心需求可以归纳为五点四态形式需要完整的 initial首、medial中、final尾、isolated独立四套形式——Unicode 已为这些形式预留了编码空间设计者应按 Unicode 预留位组织字形庞大连字集需要大量连字Unicode 已预留不少经典连字的码位但作者判断实际排印中时常还需要额外连字元音定位需要 mark-to-base 与mark-to-ligature音标对连字的锚定两类定位规则把元音符号安置在字母上方字形分解可能需要 glyph decomposition table字形分解表书写方向从右到左RTL。作者还转述了一个来自优秀阿拉伯排印实践的观察高质量阿拉伯字体每个字形往往需要远超 4 种形式涉及上下文更细致的笔画变化但作者明确表示不确定这类需求应如何用 OpenType 机制支持——这是一个留待设计师与引擎共同探索的开放问题而不是既有特性就能覆盖的确定结论。源码佐证组合字形时的自动换形FontForge 在生成复合字形composite时确实会处理阿拉伯四态换形。fvcomposite.c 中的arabicfixup()函数会在组合过程中把普通字符自动替换为对应的 initial / medial / final 形式内部通过isarabisolated()、isarabinitial()、isarabfinal()等判定与arabicform()映射实现。这说明阿拉伯四态在 FontForge 的建模与生成管线中是被显式支持的第一类对象而不只是 OpenType 规范里的抽象概念。Hebrewfinal 形式、元音定位与双表硬约束Hebrew 的需求清单相对克制final 形式只有少量词尾变体final forms且不需要特殊表来支持相比 Arabic 的完整四态换形要轻量得多字距可能需要 kerning元音定位应当有一套 mark-to-base 表把元音符号定位到字母上方注音点/元音点的安置是希伯来排印的核心需求字形分解可能需要 glyph decomposition table连字作者未发现必需的标准连字方向从右到左RTL。必须再次强调警告三的硬约束Hebrew 字体必须同时具备 GPOS 与 GSUB否则字体可能被 Uniscribe 整体拒绝使用——这是希伯来字体设计中最不容忽视的合规底线。Indic 脚本以连字为核心的排印文档对 Indic印度系脚本的描述相对简短Indic 脚本需要一组连字。作者坦诚地补充它们大概还需要更多东西但我不清楚具体是什么。——Indic 脚本如 Devanagari、Bengali、Tamil 等涉及复杂的辅音叠写conjuncts机制其完整排印需求远超一句连字清单所能概括。对有兴趣深入的设计师这正是一个需要以目标语言为基准、结合引擎实测来补全特性的领域。Korean Hangul音节组合爆炸与 CID-keyed 字体Hangul韩文字母是一种音素字母系统音节由辅音、元音字母组合而成。绝大多数字体采用预组合音节precomposed syllables的形式来覆盖全部音节。Hangul 的特殊性来自其音节组合的爆炸性数量字母有限但组合出的音节极多。文档指出这一困难在 PostScript 体系中由CID-keyed 字体按字符 ID 索引的字库来缓解——CID 机制允许用统一的索引管理海量字形而不是依赖一字节一码的简单映射。此外 Hangul 与 CJK 共有一个方向性特征竖排垂直书写与横排水平书写并用且部分字形在竖排时方向会变化最典型的例子是括号竖排时需要旋转 90° 呈现不同朝向。这意味着设计者需要为这类方向敏感字形额外准备竖排变体。日文与中文含韩文 Hanja海量字形与竖排变体文档特别指出微软的规范描述中并未覆盖这些脚本Japanese / Chinese / Korean Hanja 属于 CJK 体系其排印规范主要由 Adobe/Apple 等另一套机制约束而非 Uniscribe 的脚本级特性清单。CJK 的挑战与 Hangul 相似但规模更大海量字形集合需要庞大的字形库PostScript 体系中同样依赖CID-keyed 字体来组织书写方向竖排与横排并用括号等字形在竖排时有不同朝向需要额外的方向变体。从源码侧可以补充一个佐证FontForge 的语言识别/频率统计模块 langfreq.c 中内置了包括 Katakana 在内的多语言词频表说明 FontForge 在文本语言检测层面对日语等 CJK 文本是有原生支持的——这服务于自动判定文本所属语言、进而选择正确脚本/语言 lookup 的场景。在 FontForge 中落地一份按脚本的检查清单把全文要点压缩成可执行清单供在 FontForge 中设计多脚本字体时逐项核对脚本必须项可选项 / 注意项特别警示Common数字/标点数字、标点相关的字距等特性在 Latin/Greek/Cyrillic 全部出现按 Adobe 建议同时放入DFLT回退脚本混排时字符会被指派给相邻脚本lookup 可能落空Latinf 系列连字ff/fi/fl/ffi/ffl可加 st部分组合的字距变音字形或 mark-to-base小型大写smcp/c2sc土耳其语不要构建 fiinit/medi/calt对 Latin 在 Uniscribe 下不生效PUA 小型大写方案已弃用Greek变音字形字距polytonic 需大量字形可用 mark-to-base 与 mark-to-mark小型大写PUA 方案已弃用Cyrillic变音字形字距塞尔维亚/马其顿变体用loca特性无标准连字Arabic四态形式init/medi/fini/isol大量连字mark-to-base 与 mark-to-ligature 元音定位RTLglyph decomposition table超四态的高质量排印仍是开放问题字形数量远超想象Hebrew同时具备 GPOS 与 GSUBmark-to-base 元音定位RTL少量 final 形式无需特殊表kerningglyph decomposition table缺任一表字体可能被 Uniscribe 拒用Indic一组连字文档承认了解有限需结合目标语言实测—Hangul预组合音节海量字形CID-keyed 字体组织字形竖排变体如括号旋转—CJK日/中/韩 Hanja海量字形CID-keyed 字体竖排变体如括号旋转微软规范未覆盖勿依赖 Uniscribe 脚本清单具体操作层面为 lookup 补DFLT回退在 FontInfo 对话框中选中目标 lookup使用Add DFLT scriptfontinfo.rst核对 SFD 中的脚本/语言列表确认每条Lookup:行都写清了(DFLT dflt latn dflt )式的脚本-语言对格式见 sfdformat.rst构建变音字形与连字跟随 editexample4.rst 完成组合字形与连字的逐项搭建处理度量与字距按 editexample5.rst 检查 metrics 并生成 kerning处理变体字形与锚点mark变体与 mark 锚定规则在 editexample6.rst 中有完整演练该章同样覆盖多脚本包括DFLT的场景最后检查并生成用 editexample7.rst 的流程做字体检查与输出并记得 FontForge 会在 GPOS/GSUB 缺一时自动生成 dummy 补全最终产物的表完整性可在生成后通过工具复核。总而言之特殊脚本之所以特殊是因为每一类文字系统的排印都建立在引擎行为、应用行为、字体表三者叠加之上规范写了不等于引擎会用引擎支持不等于应用会用表不完整甚至可能让字体被拒用。以本文的脚本级清单为纲、以 FontForge 的 lookup/feature 体系为器配合引擎与真实应用的双重实测才能交付在每类脚本下都可预期的排印质量。赞分享桌面应用图形学【免费下载链接】fontforgeFree (libre) font editor for Windows, Mac OS X and GNULinux项目地址https://gitcode.com/gh_mirrors/fo/fontforge点击查看免费下载相关推荐Inter 字体 OpenType 特性体系解析src/features 目录的组织机制与实战要点Inter 字体 OpenType 特性体系解析src/features 目录的组织机制与实战要点 导读 本文以 src/features/README.md设计系统Comp AI CRM 前端排版指南变量字体与 OpenType 特性实战variable-fonts-and-opentypeComp AI CRM 前端排版指南变量字体与 OpenType 特性实战variable fonts and opentype 本文是 Comp AI后端前端CRM人工智能AI AgentFontForge阿拉伯字体设计从右到左文字排版技巧FontForge阿拉伯字体设计从右到左文字排版技巧 你还在为阿拉伯字体的连笔处理和从右到左排版烦恼吗本文将带你掌握FontForge中阿拉伯字体设计的核心桌面应用图形学上一篇sherpa-onnx Supertonic 3 TTS 模型 INT8 量化全流程指南从校准数据到 on-device 部署下一篇Unity MCP 结构化脚本编辑指南使用 script_apply_edits 安全地增删改 C 方法创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
