FontTools项目中的字形闭合逻辑问题解析

在FontTools项目中，字形闭合（glyph closure）是一个关键功能，它用于确定在特定字体子集化场景下哪些字形需要被保留。最近发现了一个关于上下文查找（contextual lookup）和连字替换（ligature substitution）的有趣案例，值得深入探讨。

问题背景

当使用类似以下的Feature文件语法时：

lookup GSUB5f1 {
    sub x' y' by X;
} GSUB5f1;

这个查找规则会生成一个上下文查找和一个连字替换子查找。然而，当我们尝试用["x", "y"]这样的字形集合来子集化字体时，结果中不会包含"X"字形。

技术分析

问题的根源在于字形闭合算法处理上下文查找时的逻辑。具体来说，当算法递归进入被引用的查找时，它只包含当前输入序列中当前位置的字形（在这个例子中只有"x"），而实际上连字替换需要匹配两个字形才能触发。

在FontTools的实现中，pos_glyphs变量被设置为仅包含输入序列中当前位置的字形，而不是整个剩余输入序列。这种设计选择虽然在某些情况下可以减少误报，但在处理连字替换时可能导致无法识别明显可达的字形。

深入理解

进一步分析发现，当Feature编译器将多个递归查找合并为单个查找以优化性能时，这种设计确实能显著减少误报。然而，这也带来了一个潜在问题：可能会遗漏那些实际上可以通过字形组合到达的字形。

解决方案验证

通过一个具体测试案例可以验证这个问题：

feature SUB5 {
    lookup GSUB5f1 {
        sub a' b' by a_b;
        sub c' d' by c_d;
    } GSUB5f1;
} SUB5;

当使用["a","b"]作为输入字形集合进行子集化时，结果确实不包含"a_b"字形。然而，当明确指定包含所有特征（使用--layout=features='*'参数）时，功能可以正常工作。

最佳实践建议

1. 当在FontTools之外使用字形闭合功能时（如在ufo2ft中），需要特别注意确保正确处理所有相关特征。

2. 对于自定义命名的特征，需要明确指定要处理的特征列表，否则它们可能被默认忽略。

3. 在处理连字替换时，建议进行额外的验证以确保所有预期的字形都被正确包含在闭合结果中。

这个案例提醒我们，在字体处理工具链中，理解底层算法的行为边界和假设条件非常重要，特别是在处理复杂的字形替换规则时。