FontTools feaLib 中多重替换规则编译优化问题分析

在字体开发工具链中，FontTools 的 feaLib 模块负责将 FEA (Font Feature Application) 代码编译为 OpenType 布局表。近期发现 feaLib 在处理内联多重替换规则时存在编译优化不足的问题，导致生成冗余的查找表(Lookup)，影响最终字体文件的效率。

问题本质

当 FEA 代码中包含带有上下文规则的内联多重替换时，feaLib 会为每个替换规则生成独立的查找表，即使这些规则可以合并。例如以下 FEA 代码片段：

feature ccmp {
    lookup ccmp_Other_1 {
        @CombiningTopAccents = [acutecomb brevecomb];
        @CombiningNonTopAccents = [dotbelowcomb ogonekcomb];
        lookupflag UseMarkFilteringSet @CombiningTopAccents;
        sub idotbelow' @CombiningTopAccents by idotless dotbelowcomb;
        sub iogonek' @CombiningTopAccents by idotless ogonekcomb;
        sub idotbelow' @CombiningNonTopAccents @CombiningTopAccents by idotless dotbelowcomb;
        sub iogonek' @CombiningNonTopAccents @CombiningTopAccents by idotless ogonekcomb;
    } ccmp_Other_1;
} ccmp;

理想情况下，这些规则可以合并到更少的查找表中，但当前实现会生成多个重复的查找表结构。

技术影响

这种编译方式带来两个主要问题：

1. 查找表冗余：生成多个功能相同的查找表实例，虽然最终会被去重，但增加了中间表示复杂度。

2. 二进制体积膨胀：由于查找表ID不同，导致无法高效去重链式类序列规则(ChainedClassSequenceRule)和规则集(ChainedClassSequenceRuleSet)表结构，显著增加最终字体文件大小。实测显示，优化后版本可减少约27%的空间占用。

深层原因分析

feaLib 的构建器(builder.py)在处理链式替换规则时，总是创建新的匿名查找表(get_chained_lookup_方法)，而不像处理简单替换时那样尝试复用现有查找表(get_lookup_方法)。这与AFDKO等工具的实现策略不同，后者会尝试合并共享相同查找标志的非重叠"辅助"查找表。

解决方案方向

参考其他实现如fea-rs的"find_or_create_anon_lookup"方法，可以考虑以下改进：

1. 实现查找表复用机制，检查现有查找表是否可重用
2. 对共享相同查找标志的非重叠规则进行合并优化
3. 在保证语义正确的前提下，尽可能减少生成的查找表数量

这种优化不仅能减小字体文件体积，还能提高编译效率，对处理复杂特性定义文件尤为有益。

对字体开发者的启示

虽然这是工具链内部的优化问题，但开发者可以注意：

1. 手动合并相同功能的内联规则可能有助于减小输出
2. 复杂特性定义可能需要关注编译后的查找表结构
3. 不同工具链(FontTools vs AFDKO)可能产生不同的优化结果

字体工具开发者应持续关注这类编译优化问题，确保特性定义能以最高效的方式转换为二进制表示。