HarfBuzz项目中的GeezaPro字体在macOS 15上的排版差异分析

在HarfBuzz项目中，开发者发现了一个关于GeezaPro字体在macOS 15系统上排版结果出现显著差异的问题。这个问题最初是在将HarfBuzz测试用例同步到Rustybuzz时被发现的，测试结果显示HarfBuzz和CoreText引擎的输出结果不一致。

问题现象

当使用GeezaPro.ttc字体处理阿拉伯文字符序列时，HarfBuzz在macOS 15上产生了与之前版本不同的输出结果。例如，处理Unicode字符U+0628和U+064F时：

• HarfBuzz输出：[883=0+0|1558=0+1415]
• CoreText输出：[883=0@250,-250+-250|242=0@250,0+1665]

这种差异不仅限于简单的字符组合，在更复杂的阿拉伯文本排版中也出现了明显不同。

问题根源

经过深入分析，发现问题出在HarfBuzz对AAT(MORX)表格的处理上。具体来说：

1. GeezaPro字体包含一个MORX表格（苹果高级排版表），但没有GSUB表格（OpenType替换表）
2. 在macOS 15上，HarfBuzz的MORX表格解析器拒绝了一个格式为LookupFormat0的子表
3. 拒绝原因是字体报告有1705个字形，但子表只包含1704个值
4. 这导致HarfBuzz回退到基本的阿拉伯语排版逻辑，而非使用字体内置的高级排版功能

技术细节

MORX表格是苹果的AAT(Apple Advanced Typography)技术的一部分，用于复杂的字形替换和定位。HarfBuzz实现了一个严格的表格解析器，会验证每个子表的结构完整性。

在GeezaPro字体中，存在一个LookupFormat0子表，它应该为字体中的每个字形提供一个值。然而，字体声称有1705个字形，但这个子表只有1704个条目，导致HarfBuzz的sanitizer（数据验证器）拒绝了这个子表。

解决方案

HarfBuzz团队提出了两种解决方案：

1. 临时方案：移除sanitizer对子表长度的严格检查，只验证不超过整个表格边界
2. 理想方案：将子表长度信息传播到LookupTable，限制其只处理有效范围内的字形

考虑到实现复杂性，团队首先采用了第一种方案，通过PR#4874修复了这个问题，并发布了10.0.1微版本。

对开发者的启示

1. 字体引擎需要处理各种质量不一的字体文件，严格的验证可能导致兼容性问题
2. 不同平台上的字体版本更新可能引入微妙的排版差异
3. 在跨平台文本渲染项目中，需要特别注意字体引擎与系统原生引擎的差异
4. 对于复杂的排版表（如AAT/MORX），需要在严格验证和实际兼容性之间找到平衡

这个问题也展示了开源字体引擎开发中的挑战：需要在遵循规范的同时，处理现实世界中不完美的字体文件。HarfBuzz团队通过快速响应和谨慎的代码修改，既解决了问题，又保持了引擎的稳定性。