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

Question

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

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

强调了。

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

很明显：有人可以确认或拒绝应该在此处提供的信息吗，字形宽度明显是多余的信息，考虑到它甚至被提到包含在字体程序中？

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

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

Answer 1

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

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

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

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

请注意，Acrobat Pro 中的 Preflight 检查器在检查 PDF/A 兼容性时，如果宽度和度量不同，则会引发错误。

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