Warum kleine Schriftarten die
OCR-Genauigkeit beeinträchtigen – 4 Ursachen und Lösungen

Das Problem ist die Physik, nicht die KI

Wenn eine OCR-Engine oder ein KI-Visionsmodell bei kleinen Texten versagt, ist der erste Impuls, die Software zu beschuldigen. Doch der eigentliche Engpass liegt vor jeder KI-Verarbeitung – er wird durch die Anzahl der verfügbaren Pixel pro Zeichen bestimmt.

Hier ist die Mathematik. Ein „Punkt" in der Typografie entspricht 1/72 Zoll. Bei 150 DPI (dots per inch, der Auflösung eines typischen Faxgeräts oder Low-End-Scanners) beträgt die Pixelhöhe eines Zeichens:

Pixelhöhe = Schriftgröße (pt) × DPI / 72

Für ein 6pt-Zeichen bei 150 DPI:

6 × 150 / 72 = 12,5 Pixel

Zwölf Pixel entsprechen in etwa der Höhe eines einzelnen Buchstabens in der kleinsten Schriftgröße, die Ihr Betriebssystem in einem Terminalfenster zulässt. Überlegen Sie nun, was in einem Zeichen in dieser Größenordnung passiert. Die Unterscheidungsmerkmale, die „8" von „6" trennen – eine geschlossene obere Schleife vs. eine geschlossene untere Schleife – umfassen maximal 2 bis 3 Pixel. Ein einzelnes Pixel Rauschen vom Scannersensor, eine winzige Schräglage der Seite oder der JPEG-Kompressionsblock eines Handyfotos können diese Unterscheidung vollständig aufheben. Das Zeichen „m" und die Buchstabenkombination „rn" belegen bei kleinen Größen dieselbe Spaltenbreite von 2-3 Pixeln – sie werden strukturell identisch.

Dies ist kein Problem, das durch besseres KI-Training oder ausgefeiltere OCR-Nachbearbeitung gelöst werden kann. Dem Eingangssignal fehlen die Informationen, die jedes Erkennungssystem für die korrekte Ausgabe benötigt. Jeder nachfolgende Fix in diesem Artikel umgeht diese Einschränkung oder reduziert sie – aber die Einschränkung selbst ist unvermeidbar.

Wie viele Pixel braucht ein Zeichen tatsächlich?

Um zu verstehen, wann kleine Schrift ein praktisches Problem darstellt, setzt man Schriftgröße und Scanauflösung in Bezug zur Pixelhöhe. Die kritische Schwelle für die Zeichenerkennung liegt bei etwa 20-25 Pixeln Zeichenhöhe für eine zuverlässige Unterscheidung ähnlicher Glyphen:

✗ = unzuverlässig    ⚠ = grenzwertig    ✓ = i.d.R. zuverlässig für gedruckten Text. Dies sind Schätzung der Zeichenhöhe – die Erkennung hängt auch von Strichstärke, Kontrast und Schriftart ab.

Die Tabelle macht das Muster deutlich: Bei standardmäßigen 300 DPI liegt 6pt-Text genau an der Grenze. Bei 200 DPI – der Auflösung vieler Büro-Multifunktionsgeräte und der meisten gefaxten Dokumente – ist alles unter 10pt grenzwertig oder unzuverlässig. Bei 150 DPI (üblich für Faxe und minderwertige PDFs) ist nur noch 12pt und größer zuverlässig.

Ursache 1: Scan-Auflösung unter 200 DPI

Die häufigste Einzelursache für fehlerhafte Texterkennung bei kleiner Schrift ist eine zu niedrige Scan-Auflösung. Das Problem liegt nicht an der Scanner-Hardware selbst, sondern daran, dass der Scan-Workflow auf lesbare Schrift (~10-12pt Fließtext) ausgelegt ist und niemand ihn für die kleineren Zeichen in Fußnoten, Tabellenzellen, rechtlichen Hinweisen und Formularanweisungen angepasst hat.

Warum 200 DPI die Gefahrenschwelle ist: Bei 200 DPI ergibt ein 8pt-Zeichen – die typische Größe vieler Tabellenwerte und Formularbeschriftungen – nur 22 Pixel Höhe. Zeichen wie „e" und „c" werden nahezu ununterscheidbar, da die offene Gegenform (der Innenraum des Buchstabens) auf 1 Pixel schrumpft. Die Schleife einer „8" und der Bogen einer „6" belegen denselben 2-Pixel-Vertikalraum. Deshalb produzieren gefaxte Rechnungen und gescannte Verträge regelmäßig Erkennungsfehler in kleinschriftigen Abschnitten, während der Haupttext einwandfrei aussieht.

Was zu prüfen ist: Wenn Ihr gescanntes PDF von einem Büro-MFP (Multifunktionsdrucker) im Standardmodus „Normalqualität" stammt, liegt die Auflösung fast sicher bei 200 DPI. Gefaxte Dokumente kommen je nach Sender-Gerät mit 100-200 DPI an. Bevor Sie das Extraktionstool bemängeln, überprüfen Sie die effektive DPI des Eingabebildes: Öffnen Sie die Dateieigenschaften in einem Bildbetrachter und teilen Sie die Pixelbreite durch die physische Seitenbreite in Zoll. Liegt das Ergebnis unter 250 DPI und enthält Ihr Dokument Text unter 10pt, ist die Auflösung höchstwahrscheinlich die Ursache.

Mehr dazu, wie die Bildqualität die Erkennungsgenauigkeit bei verschiedenen Dokumenttypen beeinflusst, finden Sie in unserem Leitfaden zu niedriger OCR-Genauigkeit bei gescannten Dokumenten.

Ursache 2: Schriftart verstärkt das Auflösungsproblem

Nicht alle 8pt-Zeichen sind gleich. Die Schriftart bestimmt, wie viel vom verfügbaren Pixelbudget tatsächlich für die Erkennung nutzbar ist:

Serifenlos vs. Serifenschrift bei kleinen Größen. Eine Serifenschrift wie Times New Roman fügt dekorative Striche (Serifen) an den Enden der Buchstabenstämme hinzu. Ab 10pt verbessern diese Serifen die Lesbarkeit. Bei 6-8pt auf einem 200-DPI-Scan verschmelzen die Serifen mit dem Hauptstrich, verdicken das Zeichen unvorhersehbar und erschweren die Trennung benachbarter Zeichen. Serifenlose Schriften (Arial, Helvetica, Calibri) haben diese zusätzlichen Striche nicht, weshalb ihre einfacheren Formen eine niedrige Scan-Auflösung besser überstehen. Tesseracts eigene Dokumentation und mehrere Bibliotheksrichtlinien empfehlen ausdrücklich serifenlose Schriften für OCR-freundliche Dokumente.

Dünne/leichte Schriftstärken. Die „Light"- oder „Thin"-Stärke einer Schriftfamilie – beliebt im modernen Markendesign, bei Finanzbericht-Headern und minimalistischen UIs – verwendet Striche, die bei üblichen Scan-Auflösungen nur 1 Pixel breit sein können. Bei einer Strichbreite von einem Pixel führt jedes Rauschen, jeder Komprimierungsartefakt oder jede Scanner-Sensor-Variation entweder zum Bruch des Strichs (das Zeichen wird unsichtbar) oder zu einer asymmetrischen Verdickung (die Zeichenform ändert sich). Fette und normale Stärken mit 2-3 Pixel Strichbreite bei gleicher Auflösung haben eine deutlich höhere Toleranz gegenüber diesen Artefakten.

Schriften mit mehrdeutigen Glyphen. Bestimmte Schriftarten machen Zeichen, die bereits für OCR schwierig sind, noch schwieriger. Arial beispielsweise stellt Kleinbuchstabe „l" (L) und Großbuchstabe „I" (i) identisch dar – das einzige Unterscheidungsmerkmal ist der Kontext, den traditionelle OCR nicht hat. Bei kleinen Größen wird diese Mehrdeutigkeit noch schlimmer, da jeder verbleibende visuelle Unterschied (ein Bruchteil eines Pixels in der Serife oder Strichhöhe) vollständig verschwindet.

Das praktische Muster: Wenn das Kleingedruckte in Ihrem Dokument eine moderne, leichte serifenlose Schriftart verwendet (üblich bei europäischen Kontoauszügen, SaaS-Rechnungen und Anlageberichten), treten Extraktionsfehler bereits bei Schriftgrößen auf, bei denen eine fettere oder serifenbetonte Schrift noch lesbare Ergebnisse liefern würde. Die Schriftart verursacht das Problem nicht – sie bestimmt jedoch, ab welcher Pixelhöhe das Problem sichtbar wird.

Ursache 3: Alles extrahieren statt priorisieren

Dies ist weniger ein technisches Problem als ein Workflow-Design-Problem – aber es ist eine der häufigsten Frustrationsquellen bei der Extraktion von Kleingedrucktem.

Viele Anwender gehen mit der Erwartung an die Extraktion heran, dass alles auf der Seite erfasst werden muss: jede Zeile, jeder Haftungsausschluss, jede Fußnote, jede Randnotiz. Wenn ein 6-Punkt-Haftungsausschluss am unteren Rand eines Kontoauszugs verstümmelte Ausgabe liefert, wirkt es, als sei die gesamte Extraktion fehlgeschlagen. In der Praxis wurden der Fließtext und die wichtigsten Finanzzahlen möglicherweise einwandfrei extrahiert – der Fehler beschränkte sich auf einen Textabschnitt, den kein praktischer Workflow tatsächlich benötigt.

Die Feldpriorisierungsstrategie: Teilen Sie den Inhalt des Dokuments vor der Extraktion in drei Kategorien ein:

• Kritische Felder (10pt+) – Rechnungsnummern, Summen, Daten, Lieferantennamen, Kontonummern, Policennummern. Diese sind fast immer in einer lesbaren Schriftgröße gesetzt und tragen das finanzielle oder operative Gewicht. Extrahieren Sie diese mit hoher Zuversicht.
• Ergänzungsfelder (8-10pt) – Referenzcodes, Abteilungsnamen, Steueraufschlüsselungen, Mengenfelder. Meist bei 300 DPI extrahierbar, bei niedrigeren Auflösungen möglicherweise grenzwertig. Markieren Sie diese zur Stichprobenprüfung.
• Nebentext (unter 8pt) – Haftungsausschlüsse, Urheberrechtsvermerke, AGB, Seitenfußzeilen, Anleitungen im Kleingedruckten. Diese werden in einem strukturierten Daten-Workflow selten benötigt. Erwägen Sie, sie ganz aus der Extraktion auszuschließen, anstatt dass Fehler in diesen Feldern das Vertrauen in das Gesamtergebnis untergraben.

Bei Verwendung eines KI-Extraktionstools mit benutzerdefinierter Spaltenextraktion (bei der Sie die benötigten Spaltennamen eingeben und die KI die Werte semantisch lokalisiert), ist diese Priorisierung von Natur aus in den Workflow integriert: Sie definieren nur Spalten für die Daten, die Sie tatsächlich benötigen. Die KI verschwendet keine Verarbeitungskapazität für Dokumentabschnitte, die Sie nie angefordert haben. Enthält eine Spalte einen Wert aus einem Bereich mit kleiner Schrift, gibt der Konfidenzwert einen natürlichen Hinweis zur manuellen Überprüfung.

Das gleiche Prinzip gilt für die Stapelverarbeitung: Wenn Sie 50 Lieferantenangebote extrahieren und die kleingedruckten Bedingungen mit gemischter Genauigkeit in jede Zeile übernommen werden, fragen Sie sich, ob Sie diese Bedingungen überhaupt in der Tabelle benötigen. Oft lautet die Antwort nein – und das Weglassen verbessert sowohl die Extraktionsgeschwindigkeit als auch die wahrgenommene Qualität der Ausgabe.

Ursache 4: Subpixel-Rendering-Artefakte in Screenshots

Diese Ursache ist für das menschliche Auge praktisch unsichtbar, führt aber zu einigen der verwirrendsten Extraktionsfehlern. Sie betrifft nur Screenshots – aber da ein wachsender Teil der Dokumentenverarbeitung mit Bildschirmaufnahmen beginnt (Dashboard-Exporte, Rechnungen aus Webportalen, Screenshots von mobilen Apps), ist sie für mehr Arbeitsabläufe relevant, als die meisten vermuten.

Moderne Betriebssysteme nutzen Subpixel-Rendering (ClearType unter Windows, Core Text unter macOS), um die Textschärfe auf LCD-Bildschirmen zu verbessern. Die Technik funktioniert, indem sie einzelne rote, grüne und blaue Subpixel innerhalb jedes Bildschirmpixels ansteuert und so die horizontale Auflösung für die Textdarstellung effektiv verdreifacht. Für Ihr Auge wirkt kleiner Bildschirmtext dadurch scharf und klar. Für eine OCR-Engine, die den Screenshot als flaches Bild verarbeitet, erscheint derselbe Text jedoch mit farbigen Rändern – roten und blauen Kanten an den Zeichenrändern – die die Kantenerkennung, Binarisierung und Zeichensegmentierung stören.

Traditionelle OCR-Engines, die auf Schwellwertverfahren basieren (das Bild vor der Erkennung in Schwarzweiß umwandeln), reagieren besonders empfindlich auf dieses Artefakt. Wenn der Binarisierungsschritt auf eine Zeichenkante mit einem roten Subpixel-Rand trifft, kann er den Rand entweder als Teil des Zeichens oder als separates Objekt interpretieren – in beiden Fällen verschiebt sich die Zeichengrenze unvorhersehbar. Bei normalen Schriftgrößen (10-12pt) ist das Artefakt im Verhältnis zum Zeichen klein, und die OCR-Engine kann noch richtig raten. Bei 6-8pt kann der Subpixel-Rand so breit sein wie die Zeichenlinie selbst, was zu einer Ausgabe führt, die scheinbar farbiges Rauschen statt Text „liest".

So testen Sie dies: Wenn Sie schlechte Ergebnisse von einem Screenshot erhalten, aber dasselbe mit 300 DPI gescannte Dokument einwandfrei funktioniert – und der Text so klein ist, dass das menschliche Auge ihn auf dem Bildschirm kaum lesen kann –, dann ist Subpixel-Rendering wahrscheinlich ein Faktor. Versuchen Sie, den Browser oder die Anwendung vor dem Screenshot auf 150 % zu zoomen. Das erhöht das Pixelbudget pro Zeichen und macht den Subpixel-Rand proportional kleiner.

Für einen detaillierteren Blick auf screenshot-spezifische Extraktionsherausforderungen, einschließlich Farb-, Kontrast- und Skalierungsproblemen, siehe Warum die OCR-Extraktion auf farbigen Hintergründen und Wasserzeichen fehlschlägt – viele der gleichen Bildqualitätsprinzipien gelten für Screenshots mit kleinem Text.

Was wirklich hilft: Eine praktische Fehlerbehebungshierarchie

Die folgenden Korrekturen sind geordnet von höchster Wirkung / geringstem Aufwand bis zu geringster Wirkung / höchstem Aufwand. Beginnen Sie oben und hören Sie auf, sobald die Genauigkeit für Ihren Workflow akzeptabel ist.

Fix 1: 300+ DPI für Dokumente mit kleiner Schrift anstreben

Wenn Sie den Scan-Schritt kontrollieren, ist dies die mit Abstand effektivste Maßnahme. Scannen Sie Dokumente mit bekanntermaßen kleiner Schrift unter 10pt mit 400-600 DPI statt der üblichen 300 DPI. Der OCR-Best-Practices-Leitfaden der University of Pittsburgh bestätigt, dass 400-600 DPI speziell für Dokumente mit kleiner Schrift empfohlen werden. Der Nachteil sind größere Dateien und langsamere Verarbeitung, aber für die Teilmenge von Seiten, bei denen die Genauigkeit kleiner Schrift wichtig ist, lohnt sich die höhere Auflösung. Bei gefaxten oder gemailten Dokumenten, deren Quelle Sie nicht beeinflussen können, vermerken Sie die Auflösungsgrenze als bekannte Einschränkung in Ihrem Workflow – nicht alle Dokumente lassen sich mit gleicher Genauigkeit extrahieren, und das ist in Ordnung, solange die Erwartungen entsprechend gesetzt sind.

Fix 2: Feldpriorisierung im Extraktionsdesign anwenden

Überprüfen Sie Ihre Spaltendefinitionen und entfernen Sie jedes Feld, das auf kleine, beiläufige Schrift abzielt. Wenn die 6pt-Fußzeile eine Lieferantenregistrierungsnummer enthält, die Sie beim Abgleich noch nie verwendet haben, entfernen Sie die Spalte. Jede entfernte Spalte ist eine Quelle für Ausgaben mit geringer Konfidenz, die nicht mehr verifiziert werden müssen. Nutzen Sie bei der benutzerdefinierten Spaltenextraktion die Konfidenzsignale des Tools – wenn ein Feld durchgängig Werte mit geringer Konfidenz liefert, prüfen Sie, ob der Quelltext so klein ist, dass die KI tatsächlich rät. Entscheiden Sie dann, ob das Feld mit manueller Verifizierung behalten werden soll oder ob Sie es anders beziehen können.

Lösung 3: Super-Resolution-Hochskalierung — mit Vorsicht verwenden

KI-basierte Hochskalierung (Super-Resolution, SR) kann einen Scan mit 150 DPI durch Interpolation neuer Pixel zwischen vorhandenen auf scheinbare 300 DPI vergrößern. Die Ergebnisse bei kleinem Schrifttext sind gemischt: Einfache Nächste-Nachbarn- oder bilineare Hochskalierung fügt keine neuen Informationen hinzu – sie verteilt dieselben 12 Pixel nur auf mehr Fläche. KI-Super-Resolution-Modelle (SRGAN, ESRGAN, Real-ESRGAN), die auf Dokumentbildern trainiert wurden, können bei mäßig degradiertem Text, insbesondere bei gedruckten, kontrastreichen Zeichen, einige Strichdetails wiederherstellen. Bei kleinem Schrifttext, dem bereits unterscheidbare Pixelmerkmale fehlen, kann SR jedoch keine nie erfassten Merkmale erfinden – es kann optisch glattere Ausgabe erzeugen, ohne die Zeichengenauigkeit tatsächlich zu verbessern. Der zuverlässigste Anwendungsfall für SR ist die Vergrößerung von Text aus einem bereits grenzwertigen Scan (z. B. von 200 DPI auf 400 DPI), bevor er an ein Extraktionstool übergeben wird – erwarten Sie nicht, dass SR Text rettet, der in Faxauflösung erfasst wurde.

Zu Vorverarbeitungstechniken, die vor der Extraktion wirken, einschließlich Hochskalierung, Binarisierung und Entschiebung, siehe unseren OCR-Bildvorverarbeitungsleitfaden.

Lösung 4: Bessere Quelldokumente anfordern, wenn möglich

In vielen professionellen Arbeitsabläufen – insbesondere in der Kreditorenbuchhaltung, Vertragsverwaltung und Steuerdokumentenverarbeitung – haben Sie die Möglichkeit, eine bessere Quelle anzufordern. Wenn ein Lieferant eine gefaxte Rechnung mit 150 DPI sendet und die Positionsbeschreibungen in 7pt durchweg unlesbar sind, bitten Sie den Lieferanten, stattdessen ein digitales PDF zu mailen. Wenn ein Subunternehmer eine Kopie einer Kopie eines unterschriebenen Formulars einreicht, fordern Sie das Original oder ein sauberes Foto an. Diese Lösung ist nicht immer verfügbar (einige Alt-Lieferanten faxen nur, einige behördliche Formulare gibt es nur in einem festen Druckformat), aber sie ist häufiger verfügbar als Teams annehmen. Die Kosten einer E-Mail-Anfrage sind geringer als die Kosten für die manuelle Korrektur von 50 Extraktionsfehlern in einer Charge.

Die ehrliche Grenze: Unter 7 pt ist für jedes System unzuverlässig

Keine Genauigkeitssteigerung, Workflow-Anpassung oder Tool-Aufrüstung wird 6-pt-Text aus einem 200-DPI-Scan zuverlässig extrahieren können. Das Pixelbudget reicht einfach nicht aus. Die Erkennungsgenauigkeit von gedrucktem Text unter 7 pt erreicht auf Zeichenebene maximal etwa 60–80 % – das bedeutet, dass 20–40 % der Zeichen falsch gelesen werden – unabhängig davon, ob die Engine eine traditionelle OCR oder ein modernes Vision-Language-Modell ist. Die 6-pt-Zahl auf Ihrer Rechnung wird nicht mit 99 % Feldgenauigkeit extrahierbar sein, und die verantwortungsvolle Antwort ist, manuelle Prüfung oder Auslassung einzuplanen, anstatt Zeit in die Optimierung eines Workflows für eine Eingabe zu investieren, die die Physik der Digitalisierung nicht unterstützen kann.

Diese Grenze gilt für jedes derzeit produktiv eingesetzte System. Nicht nur für Tesseract, nicht nur für Legacy-OCR – sie gilt gleichermaßen für Google Cloud Vision, Amazon Textract und Tools auf Basis von Vision-Language-Modellen. Der Unterschied zwischen diesen Tools bei kleinem Schriftgrad wird in Prozentpunkten gemessen, nicht in Größenordnungen. Vision-KI-Modelle haben bei Text unter 7 pt einen Vorteil, weil sie den umgebenden Kontext nutzen, um ein fehlendes Zeichen zu erraten – wenn die KI unter vertrauten Rechnungsköpfen „Rechn_g_Nr.“ sieht, kann sie die korrekten Werte ableiten – aber dieses kontextuelle Raten hat eine Obergrenze. Wenn Zeichen unterhalb einer bestimmten Pixelschwelle wirklich mehrdeutig sind, ist die Inferenz bestenfalls eine fundierte Vermutung.

Für einen breiteren Überblick über die Genauigkeitserwartungen bei verschiedenen Dokumenttypen und -bedingungen siehe unseren praktischen Leitfaden zur Verbesserung der OCR-Genauigkeit.

Häufig gestellte Fragen