8.4.5 (Graphics state parameter dictionaries, aka ExtGState): extend to full superset of parameters associated to individual operators

[stechio]

Within the graphics state model, the dictionary associated to the gs operator (ExtGState) supports only a subset (Font entry corresponding to Tf operator) of the text state parameters associated to individual operators (see 9.3, "Text state parameters and operators"); since text state operators can be applied at content stream level (see Figure 9, "Graphics objects" in 8.2, "Graphics objects") like any other graphics state operator, it looks pretty weird that such parameters are excluded from ExtGState.

Moreover, it would be convenient to include in ExtGState any other appropriate graphics state parameter associated to individual operators, such as colour-related ones (color space, color — see Table 51), as well.

PROPOSAL

My proposal is to extend ExtGState dictionary to support any appropriate graphics state parameter, in particular:

• all the text state parameters associated to the operators listed in Table 103
• all the colour state parameters listed in Table 51 (color space, color)

---

NOTE: The initial comment was updated to include any appropriate graphics state parameter, in particular colour-related ones.

[lrosenthol]

@stechio What is the use case/benefit to doing so? We already have standard ways to set these states in the content stream, what would we gain by extending ExtGState this way?

[stechio]

@lrosenthol Let me start by considering the other way around: why does ExtGState contain some parameters (font and line-related entries (such as line width, line join, etc)) which already have standard ways to be set in the content stream (respectively, Tf and w, J, j, M, d, ri operators)?

If font and line-related parameters were deemed appropriate to be mapped in ExtGState, I see no reason to exclude the other text-related parameters (such as character spacing, text rendering mode, text rise, etc): they mean to text what line-related parameters mean to paths; if the latter are useful within ExtGState, the same is, to my understanding, applicable to the former too.

Since, AFAIK, ISO PDF doesn't prescribe limitations to the use of ExtGState, I assume it can be employed in any convenient manner as a reusable resource. In my case, I would reuse a set of text-related parameters across multiple pages and/or Form XObjects, avoiding to repeat them over and over.

To me, leaving the font parameter alone in ExtGState seems an arbitrary limitation, especially considering that even future extensions to the graphics state are expected to "be implemented by adding new entries to the graphics state parameter dictionary rather than by introducing new graphics state operators", as stated by NOTE in subclause 8.4.5.

The obvious consequence of my reasoning would be the generalization of the ExtGState mapping to any other appropriate graphics state parameter already associated to individual operators, such as colour-related ones.