In meinem heutigen Blog-Eintrag möchte ich auf ein grundsätzliches Thema in unseren Viewer-Produkten eingehen: die pixelgenaue Darstellung von Dokumenten. Der Fokus liegt hierbei auf PDF, aber im Grundsatz geht es auch um alle anderen Formate. Ich möchte an dieser Stelle vorausschicken, dass ich im Gegensatz zu unseren PDF-Experten über eher oberflächliches Wissen im Bereich PDF verfüge, es kann daher an manchen Stellen etwas unscharf werden.
Farben und Mehr
An dieser Stelle möchte ich nochmal einen Blick auf die Historie der jadice Produkte werfen: Angefangen hat alles mit dem jadice viewer auf Basis von Swing. Hier ist man technologisch schon recht nahe am Bildschirm des Anwenders, zumindest im Vergleich zu einer Darstellung im Browser (jadice web toolkit). Ich meine hierbei vor allem DPI, Auflösung und Farbprofile. Im jadice web toolkit werden beim Rendering Bilder erstellt, die über den Browser dem Client zur Darstellung übergeben werden. Wir haben hier keine Möglichkeit und auch keine Informationen über mögliche Farbprofile eines Bildschirms oder Ähnliches. Von der hardware-seitigen Einstellung des physischen Bildschirms (Helligkeit, Kontrast, Farben) gar nicht zu sprechen.
Reden wir nun kurz über PDF. PDF ist seit 2008 in ISO 32000 standardisiert. Der Standard erfasst jedoch nicht alles, was technisch möglich ist und ist außerdem an manchen Stellen unscharf. Wahrscheinlich haben 90% unserer Kunden bereits ein Support-Ticket eröffnet mit den Worten „in Acrobat wird es aber richtig angezeigt“. Das ist wahrscheinlich korrekt und über die Gründe könnte man vermutlich etliche eigene Blog-Beiträge schreiben. Einige Gründe hierfür sind aber unter anderem, dass jeder PDF-Viewer den Standard anders auslegt und interpretiert und Acrobat einen grundsätzlich anderen Ansatz verfolgt, als jadice das früher getan hat. Acrobat ist sehr tolerant bei der Anzeige, jadice hat seit jeher viel Wert auf eine pixelgenaue Darstellung gelegt.
Xerox
Wieso haben wir das getan? In der Branche, in der wir uns früher beinahe ausschließlich bewegt haben, war es sehr wichtig, Dokumente möglichst genau darzustellen. Wenn beispielsweise falsches Rendering eines Dokumentes dazu führt, dass eine Versicherungssumme (fälschlicherweise) nicht ausgezahlt wird, hat dies für die beteiligten Personen sehr weitreichende Folgen. Ein Beispiel, das bei den alteingesessenen jadice Entwicklern herumspukt, ist das Beispiel Xerox aus den frühen 2010er Jahren. Xerox hat bei seinen Scannern den JBIG2 Algorithmus verwendet, welcher sehr kompakte Scans (hinsichtlich Dateigröße) von Dokumenten ermöglichte. Der Algorithmus arbeitet in etwa so, dass wiederkehrende Muster nur einmalig abgespeichert werden und bei der Anzeige dasselbe Muster dann mehrfach wieder ausgegeben wird. In der Praxis hat dies aber dazu geführt, dass bei Scans einzelne Ziffern durch andere Ziffern ersetzt wurden. Anstatt einer Rechnungssumme von 500.000€ konnte es also vorkommen, dass 50.000€ dargestellt wurde.
jadice: Strict- und Lenient-Mode
Der Standard-Anzeigemodus für PDF in jadice war bzw. ist daher der so genannte Strict-Mode. Hierbei ist die Anzeige nicht tolerant gegenüber kleinen und großen Fehlern im Dokument und es wird auch keine Interpretation oder Heuristik, beispielsweise bei fehlenden Daten vorgenommen; Fehler in der PDF Struktur führen gegebenenfalls zu Fehlern im Programmablauf und Abbruch beim Lesevorgang. Ein kleines Beispiel: PDF Dokumente bestehen im einfachsten Fall aus mindestens vier Teilen: Header, Objekte, XRef (Cross-Reference-Table) und Trailer. Die XRef-Table ordnet die vorgegangenen Objekte (unter anderem Texte und Bilder im Dokument) ihrem Byte-Offset innerhalb des Datenstroms zu. Ist die XRef-Table fehlerhaft, bricht jadice die Anzeige im Strict-Mode ab, da das Dokument fehlerhaft ist. Im jadice Anzeigemodus „Always generate XRef“ kann ein Dokument mit fehlerhafter XRef-Table dennoch angezeigt werden. Der Anzeigemodus „Lenient“ wendet Heuristiken an, um gewisse Strukturfehler automatisch zu korrigieren und somit eine Anzeige eines defekten Dokuments zu ermöglichen.
Der Lenient-Mode ist mit jadice web toolkit 6 zum Standard geworden, wir haben hier die Annahme getroffen, dass ein Kunde ein Dokument „einfach anzeigen möchte“. Ob eine Überschrift um 10 Pixel verschoben wurde, oder eine Farbe etwas zu dunkel dargestellt wird, ist dabei unerheblich. Es ist jedoch so, dass es Dokumente gibt, die im Lenient-Anzeigemodus ganz anders dargestellt werden als im Strict-Modus. Wir haben speziell präparierte Dokumente, die zu sehr unterschiedlichen Ergebnissen führen.
Es handelt sich dabei jedoch um bestimmte Konstellationen, in denen die Abweichungen so deutlich ausfallen. Gezielte Manipulationsversuche in diesem Zusammenhang sind uns nicht bekannt.
Andere Geräte
Der Paradigmenwechsel, der bei jadice stattgefunden hat und noch immer stattfindet, geht teilweise auch auf den folgenden Umstand zurück: Früher wurden Dokumente immer auf einem relativ großen PC-Bildschirm dargestellt. Spätestens seit 2007 mit dem ersten iPhone kamen langsam auch Mobilgeräte hinzu. Und die Veränderungen sind mit Handys nicht abgeschlossen.
Haben Sie mal versucht, ein Vertragsdokument auf einer Apple Watch zu lesen?
Einfacher Lesemodus, Zugänglichkeit und ein bisschen KI
Ich bin daher der Meinung, dass die pixelgenaue Darstellung an Wichtigkeit verloren hat und die Zugänglichkeit von Dokumenten heute wichtiger ist. Ich vermeide hier bewusst das Wort Accessibility, da dies gleich sehr stark an eingeschränkte Anwender (meist blinde Menschen) erinnert. Bei Accessibility geht es aber um Zugänglichkeit und nicht um Behinderung (nach Scott Davis: „It’s spelled ‚accessibility‘, not ‚disability'“). Von Zugänglichkeit profitieren aber alle Anwender.
Im jadice web toolkit kann man die Zugänglichkeit beispielsweise am „einfachen Lesemodus“ in unserer Online-Demo sehen:
Klickt man auf dieses Icon, verlässt man die klassische Seiten-basierte Dokumenten-Anzeige und das Dokument wird als dynamischer fortlaufender Text (HTML) gerendert.
Der einfache Lesemodus rendert HTML, welches die beispielsweise vom Bildschirm vorgegebenen Dimensionen dynamisch nutzt, anstatt ein Dokument mit einer fixen Breite zu rendern. Ist nach fünf Wörtern der Platz des Anzeigegerätes aufgebraucht, bricht HTML einfach um.
Mit dieser Technologie lässt sich das Dokument schon recht komfortabel auf einem kleinen Gerät darstellen. Spaß macht es aber dennoch nicht, ein längeres Dokument so zu lesen. Was man mit solch einem Dokument aber eigentlich, beispielsweise auf einer Smart Watch, tun möchte, ist schnell zu erfahren, was für ein Dokument es ist und was in etwa darin steht. Bei einer Rechnung möchte ich wissen, wer mir für welche Dienstleistung welche Summe in Rechnung stellt. Die IBAN, Rechnungsnummer, Firmenlogo etc. benötige ich auf einer Smartwatch nicht, das kann ich mir dann am PC anschauen. Hierfür gibt es mit NLU (Natural Language Understanding) KI-basierte Lösungen, die in Zukunft Einzug in die jadice Produkte finden könnten oder bereits gefunden haben.
Haben Sie Gedanken oder Erfahrungen zu diesem Thema? Kontaktieren Sie mich gerne direkt, ich freue mich über einen regen Austausch!
David Werth
Software Architect & Product Owner
Einige weiterführende Links:
