Out-of-order internal link target IDs break in some viewers

[aschmitz]

A document with internal links generally works fine, but if the link target IDs aren't in lexicographic(? ASCIIbetical?) order, some PDF viewers (notably at least Chrome's PDFium and macOS' Preview.app) will not treat the links as if they exist.

For example, rendering the following HTML fragment (no CSS necessary) with the current master branch will produce this PDF, for which the first link works in all tested PDF viewers (PDF.js, PDFium, Poppler, Preview.app), but the second link fails to work in PDFium and Preview.app:

<p>Use <a href="#zzz">link one</a> or <a href="#aaa">link two</a>.</p>
<div id="zzz"><h1>One</h1></div>
<div id="aaa"><h1>Two</h1></div>
<div style="break-before: always;">Second page for scrolling.</div>

However, swapping the zzz and aaa IDs (while leaving everything else as-is) appears to make both links work correctly.

I did a bit of digging into this, and it looks like the "Name Trees" part of the PDF reference (3.8.4) says the keys in name trees must be ordered, but it's not clear what the correct ordering there is. (They are currently in the order the targets appear in the document: perhaps some software is treating that "tree" as ordered by some key sort order and assuming the link targets don't exist?)

Hopefully the fix is simply just sorting the name tree, but you'll likely know that better than I do. (If I get some spare time, I may also attempt a fix, but again I suspect you'll be faster with it. 🙂)

[liZe]

Thanks a lot for the bug report, with the very useful HTML snippet.