Ist der Platzbedarf von PDF/A ein Hemmschuh für die Archivierung?
Ein PDF/A-Dokument erfordert, dass alle Ressourcen wie Schriftarten, Farbprofile usw. in die Datei eingebettet sind. Die Archivierung von Transaktionsdokumenten kann ein Alptraum sein, da solche Dokumente in der Regel kurz sind und eine große Anzahl von Kopien derselben Frutiger-Schriftart, des sRGB-Farbprofils und des Firmenlogos enthalten. Viele Archive bevorzugen daher TIFF gegenüber PDF/A, wenn es um originär digitale Dokumente geht. Aber das ist sicher nicht die Idee einer einheitlichen Norm. Wie kann dieses Problem gelöst werden?
PDF/A ist in Archiven für gescannte Dokumente weithin akzeptiert. Das liegt vor allem daran, dass PDF/A stärkere und standardisierte Komprimierungsalgorithmen bietet, die es ermöglichen, eine farbige gescannte Seite auf weniger als 50 KB zu reduzieren. Auch für einzelne born-digital Dokumente ist PDF/A das bevorzugte Dateiformat. Die Anwendung von PDF/A bei der Massenarchivierung von Transaktionsdokumenten ist jedoch noch umstritten. Meiner Meinung nach ist dies jedoch kein Problem des Formats. Es handelt sich um ein Problem des Archivierungssystems und muss daher dort gelöst werden.
Die meisten Archivierungssysteme sind stolz auf die Tatsache, dass sie "Objekte" speichern, ohne sich um deren Format zu kümmern. Diese Unkenntnis hat jedoch einen entscheidenden Nachteil. Sie können die Dateien nicht auf angemessene und intelligente Weise bearbeiten. Daher fügen die meisten Lösungen für die Massenarchivierung von PDF/A-Dokumenten dem Archivierungssystem eine Softwareschicht hinzu, die versucht, die negativen Auswirkungen von wiederholt eingebetteten Ressourcen zu reduzieren. Für diese Softwareschicht gibt es zwei Hauptansätze.
Der erste Ansatz sammelt einzelne Dokumente und führt sie in einer einzigen Containerdatei zusammen, für die die Ressourcen so optimiert werden können, dass sie nur einmal in der Datei vorkommen. Diese Datei wird dann an das Archiv übermittelt. Wenn ein Dokument abgerufen wird, wird die Containerdatei abgerufen und in die Originaldokumente aufgeteilt.
Beim zweiten Ansatz werden die Dokumente in einzelne Ressourcendateien und ein Hauptdokument, das darauf verweist, aufgeteilt. Die Ressourcen werden dann optimiert, indem gleiche Kopien durch eine einzige Instanz ersetzt werden. Die optimierten Ressourcendateien und die Hauptdokumente werden dann an das Archiv übermittelt. Wenn ein Dokument abgerufen wird, wird es aus seinen Teilen neu aufgebaut.
Ich persönlich bevorzuge den zweiten Ansatz, da er mit einer viel höheren Leistung als der erste Ansatz umgesetzt werden kann. Allerdings wird bemängelt, dass die "Objekte" keine PDF/A-Dokumente mehr sind. Meiner Meinung nach ist dies nicht erforderlich, da die Softwareschicht zur Aufteilung und Zusammenführung der Ressourcen dies für den Benutzer transparent macht und gewährleistet, dass das Dokument vor der Speicherung und nach dem Abruf identisch ist. In der Regel lässt sich dieses Argument besser verstehen, wenn man den Mechanismus mit dem Kompressions- oder Verschlüsselungsalgorithmus in der Speicherschicht des Archivierungssystems vergleicht. Die auf dem Datenträger gespeicherten Daten sind keine PDF/A-Datei mehr, wenn sie in komprimierter oder verschlüsselter Form gespeichert sind. Nach der Dekomprimierung oder Entschlüsselung ist es wieder die gleiche Datei. Das Gleiche gilt für die Softwareebene der Ressourcenverwaltung.
Ich habe den zweiten Ansatz für Kunden mit großen Dokumentenmengen umgesetzt, und er funktioniert einwandfrei, spart Platz und Kosten.
