FontTools项目中IUP优化导致的部分可变字体实例化视觉异常问题分析

问题背景

在FontTools项目的varLib模块中，当对可变字体进行部分实例化操作时，特别是在使用IUP(Interpolation of Unreferenced Points)优化功能时，可能会出现显著的视觉异常现象。这种现象表现为某些本应继承前一个点变化量的点被错误地解释为0变化量，导致最终渲染效果出现明显偏差。

技术原理分析

OpenType规范中的gvar表定义了"未引用点的推断变化量"机制。为了正确计算这些推断变化量，FontTools的IUP优化模块需要比较某些点的坐标是否相等。然而，当前实现中存在一个关键的时间差问题：

1. 比较时机不当：当前代码在点坐标被四舍五入之前就进行了相等性比较
2. 运行时差异：实际运行时，点的比较发生在坐标被四舍五入之后（这是glyf表序列化的必要步骤）

这种时序差异导致了语义上的分歧，进而产生错误的推断变化量。在大多数情况下，这个问题不易被发现，因为子集化操作通常处理的是已经四舍五入的点坐标。但在部分可变字体实例化场景中，当使用非默认位置时，varLib.instancer会计算并应用相关变化量到字体的原始坐标上，导致内存中存在未四舍五入的点坐标。

问题重现与验证

通过一个简单的测试用例可以重现这个问题：

1. 创建一个设计空间文档，包含两个不同字重的实例
2. 在两个实例中设置略有差异的轮廓点（包括一些仅在四舍五入前才会显示差异的点）
3. 生成可变字体后进行部分实例化操作

测试表明：

• 使用IUP优化时会出现视觉异常
• 禁用优化(--no-optimize)时则不会出现异常

解决方案

修复此问题的关键在于调整坐标比较的时机，确保在点坐标被四舍五入后再进行比较。具体实现包括：

1. 提前对点坐标进行四舍五入处理
2. 确保比较操作与运行时行为一致
3. 保持与OpenType规范的gvar语义一致

影响范围

这个问题主要影响以下场景：

• 使用部分实例化功能
• 处理包含细微坐标差异的轮廓
• 在非默认位置进行实例化操作

对于常规的子集化操作或完整实例化操作，由于通常处理的是已经四舍五入的坐标，因此不太容易遇到这个问题。

总结

FontTools项目中这个IUP优化相关的问题展示了字体处理中精度控制的重要性。正确处理坐标四舍五入的时机对于保证可变字体渲染结果的准确性至关重要。修复方案通过调整比较操作的顺序，确保了推断变化量计算的正确性，从而解决了部分实例化操作中的视觉异常问题。