Typst项目中PDF字体名称匹配问题的技术解析

在Typst项目开发过程中，我们发现了一个关于PDF字体名称匹配的技术问题，这个问题涉及到PDF规范中Type 3字体字典与字体描述符(FontDescriptor)之间的名称一致性要求。

问题背景

当Typst生成包含emoji等特殊字符的PDF文档时，系统会使用Type 3字体来表示这些字符。根据PDF 1.7规范，Type 3字体的字体描述符中如果包含FontName条目，那么父Type 3字体字典中的Name条目必须设置为相同的值。然而，规范中存在着看似矛盾的要求：

1. ISO 32000-1 PDF 1.7规范表122明确指出FontDescriptor必须包含FontName键
2. 同一规范表112对于Type 3字体字典只引用了表111(Type 1字体)，而表111声称Name条目已过时不应使用

技术分析

经过深入研究PDF规范和社区讨论，我们发现了以下关键点：

1. 在PDF 2.0规范中，通过勘误表澄清了FontDescriptor中的FontName仅在描述Type 3字体时才需要
2. Type 1字体中Name条目的过时声明可能不适用于Type 3字体
3. 存在三种可能的解决方案：
   • 省略FontName条目
   • 在Type 3字体字典中显式设置Name键
   • 忽略验证工具的警告

解决方案建议

基于技术分析和规范解读，我们推荐采用第二种方案：在Type 3字体字典中显式设置Name键，特别是在PDF 1.7文档中。这样做的优势包括：

1. 完全符合PDF 1.7规范的字面要求
2. 避免了验证工具(如veraPDF)的合规性警告
3. 保持了向后兼容性

对于未来的PDF 2.0导出功能，我们可以考虑省略FontName和Name键，因为PDF 2.0规范对这方面的要求更为宽松。

实施影响

这一修改将影响Typst生成的PDF文档中所有使用Type 3字体表示的内容，特别是包含emoji等特殊字符的文档。修改后，这些文档将能够通过更严格的PDF验证检查，提高文档的互操作性和长期可访问性。

结论

PDF规范中关于字体命名的要求存在历史遗留的复杂性。通过仔细分析规范演变和技术背景，我们确定了最符合Typst项目需求的实现方案，既保证了当前PDF 1.7文档的规范符合性，又为未来支持PDF 2.0保留了灵活性。