[Users] Unexpected validation rules in the veraPDF validation report

Boris Doubrov boris.doubrov at duallab.com
Mon Nov 6 10:10:10 GMT 2017


Hi Tony,

This looks like an issue with parsing of the embedded ICC profile, which is a part of the PDF Output Intent, required by PDF/A standard if any device colors are used.

As this data is stored compressed (eg., Flate encoded) in PDF file, veraPDF may first decode and store it in a local file system. So, my initial guess would be that this mechanism of using temporary files is broken on the way of embedding veraPDF into your .NET application.

Best regards,
Boris

From: Users [mailto:users-bounces at lists.verapdf.org] On Behalf Of Tony Schaller
Sent: Monday, November 6, 2017 10:48 AM
To: users at lists.verapdf.org
Subject: Re: [Users] Unexpected validation rules in the veraPDF validation report

Hi all
Any advice?
Thanks and kind regards,
Tony

Von: Tony Schaller
Gesendet: Montag, 30. Oktober 2017 15:44
An: 'users at lists.verapdf.org' <users at lists.verapdf.org<mailto:users at lists.verapdf.org>>
Betreff: Unexpected validation rules in the veraPDF validation report

Hi

We have integrated veraPDF validation-model 1.8.1 from the maven repo (https://mvnrepository.com/artifact/org.verapdf/validation-model) into the eHealth Connector Open Source project (see https://sourceforge.net/projects/ehealthconnector/). See https://sourceforge.net/p/ehealthconnector/wiki/CDA%20Validation/ for more information.

The eHealth Connector API is converted by IKVM.net into a .Net DLL and is therefore available on both platforms

While validating PDFs I’m confused about the veraPDF behavior:
Using the Java Demo of the eHealth Connector, the report shows exactly the same as your validation tools (http://software.verapdf.org/releases/1.8/verapdf-greenfield-1.8.1-installer.zip).
But using the .Net Demo I alwas get two additional issues in the report:
Rule 1 - Specification: ISO 19005-1:2005, Clause: 6.2.2, Test number: 1
  Error: A PDF/A-1 OutputIntent is an OutputIntent dictionary, as defined by PDF Reference 9.10.4, that is included in the file's OutputIntents
               array and has GTS_PDFA1 as the value of its S key and a valid ICC profile stream as the value its DestOutputProfile key
  See also: https://github.com/veraPDF/veraPDF-validation-profiles/wiki/PDFA-Part-1-rules#rule-622-1
  1 Occurrence(s):
    - root/document[0]/outputIntents[0]/destProfile[0]
Rule 2 - Specification: ISO 19005-1:2005, Clause: 6.2.3, Test number: 5
  Error: All ICCBased colour spaces shall be embedded as ICC profile streams as described in PDF Reference 4.5.
                                            The number of color components in the color space described by the ICC profile data must match the number of components actually in the ICC profile.
                                            As of PDF 1.4, N must be 1, 3, or 4
  See also: https://github.com/veraPDF/veraPDF-validation-profiles/wiki/PDFA-Part-1-rules#rule-623-5
  1 Occurrence(s):
    - root/document[0]/outputIntents[0]/destProfile[0]

I have investigate a lot in finding the issue within the eHealth Connector but I’m sure, that the PDF that is handover to veraPDF is identical on both platforms.
Therefore I’m kind of helpless now. And while I do not bring in-depth knowledge with your validation-model I’m currently lost.
In the meantime I decided to suppress these two messages (see https://sourceforge.net/p/ehealthconnector/code/HEAD/tree/trunk/ehealthconnector/ehealth_connector-validation/ehealth_connector-validation-service/src/main/java/org/ehealth_connector/validation/service/pdf/VeraPdfValidator.java ) but I’m sure that this is not what we should do.

Any advice is heavily appreciated.

Thanks and kind regards,
Tony
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.verapdf.org/pipermail/users/attachments/20171106/6a9c459b/attachment.html>


More information about the Users mailing list