这个问题与这个答案中讨论的问题非常相似,那里的示例文档的出现也让人想起这里的文档。
就像另一个问题中的文档的情况一样,此处文档中使用的 Devanagari 脚本字体的ToUnicode映射将多个完全不同的字形映射到相同的 Unicode 代码点。因此,基于此映射的文本提取必然会失败,并且大多数文本提取器都依赖于这些信息,特别是在缺少像这里这样的字体编码条目的情况下。
某些文本提取器可以使用嵌入字体程序(如果存在)中包含的字形到 Unicode 的映射。但是在此处文档中使用的梵文脚本字体程序中检查此映射,结果发现它将大多数字形与名为“uniF020”的 U+f020 到 U+f062 等相关联。
这些 Unicode 代码点位于Unicode Private Use Area中,即它们没有标准化含义,但应用程序可以随意使用它们。
因此,使用字体程序中包含的 Unicode 映射的文本提取器也不会立即提供可理解的文本。
不过,有一个事实可以帮助您从该文档中自动提取文本:多个页面上的梵文脚本字体引用了同一个 PDF 对象,因此在引用同一 PDF 对象的所有页面上都具有相同的原始字符标识符或相同的字体程序私有使用Unicode代码点引用相同的视觉符号。对于你的文档,我只算了 5 个字体副本。
因此,如果您找到一个文本提取器,它要么返回字符标识符(忽略所有 toUnicode 映射),要么从字体程序返回私有使用区域 Unicode 代码点,您可以使用它的输出,并且只需根据几个映射替换每个条目。
我还没有使用过这样的文本提取器,所以我不知道 python 上下文中的任何内容。但谁知道呢,也许 pdfminer 或任何其他类似的包可以被告知(通过某些选项)忽略误导性的ToUnicode映射,然后按照上面概述的方式使用。
| 归档时间: |
|
| 查看次数: |
2387 次 |
| 最近记录: |