OpenType.js 字体文件导出问题分析与修复

在字体开发领域，OpenType.js 是一个广泛使用的 JavaScript 库，它允许开发者在浏览器环境中解析和生成 OpenType 字体文件。最近，该项目在更新过程中出现了一个关键性问题：使用最新代码生成的字体文件在 Windows 系统上无法被识别为有效字体文件。

问题现象

当开发者尝试使用 OpenType.js 最新提交版本（2023年7月30日）创建并导出字体文件时，生成的 OTF 文件在 Windows 系统上会显示"不是有效的字体文件"错误。相比之下，使用稳定版本 1.3.4 导出的字体文件则能正常工作。

问题溯源

通过逐步回退版本测试，发现问题最早出现在 2023年2月4日的提交中。具体表现为：

1. 提交 c331cca 能正常导出有效字体
2. 后续提交 4c06e44 完全无法导出字体
3. 之后的提交 858a5d2 虽然修复了导出功能，但生成的字体文件在 Windows 上无效

技术分析

通过 TTX 工具对比有效和无效的字体文件，发现关键差异在于 name 表中的 namerecord 条目。有效字体包含以下关键条目：

<namerecord nameID="3" platformID="1" platEncID="0" langID="0x0" unicode="True">
<namerecord nameID="3" platformID="3" platEncID="1" langID="0x409">

其中 nameID 3 表示"唯一字体标识符"，这是字体识别的重要元数据。platformID 1 对应 Macintosh 平台，3 对应 Windows 平台。platEncID 和 langID 则分别指定编码和语言区域。

问题代码位于处理字体名称的函数中，存在两个关键错误：

1. 使用了错误的循环方式，导致遍历的是数组索引而非平台名称
2. 错误地将所有平台的缺失值都更新到 unicode 平台，而非各自对应的平台

解决方案

修复后的代码应改为：

for (const platform in names) {
  names[platform] = names[platform] || {};
  if (!names[platform].uniqueID) {
    names[platform].uniqueID = { en: font.getEnglishName("manufacturer") + ":" + englishFullName };
  }
  if (!names[platform].postScriptName) {
    names[platform].postScriptName = { en: postScriptName };
  }
}

这一修改确保：

1. 正确遍历所有平台（unicode、macintosh、windows）
2. 为每个平台单独设置 uniqueID 和 postScriptName
3. 保持各平台名称记录的一致性

技术背景

在 OpenType 字体规范中，name 表是存储字体元数据的关键结构。它包含多个名称记录，每个记录由以下属性标识：

• nameID：名称标识符，如字体家族名(1)、子家族名(2)、唯一ID(3)等
• platformID：平台标识，0=Unicode，1=Macintosh，3=Windows
• platEncID：平台特定编码标识
• langID：语言标识

Windows 系统特别依赖 platformID=3 的名称记录来识别字体。缺少这些记录会导致系统无法正确解析字体文件。

总结

这个案例展示了字体文件中元数据完整性的重要性。即使是看似微小的名称表记录缺失，也可能导致整个字体文件无法使用。对于字体工具开发者而言，必须严格遵循 OpenType 规范，确保所有必需的表和记录都被正确生成。OpenType.js 的这次修复确保了生成的字体文件在各平台上的兼容性，为开发者提供了更可靠的字体处理能力。