FontTools中feaLib模块对混合替换语句处理的局限性分析

问题背景

在FontTools项目的feaLib模块中，存在一个关于混合替换语句(mixed substitution statements)处理的重要问题。这个问题涉及到OpenType字体特性定义文件(FEA)的解析和编译过程。

技术细节

当解析FEA文件时，feaLib模块需要处理不同类型的替换规则，包括单一替换(single substitution)、多重替换(multiple substitution)和连字替换(ligature substitution)等。在特定情况下，这些不同类型的替换规则可能出现在同一个特性(feature)块中。

当前实现中的_upgrade_mixed_subst_statements函数负责处理这种情况，但它存在一个关键缺陷：该函数仅考虑替换语句(sub statements)本身，而忽略了可能影响查找表(lookup)划分的其他语句。

问题表现

这个问题在两种典型场景下会显现：

1. 查找标志中断场景：当替换语句后面跟着一个lookupflag语句时，这个标志语句实际上会强制创建一个新的查找表。但当前实现会错误地将前面的替换语句升级为连字查找类型。

2. 上下文规则中断场景：当替换语句后面跟着一个上下文替换规则时，上下文规则会强制创建新的查找表，但前面的替换语句仍会被错误分类。

影响分析

这种错误分类会导致生成的OpenType布局表不正确，可能影响字体在各种环境下的渲染效果。特别是：

• 单一替换可能被错误标记为连字替换
• 查找表类型与实际内容不匹配
• 可能导致字体引擎无法正确解析替换规则

解决方案探讨

从技术实现角度看，这个问题需要在更底层的构建器(builder)层面解决。当前的逻辑位于AST处理阶段，而正确的处理应该推迟到实际构建查找表时进行，因为只有那时才能获得完整的上下文信息。

这种改进需要考虑：

1. 查找表划分的完整规则
2. 各种语句类型对查找表边界的影响
3. 向后兼容性需求

总结

FontTools的feaLib模块在处理混合替换语句时的这一局限性，反映了字体特性编译器的复杂性。正确处理这类边界情况对于生成正确的OpenType字体至关重要。未来改进需要更全面地考虑FEA语法中各种语句对查找表结构的影响，确保生成的布局表准确反映设计意图。