The PDFs generated are not compatible to PDF/A

[schuettec]

The PDFs generated from your testcases are not PDF/A compliant.

The 3-Heights PDF validator says, that the XMP Metadata are corrupt. Multiple PDF Viewers confirm this. As you can see the metadata is not properly written to the PDF.

File    testout-MustangGnuaccountingBeispielRE-20151008_504newEdge.pdf
Compliance  pdfa-3u
Result  Document does not conform to PDF/A.
Details 

Validating file "testout-MustangGnuaccountingBeispielRE-20151008_504newEdge.pdf" for conformance level pdfa-3u

pdfaExtension:schemas/*[0] :: Missing required field 'valueType' in value type 'Schema'.

The document does not conform to the requested standard.

The document's meta data is either missing or inconsistent or corrupt.

Done.

[jstaerk]

I used to use http://www.pdf-tools.com/pdf/validate-pdfa-online.aspx which currently says "Service unavailable. Please use https://www.pdf-online.com/osa/validate.aspx ."

I guess you refer to that. I'm trying to get in touch with them but the registration on https://www.pdf-online.com/osa/register.aspx continously "Failed to send password via e-mail."

[schuettec]

You do not need any registration for https://www.pdf-online.com/osa/validate.aspx

For me it works without any account. Am 11.05.2016 16:53 schrieb "Jochen Staerk" notifications@github.com:

I used to use http://www.pdf-tools.com/pdf/validate-pdfa-online.aspx which currently says "Service unavailable. Please use https://www.pdf-online.com/osa/validate.aspx ."

I guess you refer to that. I'm trying to get in touch with them but the registration on https://www.pdf-online.com/osa/register.aspx continously "Failed to send password via e-mail."

— You are receiving this because you authored the thread. Reply to this email directly or view it on GitHub https://github.com/Rayman2200/PDFA3/issues/12#issuecomment-218484274

[jstaerk]

I checked and forwarded the issue. I believe it might be a regression in their validator, if you open the file in a text editor you can see a valueType="Text" for each of the four PDFA schema extensions.

[jstaerk]

Am 12.05.16 um 16:29 schrieb Tobias Müller (PDF Tools AG):

Guten Tag Herr Stärk,

vielen Dank für Ihre Anfrage.

Die Meldung bezieht sich auf eine Änderung des PDF/A-2 und PDF/A-3 Standards gegenüber PDF/A-1. Diese Änderung ist uns leider lange nicht aufgefallen, deshalb haben frühere Versionen hier zu wenig strikt validiert.

Der Fehler bezieht sich nicht auf den Eintrag pdfaProperty:valueType in einer Property-Beschreibung, sondern auf den Eintrag pdfaSchema:valueType in der Schema-Beschreibung. Das ist ein Seq-Array von benutzerdefinierten Value-Types.

Die Standards für PDF/A-2 und PDF/A-3 schreiben (sinnloserweise) klar vor, dass alle Felder vorhanden sein müssen. Um der Spezifikation zu entsprechen, müssen Sie also ein leeres Seq-Array einfügen: pdfaSchema:valueType rdf:Seq/ /pdfaSchema:valueType

Unser PDF/A-Konverter korrigiert das in neueren Versionen automatisch. Ich habe Ihnen die konvertierte Version gleich angehängt.

converted.pdf

[schuettec]

Hi, ich habe diese Meldung auch so interpretiert, dass pdfaSchema:valueType fehlt. Ich habe dies im Code von Mustang ergänzt und die Validierung gegen deren Tool funktioniert wieder einwandfrei. Das leere Seq-Array ist zwar sinnfrei, aber wenn es spezifiziert ist...

Wird das Mustang Projekt noch weiter gepflegt? Der Code sieht teilweise schlimm aus.

Am 13. Mai 2016 um 13:42 schrieb Jochen Staerk notifications@github.com:

Am 12.05.16 um 16:29 schrieb Tobias Müller (PDF Tools AG):

Guten Tag Herr Stärk,

vielen Dank für Ihre Anfrage.

Die Meldung bezieht sich auf eine Änderung des PDF/A-2 und PDF/A-3 Standards gegenüber PDF/A-1. Diese Änderung ist uns leider lange nicht aufgefallen, deshalb haben frühere Versionen hier zu wenig strikt validiert.

Der Fehler bezieht sich nicht auf den Eintrag pdfaProperty:valueType in einer Property-Beschreibung, sondern auf den Eintrag pdfaSchema:valueType in der Schema-Beschreibung. Das ist ein Seq-Array von benutzerdefinierten Value-Types.

Die Standards für PDF/A-2 und PDF/A-3 schreiben (sinnloserweise) klar vor, dass alle Felder vorhanden sein müssen. Um der Spezifikation zu entsprechen, müssen Sie also ein leeres Seq-Array einfügen: pdfaSchema:valueType rdf:Seq/ /pdfaSchema:valueType

Unser PDF/A-Konverter korrigiert das in neueren Versionen automatisch. Ich habe Ihnen die konvertierte Version gleich angehängt.

converted.pdf https://github.com/Rayman2200/PDFA3/files/263126/converted.pdf

— You are receiving this because you authored the thread. Reply to this email directly or view it on GitHub https://github.com/Rayman2200/PDFA3/issues/12#issuecomment-219020809

[jstaerk]

Ein entsprechender Pull-Request wäre sehr nett. Es wird noch gepflegt, der Code sah früher sogar noch schlimmer aus ;-)

[jstaerk]

Danke für den PR. Die Datei ist Thomas' Beispieleinbettung, da gings um die Diskussion wie das mit Apache PDFBox überhaupt geht. Ich hab die Änderung mal in Mustangproject (src/main/java/org/mustangproject/ZUGFeRD/ZUGFeRDExporter.java) übernommen aber der Validierer wirft immer noch dieselbe Fehlermeldung :-(

[jstaerk]

Kurze Zwischenmeldung: ich habe die Fehlermeldung in Richtung ZUGFeRD, Intarsys und Konik weiter gegeben weil deren Beispieldateien denselben Fehler werfen. ZUGFeRD/Intarsys klären das nochmal kurz mit der PDF Association, ich arbeite aber schonmal unabhängig an einer Lösung.

[jstaerk]

I pushed the fix in cb3de6b..949b9c5

[schuettec]

Sorry, ich hätte dir einen PR erstellen sollen. Zu spät gelesen.

2016-05-25 10:21 GMT+02:00 Jochen Staerk notifications@github.com:

Closed #12 https://github.com/Rayman2200/PDFA3/issues/12.

— You are receiving this because you authored the thread. Reply to this email directly or view it on GitHub https://github.com/Rayman2200/PDFA3/issues/12#event-671424973