HarfBuzz 在 macOS 上处理 TTC 字体时对已删除字形请求字距调整的问题分析

问题背景

在 macOS 系统环境下，当使用 HarfBuzz 文本渲染引擎处理 TrueType Collection (TTC) 字体文件时，特别是处理包含连字（ligature）的字体（如 Lucida Grande）时，出现了一个特殊的技术问题。HarfBuzz 会尝试获取连字字形（如"ff"连字）与特殊标识符 0xFFFF（代表 AAT 字体格式中的已删除字形）之间的水平字距（kerning）信息。

技术细节解析

1. 字形处理流程

在文本渲染过程中，HarfBuzz 会执行以下关键步骤：

• 首先进行字形替换（glyph substitution），将字符序列转换为对应的字形序列
• 然后进行字形定位（glyph positioning），调整字形间的相对位置

在字形定位阶段，HarfBuzz 会调用用户提供的自定义字距获取函数（通过 hb_font_get_glyph_h_kerning_func_t 定义）来查询特定字形对之间的字距信息。

2. 问题核心

问题的核心在于 HarfBuzz 在处理过程中没有正确过滤掉已被标记为删除的字形（0xFFFF）。当遇到连字时，引擎会错误地尝试获取连字字形与已删除字形之间的字距信息，这会导致以下问题：

1. 用户提供的自定义字距函数可能无法处理 0xFFFF 这个特殊字形标识符
2. 这种请求本身在字体设计上是无意义的，因为已删除的字形不应该参与任何排版计算

3. 代码层面分析

在 HarfBuzz 的源码中，相关处理位于 ot-shape.cc 文件的第 956 行附近。问题出现的原因是：

• 当 c->plan->apply_gpos 标志为 false 时
• 引擎跳过了正常的字形过滤流程
• 导致已删除字形没有被正确移除
• 这些无效字形随后被传递到字距计算阶段

解决方案与修复

HarfBuzz 项目组已经通过提交 225a7a8 修复了这个问题。修复的核心思路是：

1. 确保在所有情况下都正确处理已删除字形
2. 在调用用户自定义字距函数前进行严格的字形有效性检查
3. 避免将无效的字形对传递给下游处理函数

对开发者的启示

这个案例为字体处理和文本渲染开发者提供了几个重要启示：

1. 在处理字形时，必须考虑所有可能的特殊字形标识符
2. 自定义字体处理函数需要具备鲁棒性，能够处理边界情况
3. 在字体引擎开发中，字形过滤应该在早期阶段完成
4. 对于 TTC 字体和 AAT 字体表的特殊处理需要特别注意

总结

HarfBuzz 作为现代文本渲染引擎，在处理复杂字体特性时展现了其强大的功能，但同时也面临着各种边界条件的挑战。这个特定的问题展示了字体引擎在处理不同平台字体格式时需要面对的兼容性问题，以及如何通过严谨的代码设计来解决这些问题。