Annex E.2 list of places where 2nd class names are explicitly not required is incomplete

[petervwyatt]

Annex E.2, 2nd bullet under "Second class" states ".. except keys added to a document information dictionary (see 14.3.3, "Document information dictionary") or a thread information dictionary (in the I entry of a thread dictionary; see 12.4.3, "Articles").". This is an incomplete list of officially allowed places in PDF where developers may legally add their own custom names that do not have to be 2nd-class names.

A list of other places with either explicit or implied wording (in no specific order) - there may well be others:

• Encrypted Payload dictionary, Table 28, Subtype key
• 12.6.4.12 Named actions, 1st para "... further names may be added in the future".
• Optional Content Usage dict, Table 100, CreatorInfo entry: "Suggested values include but shall not be limited to ..."
• Navigators, Layout entry, para about Table 160: "This mechanism is inherently extensible and allows inclusion of custom named layouts ..."
• Rubber stamp annot, Table 184, Name entry: "Additional names may be supported as well."
• File attachment annot, Table 187, Name entry: "Additional names may be supported as well"
• Printer's Mark annot, Table 398, MN entry: "An arbitrary name identifying the type of printer’s mark, ..."
• Structure Attribute Owner, Table 360, O entry: see Errata Syntactic rules for valid attribute objects across clauses 14.7 and 14.8 is very difficult to understand and has mistakes #226
• Structure Attribute attribute key names: see Errata Syntactic rules for valid attribute objects across clauses 14.7 and 14.8 is very difficult to understand and has mistakes #226
• Marked Content tag operands, Table 352

[michaeldemey]

The names of resources are also not explicitly allowed to be custom names without the need for second class names.

7.8.3 Resource dictionaries

The paragraph just before Table 34 - Entries in a resource dictionary

"
The corresponding values shall be as follows:
• For all resource types, the value shall be a subdictionary. Each key in the subdictionary shall be the name of a specific resource, and the corresponding value shall be a PDF object associated with the name.
"
Doesn't mention that you can use a custom name.

It is implicitly talked about and shown in Example 2 following Table 34:

"
EXAMPLE 2 The following shows a resource dictionary containing fonts, and external objects. The fonts are specified with a subdictionary associating the names F5, F6, F7, and F8 with objects 6, 8, 10, and 12, respectively. Likewise, the XObject subdictionary associates the names Im1 and Im2 with objects 13 and 15, respectively.
"

But never really outspoken or defined that it is allowed. Unless I'm overlooking a clause somewhere.

[petervwyatt]

Trying to progress this forward...

Examining the Arlington PDF Model shows many (~41) places where anything might be used as a key name. Since this is such a long list it is probably a better approach to strike the incorrect statement from Annex E rather than attempt to fully expand it and maintain it.

Proposed solution is thus to replace "except keys added to a document information dictionary (see 14.3.3, "Document information dictionary") or a thread information dictionary (in the I entry of a thread dictionary; see 12.4.3, "Articles")." with "except where otherwise stated in this specification." since these few cases already have explicit statements.

If this is accepted then each situation needs to be independently reviewed as to whether the requirements for a second-class name or not are sufficiently stated (there are statements in some places, but not others - but the omission doesn't necessarily mean anything goes). Separate errata can then be raised for each of those places.

[petervwyatt]

PDF TWG agree to the Annex E change.
Other changes to be done as new errata.