FontForge中上下文查找规则生成特征文件的问题分析

问题背景

在字体设计软件FontForge中，当用户尝试为包含特定类型定位规则的字体生成特征文件(feature file)时，可能会遇到一个关键数据丢失的问题。具体表现为：在上下文相关的字形定位规则中，第一个字形的定位数据会被错误地丢弃，导致最终生成的特征文件不完整且功能异常。

问题现象

当字体中包含以下两种定位规则时会出现问题：

1. 一个独立的字形对定位规则（GPOS lookup），用于调整特定字形对（如"A"和"B"）的间距
2. 一个上下文链式定位规则，该规则引用上述独立规则，并设置为在特定上下文（如前一个字符是"A"时）触发

虽然在实际使用中这些规则能够正确工作（如在预览窗口中能看到正确的间距调整效果），但在生成特征文件时，第一个字形（如"A"）的定位数据（如-532单位的偏移量）会被丢弃，仅保留第二个字形（如"B"）的定位数据（通常为零）。

技术原因分析

问题的根源在于featurefile.c文件中的dump_contextpstglyphs()函数实现。该函数负责将上下文定位规则转换为特征文件中的文本表示。

关键问题点在于：

1. 函数在处理过程中过早地将指针pt设置为空字符('\0')
2. 这导致后续检查*next_start!='\0'的条件总是为假
3. 结果就是函数永远不会在第一个字形位置(pos == 0)调用pst_from_pos_pair_lookup()获取定位数据
4. 最终只有第二个字形位置(pos == 1)的定位数据会被正确输出

解决方案

修复方案相对直接：需要调整指针操作顺序，确保在处理完所有必要数据后再进行空字符设置。具体来说：

1. 在处理开始时保留原始指针值
2. 在处理完所有空格后，再设置空字符终止符
3. 这样start指针就能正确指向处理后的字符串末尾

这种修改可以确保两个字形位置的定位数据都能被正确获取和输出。

影响范围

这个问题不仅影响特征文件的生成，还会影响UFO(Unified Font Object)格式的导出。因为FontForge在生成UFO文件时可能使用相同的内部逻辑来处理定位规则。

对字体设计师的建议

遇到类似问题时，字体设计师可以：

1. 仔细检查生成的特征文件内容，确认所有定位数据是否完整
2. 对于复杂的上下文定位规则，建议分步测试：
   • 先验证基本字形对定位规则
   • 再逐步添加上下文条件
3. 关注特征文件中的定位数值是否与实际设计意图一致

总结

这个问题的发现和修复体现了开源字体工具开发中的典型挑战——复杂的排版规则需要精确的代码实现。FontForge作为功能强大的字体编辑工具，处理着各种复杂的OpenType特性，而这类问题的解决有助于提高工具生成文件的准确性和可靠性。对于字体开发者而言，理解这类底层机制有助于更好地诊断和解决实际工作中遇到的问题。