32K lacks clarify on use of name or a single element array for certain color spaces

[petervwyatt]

ISO 32000-2 lacks any mention of a common practice whereby named ColorSpace resources for the simple color spaces that can be defined by just a name (i.e., DeviceXXX and Pattern) can be expressed either as a name or as a single element array. This is not mentioned anywhere in ISO 32000-2 and all examples in ISO 32000-2 use the inline form (i.e. none use the array form).

e.g. /CS0 /DeviceRGB and /CS0 [ /DeviceRGB ] and /CS0 /Pattern and /CS0 [ /Pattern ] are equivalent and both forms equally acceptable.

The easiest location to fix this is in Table 34 by giving permission (so no SHALL):

Colour spaces with no additional parameters (DeviceGray, DeviceRGB, DeviceCMYK, or Pattern) may be expressed either as a name or as a single-element array.

[mkl-public]

Is this a common practice? I'm not aware to ever have seen that in a PDF. But I haven't really looked out for such a construct, so I may have overlooked it. Do you know where that practice originated?

[petervwyatt]

@lrosenthol to provide input

[faceless2]

How common they are I couldn't say, but a public sample containing this is the "one patch per page" version of the Altona Technical Test Suite at http://www.eci.org/doku.php?id=en:downloads, see object "1170 0", [/Pattern]

Scanning our core collection of sample files, we have a dozen or so like this (most, but not all using it with /Pattern). Producer tags from various products mostly claiming versions of "Adobe PDF Library" as producer, but also a few naming GhostScript. Of course the issue could be in imported artwork - the Producer tag doesn't tell us anything conclusive.

Accepting it as an alternative format is one of many compromises that have to be made with the specification in the real world - I certainly agree this need to be at least documented, and although I have slightly mixed feelings about making it an official variation I suppose it's not gong to hurt.

[petervwyatt]

PS. My Arlington PDF model currently defines [ /Pattern ] as a violation (because it is a Pattern array object that is missing the mandated 2nd parameter, which is the only SHALL statement about Pattern name in arrays) so if someone wants to analyze it is possible...

[DietrichSeggern]

Just confirming what has been said above: [/Pattern] is very common in the color space resources in PDFs created with graphic arts authoring tools. Changing Table 34 as suggested by @petervwyatt makes a lot of sense.

PS Sorry that my mic forced me to stay silent yesterday.

[petervwyatt]

PDF TWG agree to formally define. I will come back with a set of proposed changes / locations to patch this in.

[petervwyatt]

Proposed solution patch locations

• Table 34, ColorSpace entry: add permission: "Colour spaces with no additional parameters (DeviceGray, DeviceRGB, DeviceCMYK, or some cases of Pattern) may be expressed either as a name or as a single-element array."

• clause 8.6.3 Colour space families:

  • 1st para, 2nd sentence is wrong as there are no parameters for DeviceXXX so the "shall" is wrong. Reword to just be permissive - "..., they may be distinguished ...".
  • 1st bullet, last sentence, name and single-element array forms are equivalent for DeviceXXX: "Since each of these families consists of just a single colour space with no parameters, they shall be referred to as either the name DeviceGray, DeviceRGB, or DeviceCMYK or, equivalently, as a single-element array containing one of these names. See 8.6.4"
  • 2nd bullet, last sentence is incorrect as color spaces are array objects and for ICCBased the parameters are a stream, not a dictionary: "Individual colour spaces within these families shall be specified by means of a multi-element array with array elements containing the parameter values needed to define the space. See 8.6.5"
  • 3rd bullet, ignores the fact that Pattern can also be a single-element array as Dietrich mentioned above, while also making it very similar to the 2nd bullet wording. "Individual colour spaces within these families shall be specified by an array, with multi-element arrays containing additional parameter values needed to define the space as required. See 8.6.6"
  • Each of these bullets should also get a specific cross-reference to their appropriate sub-clause: 8.6.4, 8.6.5, and 8.6.6

[petervwyatt]

Note that are several other non-obvious places in PDF where this ripples to:

• 3D PDF where DeviceRGB as a name is either explicitly stated or can be assumed by example and extant data that I have. e.g. 3D streams, Render Mode and Cross Section dictionaries, etc. I propose NOT to broaden the scope of any 3D PDF object and assume this should always just be a name.
• Trapnet appearances - explicitly specified as a name only. Stays that way so array form for device colour spaces is NOT allowed.
• Shading dictionaries - allows name or array when introduced with PDF 1.3 so array form [ /DeviceXXX ] is assumed to be acceptable by not limiting.
• Indexed color space base element (2nd element) - the original PDF 1.0 specified this as a name only (specifically the values DeviceRGB or DeviceCMYK) and it was only later expanded to support other colour spaces that were arrays. So assume we formally allow [ /DeviceXXX ] as that is backwards compatible by not limiting.
• ICC profile stream Alternate - allow [ /DeviceXXX ] array form by not limiting
• uncoloured tiling Pattern 2nd array element (underlying colour space) - allow [ /DeviceXXX ] array form by not limiting
• DeviceN and Separation color space alternateSpace array elements - allow [ /DeviceXXX ] array form by not limiting
• DeviceN process dictionary - allow [ /DeviceXXX ] array form by not limiting
• Transparency Group Attributes dictionary - allow [ /DeviceXXX ] array form by not limiting
• 12.3.4 Thumbnails - this references back to Image XObjects and has been around since PDF 1.0. DeviceCMYK is not allowed in any form for thumbnails and stays that way obviously. Allow [ /DeviceXXX ] array form by not limiting.

[faceless2]

Thank you Peter, that's a useful list. Out of curiousity I tested two of those cases (indexed color space base element; separation color space alternateSpace) and the five PDF viewers I tested are all fine with this syntax, so for those at least we're simply formalising existing practice. Testcases attached.

indexed-base.pdf separation-alt.pdf

[petervwyatt]

The benefits of the Arlington data model! 😊