Thanks a lot for this information, Boris!

This might explain the behavior. -> Where can I access the temporary files?

However, temporary files are another issue for the eHealth Connector, as our open source software is often used on servers for seamless validation by streams. This issue is probably also linked with the thread-safeness issue. Or in other words: how will you get thread-safe by using temp. files?

Looking forward to our further exchange on this topic.

Kind regards,

Tony

Von: Boris Doubrov [mailto:boris.doubrov@duallab.com]
Gesendet: Montag, 6. November 2017 11:10
An: Tony Schaller <tony.schaller@medshare.net>; users@lists.verapdf.org
Betreff: RE: [Users] Unexpected validation rules in the veraPDF validation report

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@lists.verapdf.org] On Behalf Of Tony Schaller
Sent: Monday, November 6, 2017 10:48 AM
To: users@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@lists.verapdf.org' <users@lists.verapdf.org>
Betreff: Unexpected validation rules in the veraPDF validation report

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

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

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