use*_*342 1 pdf postscript tokenize
我正在将 PDFMiner(一个用 Python 编写的开源 PDF 到文本程序)翻译成 Objective-c。某些字体中有一个附言文件,其中包含字符名称及其编码值。例如:
/Encoding 256 array
0 1 255 {1 index exch /.notdef put} for
dup 65 /A put
dup 67 /C put
dup 70 /F put
dup 45 /hyphen put
Run Code Online (Sandbox Code Playgroud)
我实际上不知道上面的代码做了什么。我猜它会将这些对放入字典中。我完全不知道 dup 做了什么。上面的代码对我来说意味着,如果我在 PDF 中看到 45,那么我会查找它并将其转换为连字符,或者如果我看到 70,则将其转换为 F 等。
我正在复制的代码使用完整的 Postscript 标记器来解析 postscript 文件中的所有放置命令。对于每个 put 命令,它创建一个字典,其中包含与 put 操作数对应的键值对。
我的问题是,我真的需要构建一个完整的 Postscript 标记器来解析这些东西吗?
一个更简单的替代方法是扫描字符串“put”的每个出现,然后查看前面的两个单词。如果前面的两个单词是一个数字后跟一个 /x ,那么我认为这是我想要的,否则忽略它。
我根本不知道附言,但我想任何知道的人都可以告诉我我的更简单的替代方案是否有任何会搞砸的极端情况。
谢谢!
冗长的解释,跳到最后以获得简短的答案。
PostScript 是一种基于堆栈的编程语言(有点类似于 Forth)“dup”是一个运算符,它复制操作数堆栈上的顶部对象。
在您的示例中,它创建一个包含 256 个元素的数组,在数组中的每个位置使用名称 /.notdef 填充数组,然后将特定数组索引处的名称替换为其他名称(dup 复制数组,put 消耗操作数,包括数组副本)。上面没有显示,但稍后该数组将与名称 /Encoding 相关联,并且键值对存储在字典中,在这种情况下包含字体。
当绘制字符代码时,解释器查找字体字典并检索与键 /Encoding 关联的对象。然后它使用字符代码作为该数组中的索引,并检索在那里找到的对象。然后解释器从字体中检索 CharStrings 字典,并将从 Encoding 数组中提取的对象用作 CharStrings 字典中的键。然后进一步使用与该键关联的对象。在类型 1/2/3 字体的情况下,该对象是用于绘制字形形状的字形程序。在类型 42 字体中,该对象是一个整数,然后将其用作 GID,以从字体字典中 /sfnts 数组的 GLYF 表中检索字形程序。
现在首先要注意的是 PostScript 是一种编程语言。代替上面的简单数组设置,我可以编写一个 PostScript 例程,它接受一个字体字典、名称和一个索引,并将它插入到该字体的 Encoding 数组中。所以扫描模式的简单方法是行不通的,因为我的程序不是那样做的。
此外,'put' 运算符在 PostScript 编程中被广泛使用,因此简单地搜索 'put' 是不够的。
所有这些都是冗长的说法,如果您想使用 PostScript 程序,您将需要一个完整的 PostScript 解释器(标记器是不够的,您需要一个完整的解释器)。
现在就您的具体情况而言,您的想法将适用于 PostScript type 1 字体(受上述注意事项的约束),因为这些字体通常格式良好并遵循一些简单的准则,并且最多适用于 type 3 PDF 字体,但它不会不适用于 TrueType 字体或 CIDFonts,并且实际上不适用于上述任何子集。(它也不适用于 CFF 字体,因为它们是二进制编码的,不会被解释为 PostScript)
您应该首先检查字体是否有关联的 ToUnicode CMap,如果有,那么您很幸运,请使用它!这会将字符代码映射到 Unicode 代码点,工作完成。
在没有 ToUnicode CMap 的情况下,无法保证您可以提取文本,这可能是完全不可能的。如果你使用的是TrueType字体,你可以对Encoding进行逆向工程,提取字符代码->GID映射,然后你可以查一下TrueType字体的CMAP表,看看它是否有Unicode CMAP(大多数都有),在这种情况下你可以使用它。
如果所有这些都失败了,您可以检查字体对象中的字体是否具有标准编码,这些在 PDF 参考中列出。
所以这告诉你的是字体程序中的编码对你没有多大用处。如果没有应用其他编码,则它是字体的默认顺序。PDF 文件总是应用它们自己的编码(它是字体对象中的必需条目)。因此,实际 PostScript 字体中的编码对您没有用,它会被 PDF 文件中的条目覆盖。因此,对于 1、2 或 3 型字体,您根本不需要解释字体。
只有当以上所有方法都失败时,您才应该开始查看编码中的名称(PDF文件中的编码,而不是字体!)。您需要注意,仅仅因为有人在编码中粘贴了一个名称,并不意味着这是由字形程序绘制的实际字形形状....
对于 CIDFonts,如果它没有 ToUnicode CMap,您可能会卡住,但是您可以检查 CIDSystemInfo 以获取注册表和排序的线索。
这完全取决于您想要的彻底程度,实际上您希望生成的程序执行得有多好,请记住,如果不使用 OCR 解决方案之类的东西,就不可能达到 100% 的准确度。
无论如何,简短的回答是“你不需要做那个戴夫”。字体程序中的编码没有用,因为它被 PDF 文件中的编码覆盖。
| 归档时间: |
|
| 查看次数: |
2562 次 |
| 最近记录: |