Die meisten PDF-Extraktoren verwenden die falsche API

Die meisten PDF-Tools verwenden die falsche Datenquelle.

Wenn Entwickler über PDF-Extraktion sprechen, meinen sie meistens getTextContent(). Diese Methode liefert Textelemente und deren Positionen. Sie ist der Standard für fast jedes Tool auf Browser-Seite.

Aber getTextContent() ist eine verarbeitete Ansicht. Es ist eine vereinfachte Version dessen, was tatsächlich verfügbar ist.

In PDF.js gibt es drei Datenebenen:

• getStructTree(): Dies sagt Ihnen, was das Dokument bedeutet. Es enthält Tabellen, Überschriften und Formeln. • getOperatorList(): Dies sagt Ihnen, was das Dokument zeichnet. Es umfasst Linien, Pfade und Formen. • getTextContent(): Dies ist eine gefilterte Ansicht dessen, was das Dokument zeichnet.

Die meisten Tools nutzen die dritte Option. Das funktioniert bei 80 % der Dokumente, wie etwa einfachen Berichten. Bei wissenschaftlichen Arbeiten und komplexen Publikationen scheitert es jedoch.

Die ausschließliche Verwendung von getTextContent() führt zu vier Hauptproblemen:

  • Sie verlieren Tabellenstrukturen. Sie müssen anhand der Textpositionen raten, wo sich die Zellen befinden.
  • Mathematische Gleichungen werden zerstört. LaTeX-Gleichungen erscheinen oft als einzelne, riesige Textblöcke.
  • Spaltenlinien gehen verloren. Viele Layouts verwenden tatsächliche Linien, um Spalten zu trennen. Diese Linien existieren nicht im Textinhalt.
  • Die Lesereihenfolge ist falsch. Text erscheint oft in der Reihenfolge, in der er gezeichnet wurde, und nicht so, wie ein Mensch ihn liest.

Der richtige Weg, einen PDF-Prozessor aufzubauen, ist ein dreistufiges System:

  1. Prüfen Sie zuerst getStructTree(). Wenn das Dokument eine logische Struktur hat, nutzen Sie diese, um Tabellen und Überschriften sofort zu finden.
  2. Prüfen Sie als Nächstes getOperatorList(). Nutzen Sie explizite Linien und Pfade, um Spaltengrenzen zu finden.
  3. Nutzen Sie getTextContent() als Fallback. Verwenden Sie geometrische Berechnungen nur dann, wenn die ersten beiden Ebenen keine Daten liefern.

Dieser Ansatz bedeutet nicht mehr Arbeit. Die Ebenen 1 und 2 fungieren als schnelle Ausstiege. Wenn das Dokument gut strukturiert ist, überspringen Sie die schwierige Mathematik. Sie nutzen komplexe Inferenz nur dann, wenn das Dokument nicht getaggt ist.

Diese Architektur bewältigt sowohl einfache Unternehmensdateien als auch komplexe wissenschaftliche Arbeiten.

Quelle: https://dev.to/bonzai2carn/most-pdf-extractors-use-the-wrong-api-heres-what-we-built-instead-5dgh