Test 6-2-5-t05-fail-a: TransferFunction in a Type 5 Halftone dictionary is not required for primary components

[DietrichSeggern]

The test file uses a halftone dictionary of Type 5 with components Red, Green and Blue, neither of them has a TransferFunction entry.

PDF/A-4 requires (6.2.5): "The TransferFunction key in a halftone dictionary shall be used only as required by ISO 32000-2"

ISO 32000-2 in Table 128 on TransferFunction: "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")."
Primary color components are defined in 10.6.5.6 as being: "for the standard native device colour spaces (Gray for DeviceGray; Red, Green, and Blue for DeviceRGB; Cyan, Magenta, Yellow, and Black for DeviceCMYK;)."

My understanding is that Red, Green and Blue are primaries here and therefore no TransferFunction entry is required.

[bdoubrov]

I do remember a number of discussions around this topic, which resulted in the following note in PDF/A-4:

NOTE 1 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.

This note suggests that only Cyan, Magenta, Yellow or Black can be primary colorants. As far as remember, Red, Green, Blue cannot be primary colorants, because they are not additive.

[DietrichSeggern]

I had not seen that note in PDF/A, thanks.

The note, does, IMO contradict what is (as cited above) specified for primaries in 10.6.5.6 as being: "for the standard native device colour spaces (Gray for DeviceGray; Red, Green, and Blue for DeviceRGB; Cyan, Magenta, Yellow, and Black for DeviceCMYK;)."

I think we should not flag that as an error in PDF/A validation, because:

• That contradiction (at least not for Red, Green and Blue)
• The provision in PDF/A says that it shall only be used if required, it does not say that it has to follow what is specified in ISO 32000-2 which means we would enter PDF validation
• The provision is from a PDF/A standpoint not relevant for rendering because it would only make a difference in a professional printing environment. (It is an inheritance of PDF/X where it indeed makes sense, so I would be in favor of removing it in a dated revision for PDF/A-4).

Probably something for the TWG?

[faceless2]

I also had trouble with this one - see #238.

The TL;DR of that was that the requirement in PDF/A-4 should be identical to that in PDF/A-2 because the language in 32K was unchanged. That was how I saw it anyway - I know nothing about the reasoning behind these requirements, so I might be missing something.