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

Question

对 pdf 的引用表明，定义字体资源的 pdf 字典需要包含/Widhts提供以下信息的属性：

\n\n

\n

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

\n

\n\n

添加了强调。

\n\n

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

\n\n

坦率地说：有人可以确认还是拒绝这里应该提供的信息，字形宽度是公然的冗余信息，考虑到它甚至被提到包含在字体程序中？

\n\n

或者某些字体程序是否包含字形而不指定其宽度？\n是因为有些字体程序不包含宽度，还是这只是一种耐心练习，旨在使 PDF 文件的生成变得复杂，希望人们坚持使用 Adob​​e 软件？

\n\n

是否/Widths需要测试引用的字体（未嵌入）是否“正确”（即 pdf 查看器应该检查 pdf 所需的字体程序是否可能是在平台上找到的字体程序，比较/Widths）？

\n

Answer 1

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

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

每个字形的宽度信息都存储在字体字典和字体程序本身中。（两组宽度必须相同；将此信息存储在字体字典中，尽管是多余的，但使消费者应用程序能够确定字形位置，而无需查看字体程序内部。）

我还应该提到，有许多PDF 制作者认为滥用 Widths 数组是改变字体间距的便捷方法。如果字体数组的宽度与字体程序中字形的规格不匹配，Acrobat 将使用宽度数组值（这是您引用的文本引用的附录 H 中的实现说明）。我似乎还记得最新版本的规范取消了基本 14 字体的例外，所有字体现在都应该有一个 /Widths 数组。我们有许多 PDF 文件的示例，其中度量数组与字体程序中的宽度不匹配。

请注意，Acrobat Pro 中的印前检查检查器在检查 PDF/A 兼容性时，如果宽度和规格不同，将引发错误。

因此，虽然技术上确实 /Widths 数组是多余的，因为可以从字体中检索相同的信息，但对于某些应用程序来说，以更容易访问的形式获取信息是很方便的，并且如果（作为 PDF 用户）您希望与Acrobat的渲染相匹配，就需要使用它。