Die Disziplin der Konvertierung von PDF nach PDF/A
Wir alle wissen, dass die Konvertierung eines Dateiformats in ein anderes nicht so einfach ist, wie man es sich wünscht, und zu unangenehmen Überraschungen führen kann. Dass dies bei der Konvertierung von PDF nach PDF/A der Fall ist, ist jedoch kaum bekannt. Warum ist das so?
PDF/A ist eine Untermenge von PDF. Das ist die offensichtliche Tatsache. Typische Beispiele sind, dass die eingebetteten Schriftarten und die verwendeten Farben kalibriert sein müssen. Weniger bekannt ist, dass die PDF/A-Norm zusätzliche, strengere Regeln enthält. Ein Beispiel dafür ist, dass die Textzeichen nicht auf die Glyphe .notdef verweisen dürfen.
Wie auch immer. PDF/A wurde mit Blick auf die Dokumentenerstellung und nicht auf die Konvertierung entwickelt. Trotzdem muss ein PDF nach PDF/A Konverter eine neue PDF-Datei erzeugen, die den Regeln des Standards folgt. Einerseits ist das oft nicht einfach. Andererseits gibt es viele Möglichkeiten für das Mapping und verschiedene Strategien. Hier sind einige Beispiele.
Unkalibrierte Farbräume können einfach durch kalibrierte ersetzt werden, indem für jeden der geräteabhängigen Farbräume DeviceGray, DeviceRGB und Device CMYK ein ICC-Farbprofil ausgewählt wird.
Es ist nicht notwendig, einen Output Intent einzuführen, wenn er nicht in der Eingabedatei vorhanden ist. Wenn die Eingabedatei jedoch bereits ein Output-Intent-Profil, z. B. ein CMYK-Profil, enthält, ist es ratsam, dieses und die geräteabhängigen Farben, die sich darauf beziehen, beizubehalten.
Das Einbetten fehlender Schriftprogramme ist nur dann einfach, wenn die Originalschrift verfügbar ist, was oft nicht der Fall ist. Wenn das Schriftprogramm nicht verfügbar ist, muss es durch ein Schriftprogramm ersetzt werden, das dem Original so nahe wie möglich kommt. Die Viewer-Anwendungen verfügen über eingebaute Schriftersatzstrategien. Ein Konverter sollte sich ebenfalls an diese Strategien halten, da die resultierende Datei gleich aussehen sollte, unabhängig davon, ob die Schriftarten eingebettet sind oder nicht.
Wenn Transparenz verboten ist, wie z. B. bei PDF/A-1, dann muss der Konverter eine Art Transparenzreduzierung durchführen oder die Datei ablehnen, wenn er dazu nicht in der Lage ist.
Bei verbotenen Funktionen wie JavaScript, Multimedia-Inhalten, bestimmten Aktionen usw. hat der Konverter die Möglichkeit, die Funktionen zu entfernen oder die Datei abzulehnen, wenn der Benutzer sie nicht wünscht.
Textzeichen, die der Glyphe .notdef zugeordnet sind, können einer neuen Glyphe zugeordnet werden, die eine Kopie der Glyphe .notdef ist.
Die obige Liste kann nur einen Eindruck vermitteln. Es gibt sicherlich viel mehr Fälle als hier gezeigt. Es gibt jedoch noch weitere Aufgaben, die ein Konverter erfüllen muss. Hier sind einige von ihnen:
Vorab-Prüfung: Wenn das Eingabedokument bereits der geforderten Norm entspricht, muss die Konvertierung nicht durchgeführt werden. Dies ist vor allem bei digital signierten Dokumenten sinnvoll.
Nachvalidierung: Nach der Konvertierung möchte der Benutzer überprüfen, ob das konvertierte Ergebnis mit der gewünschten Norm übereinstimmt.
Reparieren: Der Benutzer erwartet, dass der Konverter die Eingabedatei repariert, wenn sie kleinere Fehler wie fehlende obligatorische Wörterbucheinträge, beschädigte Querverweistabellen usw. enthält.
Rückgabestatus: Ein fein abgestufter Rückgabestatuswert ermöglicht einen gut durchdachten, benutzergesteuerten Konvertierungsprozess.
Protokolldatei: Ein unvermeidliches Mittel zur Lokalisierung und Beseitigung von Konvertierungsproblemen.
