pdf-association
Regarding the display and interaction sequence of different types of annotations.
Describe the bug PDF specifications do not dictate the priority of display and interaction for different types of annotations. By default, one might expect the display and interaction priority to follow the order in which annotations were created when overlaps occur. However, this isn't consistently implemented in practice. For instance, with sticky note annotations, Adobe prioritizes their display and interaction over certain types like rectangle annotations. In contrast, Foxit prioritizes based on the creation order for both types, leading to different behaviors between the two applications. Both approaches can appear correct depending on the perspective. I suggest that the PDF specification should provide recommendations on the priority order for displaying and interacting with different annotation types. For example, Link annotations should have a higher priority (which most applications already do), Notes should be displayed before certain types of annotations even if they were created earlier than those annotations...
Here is a very simple test document. Adobe and Foxit behave differently. test.pdf
This is not an errata per-se, but a future feature request so labeled accordingly. IMHO this would be better resolved as an AppNote or Best Practice Guide to cover the breadth of issues, technologies, stakeholders, and specialized use-cases. Those types of publications have far more flexibility than ISO standards.
Without researching behaviour of any implementation, I note:
- there are many processor aspects not covered in ISO 32000 (including annot appearance stream creation/recreation);
- all annotation dictionaries can have an optional M entry (modification date, Table 166) however the fact this can be an arbitrary string and not only PDF date strings makes this painful to process;
- markup annotations can have an optional CreationDate entry (Table 172);
- there are features in PDF where we specify "in array order";
- annotations can also be imported via FDF and XFDF so this also needs consideration;
- annotations with 3D content is a challenge;
- the PDF spec only classifies annots as either markup or not;
- authoring apps can now use transparency effects when rendering annots onto a page in PDF 2.0 so overlapping annots can be made somewhat apparent now;
- there are some highly-specialized uses of annots in PDF (e.g., to support ISO 5776 text proofing; 3D markup) so need to be very careful about any presumptions about "common" annot appearances generated by widely used apps vs highly specialized apps;
- besides the individual on-page appearance of annots, nothing about the current desktop viewer popularity for "Comment" type nav-panes has ever been specified in any PDF reference or ISO 32000. The fact that implementations list only certain types of PDF annots but not others; the functionality on what gets shown vs not shown, filtering and sorting capabilities, small screen capabilities, etc. has all been left up to individual implementations and industry innovation.
This is 100% processor dependent, and there are business reasons that we do what we do - which have changed over time(!). As such, I wouldn't support any work in this area that would restrict implementation decisions.
