Harfbuzz项目中的CFF2可变字体子集化垂直度量问题分析

在字体处理领域，Harfbuzz作为一款开源的文本整形引擎，其子集化功能被广泛应用于优化字体文件大小。近期发现了一个与CFF2格式可变字体子集化相关的垂直度量问题，值得深入探讨。

问题现象

当对CFF2格式的可变字体进行子集化操作时，生成的实例中.notdef字符的垂直度量值(TSB)出现异常。具体表现为：

1. 从Source Han Sans和Noto Sans CJK的可变字体(VF)生成轻量级实例时，.notdef的TSB值被错误计算为880
2. 相同字体的静态版本子集化后TSB值正确为0
3. TrueType格式的可变字体子集化后TSB值也正确为0

这种差异会导致在垂直文本布局(TTB)时，.notdef字符被错误地渲染到过低位置。

技术背景

在OpenType字体中，vmtx表(垂直度量表)存储了每个字符的垂直布局信息，包含两个关键值：

• height：字符高度
• tsb(顶部侧方位移)：字符顶部到基线的距离

.notdef作为默认字符，其垂直度量值应当保持为0，以确保在缺失字符时能正确显示。

问题根源

通过分析Harfbuzz源码，发现问题出在子集化处理可变字体时的垂直度量计算逻辑。当前代码使用OS/2表中的sTypoAscender值减去原始TSB来计算新TSB，这种计算方式对CFF2可变字体不适用。

解决方案

正确的处理方式应考虑：

1. 对于.notdef字符，应直接设置TSB为0
2. 对于其他字符，需要更精确的垂直度量计算逻辑
3. 需要区分CFF2和其他字体格式的处理方式

影响范围

该问题主要影响：

1. 使用CFF2格式的可变字体
2. 进行子集化操作生成的实例
3. 垂直文本布局场景

最佳实践建议

开发者在处理CFF2可变字体子集化时应注意：

1. 检查生成的.notdef字符度量值
2. 对于垂直文本布局应用，建议验证子集化结果
3. 关注Harfbuzz的后续更新以获取官方修复

这个问题展示了字体处理中格式差异带来的复杂性，也提醒我们在处理可变字体时需要更加细致的考量。