PDF文档文本在IE / Firefox / Chrome浏览器中的显示方式有所不同

简单简短的介绍

PDF中的字体是PDF对象-Font字典，其中包含许多参数和子字典，这些参数和子字典对于选择字形，显示它们并将字符代码转换为逻辑（Unicode）表示形式是必需的，以进行内容提取。用外行术语表示的字体（如我们所看到的* .ttf或* .pfb文件）被称为字体程序，可以是嵌入式程序也可以是外部程序，并且由Font对象的子词典之一引用。

Fonts 分为两组：

• 简单字体（Type1，Type3或TrueType），其中字形是通过从文本显示运算符显示的字符串中获得的单字节字符代码选择的。从代码到字形的映射称为字体编码，它可以内置在字体程序中，也可以由Font对象定义（通过预定义名称或显式），或者在特殊情况下，根据查看器应用程序根据定义的规则构造。

有问题的文件不包含简单字体，我们将不再进一步讨论它们-但是请注意，过于简单的描述甚至还没有开始反映现实生活中的任何复杂性。

• 复合字体（Type0），用于显示文本，其中的字符代码可以具有可变长度（最大4个字节），因此不限于256个代码点。Type0字体始终有一个后代，该后代是一个类似于字体的对象，称为CIDFont，类似于简单字体的编码，该CMap对象将字符代码映射到字符选择器，在PDF中，该字符选择器始终是CIDs-整数，最大为65536。

现在，字符选择器（CID）通常不直接用于从字体程序中选择字形。对于CIDFont的CIDFontType2类型，它的字典中包含CIDToGIDMap的条目，即，很明显，映射CID到字型标识符。这些GIDs是，在最后，用于选择从嵌入字形字体程序（对于CIDFontType2字体，是一个的TrueType字体程序（不要混淆Font的对象的TrueType Subtype））。

Font对象可以具有ToUnicode将CID映射到Unicode值以进行索引，搜索和提取的资源。它被称为ToUnicode Cmap（因为它遵循类似的语法），但不应与CMap上面提到的对象混淆。

在我所说的简单情况下（我认为是明智的决定），它CMap是预定义的Identity-H名称，CIDToGIDMap是预定义的Identity名称，因此，从字符串中提取的字符代码（表示操作符的文本的参数）始终为2个字节的数字，可以有效地直接从嵌入式TrueType程序中选择字形。根据我的经验，这是最常见的场景，事实就是如此，测试通用软件时就是这种情况。

但是，有关文件的情况并非如此。

（简短而简短的介绍的结尾）

在我们的文件中，显示操作符的文本有效地获得了以下字符串：

0x000a 0x000a 0x000a 0x20 0x0020 0x0020 0x0020 0x20 0x0025 0x0025 0x0025 

当然没有“组”，它们在这里是因为我创建了它们，基于CMap它们包含两个范围：

<20> <20>
<0000> <19FF>

长话短说，如果我们查找字符代码CMap并获取CID，然后查找CIDCIDToGIDMap并获取GID，然后以嵌入式David-Bold字体查找GID并获取Unicode值，则此表

Code        CID     GID     Unicode     Name

0x000a      10      180     05EA        tav
0x0020      32      159     05D5        vav
0x0025      37      154     05D0        alef
0x20        228     03      0020        space

现在我们有足够的信息来推测，是什么使查看器应用程序感到困惑

在我的第一次尝试中，我建议将其32代码（和CID）用于非空格字符（请参见上面的注释）。这个假设是基于几年前的一个案例，当时（较旧的版本）Acrobat没有在0x20代码中显示字符，而是在字符串的末尾-假设它space实际上是，根据编码矢量（简单字体），它是另一个字符。

我改变了这个：

• 0x0020以0x0004在内容流;
• 字节08和09CIDToGIDMap进入GID = 159;
• WidthsCID = 4数组中的值到'vav'宽度；
• ToUnicode cmap 进行了相应的调整。
• （+以后，我尝试从中删除<0020> 32字符串CMAP-未反映在文件中，以评论形式链接）

是的，它确实有帮助，但是不幸的是，一些观众仍然拒绝遵守规范。

然后我想，可能是可变字符代码宽度是问题所在。

我返回到原始文件并更改了此内容：

• 0x20以0x00e4在内容流;
• <20> 228以<00e4> 228中CMAP;
• codespacerange <20> <20>在CMAP删除;
• codespacerange <20> <20>中ToUnicode Cmap已删除。

该文件似乎在所有查看器中均可完美打开，下面的原始问题和评论中提到了该文件。奇迹般地，0x0020编码并且32 CID不干涉。

我认为结论可以是：

在当前状态下，不建议PDF创建者在字体编码（CMAP）中混合使用单字节和双字节代码。