12.5.6.13 (Ink annotations): functional gap between InkList and Path entries

[stechio]

Older InkList entry (Table 185 — Additional entries specific to an ink annotation) defines an array of separate subpaths ("An array of n arrays, each representing a stroked path"), whilst newer Path entry defines a single subpath ("An array of n arrays, each supplying the operands for a path building operator (m, l or c)").

PROPOSAL

Path entry syntax should be augmented to support intermediate moveto operations (beyond the first one currently supported) in order to allow separate subpaths, like the corresponding InkList entry.

Since operand arrays associated to moveto and lineto operators are indistinguishable, in order to fit multiple separate subpaths it would be necessary to add a new unambiguous syntactic delimiter (which would be incompatible with current definition), for example the null value:

[
% subpath 1
  [10 0]   % moveto
  [10 10]  % lineto
  [35 15]  % lineto
  null     % end subpath
% subpath 2
  [80 100] % moveto
  [50 40]  % lineto
]

or, alternatively, to add a grouping level, encapsulating each subpath in a separate array:

[
% subpath 1
[
  [10 0]   % moveto
  [10 10]  % lineto
  [35 15]  % lineto
]
% subpath 2
[
  [80 100] % moveto
  [50 40]  % lineto
]
]

[lrosenthol]

These are designed for very different purposes and allowing for disconnected segments in Path would break that.

[stechio]

@lrosenthol:

These are designed for very different purposes and allowing for disconnected segments in Path would break that.

Could you please clarify the "very different purposes" which distinguish Path entry from InkList entry?

Apparently, subclause 12.5.6.13 doesn't say anything in regards to this; on the contrary, it emphasizes that paths in an ink annotation can be disjoint:

An ink annotation (PDF 1.3) represents a freehand "scribble" composed of one or more disjoint paths.

Based on such strong assumption, my interpretation inferred that Path entry was just a more capable and refined representation of the same content described by the older InkList entry; in fact, InkList entry misses curves, sloppily referring the details of the actual drawing to the renderer:

When drawn, the points shall be connected by straight lines or curves in an implementation-dependent way.

On the other hand, Path entry adds an explicit expression for curves, clearly filling the gap left by the coarse definition of older InkList entry.

Because of my inference, I think Path entry is an incomplete representation of the ink annotation, as it cannot express disjoint segments, contrary to homologous InkList entry.

[lrosenthol]

Could you please clarify the "very different purposes" which distinguish Path entry from InkList entry?

Path is present to enable support for handling click testing on non-rectangular annotations/regions, while InkList is present to enable recreation of the appearance of an Ink annot.

[stechio]

@lrosenthol:

Path is present to enable support for handling click testing on non-rectangular annotations/regions, while InkList is present to enable recreation of the appearance of an Ink annot.

Sorry, your definition is seriously at odds with what the spec states: as already noted in a previous issue (#444), the Path entry is symmetrically defined BOTH for ink annotations AND for polygon and polyline annotations (12.5.6.9). In both cases the constructed path is explicitly aimed at graphical rendering (NOT click testing!):

The current graphics state shall control the path width, dash pattern, etc.

For polygon/polyline annotations, the Path entry has always been explicitly related with the Vertices entry as a more capable and refined representation, so much so that they are mutually alternative:

[Vertices entry] (Required unless a Path key is present, in which case it shall be ignored)

[Path entry] If this key is present the Vertices key shall not be present.

Analogously, for ink annotations the graphical relation between Path and InkList entries has been confirmed by the PDF TWG through @petervwyatt (see #444 and related erratum).

Comparing the spec definitions of polygon/polyline annotations and ink annotations, I can deduce that the spec editor made a verbatim copy of the Path entry description overlooking the fact that ink annotations, contrary to polygon/polyline annotations, are disjoint sequences of points: the old definition (InkList entry) supported such disjoint paths, whilst the spec editor missed to adjust to the multi-path ink annotations the single-path Path entry description copied from polygon/polyline annotations.

All considered, my initial assumption is still valid, and so my request to fix the definition of the Path entry of ink annotations to support disjoint paths, thanks.

[seehuhn]

One additional thought: Since Path was introduced in PDF 2.0 where appearance streams are required, Path cannot be involved in rendering the ink annotation when viewing the document. I agree that this contradicts the language in the spec. Also see #607 .