Link annotations as Artifacts

[bdoubrov]

PDF/UA-2 and WTPDF contain two conflicting statements regarding link annotations and Artifacts:

8.2.5.20: A link annotation (see 8.9.2.4.2) and its associated content shall be enclosed in either a Link or Reference structure element.

8.9.2.2: Any annotation, regardless of its type, may be an artifact (see 8.3). Annotations that are artifacts shall either not be present in the structure tree or shall be enclosed within Artifact structure elements.

It is understood that 8.9.2.2 takes precedence and Link annotations may still be Artifacts and, in such case, may not be included into the structure tree despite the statement of 8.2.5.20. If this is correct, it would be great to have an explicit note in the specification to clarify this.

[DuffJohnson]

I propose that we add a new NOTE to 8.9.2.2, after the first sentence of the first paragraph, as follows:

NOTE: This provision supersedes other requirements in 8.9.

[petervwyatt]

A NOTE doesn't change anything normatively...

Why not reword 8.2.5.20 as:

Unless artifacted (see 8.9.2.2), a link annotation (see 8.9.2.4.2) and its associated content shall be enclosed in either a Link or Reference structure element.

[DuffJohnson]

The note provides guidance on how the document's existing provisions are to be understood.

Maybe this clarification requires a normative change, but that's not obvious (to me).

[mrbhardy]

I agree with Duff. There’s nothing wrong with the provisions. Just a little bit of clarification needed.

…

On Tue, May 12, 2026 at 7:22 PM Duff Johnson ***@***.***> wrote: *DuffJohnson* left a comment (pdf-association/pdf-issues#751) <#751 (comment)> The note provides guidance on how the document's existing provisions are to be understood. Maybe this clarification requires a normative change, but that's not obvious (to me). — Reply to this email directly, view it on GitHub <#751 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABT6F2QB2E6W7TFXT66S43D42PL6NAVCNFSM6AAAAACYY5674SVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHM2DIMZWGU4TOMRXGA> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>. You are receiving this because you were assigned.Message ID: ***@***.***>

[u-fischer]

NOTE: This provision supersedes other requirements in 8.9.

As the requirement for link annotation is in 8.2.5.20 (and so not in 8.9), I'm not confident that this note makes clear that links annotations can be artifacts too. I would suggest to be more explicit:

NOTE: This provision applies also to link annotations and supersedes 8.2.5.20.

[DuffJohnson]

But, "this provision" does NOT supersede any requirement in 8.2.5.20 at all.

Provisions regarding annotations (which in PDF includes links in PDF) govern annotations. 8.2.5.20 governs structure elements.

There's nothing in PDF/UA-2 suggesting that links cannot be artifacts. However, given that many readers may bring a PDF/UA-1 "mindset" I agree that we could do more to help them.

So, in addition to the previously-suggested NOTE after the first sentence of the first paragraph:

NOTE 1: This provision supersedes other requirements in 8.9.

I suggest another NOTE following the second sentence in the same paragraph:

NOTE 2: As 8.2.5.20 requires Link annotations to be enclosed in either Link or Reference structure elements, this provision implies that in conforming documents Link annotations intended as artifacts will their respective Link or Reference structure elements enclosed by Artifact structure elements.

[u-fischer]

I suggest another NOTE following the second sentence in the same paragraph:

With this suggestion you are actually contradicting the discussion from the last LWG meeting and go back to the current status.

The main question in the discussion was, if link annotations can be "real artifacts". That means can they like other annotations not be present in the structure tree and so does 8.9.2.2 supersede 8.2.5.20. If you now require again that 8.2.5.20 takes precedence and force link annotations to be inside an Link SE inside an Artifact SE you are back to the problem we demonstrated in the meeting: as SE inside Artifact are not necessarily ignored (by implementation but also as discussed by design) we have to collect the artifact link annotations at the end of the document to avoid that you get random readout "Link" "Link" from links in artifacted frames or headers and footers.

[DuffJohnson]

Perhaps I'm not recalling the discussion fully / correctly.

The problem you are describing is a problem for software that doesn't understand PDF/UA-2.... but this should not influence PDF/UA-2, should it?

[u-fischer]

Well they were in London (e.g. in UA-processor) also various discussions about Artifact SE. And the consensus was that their content and their Kid-structures are not necessarily ignored. Putting content inside an Artifact SE is not the same as putting content inside an Artifact MC. The expectation is that a processor can retrieve and use content like linenumbers from an Artifact SE depending on the use case. If you want something to be always ignored you have to use artifact MC.

For annotation this means that putting an annotation inside an Artifact SE is not the same as not putting it into the tree at all.
If you really want an annotation to be ignored you should not put it into the tree at all.

If you forbid that for link annotations it means that you are not allowing to fully artifact them.