PDF/A ist das griffige Kürzel für eine am 1. Oktober 2005 publizierte ISO-Norm „ISO 19005-1, Document management – Electronic document file format for long-term preservation – Part 1: Use of PDF 1.4 (PDF/A-1)“. Und wie der Name bei genauem Lesen verrät, ist es eher eine Gebrauchsanweisung zur Benutzung von PDF 1.4 (siehe Kasten: PDF-Historie) und kein neues Format. Mit diesem Standard steht zum ersten Mal ein für viele (nicht alle) Archiv-Dokumente geeignetes Format zur Verfügung, welches eine Reihe von Problemen bisher verwendeter Formate löst. Das dadurch begründete große Interesse am Markt für PDF/A ging leider gleichzeitig einher mit einer Fülle von Missverständnissen und Vereinfachungen. Der folgende Artikel soll die grundlegenden Aspekte erläutern und Missverständnisse auflösen.

Risiken jahrzehntelanger Aufbewahrung proprietärer Formate
PDF/A wurde am 13. September 2005 nach mehrjähriger Arbeit – begonnen in einer Arbeitsgruppe der AIIM (Association for Information and Image Management) – offiziell verabschiedet. Hintergrund war das Problem, dass sehr viele Unternehmen, Behörden und Organisationen Dokumente viele Jahre aufbewahren und reproduzieren müssen. Die Speicherung der nativen, proprietären Formate wie IBM 1403 oder AFP, Microsoft Word oder Excel etc. erscheint vielen Organisationen als nicht hinreichend zukunftssicher, weil man nicht weiß, ob man für IBM 1403-Druckdaten in 20 Jahren noch einen Viewer verfügbar hat oder ob und wie man das MS Word-Dokument auf einem Nicht-Windows-Client lesbar machen kann, der bei einem leseberechtigten Bürger, Partner etc. im Einsatz ist. Auch PDF kam nur bedingt in Frage, weil sich mit diesem Containerformat eine Vielzahl von Features nutzen lassen (JavaScript, HyperLinks, eingebettete Dateien), bei deren Verwendung eine zukünftige einwandfreie Reproduzierbarkeit nicht zugesichert werden kann.

Je länger die Aufbewahrungsfristen, desto größer diese Unsicherheit. Klassische Beispiele sind Lebens- und Sozialversicherungen, deren Dokumente mehrere Jahrzehnte aufbewahrt werden müssen und die in der Regel sehr umfangreiche Archive verwalten müssen. Solche Organisationen wollen sich verständlicherweise nicht mit der Idee anfreunden, Dokumente alle paar Jahre in neue Formate konvertieren zu müssen, um der Pflicht zur Reproduktionsfähigkeit gesichert nachkommen zu können. Gleiches gilt für viele andere Branchen: Kraftwerksbetreiber, Chemie- und Pharmabranche, Anlagenbauer und viele andere. Alle diese Hersteller müssen ihre Produkte, Komponenten oder Produktionsverfahren dokumentieren. Und da die betriebsgewöhnliche Nutzungsdauer einer Brücke oder eines Kraftwerks deutlich über die vergleichsweise bescheidenen 10 Jahre der kaufmännischen Aufbewahrung hinausgeht, bestand hier immer der Bedarf nach einem Dokumentenformat, das sowohl die funktionalen als auch archivischen Anforderungen erfüllt.

TIFF: Öffentliche und Private Angelegenheiten
TIFF (TIFF steht für Tagged Image File Format) war viele Jahre das dominierende Dateiformat für archivische Dokumente, erfüllt heute aber viele aktuellen Anforderungen nicht mehr. TIFF ist eine Spezifikation, die auf die Firma Aldus zurückgeht, den ursprünglichen Hersteller von PageMaker, der revolutionären Software, die mit dem Apple Macintosh den Markt für Desktop Publishing begründete. In solchen Anwendungen werden Image-Dateien zum Beispiel in einem Scanner erzeugt und in einer anderen Umgebung (z.B. PageMaker auf dem Apple Mac oder im Satzbelichter eines anderen Herstellers) verarbeitet. Ohne eine verbindliche Vereinbarung, wie die verschiedenen Hard- und Software-Systeme eine solche Bitmap-Datei interpretieren, war die gesamte Verarbeitungskette auf individuelle proprietäre Lösungen angewiesen und dadurch fehleranfällig und teuer. Ein Image-Austausch Format musste her. Und genau das war das Ergebnis des Vorschlags von Aldus, die eine erste TIFF-Version im Herbst 1986 veröffentlichte.

Von der Version 1.0  bis zur aktuellen Version 6.0 (veröffentlicht im Juni 1992, dann bereits von der Firma Adobe, die die Firma Aldus übernommen hatte)  hat sich an dieser grundlegenden Funktionalität von TIFF nichts geändert: Es ist ein breit akzeptiertes Format für Image-Dateien, die sich aber bezüglich zahlreicher Merkmale unterscheiden dürfen: Farbtiefe (von bitonal – also rein schwarz oder rein weiss – bis Farbe), Auflösung, Kompressionsalgorithmen etc. Wie diese Merkmale ausgeprägt sind, steht in den so genannten „public tags„, das sind nichts anderes als Merkmalskennzeichner und diese stellen den Kern der TIFF-Spezifikation dar. Zum besseren Verständnis: In der heutigen XML-Welt würde man sagen, man hätte ein „Schema“ für Image-Dateien.

Kein Standard für TIFF-Annotationen
Dieses „Schema“ kann auch individuell angepasst werden: ein Hersteller kann Tag-Nummern bei Adobe für spezifische Verwendungen reservieren lassen, zum Beispiel weil er an bestimmten Stellen im TIFF-Container Textannotationen, Stempel  oder sonstige Markups unterbringen möchte. Diese „private Tags“ sind aber eben – wie der Name schon sagt – „private“ Kennzeichner und die Lesbarkeit in TIFF-Viewern, die diese private tags nicht kennen, ist dann auch nicht möglich. Berühmte Beispiele sind die Annotationen im Eastman-TIFF-Viewer, der ab Windows 98 (Hintergrund war ein Patenrechtsstreit zwischen Microsoft und Wang, später Eastman Software) mit dem Betriebssystem mitgeliefert wurde. Mit Windows XP wurde dieses Bundling nicht mehr fortgesetzt, was viele Anwender mit der Tatsache konfrontierte, dass die Eastman-Annotationen nicht standardisiert sind und man sich nicht darauf verlassen kann, dass die Informationen langfristig reproduziert werden können, nur weil Microsoft sie zur Verfügung stellt.

1986 bis 2000: TIFF ist das vorherrschende Archivformat für eingehende und häufig auch ausgehende Dokumente
Diese TIFF-Spezifikation erlaubt also die Erzeugung von Bitmaps, die unkomprimiert oder – und jetzt wird es Archiv-relevant – komprimiert im TIFF-Container  untergebracht werden können. Eine der zugelassenen Kompressionsformate sind die in der CCITT genormten Kompressionsverfahren für den Faxdienst – häufig kurz CCITT G3 oder G4 genannt und in Anlehnung daran nennt man diese Formate TIFF G3 bzw. TIFF G4. Diese erlauben die Kompression bitonaler Image-Dateien (vulgo: schwarz-weißer Dokumente, keine Graustufen, keine Farbe). Und genau das war der Grund, warum sich TIFF G3 oder TIFF G4 als dominierendes Format im Archivmarkt verbreitet haben: breite Unterstützung, Multi-Plattform, erfüllt als „Abbild“ die regulatorischen Anforderungen zur „bildlichen Identität“ der eingehenden Handelsbriefe“ und eine relativ geringe Dateigröße im Vergleich  zu unkomprimierten TIFFs.

Mitte der 80er Jahre bis Ende der 90er Jahre war TIFF G4 (Gruppe 3 wird kaum noch verwendet) das dominierende Archivformat für Eingangspost aber auch häufig verwendet für Ausgangspost, die per Vertiffung ebenfalls in Bitmaps gewandelt wurde. Die Vertiffung hat den Vorteil, dass man die Druckformate wie IBM 1403, AFP zur Reproduktion nicht interpretieren musste und man muss auch keine Ressourcen vorhalten (Fonts, verlinkte Hintergrundlayer etc.), um das damalige Abbild des Ausgangsschreibens zu reproduzieren.

PDF: Format-Monopol im Internet
Zunehmend machten sich aber Limitierungen des TIF-Formates bemerkbar angesichts neuer Anforderungen, von denen viele mit TIFF nicht gut oder gar nicht abdeckbar sind.

• Text und Farbe auf einer Seite ist in TIFF nicht möglich. Die ganze Seite ist entweder G4-komprimiert (geeignet für schwarz-weißen Text) oder JPEG (geeignet für Farbfotos). Eine Kombination beider Verfahren auf einer einzigen Seite ist nicht möglich. Das ist aber genau was, was viele Unternehmen – zum Beispiel Versicherungen im Schadensbereich – benötigen. PDF kennt diese Limitierungen nicht. Auf einer einzigen Seite können sich unterschiedliche Elemente – Texte, Grafiken, Bitmaps befinden und alle Viewer seit Version 1.0 können diese darstellen.
• Die Abspeicherung von per OCR ermitteltem Volltext der Bitmapseite ist in der offiziellen TIFF-Spezifikation nicht vorgesehen und daher nur mit Hilfe von private tags als proprieätre Lösung (wie in den Microsoft Office Imaging Komponenten) machbar. Solche Lösungen werden dann benötigt, wenn eingehende Dokumente auch inhaltlich durchsucht werden müssen. PDF bietet hierfür seit Version 1.4 die Multilayer-Funktionen an, die im Viewer übereinander gelegt werden. Farbe kann im Hintergrundlayer, Schwarz-Weiße-Textbitmaps im Vordergrundlayer und per OCR ermitteltem Text in der invisible Text-Layer abgelegt werden. Import-Filter für derartige PDFs bietet jede beliebige Volltext-Engine. Mit anderen Worten: Das gescannte Dokument sieht so aus wie ein farbiges Bitmap (und erfüllt damit die regulatorischen Anforderungen nach bildlicher Identität für eingehende Handelsbriefe), die Datei ist trotzdem relativ klein, weil Farbfotos anders komprimiert werden wie Schriften und der Text ist inhaltlich recherchierbar: sowohl via Volltextdatenbank als auch im Viewer selbst.
• Die Dokumente sollen nicht nur den eigenen Mitarbeitern, sondern in Zeiten von E-Billing, e-Government etc. auch Externen zur Verfügung gestellt werden, die höchstwahrscheinlich keinen TIFF-Viewer, dafür aber mit größter Wahrscheinlichkeit einen PDF-Viewer zur Verfügung haben.

Aus allen diesen Gründen gehen Anwender zunehmend dazu über, PDF als präferiertes Format für die Archivierung zu verwenden, und zwar nicht nur für die Ausgangsdokumente, sondern häufig auch für Eingangsdokumente. Die dort erzeugten TIFF-Dateien wurden einfach in einen PDF-Container „gestopft“. Dies funktioniert recht einfach, da PDF als Multiformat-Container auch TIFF G3 oder TIFF G4 umfasst. Und damit kann auch der Mac-Anwender ein „TIFF-Dokument“ anzeigen, weil er es als PDF ausgeliefert bekommt. Diese Formatkonsolidierung Richtung PDF erlaubt einerseits eine Reduzierung der Anzahl Viewer auf der Client-Seite; gleichzeitig hat man nun die Möglichkeit, auch intern erstellte, farbige Grafik- oder Textdokumente genau so zu reproduzieren, wie sie zum Zeitpunkt der Erstellung ausgesehen haben.

Vor- und Nachteile Dokumentformate

Trotz dieser offensichtlichen Vorteile stand PDF als Archivformat häufig in der Kritik, weil es eine Ein-Hersteller-Spezifikation sei (wobei anscheinend vergessen wurde, dass die TIFF-Spezifikation ebenfalls seit 1989 der Firma Adobe gehört) und diese eine Firma nicht garantiere, dass ein im Jahre 2006 erzeugtes PDF auch noch im Jahre 2056 reproduzierbar sei. Und wer die Probleme der mangelnden Rückwärtskompatibilität der späteren PDF-Versionen zur Version 1.0 bzw. 1.1. kannte, wird diese Besorgnis teilen. Um dem abzuhelfen, begannen in der AIIM im Mai 2002 die ersten Vorarbeiten zu einer Spezifikation, die diesen Mangel nicht aufweisen sollte. Das Ergebnis ist PDF/A: eine Vereinbarung nach dem Motto: „wenn die Funktionen A, B und C genutzt werden, auf D, E und F wird aber verzichtet: dann ist sichergestellt, dass ein PDF-Viewer im Jahre 2056 ein heute erzeugtes Dokument wird auslesen können. Selbst wenn Adobe dann nicht mehr existieren würde: die Offenlegung der Spezifikation sorgt bereits heute dafür, dass es genügend Drittfirmen gibt, die gerne diese Lücken füllen.

Die funktionale Basis für PDF/A ist PDF 1.4, das mit Acrobat 5 (Adobe-Versionsregel: man addiere die Zahlen der PDF Versionen: also 1 plus 4 = 5 und erhält die Version der zugehörigen Adobe Acrobat Software. PDF 1.6 ist die Spezifikationsbasis für Acrobat 7) im Jahre 2001 veröffentlicht wurde.

PDF-Verionshistorie

Die späteren Versionen 1.5 und 1.6 umfassen weitere Funktionen, diese sind jedoch nicht Bestandteil von PDF/A-1 (eine PDF/A-2 Version ist in Arbeit und wird Features der späteren PDF-Versionen berücksichtigen)

Leitlinie für PDF/A-1 war: Das Dokument muss ohne externe Ressourcen oder Systeme alle archivierten Informationen anzeigen können. Bereits PDF 1.4 umfasst eine Reihe von Features, die gegen diese Anforderung verstoßen könnten. Kern der Arbeiten war daher die Definition, was auf Basis von PDF 1.4 erlaubt, verboten und vorgeschrieben ist.

Erlaubt sind beispielsweise:

• Text (und Hidden Text)
• Grafik (Vektorgrafik, Bitmaps)
• Layer
• Geräte-unabhängige Farbräume (müssen eingebettet sein)

Nicht erlaubt sind in PDF/A-1 u.a.:

• Audio/Video-Objekte
• Transparenz
• 3D
• JavaScript
• Farbraum-Abhängigkeiten, gemischte Farbräume (CMYK, RGB)
• Hyperlinks, die zum Zeitpunkt der Reproduktion visuelle Elemente aus externen Quellen laden. Einfache Hyperlinks wie www.zoeller.de, die sichtbare Informationen im Dokument darstellen, sind zulässig
• Verschlüsselung
• Eingebettete Dateien
• Kompressionsverfahren mit Lizenzrisiken (LZW)
• Passwörter

in PDF/A ist

• Font Embedding: Alle verwendeten Fonts müssen im Dokument enthalten sein, um alle notwendigen Komponenten bei der Reproduktion verfügbar zu haben. Das gilt auch für – aus heutiger Sicht – universell verfügbare Fonts wie Arial, Times etc.
• Fonts müssen rechtlich eingebettet werden dürfen! (Font-Lizenzen!)

Achtung: Font Embedding
Manche, die den letzten Abschnitt gelesen haben, dürften nun anfangen zu rechnen. Wenn Font-Embedding Pflicht ist, dann würde das bedeuten, dass ein Anwender, der wöchentlich 250.000 AFP-Dokumente á 5 KB Netto pro Dokument druckt zukünftig noch JEDEM Dokument alle verwendeten Fonts mitgeben müsste. Das sind je nach Fontfamilie und Anzahl verwendeter Zeichen und Fonts zwischen 10 bis 250 KB je Dokument! Es wird „intelligente“ PDF/A-Konverter geben, die nicht den kompletten ISO-Latin 1 Zeichensatz einbetten, sondern nur die im Dokument verwendeten Zeichen. Trotzdem reden wir von einer Vervielfachung der Dateigröße je Dokument. Das bedeutet die n-fache Speicherkapazität und die n-fache Leitungskapazität, die zur Verfügung gestellt werden muss. Hierzu zwei Anmerkungen:

• Unsere Empfehlung in solchen Fällen: Vor allem bei Verwendung von Massendrucksachen mit Standard-Fonts sehen wir keinen zwingenden Grund, Fonts einzubetten. Machen Sie PDF/A, aber ohne Font Embedding! Solange Sie lateinische Zeichen verwenden, wird der spätere PDF-Viewer die Dokumente mit den korrekten lateinischen Zeichen darstellen. Ein „A“ bleibt ein „A“ – auch wenn der ursprüngliche Font in 20 Jahren nicht mehr verfügbar ist. Standard-Schriften mit und ohne Serifen werden durch die PDF-Viewer auch ohne Verfügbarkeit der Schrift so ähnlich dargestellt, dass nur geschulten Typografen auffallen dürfte, dass hier eine Ersatzschrift „gebaut“ wurde. Rechtlich ist das ebenfalls nicht zu beanstanden. Eine Regel, Originalfonts vorzuhalten, kennen wir weder aus Handels- noch aus Steuerrecht. Wenn Sie allerdings aus Corporate Indetity Gründen grafisch gestaltete Fonts verwenden und sicherstellen wollen, dass exakt dieser Font in Zukunft auf allen archivierten Dokumenten sichtbar ist, dann kommen Sie um Font Embedding nicht herum. Das ist allerdings nichts Neues und hat mit PDF/A wenig zu tun. Ein PDF/A Tool würde Ihnen hier das Risiko minimieren, Font Embedding zu vergessen.

• Wenn Sie allerdings Fonts mit nicht-lateinischen Zeichen verwenden – bekannte Beispiele sind Zeichensätze wie Wingdings für PowerPoint Bullets – dann müssen Sie sicherstellen, dass diese Zeichen – sofern sie inhaltlich relevant sind – später auch wieder reproduzierbar sind. Eine einfache Möglichkeit ist ein Ressourcen-Archiv, in dem die Fonts – und andere Ressourcen – einmal abgelegt werden. Sollte der Font dann tatsächlich in Zukunft nicht mehr auf den Arbeitsplätzen verfügbar sein, wird er aus dem Ressourcen-Archiv geholt. Variante: der Reproduktionsprozess erzeugt bei Bedarf ein PDF/A-Dokument: das PDF/A-Dokument wird nicht bei der Archivierung sondern bei der Reproduktion erzeugt: die notwendigen Fonts werden aus dem Ressourcen-Archiv hinzugefügt und das Dokument als PFD/A-Dokument ausgeliefert.

Komplexes Thema: Signaturen
Ein derzeit noch strittiges Thema sind digitale Signaturen. Grundsätzlich sind Signaturen in PDF/A bereits zulässig. Allerdings hat man den Eindruck, dass sich AIIM und ISO mit der Komplexität von Signaturen und dem Unterschied zwischen einfachen Signaturen (diese kann man natürlich einbetten, aber sie haben keinerlei rechtliche Beweiskraft) zu fortgeschrittenen bzw. qualifizierten elektronischen Signaturen nicht ausreichend auseinandergesetzt haben. Eine qualifizierte elektronische Signatur – und um die geht es häufig, besonders in Deutschland –  lässt sich nur mit Hilfe externer Systeme – Trust Center oder hauseigene PKI-Infrastruktur – validieren. Aber genau diese Referenz auf externe Systeme trägt ja zur Unsicherheit bei: wie soll heute garantiert werden, dass dieser Dienst, dieses Trust Center in 50 Jahren noch vorhanden ist? Derzeit besteht aber Konsens (auch im PDF/A Competence Center), dass die Einbettung qualifizierter elektronischer Signaturen erlaubt ist, da die visuelle Lesbarkeit des Dokumentes (und um diese geht es) davon unbeeinflusst ist. In PFD/A-2 soll dieses Thema mehr Berücksichtigung finden. Wir sind gespannt, ob und wie dieser Fragenkomplex aufgelöst wird. Für die Anwender, die PFD/A Dokumente mit Signaturen archivieren wollen, sollte dies aus den o.a. Gründen kein Hinderungsgrund sein. Jedes andere Format wäre noch „proprietärer“ (wenn es diesen Superlative gäbe) als PDF/A mit spezifischen Erweiterungen. PDF/A ist für solche Anwendungen die am weitesten gehende Standardisierung. Sie deckt aber nicht alle Funktionen ab, die Anwender in Dokumente einbauen möchten.

PDF/A-Historie

Produktangebot
Es gibt bereits eine Reihe von Drittanbietern wie Compart, Luratech oder PDFtools, mit deren Hilfe Anwender im Eingangs- oder Ausgangspostbereich PDF/A-konforme Dokumente erzeugen. Wichtiger Bestandteil dieser Werkzeuge sind Validierungsfunktionen, die sicherstellen, dass die erzeugten PDF-Dateien den PDF/A-Spezifikationen entsprechen.

Fazit
Mit PDF/A-1 steht zum ersten Mal ein international normiertes Dokumentenformat für die Langzeitarchivierung unterschiedlicher Dokumentinhalte zur Verfügung. Die Verfügbarkeit einer solchen Norm löst die Probleme, dass bisher verwendete Archivformate wie TIFF G4 oder Druckformate wie IBM 1043 oder AFP entweder vielen modernen Anforderungen  nicht mehr gerecht werden (Farbe, Reproduktionsfähigkeit in Browsern ohne spezielle Viewer-Plug-Ins, Volltextsuche für TIFF) oder nicht sichergestellt ist, dass diese Formate auch in Jahrzehnten noch ohne Informationsverlust lesbar sind (proprietäre Formate oder Dokumente mit „unsicheren“ Ressourcen-Referenzen).

PDF/A als weit verbreiteter „Multi-Format-Container“ löst sowohl die Probleme der Einbettung unterschiedlicher Komponenten (farbige oder schwarz-weiße Grafik, Text, Bitmaps) als auch die Frage nach der langfristig gesicherten Reproduktionsfähigkeit.

PDF/A wird sich daher nach unserer Auffassung in vielen Archivanwendungen sehr schnell verbreiten; sowohl bei Inhouse-erstellten Dokumenten mit proprietärer Formatierung aber auch bei gescannten Dokumenten, bei denen mittels der PDF-Layertechnik die Lesbarkeit von Text und Grafik bei gleichzeitiger Minimierung der Dateigrößen optimiert werden kann. Letzteres war bisher zwar auch möglich, jedoch – mit Ausnahme der ISO-JPM-Spezifikation – nur mit herstellerspezifischen Verfahren. Die Kombination aus beinahe beliebiger Reproduktionsfähigkeit (für PDF/A genügt ein Acrobat Viewer Version 5 oder neuer) und Optimierung der Faktoren Dateigröße und Darstellungsqualität ist der besondere Vorteil der PDF/A-Spezifikation.