Sind die Anforderungen an den PDF/A-Raum ein Showstopper für die Archivierung?
Ein PDF/A-Dokument erfordert, dass alle Ressourcen wie Schriftarten, Farbprofile usw. in die Datei eingebettet werden müssen. Das Archivieren von Transaktionsdokumenten kann ein Albtraum sein, da solche Dokumente in der Regel kurz sind und eine große Anzahl von Kopien derselben Frutiger-Schriftart, des sRGB-Farbprofils und des Unternehmenslogos enthalten. Viele Archive bevorzugen daher TIFF gegenüber PDF/A, wenn es um digital geborene Dokumente geht. Aber das ist sicherlich nicht die Idee eines einheitlichen Standards. Wie kann dieses Problem gelöst werden?
PDF/A wird in Archiven für gescannte Dokumente weitgehend akzeptiert. Dies liegt hauptsächlich daran, dass PDF/A stärkere und standardisierte Kompressionsalgorithmen bietet, die es ermöglichen, eine farbige gescannte Seite auf weniger als 50 KB zu reduzieren. Auch für einzelne digital geborene Dokumente ist PDF/A das bevorzugte Dateiformat. Die Anwendung von PDF/A in der Massenarchivierung von Transaktionsdokumenten ist jedoch weiterhin umstritten. In meiner Meinung ist dies jedoch kein Problem des Formats. Es ist ein Problem des Archivierungssystems und muss daher dort gelöst werden.
Die meisten Archivierungssysteme sind stolz darauf, 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 angemessen und intelligent verarbeiten. Daher fügen die meisten Lösungen für die Massenarchivierung von PDF/A-Dokumenten eine Softwareschicht zum Archivierungssystem hinzu, die versucht, die negativen Effekte von wiederholt eingebetteten Ressourcen zu reduzieren. Es gibt zwei Hauptansätze für diese Softwareschicht.
Der erste Ansatz sammelt einzelne Dokumente und kombiniert sie zu einer einzigen Containerdatei, für die die Ressourcen so optimiert werden können, dass sie nur einmal in der Datei vorkommen. Diese Datei wird dann dem Archiv übergeben. Wenn ein Dokument abgerufen wird, wird die Containerdatei abgerufen und in die Originaldokumente aufgeteilt.
Der zweite Ansatz trennt die Dokumente in einzelne Ressourcen und ein Hauptdokument, das darauf verweist. Die Ressourcen werden dann optimiert, indem gleiche Kopien durch eine einzige Instanz ersetzt werden. Die optimierten Ressourcen und die Hauptdokumente werden dann dem Archiv übergeben. Wenn ein Dokument abgerufen wird, wird es aus seinen Teilen rekonstruiert.
Ich bevorzuge persönlich den zweiten Ansatz, da er mit einer viel höheren Leistung als der erste implementiert werden kann. Die Leute kritisieren jedoch, dass die 'Objekte' keine PDF/A-Dokumente mehr sind. Meiner Meinung nach ist dies nicht erforderlich, da die Softwareebene, um die Ressourcen zu teilen und zusammenzuführen, dies transparent für den Benutzer tut und garantiert, dass das Dokument dasselbe ist, bevor es gespeichert wird und nachdem es abgerufen wird. In der Regel kann dieses Argument besser verstanden werden, wenn der Mechanismus mit dem Kompressions- oder Verschlüsselungsalgorithmus innerhalb der Speicherschicht des Archivierungssystems verglichen wird. Die Daten, die auf dem Medium gespeichert sind, sind keine PDF/A-Datei mehr, wenn sie in komprimierter oder verschlüsselter Form gespeichert werden. Nach der Dekompression oder Entschlüsselung ist es die identische Datei wieder. Das Gleiche gilt für die Softwareschicht zur Ressourcenverwaltung.
Ich habe den zweiten Ansatz für Kunden mit großen Dokumentenvolumen implementiert, und er funktioniert einwandfrei, spart Platz und Kosten.
