Query on halftone failure for PDF/A-4 test 6-2-5-t05-fail-a.pdf

[faceless2]

Specifically this one is on "PDF_A-4/6.2 Graphics/6.2.5 Extended graphics state/veraPDF test suite 6-2-5-t05-fail-a.pdf"

Issue is - I'm not sure why this is a fail.

The PDF has an RGB output intent and is drawing in RGB - and it has applied a Type 5 halftone, with nested Type 1 halftones called Red, Green and Blue. The nested halftones do not have a TransferFunction key.

I can't see anything in 6.2.5 that disallows this, nor in ISO32K:2020 10.6

The text which I suspect is driving this test is the definition of the TransferFunction key for a Type 1 halftone dictionary:

A transfer function, which overrides the current transfer function in the graphics state for the same component. This entry shall be present if the dictionary is a component of a Type 5 halftone (see 10.6.5.6, "Type 5 halftones") and represents either a nonprimary or nonstandard primary colour component (see 10.5, "Transfer functions"). The name Identity may be used to specify the identity function....

If Red, Green and Blue were "nonprimary or nonstandard primary colour component" they would indeed require a TransferFunction key.

But... the output intent of the PDF is an RGB profile, so I think the "primary colors" of the output device are Red, Green and Blue. Because Red, Green and Blue are the primary colors, they don't need a TransferFunction key in their Halftone dictionaries.

That's my reading, unless I've missed something. It does depend on the "Output Intent" defining the "native color space" of the device, which I thought was a pretty solid presumption until I realised that's not explicitly stated in 32000 or 19005. If not (or if the OutputIntent is missing) then what is the "native color space" at that point? It's device-dependent, surely? I can't see anything that says otherwise - the nearest is a comment in 32000 sec. 8.6.45.7 note 2:

... This calibration is then considered to be that of the native colour space of the intended output device (typically DeviceCMYK) ...

As usual, I'm happy to move this to PDF/A issues if you think there's something other than a typo here. And I'm also prepared for you to point me to where the native color-space is defined as CMYK, in which case feel free to close this.

I would also like to add this this is a very obscure test on a very obscure area, and we're absolutely failing it for either interpretation! Well done to whoever came up with this one.

[bdoubrov]

This has been debated several times: whether RGB output intent means that Red, Green, Blue are the primary colors. The issue is that they are not additive, while only additive colorants may be primary. But I'd be happy to rediscuss this question at the next PDF/A TWG.

[faceless2]

Yes, it does feel like old ground, although I'm not sure I've personally hit it in the context of halftones before. But I agree with your assessment and it's the only approach that's possible when no output-intent is present. We'll adjust to match this approach and if you feel it's necessary we can confirm at the next TWG as you say. Thanks.

[faceless2]

I have to come back to this one, sorry. The reason I've circled back here is that the language in PDF/A-2:

The TransferFunction key in a halftone dictionary shall be used only as required by ISO 32000-1.

and PDF/A-4:

The TransferFunction key in a halftone dictionary shall be used only as required by ISO 32000-2:2020.

is identical. PDF/A-4 contains an explanatory note which is missing from PDF/A-2:

The TransferFunction key in a halftone dictionary can only be present if it is a component in a Type 5 halftone dictionary representing a colorant other than Cyan, Magenta, Yellow or Black.

but the requirements in the underlying spec didn't change between ISO32000-1 and ISO32000-2 - the language (quoted in my first post) is essentially identical. Which is why I'm confused as to why these two identical tests have different results under PDFA4 and PDFA2.

• PDF_A-4/6.2 Graphics/6.2.5 Extended graphics state/veraPDF test suite 6-2-5-t05-fail-a.pdf
• PDF_A-2b/6.2 Graphics/6.2.5 Extended graphics state/veraPDF test suite 6-2-5-t03-pass-b.pdf

I'm presuming that this requirement wasn't clear at the time of PDF/A-2, so the PDFA2 test (which is nominally testing something else) was considered a pass. When the requirement was clarified (but not changed) for PDF/A-4, the PDF/A-2 version of the test was left unchanged.

But looking at both together, with the language in ISO32K unchanged I'm unable to see how one is a pass and one is a fail.

[bdoubrov]

We have fixed the implementation and updated the test file accordingly. Now RGB colorants are not treated as primary. Thus, transfer function is permitted for halftones, associated with these colorants.

[MaximPlusov]

Included into release 1.24