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

Question

我尝试使用希伯来语文本生成PDF文本文件。

我设法产生了一个简单的文件。文件是here

该文件将在Adobe Acrobat Reader中完美打开，显示字符串“אאאווותתת”。
它也可以在IE中完美打开。

问题是其他观众对此表现不好:
Google Chrome / Google文档显示了所有“ו”字样(即三个字母“ו”字样消失了)!

Mozilla Firefox的显示效果很差，多次在页面上的奇数处显示一些字母...

我究竟做错了什么？？
文件中有什么问题？

A link to the file is here

我知道这是一个棘手的问题。

任何帮助将不胜感激...

Answer 1

简单简短的介绍
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字体程序(不要与TrueType Font的Subtype对象混淆))。Font对象可以具有ToUnicode资源，该资源将CID映射到Unicode值以进行索引，搜索和提取。它被称为ToUnicode Cmap(因为它遵循类似的语法)，但是不应与上面提到的CMap对象混淆。
在我所说的简单情况下(我认为这是明智的决定)，CMap是预定义的 Identity-H 名称，CIDToGIDMap是预定义的身份名称，因此是从字符串中提取的字符代码(参数为文本)显示运算符)始终是2个字节的数字，可以有效地直接从嵌入式TrueType程序中选择字形。根据我的经验，这是最常见的情况，事实就是如此，测试通用软件就是这种情况。
但是，有关文件的情况并非如此。
(简短简短的介绍结束)
在我们的文件中，显示操作符的文本有效地获得了以下字符串:

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

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

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

长话短说，如果我们在CMap中查找字符代码并获取CID，然后在CIDToGIDMap中查找CID并获取GID，然后在嵌入式 David-Bold 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；

CIDToGIDMap中的

字节08和09到GID = 159;

CID = 4的Widths数组中的

值等于'vav'宽度；

ToUnicode cmap进行了相应的调整。

(+稍后我尝试从<0020> 32中删除CMAP字符串-未反映在文件中，在评论中链接)

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

然后我想，也许可变字符代码的宽度才是问题所在。
我返回到原始文件并更改了此内容:

内容流中的

0x20到0x00e4；

中的

<20> 228转换为<00e4> 228；

已删除CMAP中的

codespacerange <20> <20>；

CMAP中的

codespacerange <20> <20>已删除。

This文件似乎在所有查看器中均可完美打开，下面的原始问题和评论中提到了该文件。神奇的是，ToUnicode Cmap代码和0x0020 32不干扰。

我认为结论可以是:
在当前情况下，建议PDF创建者而不是建议在字体编码(CID)中混合使用单字节和双字节代码。