Handling of inline images with both abbreviated and full keys

[petervwyatt]

Clause 8.9.7 Inline images, Table 91 establishes that many keys in an inline image header pseudo-dictionary can be abbreviations of longer named keys in an Image XObject. But what happens if an inline image has both the full key name and its abbreviation (and they have different values)?

Is this a "duplicate key" and an error? In which case the clause 7.3.7 wording "Multiple entries in the same dictionary shall not have the same key" is inadequate as they are not actually the same key names (just logically/semantically).

We do NOT want to have "first key in dict" / "last key in dict" logic as that would also clearly contradict everywhere else in PDF and clause 7.3.7 "That ordering shall be ignored."

Or does one form of the key take precedence? e.g. long-form over abbreviation? Or vice-versa?

Or do we call this case out explicitly as an error in 8.9.7 and state that the inline image "shall" be skipped in any rendered output.

My preference is for some type of "resolve and continue processing" handling so that the inline image might hopefully get painted.

[lrosenthol]

Looking at the implementation of a well known PDF processor...

We always look for the short form/abbreviation first. If not present, then we look for the full name.

[petervwyatt]

Proposed solution: prioritize abbreviated keys first, then use full key names.

Proposed additional sentence: "In the situation where both an abbreviated key name and the corresponding full key name from Table 91 are present, the abbreviated key name shall take precedence."

Appended to this paragraph "The key-value pairs appearing between the BI and ID operators (as listed in "Table 91 — Entries in an inline image object") are analogous to their respective key-value pairs in an image XObject dictionary (see "Table 87 — Additional entries specific to an image dictionary") or a stream dictionary (see "Table 5 — Entries common to all stream dictionaries"). For convenience, the abbreviations shown in "Table 91 — Entries in an inline image object" and "Table 92 — Additional abbreviations in an inline image object" may be used in place of the full names. Entries other than those listed shall be ignored."

[MPBailey]

+1 for the proposal.

But every time I re-read a section I find some more niggles. So here are a few minor tweaks in the related text; feel free to split into separate stories if you think these are worth following up:

• There a striking contrast between the text in the 1st para after Table 90: “Unless the image uses ASCIIHexDecode or ASCII85Decode as one of its filters” and in Note 2: “if the final or only filter is ASCIIHexDecode or ASCII85Decode”. Shouldn’t the first of those also talk about “if the final or only filter” rather than ASCII~ being “one of its filters”? I realise you’d need to have done something very odd if you’re using ASCII~ and something else, and the ASCII~ is not last, but …

• Note 1 carefully mentions both Length and L, but Note 2 only mentions L, which seems inconsistent. Note 2 should identify both as well.

• Note 3 says that various colour space names don’t refer to resources in the ColorSpace subdictionary; all well and good. But it starts by saying that they identify the corresponding colour spaces directly. Hmmm, don’t DefaultGray, DefaultRGB and DefaultCMYK kick in here?

[petervwyatt]

Could you please make a new Issue for your 2 new points above?
This issue is about the behaviour for logically-duplicated-but-not-actually-duplicated keys in inline images, whereas your new issues are about special handling rules for ASCII* filters in inline images. Same clause but different core issues. Thanks.

[MPBailey]

Done, thanks