14种标准PDF字体和字符编码

Question

14种标准PDF字体和字符编码

8

我在生成使用14种标准PDF字体的PDF时遇到了困难，以Times-Roman为例。

我创建了一个类型为Type1的Font字典，其中的BaseFont设置为Times-Roman。如果我省略Font字典中的Encoding条目，或者添加一个没有设置BaseEncoding的Encoding字典，PDF查看器应该使用字体内置的编码。对于Times-Roman，这是AdobeStandardEncoding。

这对ASCII字符可以正常工作。但是，一些更奇特的内容，例如“fi”连字（AdobeStandardEncoding代码174），并不被所有PDF查看器正确地显示：

Adobe Reader在Times-Roman和Times-Italic上分别显示®（unicode索引174）和Ă
SumatraPDF（wine）两个字体都会显示®
Mozilla的PDF.js会在两种字体中显示“AE”连字

我尝试了的所有其他PDF查看器均可正确显示“fi”连字。它们还通过Encoding字典中的Differences数组正确显示€符号（因为它未包含在AdobeStandardEncoding中）：

Apple Preview/Skim
GhostScript
PDF-XChange Viewer（wine）
Foxit Reader（wine）
Chromium的内部PDF查看器
Evince（homebrew）

打开Adobe Reader的“文档属性”窗口会显示：

Times-Roman
    Type: Type1
    Encoding: Custom
    Actual Font: Times-Roman
    Actual Font Type: TrueType

我怀疑使用TrueType字体而非Type1字体可能与问题有关。PDF规范中提到：

StandardEncoding Adobe标准拉丁文本编码。这是Type 1拉丁文本字体程序中定义的内置编码（但通常不在TrueType字体程序中）。

它还说WinAnsiEncoding和MacRomanEncoding可以与TrueType字体一起使用。所以我们应该避免使用内置或StandardEncoding来处理标准14种字体吗？它的影响似乎是未定义的。Adobe Reader似乎不会对从字形名称到正在使用的TrueType字体中的字形进行正确映射。

当使用Win或Mac编码时，提供Differences数组是否会产生正确的结果？由于这些将代码点映射到Type1 / Postscript字形名称，因此没有直接链接到TrueType字形。

编辑：嗯，我觉得这些标准字体的字体描述符标志可能很重要。到目前为止，我已经将所有字体的标志设置为4，这似乎对True/OpenType字体有效。

- Brecht Machiels

1

请注意，标准的14种字体并不完全是真正使用它们的字体程序。它们是抽象的，在不同的查看器中可能由不同的实际字体支持。因此，依赖某些标准编码肯定会在某个查看器或另一个版本的同一个查看器中失败。此外，标准字体的特殊处理早已被宣布为不推荐使用... - mkl

@mkl，现在我设置了Nonsymbolic标志，它似乎在所有上面列出的PDF查看器中都能很好地工作。根据我的理解，规范对标准字体的特殊处理仅涉及Fonts字典中的FirstChar、LastChar、Widths和FontDescriptor条目。只要包括这些条目，您仍然可以使用14种标准字体而无需嵌入它们。 - Brecht Machiels

1个回答

网页内容由stack overflow 提供, 点击上面的

可以查看英文原文，
原文链接

- Brecht Machiels · Accepted Answer

原来在FontDescriptor字典中的Flags很重要。对于Times字体，需要设置Nonsymbolic标志（第6位）。其实Times最终使用的是TrueType字体并不影响这一点。

为了使用字体的内置编码，Type1字体字典中的Encoding条目不应该被设置。只有当Encoding字典包含非空Differences数组时，才可以添加Encoding字典（省略BaseEncoding），否则Adobe Reader会报错。

遵循这些预防措施，生成的PDF将在上述所有9个查看器应用程序上正确显示。