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

Question

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

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

强调补充。

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

简而言之：有人可以确认或拒绝应该在这里提供的信息吗，字形宽度是明显的冗余信息，考虑到它甚至被提到包含在字体程序中？

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

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

标签： pdffonts

Answer 1

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

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

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

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

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

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