如果识别 PDF 文档中的文本结构如此困难，那么 PDF 阅读器是如何做到如此出色的呢？

Posted 2023-02-24

【中文标题】如果识别 PDF 文档中的文本结构如此困难，那么 PDF 阅读器是如何做到如此出色的呢？

【英文标题】：If identifying text structure in PDF documents is so difficult, how do PDF readers do it so well?

【发布时间】：2014-05-05 17:20:27

【问题描述】：

我一直在尝试编写一个简单的控制台应用程序或 PowerShell 脚本来从大量 PDF 文档中提取文本。有几个库和 CLI 工具可以做到这一点，但事实证明，没有一个能够可靠地识别文档结构。我特别关心文本列的识别。即使是非常昂贵的 PDFLib TET 工具也经常会混淆相邻两列文本的内容。

人们经常注意到，PDF 格式没有任何列的概念，甚至没有单词。 SO上类似问题的几个答案提到了这一点。这个问题是如此之大，以至于它甚至值得学术研究。 This journal article注：

PDF 文件中的所有数据对象都以 以视觉为导向的方式，作为一系列运算符......通常 不要传达有关更高级别文本单元的信息，例如 记号、行或列——关于此类之间边界的信息 单位只能通过空格隐式使用

因此，我尝试过的所有提取工具（iTextSharp、PDFLib TET 和 Python PDFMiner）都无法识别文本列边界。在这些工具中，PDFLib TET 表现最好。

但是，SumatraPDF，非常轻量级和开源的 PDF 阅读器，以及许多其他类似的工具，可以完美地识别列和文本区域。如果我在其中一个应用程序中打开文档，选择页面上的所有文本（甚至使用 CTRL+A 选择整个文档）将其复制并粘贴到文本文件中，文本将以正确的顺序呈现，几乎完美无瑕。它偶尔会将页脚和标题文本混合到其中一列中。

所以我的问题是，这些应用程序如何才能完成看似如此困难的事情（即使对于 PDFLib 等昂贵的工具也是如此）？

编辑 2014 年 3 月 31 日：值得一提的是，我发现 PDFBox 在文本提取方面比 iTextSharp 好得多（尽管有定制的策略实施），而且 PDFLib TET 略好于 PDFBox，但它相当昂贵。 Python PDFMiner 是无望的。我见过的最好的结果来自谷歌。可以将 PDF（一次 2GB）上传到 Google Drive，然后以文本形式下载。这就是我正在做的事情。我编写了一个小实用程序，可以将我的 PDF 拆分为 10 页文件（Google 只会转换前 10 页），然后在下载后将它们缝合在一起。

编辑 2014 年 4 月 7 日。取消我的最后一次。最好的提取是通过 MS Word 实现的。这可以在 Acrobat Pro 中自动执行（工具 > 动作向导 > 创建新动作）。 Word 到文本可以使用 .NET OpenXml 库实现自动化。 Here is a class 将非常巧妙地进行提取（docx 到 txt）。我最初的测试发现，MS Word 转换在文档结构方面要准确得多，但是一旦转换为纯文本，这就不那么重要了。

【问题讨论】：

我不了解其他产品，但如果是 iTextSharp，您不会获得最终的完整文本提取器。相反，您会得到一个具有两种示例策略的框架，一种非常简单（按照其在 PDF 中的绘图命令出现的顺序获取文本）和一种位置感知（从上到下、从左到右读取）。后一个可以很容易地（例如，@David 给出的提示）被扩展以尝试识别列。不过，这意味着一些工作，而且似乎还没有人投入到这个问题上，并允许结果进入 iTextSharp 的开源。

使用 Word 的好选择。另一种可能性是在 Word 中使用 VBA 从文档中提取您想要的任何信息。

【参考方案1】：

我曾经写过一个算法，它完全符合您提到的 PDF 编辑器产品的功能，该产品仍然是当今使用的第一大 PDF 编辑器。您提到的原因有几个（我认为），但重要的一个是重点。

您是正确的，PDF（通常）不包含任何结构信息。 PDF 对页面的视觉表示感兴趣，而不一定对页面的“含义”感兴趣。这意味着在其最纯粹的形式中，它不需要有关行、段落、列或任何类似内容的信息。实际上，它甚至不需要有关文本本身的信息，而且有很多 PDF 文件，您甚至无法复制和粘贴文本而不会出现乱码。

因此，如果您希望能够提取格式化文本，您确实必须查看页面上的所有文本片段，也许还要考虑一些艺术线条信息，并且您必须拼凑他们重新在一起。通常这是通过编写一个查看空白然后首先决定什么是行、什么是段落等等的引擎来实现的。例如，表格是出了名的困难，因为它们非常多样化。

替代策略可能是：

查看一些 PDF 文件中的一些结构信息。一些 PDF/A 文件和所有 PDF/UA 文件（用于存档的 PDF 和用于通用可访问性的 PDF）必须具有可以很好地用于检索结构的结构信息。其他 PDF 文件也可能包含该信息。 查看 PDF 文档的创建者并使用特定算法来处理这些 PDF。如果您知道自己只对 Word 感兴趣，或者如果您知道您将处理的 99% 的 PDF 都来自 Word 2011，那么使用这些知识可能是值得的。

那么为什么有些产品在这方面比其他产品更好？我猜是重点。 PDF 规范非常广泛，有些工具更侧重于较低级别的 PDF 任务，有些更侧重于更高级别的 PDF 任务。有些面向“办公室”使用 - 有些面向“图形艺术”使用。根据您的关注重点，您可能会决定某个功能是否值得关注。

此外，这似乎是一个糟糕的答案，但我相信这是真的，这是一个算法难题，只需一个天才开发人员就可以实现比市场上平均产品更好的算法。这是那些领域之一——如果你很聪明，并且你有足够的注意力来集中注意力，特别是如果你很清楚你写这篇文章的目标市场是什么——你会做对的，而其他人会觉得它平庸。

（不，我当时写代码的时候并没有正确地理解它——我们从来没有足够的注意力去跟进并做出真正好的东西）

【讨论】：

关于“做对”：这很可能被认为是“一个移动的目标”。假设左边有 3 行小文本，右边有 2 行大文本。通用文本提取器能否按照原始文本的“正确”顺序假定 任何内容？

完全正确。问题还在于我们大部分时间都在处理设计繁重的文档，并且文本识别不喜欢杂志设计师在页面上所做的事情。与在 InDesign 中设计的文件相比，为简单的业务报告做正确的事情更容易......

【参考方案2】：

要正确提取格式化文本，库/实用程序应该：

检索有关 PDF 中使用的字体属性的正确信息（字形大小、提示信息等） 维护图形状态（即非字体参数，如文本和页面缩放等） 实施某种算法来决定页面上的哪些符号应被视为单词、行或列。

对于您在问题中提到的产品，我并不是真正的专家，因此以下结论应该持保留态度。

不绘制 PDF 的工具往往在前两个要求方面缺乏专业知识。他们不必处理更深层次的字体细节，而且在维护图形状态方面可能没有经过很好的测试。

任何将 PDF 转换为图像的好工具迟早都会意识到它在文本定位方面的缺点。修复这些将有助于在文本提取方面表现出色。

【讨论】：

实际上不需要提示 - 对你的好答案的一个小细节评论。