PDF字体对象的/Widths数组是否是冗余信息？

Question

“pdf参考”通知定义字体资源的pdf字典需要包含属性/Widhts，提供以下信息：

(标准的14种字体除外；间接引用首选)一个( LastChar−FirstChar + 1)宽度的数组，每个元素都是字符代码的符号宽度，等于FirstChar加上数组索引。对于FirstChar到LastChar范围之外的字符代码，将使用此字体的FontDescriptor条目中的MissingWidth值。字形宽度以1000个单位对应于文本空间中的1个单位的单位来测量。这些宽度必须与字体程序中给出的实际宽度一致。(见附录H中的实施说明61 )

重点补充。

再次提供宽度有什么好处？--它们显然包含在字体程序中吗？

简单地说:是否有人确认或拒绝在这里提供的信息，字形宽度是完全多余的信息，考虑到它甚至被提到包含在字体程序中？

或在没有指定宽度的情况下对字形做一些字体程序？是因为有些字体程序不包括宽度，还是这仅仅是一种耐心的锻炼，使生成PDF文件变得复杂，希望人们随后坚持使用Adobe？

是否需要/Widths条目来测试所引用的字体(未嵌入)是否“正确”(即pdf查看器应该检查pdf所需的字体程序是否可能是平台上比较/Widths的字体程序)？

Answer 1

宽度数组被记录为存在，以便应用程序可以确定象形文字的度量，而不需要解码字体。当在文本周围绘制选择框或以某种方式突出显示文本时，这可能是有用的(例如)。

参见PDF 1.7规范的第393页和第394页：

每个字形的宽度信息都存储在字体字典和字体程序本身中。(这两组宽度必须是相同的；将这些信息存储在字体字典中，虽然是多余的，但使使用者应用程序能够确定字形的位置，而不必查看字体程序。)

我还应该提到，有许多 PDF生成器，它们认为滥用宽度数组是更改字体间距的一种方便方法。如果字体数组的宽度与字体程序中的象形文字不匹配，Acrobat将使用宽度数组值(这是您引用的文本所引用的附录H中的实现说明)。我似乎还记得，该规范的最新版本取消了基本14种字体的异常，所有字体现在应该有一个/Widths数组。我们有PDF文件的数字例子，其中度量数组与字体程序中的宽度不匹配。

请注意，Acrobat中的飞行前检查器在检查PDF/A兼容性时，如果宽度和度量不同，则会抛出错误。

因此，虽然从技术上说/Widths数组是多余的，因为可以从字体中检索相同的信息，但对于某些应用程序来说，以更容易访问的形式获得信息是很方便的，如果(作为PDF使用者)您希望与Acrobat的呈现相匹配，则需要使用它。