HTML als Archiv-Format?

Eignet sich HTML als Archiv-Format? Gibt es dazu nicht PDF? Ist das nicht Standard?

Was verstehe ich als Archiv-Format? In meinem Sinne geht es um digitalisierte Dokumente (Berichte, Karten, Abbildungen, Tabellen, zumeist im A4-Format, aber auch sehr viel größer), die schon einige Jahre oder Jahrzehnte alt sind und im Zuge der »Digitalisierungskampagnen« endlich auch elektronisch zugänglich sein sollen.

PDF wird gerne als Standard-Archiv-Format genannt. Immerhin gibt es eine sog. PDF/A-Spezifikation, die die Zugänglichkeit im Sinne der Langzeitarchivierung ermöglichen soll.

Aber ist PDF wirklich das beste Format dafür? Hat PDF eigentlich etwas mit der Digitalisierung und Archivierung von Dokumenten zu tun?

PDF kann nämlich nur dann als Archiv-Format gelten, wenn es korrekt benutzt wird. Dazu zählen ordentlich eingetragene Metadaten, eine (verwendbare!) Texterkennung (OCR), das Aufteilen, Ausrichten und Beschneiden von Seiten. In 9 von 10 Fällen fehlt diese notwendige Nachbearbeitung, meist aus Bequemlichkeit. Für viele Menschen ist der Vorgang der Archivierung abgeschlossen, wenn die PDF-Datei ungesehen in einen Archiv-Ordner verschoben werden kann.

Daneben hat PDF das viel größere Problem, daß es meist nur als Container für gescannte Dokumente dient – und dafür hat es durchaus seine Berechtigung! Niemand will einen alten Bericht über das Durchschalten von zwei Dutzend tiff-Dateien anschauen! Was ist dann also das Problem?

Gescannte Unterlagen (digitalisierte Dokumente, siehe oben) sind keine echten Digital-Dateien. Selbstverständlich bestehen die Unterlagen nach dem Scannen nun aus Bits und Bytes. Eigentlich sind es aber nur im PDF eingebettete Fotos. Nicht mehr und nicht weniger. Das Grafikformat (.pfb, .tif, .jpg) tut dabei nichts zur Sache.

Alles Papier, das auf Scanner-Glas gelegt wurde, ist erst den halben Weg zur Digitalisierung gegangen! »Echt-digital« wäre es erst dann, wenn jemand den abstoßenden Aufwand betriebe, jeden einzelnen Satz aufs neue abzutippen, alle Tabellen neu zu setzen, Strichgrafiken neu zu zeichnen. Das wäre der wahre Preis für echte Digitalisate!

Viele Menschen meinen, beim Digitalisieren von Schriftstücken gehe es um die Wiedergabe des Original-Layouts – nur am Bildschirm. Gemeint sind Satzlayout (mehrspaltiger Satz), Position von Abbildungen und Tabellen, Schriftformatierungen usw. Das wird am leichtesten erreicht durch das Scannen der Dokumente. Das erzeugte Foto gibt das Original-Layout wieder. Mitsamt seiner ggf. abscheulichen Typographie, orthographischen Fehler oder bereits im Druck schlecht lesbaren Buchstaben.

Genauso falsch wäre es aber, eine echte Digitalisierung zu erzeugen, indem man das ursprüngliche Layout in einem Textsatz- oder Textverarbeitungsprogramm (LO Writer, MS Word, auch TeX!) nachstellt, und damit einer Vorgabe nacheifert, die ungeeignet ist. Das wäre wahrlich vergeudete Tatkraft!

Betrachten wir als Beispiel eine Schreibmaschinen-Seite, wie sie in den 1960er Jahren nicht unüblich in Archiv-Mappen abgelegt worden ist. Dem damaligen Eingabegerät geschuldet, wurden auf einer A4-Seite vergleichsweise schwer lesbare Texte erzeugt: Eine trockene Monospace-Schrift, keine (selten manuell gesetzte) Worttrennungen, Behelfe bei der Eingabe von Sonderzeichen (»mum« anstelle von »µm«, »km2« statt »km²«), weiter Zeilenabstand. Wozu sollte man derartige Umständlichkeiten mit modernen Möglichkeiten nachstellen?

Digitalisierung bedeutet also nicht den Erhalt des Original-Layouts, sondern der nackten Information. Ob der Satz ursprünglich in Schriftgröße 10, einer Monospace-Schrift und in blauer Farbe vorlag, ist unerheblich. Der Satz bleibt der Satz nur durch seine Worte. Und allein diese zu erfassen, bedeutet Digitalisierung.

Nur ein derartiges »volldigitales« Textdokument kann korrekt nach Text durchsucht werden (OCR funktioniert bei den wenigsten Schreibmaschinenseiten zuverlässig), und nur ein solches Dokument kann auf verschiedenen Ausgabegeräten nach jeweiligem Bedarf unterschiedlich ausgegeben werden (siehe nächster Punkt).

Das PDF-Format wurde für die Weitergabe an den Drucker konzipiert – es ist ja letztlich nichts anderes als ein aufgepustetes PostScript. Diesem Zweck geschuldet ist seine einzige vermeintliche Stärke, nämlich die layouttreue Wiedergabe von Dokumenten. Egal auf welchem Betriebssystem das Dokument geöffnet wird – es sieht immer gleich aus. So weit, so gut. Warum sollte es sich dann nicht als Archiv-Format eignen? Geht es nicht darum, den Original-Bericht genauso dazustellen, wie er auf Papier vorliegt?

Das stimmt. Jedenfalls, wenn Sie nicht am Bildschirm lesen. Oder eine Sehbehinderung haben. Oder Text herauskopieren wollen.

Gescannte Dokumenten liegen meistens in einem A4-Hochformat vor. Ihr Bildschirm wird ein Querformat haben. A4-Hochformat ist nicht dazu da, um am Bildschirm gelesen zu werden, dafür wurde es nie geschaffen. Die Folge ist, daß ein PDF nur durch tatkräftiges Schieben und Scrollen einigermaßen flüssig gelesen werden kann, insbesondere wenn es sich um mehrspaltigen Satz handelt.

In einem PDF kann man auch die Schriftart und -größe nicht einstellen. Man bekommt das, was das PDF bietet. Das ist im ungünstigsten Fall eine schlecht gesetzte, schlecht lesbare Schriftart. Vergrößerungen über das Dokument-Zoom sind zwar möglich, verschärfen aber das Problem des Schiebens und Scrollens der Textfläche. Dazu kommen die Seitenumbrüche, die den Lesefluß stören. Ein PDF kann sich in seinem Layout dem Bildschirm und Lesebedürfnissen nicht flexibel anpassen!

Eine HTML-Seite dagegen – und auf dieses Format will ich letztlich hinaus – enthält nur die reine Information. Der Browser dagegen bestimmt die Schriftart und -größe (jedenfalls ohne CSS-Anweisungen), und beim Anpassen der Größe des Browser-Fensters wird automatisch der angezeigte Text flexibel umgebrochen.

Menschen mit Sehbehinderung nutzen Möglichkeiten, um den im Browser angezeigten Text kontrastverstärkt darstellen zu lassen oder in starker Vergrößerung (siehe oben). Sie nutzen auch sog. Screenreader, die den Bildschirmtext mit Computerstimme vorlesen können. Das funktioniert nur dann sinngemäß, wenn (1) der Text korrekt ist und nicht auf fehlerhaftem/unvollständigem OCR basiert, und (2) wenn Informationen zur verwendeten Dokumentsprache mitgegeben werden (das ist als Metainformation in einem HTML-Dokument möglich). Webdienste nutzen diese Angabe beispielsweise, um eine Übersetzung der Seite anzubieten. Und um die Zugänglichkeit von Inhalten für alle Menschen geht es ja letztlich bei einem digitalen Archiv.

Das Herauskopieren von Text war in einem PDF schon immer eine Krux. Durch das festgelegte, unveränderliche Layout und die »eingebrannten« Worttrennungen wird das Markieren und Kopieren von längeren Textpassagen zum Geduldsspiel, und was aus dem Zwischenspeicher herauskommt, enthält ggf. Bindestriche an unpäßlichen Stellen. Handelt es sich um ein Dokument, über das nachträglich eine Texterkennung (OCR) angewendet wurde, wird in den meisten Fällen unsinniger Buchstabensalat kopiert. Nachbearbeitung der herauskopierten Texte ist in den meisten Fällen unumgänglich.

Wem diese Mankos beim täglichen PDF-Lesen noch nicht aufgefallen sind, sollte einen Moment darüber nachdenken.

Das Öffnen einer PDF-Datei wird immer mehr Speicher und CPU-Leistung anfordern als das Darstellen von HTML-Text. Das ist auf älteren Geräten relevant.

PDF-Dateien enthalten beim sorglosen Erstellen nicht selten inkompatible Schriftarten, was, insbesondere in Verbindung mit mehrspaltigem Satz, zu einer eigenartigen Darstellung nach dem Öffnen führen kann. Die Layouttreue ist also in der Tat nur bei gescannten Dokumenten = Fotos gegeben.

PDF-Dateien mit gescannten Inhalten werden IMMER größer sein als ein entsprechendes HTML-Dokument. Ein Größenvergleich zwischen einer einzigen gescannten Dokumentseite (inkl. Fusseln, Zwischenräumen, Daumen, die allesamt Pixel-Bytes belegen!) und einem HTML mit demselben Textinhalt ist beeindruckend. Dokumente, die gescannt 100e Megabyte Speicherplatz belegen, können als reines HTML nur einige 100 Kilobyte groß sein. Auch das ist – sehr wohl! – ein relevanter Aspekt beim Vorhalten eines Archivs (Server-Speicherplatz).

Werden PDF-Dateien beschädigt, können sie nur selten wiederhergestellt werden, weil die ursprünglichen Formatierungsanweisungen nicht enthalten sind.

Verblüffenderweise sind Programme zum Erzeugen und Lesen von PDFs weniger verbreitet (und kosten Geld!) als solche zum Erzeugen und Darstellen von HTML. Jeder Browser liest HTML. HTML ist die Sprache des Internets und wird auf jedem Betriebssystem, auf jedem Mobilgerät verstanden. HTML kann von jedermann ohne zusätzliche Software mit einem beliebigen Texteditor angelegt und bearbeitet werden.

Jetzt, da ich PDF ordentlich madig gemacht habe, stellt sich die Frage, ob fairerweise auch etwas für PDF spricht. Einige Argumente gibt es:

• PDFs lassen sich verschlüsseln. (Das ergibt bei Verwendung in einem möglichst zugänglichen Archiv allerdings keinen Sinn.) HTML-Dateien können andererseits in einem verschlüsselten Archiv (ZIP o.ä.) zusammengefaßt werden.
• Für PDFs lassen sich Rechte vergeben, etwa die Erlaubnis zum Drucken eines Dokuments. Hierzu gehören auch Wasserzeichen und digitale Unterschriften. Das ist möglicherweise bei der Weitergabe von Archiv-Dokumenten mit brisanten/geschützten Informationen wichtig.
• Es besteht die Möglichkeit zum Schwärzen von Textpassagen. Das Verbergen personenbezogener Daten kann durchaus sinnvoll und berechtigt sein. HTML verbirgt gar nichts.
• PDF bettet alle Grafiken zusammen mit Text ein (bei HTML stets getrennt). Im PDF enthaltene Grafiken sollten dann aber auch für Bildschirme optimiert sein (z.B. keine übertriebene Auflösung haben). Die strikte Trennung zwischen Text und Grafiken (HTML) bringt allerdings den Vorteil mit sich, daß extern gespeicherte Bilder jederzeit separat verarbeitet werden können. PDF hält also alles in einer Datei vor, während HTML auf verschiedene Quellen zugreift, um DIESELBE Information im Browser darzustellen.

Alle oben genannten Punkte gereichen HTML allerdings nicht zum Nachteil. Denn HTML läßt sich problemlos in PDF konvertieren. Anschließend lassen sich Passagen schwärzen, Wasserzeichen anbringen, Rechte vergeben etc.

Beide Formate können nachträglich mit zusätzlichen Zeichenelementen ausgestattet werden. Dazu zählen Kopf- und Fußzeilen (die beispielsweise Angaben zum Digitalisierungsprozeß, Archiv-Nummer oder das Logo des Archivs aufnehmen) sowie Buttons für das Weitersenden oder Drucken.

Sowohl bei PDF als auch HTML können Links auf weiterführende Seiten, Dateien, Quellen hinterlegt werden.

Beide Formate ermöglichen das Verorten von nicht zum Dokument gehörenden Anmerkungen, bei PDF im Sinne von Kommentarboxen, bei HTML z.B. mit dem aline-Tag.

Im Kopfbereich einer HTML-Datei kann angegeben werden, ob ein Crawler den Inhalt indizieren soll – oder eben nicht. Normalerweise wird darüber den Crawlern/Spidern von Suchmaschinen die Erlaubnis gegeben oder verweigert, den Inhalt der Seite (und ggf. aller verlinkter Unterseiten) in ihren Suchindex aufzunehmen. Ob sich die Crawler allerdings an diese Bestimmung halten, kann niemand überprüfen.

Im Hinblick auf die Archiv-Digitalisierung könnte man über diese HTML-Funktion mitteilen, daß besonders brisante Dokumente zwar digitalisiert worden sind, aber nicht über eine Suchanfrage gefunden werden dürfen.

• HTML ist ein weltweit genutzter Standard und zum Datenaustausch über das Internet konzipiert worden.
• Es dient primär der Anzeige von Informationen am Bildschirm.
• Die Syntax der wichtigsten HTML-Befehle ist in einer halben Stunde erlernt.
• HTML-Seiten können ohne zusätzliche Software auf jedem Betriebssystem oder mobilen Gerät angezeigt werden. Browser genügt.
• HTML-Code kann mit jedem beliebigen Texteditor bearbeitet werden, notfalls geht auch eine Textverarbeitung wie MS Word oder LO Writer.
• HTML kann unkompliziert in viele andere Formate konvertiert werden (Markdown, TeX, PDF, Open Document, Word-Formate usw.)
• Die Trennung von Inhalt und Formatierung ermöglicht auf einfache Weise die Kontrolle über ein einheitliches Aussehen der HTML-Dateien (alle Laborberichte eines Jahrgangs im gleichen Aussehen usf.)
• In HTML können Tabellen, Abbildungen, Formeln und Videos eingebunden werden. Bezogen auf ein Medien-Archiv müßte man nicht erst Bild- und Video-Dateien zum Ansehen downloaden, sondern könnte sie direkt über die Webseite einbinden, Player-Elemente inklusive.
• HTML kann sehr leicht über eine vorhandene Weboberfläche eingebunden werden. Das ist Zweck und Aufgabe von HTML. Als HTML-gespeicherte Digitalisate von Dokumenten könnten damit problemlos Teil einer bestehenden Web-Infrastruktur des Archivs oder der betreffenden Institution/Behörde werden.

Würde jemand ein Digital-Archiv jemals auf HTML umstellen? Denn das ginge nur dann, wenn man eine Armee Sekretärinnen beschäftigte, die alle Texte neu abtippen (eine sinnvolle Arbeitsbeschaffungsmaßnahme?) Für die meisten ist mit dem Abspeichern eines PDFs der Digitalisierungsprozeß ja »hinreichend abgeschlossen«. Wer sich jedoch die Digitalisierung ernsthaft in die Agenda gesetzt hat, muß diesen zweiten Schritt gehen.

Richtig ist, daß auch nach der Sinnhaftigkeit unterschieden werden muß: Niemand braucht jeden belanglosen Geschäftsbrief neu abtippen, nur, weil er das Pech hatte, auf der Schreibmaschine verfaßt worden zu sein. Und auch ich erfreue mich an der Schönheit einer mittelalterlichen Handschrift aus einer Museumsbibliothek. Da sich gebrochene Schrift (Textur, Fraktur und Bastarda, von tatsächlichen »Handschriften« abgesehen!) ohnehin fast nie fehlerfrei mit OCR erfassen läßt, wäre in diesen historischen Fällen eine Transkription zu HTML allerdings eine Möglichkeit, den Text auch in gebrochenen Schriften ungeübten Lesern zugänglich zu machen. Derartige echte Digitalisierungen existieren z.B. für Kirchenbuch-Einträge, mit denen dann Ahnenforscher ihre Familienstammbäume verfolgen.

Ausdrücklich muß darauf hingewiesen werden, daß das erneute Abtippen von Dokumenten immer eine Fehlerquelle ist. Möglicherweise wird der digitalisierte Text durch Tippfehler beeinträchtigt (Suche nach Schlagworten usw.). Andererseits kann es nicht schlimmer als eine mißratene Texterkennung (OCR) sein. Für Interessierte sei auf die spannende Geschichte der Digitalisierung des »Deutschen Wörterbuchs« der Gebrüder Grimm verwiesen, das nicht von Deutschen, sondern Chinesen abgetippt worden ist. Letztere haben ein besseres Auge für Details an Buchstaben (Fraktur!) und lassen sich durch die ihnen fremde Sprache auch nicht durch unbemerkte Wortergänzungen ablenken (Mitlesen/Mitdenken während des Tippens).

Wäre ein Kompromiß die Lösung? Erst alles als PDF scannen, anschließend die wichtigsten Dokumente zu HTML transkribieren? Ob man damit doppelte Arbeit hat, oder ob man die Original-Orthographie beibehalten sollte – solche Fragen liegen dann im Ermessen der Verantwortlichen. Was allerdings von allen verstanden werden muß: GESCANNT IST NICHT DIGITAL!