PDF in Text umzuwandeln ist ein schwieriges Problem

 (marginalia.nu)
4 Punkte von GN⁺ 2025-05-15 | 1 Kommentare | Auf WhatsApp teilen
  • PDF-Indexierung wurde zwar zu einer Suchmaschine hinzugefügt, aber aus PDFs für die Suche brauchbaren strukturierten Text zu gewinnen, ist deutlich schwieriger als die Verarbeitung von HTML
  • PDF ist eher ein koordinatenbasiertes Grafikformat als ein Textdokument; Glyphen können gedreht, überlappend oder in vermischter Reihenfolge angeordnet sein
  • Der PDFTextStripper von PDFBox kann ein Ausgangspunkt sein, bildet aber semantische Strukturen wie Überschriften und Absätze nicht ausreichend ab, was die Bewertung der Suchrelevanz einschränkt
  • Um Überschriften und Absätze zu unterscheiden, sind Heuristiken wie seitenbezogene Schriftgrößenstatistiken und der Median des Zeilenabstands oft nützlicher als globale Maßstäbe für das gesamte Dokument
  • Da eine perfekte Textextraktion aus PDFs schwierig ist, ist für Suchmaschinen ein hinreichend guter Ansatz, der die Struktur aus Titel, Abstract und Haupttext stabil gewinnt, ein realistisches Ziel

Probleme, die beim Hinzufügen der PDF-Indexierung sichtbar wurden

  • Die Suchmaschine kann seit Kurzem PDF-Dateien indexieren; die Änderungen werden über mehrere Monate hinweg ausgerollt
  • Aus Sicht einer Suchmaschine ist sauberes HTML am einfachsten zu verarbeiten, aber PDFs liefern nicht unmittelbar denselben Grad an strukturiertem Text
  • Auch wenn oberflächlich Text sichtbar ist, ist es nahezu ein eigenes Problem, daraus innerhalb eines PDFs durchsuchbare Sätze und Absätze zu rekonstruieren

Warum PDFs für die Textextraktion schwierig sind

  • PDF ist kein gewöhnliches Textformat, sondern eher ein Grafikformat
  • Die interne Darstellung ähnelt eher der Platzierung von Glyphen an Koordinaten auf einem „Papier“ als der Speicherung von Sätzen oder Absätzen
  • Glyphen können sich in folgenden Zuständen befinden
    • gedreht
    • überlappend
    • in anderer Reihenfolge als der Lesereihenfolge
    • mit nur sehr wenig begleitender Bedeutungsinformation
  • Dass in einem PDF-Viewer oder Browser überhaupt eine Suche mit ctrl+f funktioniert, ist an sich schon ein bemerkenswertes Ergebnis
  • Visionsbasierte Machine-Learning-Modelle könnten derzeit ein guter Ansatz sein, passen aber nicht zu dem Maßstab, bei dem auf einem einzelnen Server ohne GPU Hunderte GB an PDFs verarbeitet werden

Mit PDFBox kann man anfangen, aber es reicht nicht aus

  • Das Problem ist nicht völlig unerforscht; man kann mit der Klasse PDFTextStripper aus PDFBox beginnen
  • PDFTextStripper extrahiert Text aus PDFs, konzentriert sich seinem Namen entsprechend aber vor allem darauf, den Text herauszulösen
  • Für Suchmaschinen sind semantische Informationen wie Titel wichtige Relevanzsignale, doch mit den Standardergebnissen der Extraktion ist diese Struktur nur schwer ausreichend zu gewinnen

Heuristiken zum Finden von Überschriften

  • Die einfachste Erkennung von Überschriften besteht darin, nach Zeilen mit mindestens semiboldem Schriftschnitt zu suchen, die vom übrigen Text abgesetzt sind
  • Aber nicht jede Überschrift ist fett gesetzt, und in vielen Dokumenten werden Überschriften über die Schriftgröße unterschieden
  • Globale Bezugswerte für Schriftgrößen schwanken von Dokument zu Dokument
    • In einem Dokument kann der Fließtext 10 pt und die Überschrift 16 pt haben
    • In einem anderen Dokument kann der Fließtext 14 pt und die Überschrift 20 pt haben
  • Seitenbezogene Statistiken sind mitunter geeigneter als Werte für das gesamte Dokument
    • Die erste Seite kann sich wegen Abstract und Autorenliste bei der Schriftwahl stark von den übrigen Seiten unterscheiden
    • Im Beispieldokument wird für den Dokumenttitel eine Schriftgröße 17 verwendet und für spätere Überschriften Größe 14
  • Auf jeder Seite gibt es meist eine dominante Schriftgröße, die dem Fließtext entspricht
  • Wenn man den medianen Schriftgrad pro Seite mit einem Faktor von etwa 20 % versieht, lassen sich Überschriften recht stabil identifizieren
  • Ausnahmen bleiben, aber die meisten wichtigen Fälle lassen sich erfassen

Mehrzeilige Überschriften zu einer zusammenführen

  • Überschriften werden aus Stilgründen oft auf mehrere Zeilen verteilt, sodass aufeinanderfolgende Überschriftenzeilen manchmal zu einer zusammengeführt werden müssen
  • Das Kriterium, wann zusammengeführt werden soll, ist nicht simpel
  • Im Beispiel treten folgende Bedingungen gemeinsam auf
    • eine zweizeilige Überschrift
    • eine rechtsbündige Überschrift
    • unmittelbar nach der Überschrift folgende Autorennamen in semibold
    • eine nicht fett gesetzte Überschrift einige Zeilen darunter
  • Einzug wird auch als Signal zur Absatztrennung verwendet, was die Beurteilung bei rechtsbündigen Überschriften zusätzlich erschwert
  • Aufeinanderfolgende Überschriften mit gleicher Schriftgröße und gleichem Schriftschnitt zusammenzuführen, funktioniert im Allgemeinen gut, kann aber auch unerwünschte Ergebnisse erzeugen

Fallstricke bei der Absatzidentifikation durch Zeilenabstände

  • PDFTextStripper erkennt Absätze bereits recht gut
  • Dabei wird anhand von Zeilenabständen und Einzügen entschieden, wo Absätze getrennt werden sollen
  • Verbesserungsbedarf besteht vor allem bei der Logik für Zeilenabstände
  • Ein großes Problem von PDFTextStripper ist, dass für die Zeilentrennung ein fester Referenzwert verwendet wird
    • Ist der Abstand größer als dieser Referenzwert, wird entschieden, dass es sich nicht um denselben Absatz handelt
    • Dass sich Zeilenabstände je nach Dokument unterscheiden, wird dabei nicht ausreichend berücksichtigt
  • In wissenschaftlichen Entwürfen und Preprints sind 1,5- bis 2-fache Zeilenabstände recht verbreitet
  • Setzt man den Grenzwert zu hoch an, können manche Überschriften in Fließtextabsätze absorbiert werden, was die Überschriftenerkennung stört

Korrektur über Zeilenabstandsstatistiken

  • Ähnlich wie bei der Behandlung von Schriftgrößen lässt sich auch auf den Abstand zwischen Zeilen eine statistische Methode anwenden
  • Erstellt man für eine Textseite ein Histogramm der Zeilenabstände, treten meist große Ausreißer auf
  • Der Mittelwert ist anfällig für Ausreißer, aber der Median kann sehr genau dem im Fließtext verwendeten Zeilenabstand entsprechen
  • Verwendet man auf den Median einen bestimmten Faktor, lässt sich eine robuste Heuristik zur Absatztrennung erzeugen, die auch bei unterschiedlichen Zeilenabständen funktioniert

Ein realistisches Ziel ist Stabilität statt Perfektion

  • Die Extraktion von Text aus PDFs lässt sich nur schwer perfekt machen
  • Das PDF-Format selbst wurde für solche Aufgaben nicht entworfen, und bei der Wahl einer „hinreichend guten“ Lösung entstehen verschiedene Trade-offs
  • Für Suchmaschinen sind insbesondere folgende Informationen wichtig
    • Relevanzsignale wie Überschriften
    • die Identifikation des Abstracts
    • eine einigermaßen konsistente Struktur des restlichen Textes
  • Mit solchen Zielen kann man sich einer Lösung nähern, die die meisten relevanten Dokumente ohne allzu große Probleme verarbeitet

Verwendete Beispieltexte

  • Can Education be Standardized? Evidence from Kenya (2022) - Working Paper
  • Guthrie Gray-Lobe, Anthony Keats, Michael Kremer, Isaac Mbiti, Owen W. Ozier
  • The theory of ideas and Plato’s philosophy of mathematics (2019)
  • Dembiński, B.
  • The role of phronesis in Knowledge-Based Economy (2024)
  • Anna Ceglarska, Cymbranowicz Katarzyna

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2025-05-15
Meinungen auf Hacker News

  • Es kommt vor, dass man völlig vergisst, dass man sich früher monatelang oder jahrelang in etwas vertieft und Expertenniveau erreicht hatte, und später denkt: „Das ist neu und interessant.“
    Man hat ziemlich viele spannende Dinge gemacht, aber sie verschwinden aus dem Gedächtnis, sodass man sich wie jemand fühlt, der sein Leben neu beginnt, bis irgendetwas sie wieder auslöst.
    Ich erinnere mich vage, vor etwa 6–7 Jahren ziemlich coole Sachen mit PDF und OCR gemacht zu haben, und beim Nachsehen war es wohl Tesseract.

    • Um 2006 herum habe ich mich bei einem frühen E-Book-Reader namens iRex damit beschäftigt, warum man aus mehrspaltigen wissenschaftlichen Papers keinen Text kopieren konnte. Da der PDF-Reader intern Poppler verwendete, habe ich Poppler so angepasst, dass es anhand eines von Tesseract-Autor Thomas Breuel veröffentlichten OCR-Algorithmus die Lesereihenfolge mehrspaltiger Dokumente ableitet.
      Das war eher ein heuristischer Hack, und die alte Poppler-API stellte Text-Runs damals meiner Erinnerung nach nicht in einer für Accessibility-APIs geeigneten Form dar.
      Die mehrspaltige Auswahl wurde bis zu einem gewissen Grad aufgenommen, aber spätere Vorschläge zur Performance-Verbesserung waren schwer bei den Maintainern durchzubekommen, weil sich die Heuristik leicht änderte und die Auswahl in manchen Fällen anders ausfiel.
      Schon grundsätzlich gab es nicht die eine „richtige Antwort“, daher war es unsinnig, identische Ergebnisse zu verlangen, und so entstand die mehrspaltige Auswahl in kpdf zumindest teilweise.
      Heutzutage ist es für diesen Zweck wahrscheinlich sinnvoller, direkt Tesseract zu verwenden.
    • Die durch dieses Format kollektiv verbrannten Jahrzehnte an Arbeitszeit lassen sich niemals zurückholen.
      Ich weiß nicht, wann dieser Wahnsinn endet.
    • Tesseract war lange die beste Open-Source-OCR, aber heute halte ich docTR für besser.
      Die Standardgenauigkeit ist höher, es gibt GPU-Beschleunigung, und es implementiert mehrere Modellarchitekturen zur Texterkennung und -detektion als kombinierbare Pipeline.
      Mit PyTorch oder TensorFlow kann man es trainieren und feinabstimmen, um die Leistung in bestimmten Domains weiter zu steigern.
    • Als mich jemand nach C++ fragte, antwortete ich einmal: „Ich habe nie ernsthaft mit C++ gearbeitet“, und dann fiel mir ein, dass ich vor etwa 20 Jahren mit Borland C++ den Code für einen privaten Messenger-Client geschrieben hatte, den Tausende nutzten.
      Solche Dinge passieren also wirklich.
    • Jedes Mal, wenn ich ein Projekt abschließe, denke ich oft: „Jetzt bin ich Experte darin geworden. Aber vermutlich werde ich das nie wieder machen.“
      Die nächste Aufgabe liegt dann in einem völlig anderen Bereich, und ich fange wieder bei den Grundlagen an.

  • Es wäre schön, wenn jemand so etwas wie Browser-Entwicklertools für PDFs bauen würde.
    Man könnte wie bei „Element untersuchen“ den Content Stream eines PDFs als Quelle ansehen und nachvollziehen, wie BT … ET-Textoperatoren oder Tj-Textplatzierungsoperatoren die einzelnen Pixel spezifizieren und erzeugen.
    Das ist das Gegenteil des heutigen Trends, bei dem visuelle Modelle PDFs wie ein Mensch „ansehen“ und lesen, aber es wäre viel besser, tatsächlich verstehen zu können, was in einer PDF-Datei steckt.
    Es gibt einige Tools zum Untersuchen von PDF-Inhalten (https://news.ycombinator.com/item?id=41379101), aber sie hören auf der Ebene von PDF-Objekten auf, sodass der gesamte Content Stream nur als ein einzelnes Objekt erscheint.
    Auf PDF-Seite 8, also Seite 6 der im Artikel erwähnten Datei https://bfi.uchicago.edu/wp-content/uploads/2022/06/BFI_WP_2..., wird Text beispielsweise mit Operatoren wie BT, Font-Einstellungen, Td und TJ platziert.
    Wenn man diese „Quelle“ und das gerenderte PDF nebeneinander sehen könnte und beim Überfahren einer Seite mit der Maus der entsprechende Bereich auf der anderen Seite hervorgehoben würde, ließe sich das wie eine HTML-Seite debuggen.

    • Wenn man ein PDF mit Mozillas PDF.js ins DOM rendert, könnte man dem ziemlich nahekommen.
      Zum Beispiel würde vermutlich jedes Tj zu einem DOM-Element, und TJ zu einer Gruppe mehrerer Elemente.
      Da es das Originaldokument korrekt widerspiegeln muss, dürfte die Umwandlung recht genau sein.
    • Mit cpdf geht das bis zu einem gewissen Grad.
      Mit cpdf -output-json -output-json-parse-content-streams in.pdf -o out.json erzeugt man JSON, bearbeitet dieses JSON und kann es anschließend mit cpdf -j out.json -o out.pdf wieder in ein PDF zurückverwandeln.
      Allerdings gibt es keine bidirektionale Echtzeit-Verknüpfung.
    • Gemeint war vermutlich Open Source oder kostenlos, aber Acrobat Pro, das ich vor einigen Jahren benutzt habe, hatte fast eine ähnliche Funktion.
      Allerdings inspizierte man nicht die Seite selbst, sondern navigierte durch den Content Tree, und Objekte auf der Seite wurden hervorgehoben.
      Bis auf Befehlsebene ging es nicht, nur bis zur Objekt- oder Stream-Ebene.
    • Dieses Notebook ist nicht ganz das, was gewünscht ist, bietet aber eine Funktion, um verschiedene Zeichenoperationen in PDFs „live“ zu untersuchen.
      https://observablehq.com/@player1537/pdf-utilities
    • Was Tensorlake baut, kommt dieser Kombination ebenfalls nahe.
      Es geht nicht nur darum, ein PDF wie ein Mensch „anzusehen“ und nur den Text zu lesen, sondern darum, Inhalte einschließlich Tabellen, Bildern, Text, Formeln und Handschrift zu verstehen.
      Deshalb wird das PDF geparst, es werden mehrere Modelle ausgeführt und Markdown-Fragmente oder JSON extrahiert, damit die tatsächlichen Daten in AI-Agents, LLMs und andere Anwendungen eingespeist werden können.
      https://tensorlake.ai

  • „PDF zu Text“ ist eine viel zu starke Vereinfachung
    In diese Kategorie fallen 1) zuverlässige OCR für Suchindizes oder als Input für Vektor-DBs, 2) strukturierte Datenextraktion, bei der bestimmte Werte herausgezogen werden, und 3) End-to-End-Dokumentenpipelines wie die Automatisierung von Hypothekenanträgen
    Was Marginalia lösen muss, ist OCR nach Punkt 1, und durch Modelle wie Gemini Flash wird das schnell zur Commodity
    Ich habe gesehen, wie mehrere Unternehmen ihre bestehenden OCR-Pipelines durch Flash ersetzen und dadurch die Kosten stark senken; das war ziemlich beeindruckend
    Punkt 2 und 3 sind jedoch deutlich schwieriger, und zwischen rohem OCR-Output und mission-critical Dokumentenpipelines in Produktionsumgebungen klafft noch eine große Lücke
    LLMs und Vision-Language-Modelle sind keine Magie, und wer 100 % Automatisierung erwartet, wird überrascht werden
    Der Aufbau und das Labeling von Datensätzen, die Orchestrierung von Klassifizieren -> Aufteilen -> Extrahieren-Pipelines, Unsicherheitserkennung und Human Review sowie Fine-Tuning sind weiterhin nötig
    Langfristig kann man zwar nahezu vollständiger Automatisierung näherkommen, aber das braucht Zeit und Aufwand; die Zukunft scheint sich klar in diese Richtung zu bewegen
    In diesem Zusammenhang habe ich eine LLM-Dokumentenverarbeitungsfirma namens https://extend.ai gestartet

    • Aus Sicht der Barrierefreiheit braucht es auch Punkt 4: zuverlässige OCR und semantische Extraktion, die über viele verschiedene Dokumenttypen hinweg funktioniert
      Business-Workflows haben es oft nur mit einigen wenigen festgelegten Dokumenten zu tun, aber ein universeller PDF-Reader weiß nicht, welche Dokumente Nutzer öffnen werden
      Er muss nicht nur Text erkennen, sondern auch Tabellen, Kopf- und Fußzeilen, Fußnoten, Überschriften, mathematische Formeln usw.
      Da die Ausgabe für Menschen gedacht ist, müssen Fehler minimiert werden; deshalb sollte OCR nicht eingesetzt werden, wenn sie unnötig ist, und man muss den im PDF enthaltenen Basistextext nutzen und zugleich die semantische Struktur extrahieren
      Letztlich braucht es zwei Pfade: einen für PDFs, die nur aus Bildern bestehen, und einen für PDFs, bei denen Informationen aus dem Content Stream gewonnen werden können
      Im Content Stream kann allerdings Text stehen, der von der tatsächlichen Anzeige abweicht. Beispiele sind mit weißer Schrift versteckte Informationen oder LaTeX-artige Implementierungen, die Akzentzeichen per Befehl zeichnen statt Unicode-Akzente zu verwenden
      Das läuft meist als lokale App auf leistungsschwachen Geräten der Nutzer, und da es wahrscheinlich kein Server- oder Abo-Modell gibt, kann man auch keine Cloud-KI-Modelle verwenden
      Nutzer von Accessibility-Software können Schwierigkeiten haben, Formulare auszudrucken und mit Stift auszufüllen; daher müssen nicht nur sauber spezifikationskonforme Formulare verarbeitet werden, sondern auch Formulare, die für den Druck gedacht sind
      Das ist ein offenes Problem, dessen Lösung noch lange nicht in Sicht ist; alle heutigen Ansätze haben auf irgendeine Weise Defizite, und es gibt keine einzelne Lösung, die alle fünf genannten Punkte wirklich gut löst
    • Aus der Perspektive von jemandem, der eigene Tools bauen musste, weil Vision-Language-Modelle zu instabil waren, dürften Unternehmen, die VLMs auf unverarbeiteten Bildern einsetzen, erhebliche Schmerzen bekommen
      Beim Image Labeling sind sie sehr gut, und für einfache Dokumente wie einspaltigen Text, zentrierte einstufige Überschriften oder ein einzelnes Bild bzw. eine einzelne Tabelle pro Seite sind sie in Ordnung
      Die meisten MVP-Demos zeigen genau solche Beispiele
      Bei komplexen Dokumenten mit gemischten Tabellen und Bildern bräuchte es meiner Einschätzung nach noch viel mehr Parameter, um überhaupt „schlecht“ zu sein
      Derzeit halluzinieren sie so stark, dass selbst eine einfache Tabelle mit Titel oben, Daten in der Mitte und Zusammenfassung unten kaum direkt verwendbar ist
    • Ich versuche weiterhin, PDFs nach Markdown zu verarbeiten, und stoße wie im Originalbeitrag auf Header-Erkennung und diverse andere Probleme
      Heutige OCR ist hervorragend, aber die globale Dokumentstruktur zu erhalten, ist deutlich kniffliger
      Konsistentes HTML aus großen Dokumenten zu bekommen, scheint noch in weiter Ferne; Markdown liefert halbwegs brauchbare Ergebnisse, wenn man das Dokument mehrfach durch ein LLM schickt, die Dokumentstruktur extrahiert und sie dann als Kontext in die seitenweise Extraktion einspeist

  • Apple hat dieses Problem über mehrere Jahre hinweg recht erfolgreich bearbeitet; der Kerntrick war, alles als Geometrie zu betrachten und mit Cluster-Analyse zwischen Wortabständen und Zeichenabständen unterscheiden zu wollen
    Bei vielen PDFs funktioniert das sehr gut, aber PDFs sind so vielfältig, dass es immer Fälle mit eher schlechten Ergebnissen gibt
    Würde ich es heute noch einmal machen, würde ich die Geometrie beibehalten und OCR komplett vermeiden, aber Machine Learning einsetzen
    Der große Vorteil von Machine Learning ist, dass man mit vorhandenen Tools, die aus bekanntem Text PDFs erzeugen, die Trainingsphase vollständig automatisieren kann
    Szene, in der Bertrand Serlet diese Funktion auf der WWDC 2009 vorstellt: https://youtu.be/FTfChHwGFf0?si=wNCfI9wZj1aj9rY7&t=308

  • Eine bessere Lösung wäre, das editierbare Originaldokument mit in das PDF einzubetten
    In LibreOffice ist das leicht möglich, und weil es sich gut komprimieren lässt, kostet es normalerweise kaum Speicherplatz
    Dann bekommt man deutlich bessere Informationen über Text und Bedeutung, und es funktioniert weiterhin gut mit bestehenden PDF-Readern

    • Stimmt, aber die Interessen von PDF-Erzeuger und -Konsument müssen zusammenpassen
      Im Bereich eDiscovery kommt es häufig vor, dass die beweisliefernde Partei Dinge absichtlich als PDF dumpet, damit die gegnerischen Anwälte die Inhalte schwerer auswerten können
      Wenn beide Seiten viel Geld haben, ist das keine Barriere; ein Pflichtverteidiger etwa hat aber kein Budget, um jemanden einzustellen, der PDFs in ein leicht lesbares Format überführt, wodurch die Bearbeitungszeit deutlich länger wird und die psychische Belastung für den Angeklagten steigt
      Möglicherweise können die Daten sogar gar nicht korrekt verarbeitet werden
      Die Lösung besteht darin, ein solches Verhalten illegal zu machen
      Abhördaten sollten beispielsweise in einem standardisierten maschinenlesbaren Format bereitgestellt werden, und es gibt keinen ethischen Grund dafür, dass bloße technische Reibung den Ausgang eines Strafverfahrens beeinflusst
    • Es ist merkwürdig, dass die bessere Lösung für das Problem einer Suchmaschine, die Text aus bestehenden PDFs extrahieren muss, ein Ratschlag dazu sein soll, wie PDFs erstellt werden sollten
      Ich frage mich, wie lange es dauern würde, bis diese Lösung Wirkung zeigt
    • Stimmt, aber dadurch entsteht auch eine Schwachstelle, bei der das Originaldokument beliebig vom gerenderten PDF-Inhalt abweichen kann
    • 90 % des Problemraums dürften Legacy-PDFs sein
      Auch in unserer Firma gibt es Tausende solcher Dateien; einige sind miserable Scans, einige haben von Adobe OCR eingebettet, aber die meisten enthalten gar nichts
    • Wenn man Zugriff auf das Originaldokument hat, aus dem das PDF erstellt wurde, ist das ein guter Ansatz
      Üblicherweise hat man diese Kontrolle aber nicht

  • Das folgende PDF ist tatsächlich eine .txt-Datei.
    Wenn man sie mit der Endung .pdf speichert, lässt sie sich in einem PDF-Viewer öffnen und auch mit einem Texteditor bearbeiten.
    Man kann diese Textdatei zum Beispiel so bearbeiten, dass sich der beim Öffnen des PDFs angezeigte Text, die Schriftart, Schriftgröße, der Zeilenabstand, die maximale Zeichenzahl pro Zeile, die Zeilenzahl pro Seite, Papierbreite und -höhe sowie Hoch- bzw. Querformat ändern.
    Das Beispiel ist eine minimale PDF-Struktur, die mit %PDF-1.4 beginnt und Catalog, Pages, Font, Page, Contents, xref, trailer usw. direkt als Text beschreibt.

    • PDFs können auch eingebettete binäre Streams enthalten.
      PDF wurde nicht für Text entwickelt, sondern für Layout und Grafik.
      Das Beispiel ist gut, aber jede Zeile kann auch in einen Aufruf pro Zeichen oder einen Aufruf pro Wort zerlegt sein, und die Reihenfolge kann durcheinandergeraten.
    • „PDF“ steht für „Portable Document Format“.
      Im Abschnitt „2.3.2 Portability“ der PDF-1.0-Referenz wird eine PDF-Datei als 7-Bit-ASCII-Datei beschrieben; selbst Dokumente mit Bildern und Sonderzeichen werden demnach ausschließlich mit der druckbaren Teilmenge von ASCII beschrieben.
      Dadurch sei sie über verschiedene Hardware- und Betriebssystemumgebungen hinweg sehr portabel.
      https://opensource.adobe.com/dc-acrobat-sdk-docs/pdfstandard...
    • Das ist so etwas wie das Hello World von PDF.
      Die meisten heutigen PDFs haben alle Objekte mit Deflate komprimiert.
      Um das Nachverfolgen zusätzlich zu erschweren, packen viele PDFs außerdem den Großteil der Objekte in Objekte vom Typ Objekt-Stream und komprimieren sie erneut.
      Wenn man also das Ende von 6 0 R verfolgen will, kann man im Texteditor nicht einfach nach 6 0 Obj suchen.

  • Es gibt ein Dokument, das ich mag, weil es die in diesem Beitrag beschriebenen Schwierigkeiten zeigt: https://academic.oup.com/auk/article/126/4/717/5148354
    Schon auf der ersten Seite gibt es den typischen zweispaltigen Text, einen zentrierten Titel und eine Textbox zwischen den beiden Spalten, die Zeilenlänge und Einrückung verändert.
    Später kommen Kopfzeilen hinzu, die sich auf ungeraden und geraden Seiten unterscheiden, sowie stark variierende Regeln für Abschnittsüberschriften.
    Noch schlimmer: Es gibt keinen zusätzlichen Abstand zwischen Absätzen, und eine Einrückung der ersten Zeile ist auch nicht immer vorhanden – damit ist praktisch die ganze Palette an Problemen enthalten.

    • Die CoreGraphics-PDF-API von macOS lieferte den Text standardmäßig seitenweise in der Reihenfolge, in der er im Dictionary codiert war.
      In etwa 95 % der Fälle war das ziemlich gut, und für PDFKit und Preview auf dem Mac reichte das viele Jahre lang aus.
      Wenn man an die ursprüngliche App denkt, die das PDF erzeugt hat – etwa eine Textverarbeitung –, hat sie den Text vermutlich in einer recht sinnvollen Reihenfolge aus ihrem eigenen Textpuffer in den PDF-Kontext gerendert.
      Deshalb floss der Text selbst bei zweispaltigen Dokumenten oft korrekt von der linken in die rechte Spalte und lag im PDF bereits in der richtigen Reihenfolge vor.
      Bei Fuß- oder Kopfzeilen weiß man allerdings nicht, in welcher Reihenfolge die erzeugende PDF-App sie in den Kontext gekippt hat.

  • Text aus PDFs zu extrahieren, erst recht strukturierten Text, ist überhaupt nicht einfach.
    Tabellen aus HTML-Dokumenten zu scrapen ist oft simpel, selbst wenn eine Website das Anti-Pattern nutzt, alles mit div zu bauen; mit semantischen Elementen wird es noch einfacher.
    Bei PDF ist das nicht so.
    Ich bin kein Formatspezialist und weiß nicht, wie viel Unterstützung es für semantische Struktur gibt, aber ich habe viele PDFs gesehen, in denen Tabellen aus einer losen Sammlung von Grafik- und Textelementen bestehen, die nur beim Rendern wie eine Tabelle aussehen.
    In der Praxis hatte ich recht guten Erfolg damit, PDFs mit den Poppler-PDF-Utilities nach HTML zu konvertieren, dann die erwarteten Tabellenüberschriften zu suchen und anhand der x-Koordinaten der einzelnen Werte die Spalten zu berechnen, um die Werte zeilenweise zu extrahieren.
    Das ist ein schmutziger Ansatz, funktionierte für den benötigten Zweck aber zuverlässig und war deutlich besser als formatierter Fließtext mit unregelmäßigen Abständen oder Zeilenumbrüchen mitten in einer Zeile.

    • Weil es frustrierend ist, dass man aus PDFs nicht so Daten extrahieren kann wie aus Webseiten mit BeautifulSoup, habe ich eine Bibliothek gebaut, die in etwa etwas Ähnliches macht.
      Sie hat auch verschiedene Nebenfunktionen, aber das Kernziel ist, auf eine menschlichere Art zu interagieren, etwa mit page.find('text:bold:contains("Summary").below().extract_text().
      Da jedes PDF ein maßgeschneiderter Albtraum ist, sammle ich schwierige Extraktionsbeispiele, um sie als Grundlage für eine Methodenbibliothek zu nutzen.
      https://jsoma.github.io/natural-pdf/
      https://badpdfs.com/
    • Am liebsten sind mir offizielle Regierungsdokumente, bei denen der gerenderte Text und der Text, der bei einer üblichen Extraktion herauskommt, völlig verschieden sind.
    • Ich hoffe, dass meine Software zur Datenbereinigung eines Tages Tabellendaten aus PDFs extrahieren kann.
      Falls jemand eine PDF-Tabellenextraktionsbibliothek kennt, die sich in eine C++-App integrieren lässt und kostenlos ist oder weniger als ein paar Hundert Dollar kostet, würde ich mich über einen Hinweis freuen.
    • PDF ist im Kern ein Markup-/XML-Format, und der Standard ist öffentlich und lässt sich erlernen.
      Es gibt wirklich viele Wege, dasselbe PDF zu erzeugen.
      Manche Tools ähneln eher einem Grafikeditor, der ein Layout mit Text und Grafiken exportiert; andere eher einer Textverarbeitung, bei der Wörter im Vordergrund stehen und Text und Grafiken exportiert werden.
      Die Sichtweise der erzeugenden App darauf, wie sie Informationen behandelt, beeinflusst häufig auch die Art der PDF-Ausgabe.
      Wenn man ein fertiges Utility sucht, haben Tools wie cisdem das Problem zumindest so weit gelöst, dass sie lokalen Nutzern recht gut strukturierte Daten extrahieren.
      Es gibt viele solcher Tools, und viele versprechen Unterstützung für strukturierte Daten, aber sie müssen zu der Aufgabe passen, die man erledigen will.

  • PDF ist ein Anzeigeformat.
    Es ist für das menschliche Auge und Drucker optimiert, und seine Funktionen sind im Laufe der Zeit immer weiter gewachsen.
    Als Mittel zur Datenübertragung zwischen Maschinen ist es miserabel, aber zum Lesen durch Menschen oder zum Speichern einer A4-Seite ist es sehr gut geeignet.
    Wenn man mit der Annahme beginnt, dass eine .pdf Text speichert und man genau diesen Text haben will, läuft es letztlich darauf hinaus, sich einfach größere Augen zuzulegen.
    Oder man muss sich mit etwas sehr Komplexem auseinandersetzen.
    Schon die Frage, ob dieser Text wirklich Text oder ein Bild ist, ist ein Problem.
    Das menschliche Auge kann ihn, notfalls mit neu aufgesetzter Brille, trotzdem lesen, aber ein Parser kann an Segmentierungsfehlern scheitern.
    Da PDFs zum Lesen durch Menschen gedacht sind, muss man Menschen nachahmen, um PDFs zu lesen.

  • Früher habe ich einmal einen Spielzeug-PDF-Parser gebaut, und nachdem ich verstanden hatte, wie das Format funktioniert, war ich ziemlich verblüfft.
    Wenn man das bedenkt, ist es umso seltsamer, dass PDF so häufig für textlastige Anwendungsfälle genutzt wird.
    Besonders denke ich dabei an Fälle wie Rechnungen.
    Digitale Systeme sollten Daten leicht aus der Datei extrahieren können, während sie zugleich für Menschen ansprechend formatiert ist.
    Es wäre wohl deutlich besser, wenn die Tech-Branche auf ein geeigneteres Format umsteigen würde.

    • XML+XSLT war beinahe eine solche Lösung, aber leider unterstützen Browser lokale XML-Dateien inzwischen nicht mehr, sondern nur noch XML von Remote-Servern.