PDF文件通常使用“正确”的字符编码来表示字体字形吗？

Question

假设我有一个包含一个或多个嵌入字体的PDF文件。以下是我对单个字符如何呈现的理解：

• 首先，确定字符使用的字体。
• 使用嵌入在PDF中的字体"cmap"来确定给定字符的字体字形名称。例如，PDF文本中的"&"字符可能映射到字体内部称为"ampersand"的字形。
• 使用字体的"glyph"表来确定字形名称的边界框/绘制指令。

我的问题是：PDF cmap通常一致吗？换句话说，如果我在PDF中遇到字符"&"，我可以确信cmap将始终将"&"映射到ampersand字形吗？还是某些PDF生成软件创建了自己的任意字符代码和字形名称映射（这将是相当邪恶的，并可能破坏在PDF中搜索和文本选择）？

当然，我意识到cmap可能使用不直观的映射-我想知道，在现实世界中是否真的会发生这种情况？

我的具体用例是在音乐字体领域。我正在分析PDF中的字符，以确定每个字符代表哪个音乐字形（例如，高音谱号，音符头等）。我想知道字体名称和字符代码的组合始终会产生相同的字形的确信程度。例如，如果我知道字体名称为"Opus"，字形为"#"，我可以假设它将始终映射到高音谱号字形吗？还是我必须分析字形的度量，以确保它实际上是高音谱号？

- Adrian Holovaty

Answer 1

这取决于PDF创建者的不同。

一种相当普遍的方法（唉！）是“顺序遇到”的方法，在文本流中，第一个字符映射为\001，下一个字符映射为\002，依此类推。因此，文本"Hello"将被编码为\001\002\003\003\004。

我想知道字体名称和字符代码组合会始终生成相同的字形的可信度有多高。

在单个PDF文档中，如果同一个字体对象用于不同的上下文中，那么它就是真实的--映射定义在字体对象内。如果你遇到另一个使用相同字体的字体对象，但它指向另一个字体流（即，嵌入了两次字体子集），那么可能是错误的。每个子集都可以有自己的编码。

只有当字体对象包含/ToUnicode映射时，才可以确认值映射到正确的字符。

- Jongware

---

+1；仅当字体对象包含/ToUnicode映射时，您可以确信值映射到正确的字符。 - 您可以非常自信，但不能百分之百确定 - 有些PDF文件会在ToUnicode映射中明确包含错误信息以防止文本提取。 - mkl

@mkl：哎呀 :) 这是新的。你知道这是特定软件中的“功能”吗？ - Jongware

请看这里：该软件替换了一个代码的ToUnicode条目，从而导致所有仅依赖ToUnicode的文本提取器提取到错误的内容。然而，为了使从Adobe Reader中复制和粘贴工作正常，它会添加一个ActualText结构元素条目，在使用该代码时指示正确的Unicode代码。 - mkl