Zeitschrift Naturforschung Discussion

MPDL

This page will function as a shared discussion page for metadata issues in the ZfN project.

Metadata Problems




OCR Problems

 * special character problems with:
 * Greek symbols like α, β etc.
 * elevated numbers 2e² => 2e2
 * mathematical signs like ∞,
 * Diacritical signs like é, ă
 * Latin alphabet Å

pdf/a_1b Problem
In a project meeting was decided that we use pdf/A_1b format, which is not the case.
 * pdf properties claim to be pdf/a-1b compliant, but validating the pdf bring error messages:
 * http://www.pdf-tools.com/pdf/validate-pdfa-online.aspx
 * Validating file "ZNA-1948-3a-0434.pdf" for conformance level pdfa-1b
 * The value of the key N is 4 but must be 3.
 * The document does not conform to the requested standard.
 * The document doesn't conform to the PDF reference (missing required entries, wrong value types, etc.).


 * validation report from validatepdf.com:
 * 
 * OutputIntent object has an incorrect parameter or invalid color profile
 * 
 * Predefined XMP property 'amd' of the schema 'pdfaid' should not be defined in custom extension schemas
 * Predefined XMP property 'conformance' of the schema 'pdfaid' should not be defined in custom extension schemas
 * Predefined XMP property 'part' of the schema 'pdfaid' should not be defined in custom extension schemas
 * Predefined XMP property 'InstanceID' of the schema 'xmpMM' should not be defined in custom extension schemas
 * Predefined XMP property 'part' of the schema 'pdfaid' should not be defined in custom extension schemas
 * Predefined XMP property 'InstanceID' of the schema 'xmpMM' should not be defined in custom extension schemas

pdf/a_1b result (mail from Dr. rer. nat. Helge Knüttel, UR - Universität Regensburg)
Die Frage ist hier: Wie entscheide ich, ob eine vorliegende Datei konform zur Norm ist?

Wir erzeugen die PDF/A-Dateien mit Adobe Acrobat Pro 9 und ggf. 10. Die PDF/A-Konformität stellen wir durch eine Überprüfung und ggf. Konvertierung mit dem in Acrobat eingebauten Preflight-Werkzeug her. Dies stammt von der Firma callas (siehe z.B. http://www.callassoftware.com/callas/doku.php/en:news:press:20110706).

Eine erneute Überprüfung der von Ihnen genannten Datei (ich nahm sie vom ftp-Server) mit Acrobat 9.5 sowie auch dem aktuellen callas pdfaPilot 3 ergab keine Probleme bzgl. der Konformität mit PDF/A-1b. Sie können dies gerne nachvollziehen, der pdfaPilot ist als Testversion zum Download erhältlich: http://www.callassoftware.com/callas/doku.php/de:download

Allgemein gilt, dass die PDF/A-Standards komplex sind und entsprechend auch die Validierung von Dateien auf Standardkonformität (vgl. http://www.pdfa.org/2011/08/validating-pdfa/). Es gibt nun verschiedene Software zur Konformitätsprüfung. Doch, welcher Software will man vertrauen?

Was fehlt ist eine Referenzimplementierung, also eine vom Standardisierungsgremium abgesegnete Software, die die Konformitätsprüfung von Dateien sicher, korrekt und vollständig vornimmt. Es gibt einen kompenten und umfangreichen Test diverser Software von 2009 (http://www.pdflib.com/fileadmin/pdflib/pdf/pdfa/2009-05-04-Bavaria-report-on-PDFA-validation-accuracy.pdf), incl. Vorgängerversionen der hier genannten Software. Darin schneiden Acrobat/callas nicht schlecht ab. Kein Programm ist perfekt. Das häufigste Problem bei Acrobat, callas, Solid Documents und PDF Tools sind falsche Alarme, d.h. es werden Verstöße gegen die Norm gemeldet, die aber tatsächlich nicht vorhanden sind.

Von den verfügbaren Optionen erscheint uns die callas-Software nicht die schlechteste Wahl. Sie hat offenbar eine gewisse Marktpräsenz und wird ja auch nicht ohne Grund von Adobe (den Schöpfern von pdf!) in die Acrobat-Software integriert. callas ist eines der Mitglieder des PDF/A Competence Center und arbeitete aktiv an der Erstellung diverser pdf-Standards incl. den PDF/A-ISO-Normen mit.

Andererseits: Ich testete die genannte Datei heute auch selber mit der von Ihnen genannten online-Validierung von pdf-tools.com und erhielt ebenfalls die Fehlermeldung. Diese ist aber wenig hilfreich, da sie das gefundene Problem nicht genau lokalisiert. So kann man (oder zumindest ich) nicht wirklich für Abhilfe sorgen.

Der von Ihnen zitierte Validierungsreport von validatepdf.com bemängelt einen Fehler im OutputIntent, lässt aber offen, worin das Problem genau liegt. Weiterhin gibt er Warnungen bzgl. der XMP-Metadaten aus. Die XMP-Metadaten werden aber von den anderen Programme, incl. dem XMP-Validierer für PDF/A-1 von PDFlib (http://www.pdflib.com/de/knowledge-base/xmp-metadaten/kostenloser-xmp-validator/) nicht bemängelt.

Fazit: Manche Software bestätigt Normen-Konformität, während andere Fehler oder Warnungen ausgibt. Keiner der angeblichen Mängel wird von einer zweiten Software gefunden. Dies entspricht dem Bild aus dem oben zitierten Bavaria-Report. Inhaltlich erscheinen mir die Mängel, so sie denn existent sind, nicht gravierend.

Was ist das eigentliche Ziel der Verwendung von PDF/A in diesem Projekt?

Wir schlugen Ihnen die Lieferung als PDF/A vor, um Ihnen möglichst große Sicherheit für die langzeitige Verfügbarkeit der Daten zu geben. Wobei unsere pdf-Dateien ja ohnehin recht einfach aufgebaut sind und schon ohne PDF/A wenig Probleme erwarten ließen. Absolute Zukunftssicherheit gibt es bei der digitalen Langzeitarchivierung bislang nicht. Wir sind aber zuversichtlich, dass die an Sie gelieferten und nach Acrobat/callas auch PDF/A-konformen Dateien vergleichsweise sehr zukunftssicher sind.

PDF/A-Konformität nach Acrobat/callas sehe ich als ausreichend an. Ich würde mich freuen, wenn Sie dem zustimmen könnten.

(Die Projektleitung der MPDL (Malte Dreyer) stimmt dem zu und ist vor diesem Hintergrund gerne bereit die Anlieferung zu akzeptieren.)