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

我在制作使用14种标准PDF字体的PDF时遇到了困难。让我们以《泰晤士报》为例

我创建了一个

Font

类型为

Type1

的字典，将

BaseFont

设置为

Times Roman

。如果我省略了

Font

字典中的

Encoding

条目，或者添加了一个没有

BaseEncoding

集的

Encoding

字典，PDF viewer应用程序应该使用字体的内置编码。对于《泰晤士报》来说，这是一种最好的标准编码

这适用于ASCII字符。但是，并非所有PDF查看器都能正确显示“fi”连字（ADOBESTANDARDENCODE 174）等更奇特的内容：

• Adobe Reader shows®（unicode索引174）表示泰晤士报罗马版，而Ă表示泰晤士报斜体版
• 苏门答腊PDF（葡萄酒）显示两种字体
• Mozilla的PDF.js显示了两种字体的“AE”连字

我尝试过的所有其他PDF查看器都正确显示“fi”连字。它们还正确显示欧元符号，该符号使用

编码

字典中的

差异

数组进行额外映射（因为它不包括在AdobeStandardEncoding中）：

• 苹果预览/浏览
• 鬼书
• PDF XChange查看器（葡萄酒）
• Foxit阅读器（葡萄酒）
• Chromium的内部PDF查看器
• 显示（自制）

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

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

我怀疑使用TrueType字体而不是Type1字体可能与此问题有关。PDF规范：

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

它还说，winansioncoding和宏编码可以与TrueType字体一起使用。那么，我们应该避免对标准14种字体使用内置或标准编码吗？它的影响似乎没有定义。在使用的TrueType字体中，AdobeReader似乎不需要执行从字形名称到字形的正确映射

在使用Win或Mac编码时提供

差异
数组是否会产生正确的结果？由于这些代码点映射到Type1/Postscript标志符号名称，因此没有到TrueType标志符号的直接链接

编辑嗯，我感觉字体描述符标志对于这些标准字体可能很重要。到目前为止，我将所有字体的标志都设置为4，这对于True/OpenType字体似乎很有效。
结果是
FontDescriptor
字典中的
标志非常重要。有时，需要设置非符号标志（位6）。《时代》实际上是用TrueType字体排版的，这与此无关

要使用字体的内置编码，不应设置Type1
font
字典的
encoding
条目。如果
编码
字典包含非空的
差异
数组，则只能添加
编码
字典（省略
BaseEncoding
），否则Adobe Reader将出错

通过这些预防措施，生成的PDF在上面列出的所有9个查看器应用程序上都能正确显示。
表114-编码字典中的条目
BaseEncoding（可选）-基本编码，即差异条目（如果存在）的编码描述差异-应为预定义编码MacRomanEncoding、MacExpertEncoding或WinAnsionCodeing之一的名称。如果没有此条目，差异条目将描述与隐式基本编码的差异。
@dwarring我不确定你的意思，但我已经更新了我的答案，说明了我认为应该如何处理差异。如果我根本没有指定
FontDescriptor
字典，它在所有查看器中的行为是否都相同（与14种标准字体相同）？请考虑到标准的14种字体并不完全是用于它们的真正字体程序。它们是抽象的，在不同的查看器中可能有不同的实际字体支持。因此，依靠一些标准编码在某些查看器或其他查看器上，或在同一个查看器的某些版本中，肯定会失败。进一步此外，标准字体的特殊处理方式早就被宣布为不推荐使用了…@mkl现在我设置了非符号标志，似乎在上面列出的所有PDF查看器中都能很好地工作。根据我对规范的理解，标准字体的特殊处理只与
FirstChar
，
LastChar
，
W有关
字体
字典中的idths
和
FontDescriptor
条目。只要包含这些条目，您仍然可以使用14种标准字体，而无需嵌入它们。