过时的实现如何优雅地处理新版本的 OpenType 字体？

Posted 2023-03-15

【中文标题】过时的实现如何优雅地处理新版本的 OpenType 字体？

【英文标题】：How can an out of date implementation gracefully process a new version of an OpenType font?

【发布时间】：2017-09-10 17:09:14

【问题描述】：

您可以在MS OpenType font file specification 的版本号部分中找到以下文本：

读取表的实现必须包含检查版本的代码 数字，以便，如果和何时格式以及版本 编号更改，旧实现将处理新版本 优雅地。

假设有人编写了一个代码来读取版本 1 和更高版本的 OpenType 字体文件，该代码用于处理相同的字体文件，但版本 2。我只是无法想象这怎么能“优雅地”成功，除非上述声明意味着必须在处理之前将代码更新到字体文件的最终版本。

【问题讨论】：

为了让 *** 实际上对未来的访问者有用，您能否接受答案或发表评论，说明它如何无法解决您的问题？

【参考方案1】：

您将“优雅”误认为“仍在解析字体文件”。该规范的想法是有版本号，以便每个解析器显式检查版本号，继续解析它知道如何解析的版本，并正确报告和确定性地在它不知道如何处理的版本上运行。

优雅：

开始读表 将版本号读入表结构 检查版本号 分支到已知版本号的解析函数 报告无法继续解析未知版本号 以确定的、记录的方式取消解析运行 使用解析器的应用程序现在可以优雅地处理它们所处的“无法加载请求字体”的情况。

不优雅：

开始读表 在写入解析器时将字节读入反映最新 OpenType 表格式的结构中。 由于版本不匹配而导致数据损坏，可能会在那里发生硬崩溃，然后由于访问表的分配范围之外的内存。 可能会提供损坏的数据和/或稍后崩溃，因为偏移量错误 可能会导致使用解析器的应用程序崩溃，因为返回了损坏的数据，或者解析器崩溃的难度足以杀死进程 可能……等等等等。

对于解析器能够解析较新的 OpenType 表格式的期望为零，但它绝对应该以优雅的方式处理它们，检查版本是否匹配那些它知道如何使用的对象，并报告无法解析它没有解析规则的数据，并有一个干净的出口，允许消费应用程序做他们需要做的事情。