On 10/23/2017 7:01 PM, luigi scarso wrote:

On Mon, Oct 23, 2017 at 6:25 PM, Pablo Rodriguez wrote:

...

Hans,

according to Boris Doubrov (one of the developers of the veraPDF parser for PDF/A validation) the subtype of the /OutputIntent dictionary for all PDF/A intents should be GTS_PDFA1 (no GTS_PDFA2 or GTS_PDFA3).

Here is his reply for reference: https://github.com/veraPDF/veraPDF-parser/issues/317#issuecomment-338613962.

The attached patch fixes the issue. I have tried it myself and it solves the problems with color space profiles.

Could you apply it to ConTeXt?

Many thanks for your help, sure, but it's better if we have an example that fails --- I mean, the source code, the version of the parser , the command line used. It could be that other parts are also not ok. i also want to check with Peter

----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | www.pragma-ade.nl | www.pragma-pod.nl -----------------------------------------------------------------

On Mon, Oct 23, 2017 at 11:14 PM, Peter Rolf wrote:

Am 23.10.2017 um 19:14 schrieb Hans Hagen:

...

On 10/23/2017 7:01 PM, luigi scarso wrote:

...

...

Hans,

according to Boris Doubrov (one of the developers of the veraPDF parser for PDF/A validation) the subtype of the /OutputIntent dictionary for all PDF/A intents should be GTS_PDFA1 (no GTS_PDFA2 or GTS_PDFA3).

Here is his reply for reference: https://github.com/veraPDF/veraPDF-parser/issues/317#issuecomment-338613962.

The attached patch fixes the issue. I have tried it myself and it solves the problems with color space profiles.

Could you apply it to ConTeXt?

Many thanks for your help, sure, but it's better if we have an example that fails --- I mean, the source code, the version of the parser , the command

On Mon, Oct 23, 2017 at 6:25 PM, Pablo Rodriguez wrote: line used. It could be that other parts are also not ok. i also want to check with Peter

No objections, the 'gts_flag' is also fix for the PDF/X variants.

I think I have tested all variants at that time (around Oct 2015) and 'veraPDF' didn't throw an error. Looks like they have improved their parser on that part.

yes, the parser looks better, and a nice thing is that an error shows the reference to the part of the standard that is interested to the failure. -- luigi

On Tue, Oct 24, 2017 at 9:15 AM, Hans Hagen wrote:

Well, for me it means that all that validation esp of keys like this are rather useless (creating work) because docs validated in the past and archived now are suddenly no longer valid.

Hm I have made a pdf with format={pdf/a-3a}, where I see /S /GTS_PDFA3 verapdf 1.8.4 says that it's valid. I need to investigate, perhaps my version of verapdf is older. -- luigi

Am 24.10.2017 um 09:15 schrieb Hans Hagen:

On 10/23/2017 11:14 PM, Peter Rolf wrote:

...

Am 23.10.2017 um 19:14 schrieb Hans Hagen:

...

On 10/23/2017 7:01 PM, luigi scarso wrote:

...

...

Hans,

according to Boris Doubrov (one of the developers of the veraPDF parser for PDF/A validation) the subtype of the /OutputIntent dictionary for all PDF/A intents should be GTS_PDFA1 (no GTS_PDFA2 or GTS_PDFA3).

Here is his reply for reference: https://github.com/veraPDF/veraPDF-parser/issues/317#issuecomment-338613962.

The attached patch fixes the issue. I have tried it myself and it solves the problems with color space profiles.

Could you apply it to ConTeXt?

Many thanks for your help, sure, but it's better if we have an example that fails --- I mean, the source code,  the version of the parser , the command

On Mon, Oct 23, 2017 at 6:25 PM, Pablo Rodriguez wrote: line used. It could be that other parts are also not ok. i also want to check with Peter

No objections, the 'gts_flag' is also fix for the PDF/X variants.

So all variants get GTS_PDFA1 ?

Yes. My guess (as I have no ISO documention) at that time was, that the number should be increased with the versions. I couldn't imagine, why the should use a number in that flag (there may be reasons for it, but I donno them). Anyhow, I'll download veraPDF and test all variants with the actual beta. I doubt that the results will differ. If I find any other errors you can fix them at one go. Will report back (probably after lunch break). I hope nobody is in a hurry :D

...

I think I have tested all variants at that time (around Oct 2015) and 'veraPDF' didn't throw an error. Looks like they have improved their parser on that part.

Well, for me it means that all that validation esp of keys like this are rather useless (creating work) because docs validated in the past and archived now are suddenly no longer valid.

Hans

-----------------------------------------------------------------                                           Hans Hagen | PRAGMA ADE               Ridderstraat 27 | 8061 GH Hasselt | The Netherlands        tel: 038 477 53 69 | www.pragma-ade.nl | www.pragma-pod.nl ----------------------------------------------------------------- _______________________________________________ dev-context mailing list dev-context@ntg.nl https://mailman.ntg.nl/mailman/listinfo/dev-context

On Tue, Oct 24, 2017 at 10:14 AM, luigi scarso wrote:

On Tue, Oct 24, 2017 at 10:01 AM, Peter Rolf wrote:

...

Yes. My guess (as I have no ISO documention) at that time was, that the number should be increased with the versions. I couldn't imagine, why the should use a number in that flag (there may be reasons for it, but I donno them).

Anyhow, I'll download veraPDF and test all variants with the actual beta. I doubt that the results will differ. If I find any other errors you can fix them at one go. Will report back (probably after lunch break). I hope nobody is in a hurry :D

I have made a test with pdf/a-2a, pdf/a-3a, they pass both the verapdf 1.8.4 and 1.9.46-dev The problem with the file $ cat unrgb.tex \nopdfcompression \setupexternalfigures[location=default] \setuptagging[state=start] \setupbackend [format=PDF/A-3a, intent=sRGB IEC61966-2.1, profile={sRGB.icc,default_gray.icc}, level=0] \setupcolors[cmyk=no, pagecolormodel=auto] \starttext \startTEXpage[offset=1em] \externalfigure[cow-brown] \stopTEXpage \stoptext

is that it includes a pdf (cow-brown.pdf) and this can lead to conflicts with the specs. of the setupbackend. There is no way to solve this: even is both the pdf are pdf/a-3a ok, they can conflict. So, the safest way is always to include bitmap images.

-- luigi

infact $ convert cow-brown.pdf --flatten -density 300 cow-brown.png %% unrgb.tex \nopdfcompression \setupexternalfigures[location=default] \setuptagging[state=start] \setupbackend [format=PDF/A-3a, intent=sRGB IEC61966-2.1, profile={sRGB.icc,default_gray.icc}, level=0] \setupcolors[cmyk=no, pagecolormodel=auto] \starttext \startTEXpage[offset=1em] \externalfigure[cow-brown.png] \stopTEXpage \stoptext $ context unrgb.tex $ verapdf -f 3a unrgb.pdf <?xml version="1.0" encoding="utf-8"?> <report> <buildInformation> <releaseDetails id="core" version="1.8.2" buildDate="2017-08-14T09:56:00+02:00"></releaseDetails> <releaseDetails id="validation-model" version="1.8.3" buildDate="2017-08-21T14:17:00+02:00"></releaseDetails> <releaseDetails id="gui" version="1.8.4" buildDate="2017-08-21T14:49:00+02:00"></releaseDetails> </buildInformation> <jobs> <job> <item size="235110"> <name>/opt/luatex/harald/Indien-2015/unrgb.pdf</name> </item> <validationReport profileName="PDF/A-3A validation profile" statement="PDF file is compliant with Validation Profile requirements." isCompliant="true"> <details passedRules="131" failedRules="0" passedChecks="430" failedChecks="0"></details> </validationReport> <duration start="1508833358743" finish="1508833359138">00:00:00.395</duration> </job> </jobs> <batchSummary totalJobs="1" failedToParse="0" encrypted="0"> <validationReports compliant="1" nonCompliant="0" failedJobs="0">1</validationReports> <featureReports failedJobs="0">0</featureReports> <repairReports failedJobs="0">0</repairReports> <duration start="1508833358683" finish="1508833359162">00:00:00.479</duration> </batchSummary> </report> -- luigi

Am 24.10.2017 um 10:01 schrieb Peter Rolf:

Am 24.10.2017 um 09:15 schrieb Hans Hagen:

...

On 10/23/2017 11:14 PM, Peter Rolf wrote:

...

Am 23.10.2017 um 19:14 schrieb Hans Hagen:

...

On 10/23/2017 7:01 PM, luigi scarso wrote:

...

...

Hans,

according to Boris Doubrov (one of the developers of the veraPDF parser for PDF/A validation) the subtype of the /OutputIntent dictionary for all PDF/A intents should be GTS_PDFA1 (no GTS_PDFA2 or GTS_PDFA3).

Here is his reply for reference: https://github.com/veraPDF/veraPDF-parser/issues/317#issuecomment-338613962.

The attached patch fixes the issue. I have tried it myself and it solves the problems with color space profiles.

Could you apply it to ConTeXt?

Many thanks for your help, sure, but it's better if we have an example that fails --- I mean, the source code,  the version of the parser , the command

On Mon, Oct 23, 2017 at 6:25 PM, Pablo Rodriguez wrote: line used. It could be that other parts are also not ok. i also want to check with Peter

No objections, the 'gts_flag' is also fix for the PDF/X variants.

So all variants get GTS_PDFA1 ?

Yes. My guess (as I have no ISO documention) at that time was, that the number should be increased with the versions. I couldn't imagine, why the should use a number in that flag (there may be reasons for it, but I donno them).

Anyhow, I'll download veraPDF and test all variants with the actual beta. I doubt that the results will differ. If I find any other errors you can fix them at one go. Will report back (probably after lunch break). I hope nobody is in a hurry :D

Tested all PDF/A versions with veraPDF 1.8.4 and ConTeXt 2017.10.24 10:30. No errors reported.

...

...

I think I have tested all variants at that time (around Oct 2015) and 'veraPDF' didn't throw an error. Looks like they have improved their parser on that part.

Well, for me it means that all that validation esp of keys like this are rather useless (creating work) because docs validated in the past and archived now are suddenly no longer valid.

Well, the good news is that the actual problem does not effect any A1 documents. And even with an incomplete (99.9%) validity the documents stay usable. I'm sure that (alien) historians will love any ConTeXt created PDF/A document :D Anyhow, next time I'm in doubt about an entry I will ask the guys from veraPDF. They have a copy of the ISO docs. Peter

...

Hans

-----------------------------------------------------------------                                           Hans Hagen | PRAGMA ADE               Ridderstraat 27 | 8061 GH Hasselt | The Netherlands        tel: 038 477 53 69 | www.pragma-ade.nl | www.pragma-pod.nl ----------------------------------------------------------------- _______________________________________________ dev-context mailing list dev-context@ntg.nl https://mailman.ntg.nl/mailman/listinfo/dev-context

_______________________________________________ dev-context mailing list dev-context@ntg.nl https://mailman.ntg.nl/mailman/listinfo/dev-context

On 10/24/2017 01:48 PM, Peter Rolf wrote:

...

[...] Well, the good news is that the actual problem does not effect any A1 documents. And even with an incomplete (99.9%) validity the documents stay usable. I'm sure that (alien) historians will love any ConTeXt created PDF/A document :D

Sorry, Peter, but I’m afraid that the bad news is that CMYK in form xobjects doesn’t work fine :-(:

\nopdfcompression

\setupexternalfigures[location=default]

\setuptagging[state=start]

\setupbackend [format=PDF/A-3a, intent=sRGB IEC61966-2.1, profile={isocoated_v2_eci.icc,default_gray.icc}, level=0]

\setupcolors[pagecolormodel=auto]

\starttext \startTEXpage[offset=1em] \externalfigure[cow] \stopTEXpage \stoptext

I don’t use CMYK myself, but am I missing something or is this something that needs further investigation? is this \externalfigure[cow] a pdf ? As said previously , including pdf can break the rules of

On Tue, Oct 24, 2017 at 7:02 PM, Pablo Rodriguez wrote: format=PDF/A-3a. Simply include bitmap images, it's way more robust. -- luigi

On Tue, Oct 24, 2017 at 7:27 PM, Alan Braslau wrote:

On Tue, 24 Oct 2017 19:06:51 +0200 luigi scarso wrote:

...

is this \externalfigure[cow] a pdf ? As said previously , including pdf can break the rules of format=PDF/A-3a. Simply include bitmap images, it's way more robust.

Isn't that non-optimal, using bitmap images rather than vector graphics? Must there not be a way to correctly include PDF graphics, perhaps modifying the included file to make it conforming? Forgetting for the moment that a generic pdf could not have the right structure (and fix it can be quite complicate) you can have a "guest" pdf file that is valid pdf/a but once included with \externalfigure can conflicts with the "host" pdf, because the host specifies a different color spaces, for example. On the other side, if you include it as bitmap, you are safe on the

color spaces and the structure. Of course This sound not ok if the pdf is only text --- but even in this case the situation is not so simple: the fonts must be correct (it's known that we have math fonts that are not ok ), the tounicode also.. so also in this case a high res bitmap can be the only solution., -- luigi

On Tue, Oct 24, 2017 at 8:21 PM, Alan Braslau wrote:

"Let the buyer beware".

Given that bitmap graphics are NOT OK (think bloat, an MS/Office specialty), there must be a better solution. Perhaps simply detecting a conflict between an included PDF and the "host" PDF and printing a warning! Then it could be up to the user to "fix" the included PDF so not to break the host PDF. For the purpose of pdf/a (long term preservation, reproducibility and robustness of the file ) bitmap graphics are ok. RGB is one of the best color space.

-- luigi

On 10/24/2017 07:06 PM, luigi scarso wrote:

a pdf ? As said previously , including pdf can break the rules of format=PDF/A-3a. Simply include bitmap images, it's way more robust.

Allow me a fair and respectful disagreement, Luigi. Bitmap images are less problematic in PDF/A because they include their own color space. This is why they work even with /S /GTS_PDFA3. But replacing vectors with bitmaps is a way of avoiding the issue, not of fixing it (if this needs to be fixed). Again, I don’t have any CMYK images and I thought this might be relevant to other users. Pablo -- http://www.ousia.tk

On 10/24/2017 07:51 PM, luigi scarso wrote:

On Tue, Oct 24, 2017 at 7:42 PM, Pablo Rodriguez wrote:

...

But replacing vectors with bitmaps is a way of avoiding the issue, not of fixing it (if this needs to be fixed).

yes, it's a clean way to resolve a problem that could not be solvable. The point is that is more easy to make a correct pdf than fix an arbitrary pdf to make it conform to the document

If the document is invalid, I totally agree with you, there is nothing to fix there. After analyzing cow.pdf, the issue is in that file. Of course, I didn’t mean to fix invalid documents. Although I think that there might be an issue with the way that LuaTeX (or ConTeXt, I don’t know) inserts form xobjects with CMYK colors in a PDF document. It adds them a color space that (I think) makes it impossible that an icc profile can be referred to the form xobject. Pablo -- http://www.ousia.tk

On 10/24/2017 09:38 PM, Hans Hagen wrote:

On 10/24/2017 8:21 PM, Pablo Rodriguez wrote:

...

It adds them a color space that (I think) makes it impossible that an icc profile can be referred to the form xobject.

Are you sure? The image is included as is. Nothing is added to its resource and as i mentioned a while ago, that's also beyond the engine.

You’re right, Hans, the issue with validation is caused by something different. I will investigate the issue myself and report here (or in the user list) the results. Many thanks for your help, Pablo -- http://www.ousia.tk

Am 24.10.2017 um 19:51 schrieb luigi scarso:

On Tue, Oct 24, 2017 at 7:42 PM, Pablo Rodriguez wrote:

...

On 10/24/2017 07:06 PM, luigi scarso wrote:

...

a pdf ? As said previously , including pdf can break the rules of format=PDF/A-3a. Simply include bitmap images, it's way more robust.

Allow me a fair and respectful disagreement, Luigi.

Bitmap images are less problematic in PDF/A because they include their own color space. This is why they work even with /S /GTS_PDFA3.

But replacing vectors with bitmaps is a way of avoiding the issue, not of fixing it (if this needs to be fixed). yes, it's a clean way to resolve a problem that could not be solvable. The point is that is more easy to make a correct pdf than fix an arbitrary pdf to make it conform to the document --- there are tools like pitstop for that.

I agree. Pitstop (Acrobat plugin) and PDFToolBox are the tools for such stuff. Analysing arbitrary PDF documents with successive color management is far beyond the scope of ConTeXt. Both mentioned prepress tools have free evaluation versions (at least at the time I tested them). If I remember right, Pitstop has build in such an option (change default CS for a complete document). Hope that helps, Peter