Even if you did get it working, there is a very good chance that only Adobe Reader/Acrobat would support it.
This severely limits valid use-cases because users have become acclimatized to relying on in-browser viewers embedded in a web app (e.g. that of Google Drive, OneDrive, Dropbox, HubSpot, etc.) or built into the browser itself. These almost always are highly minimalistic implementations.
For example, in a previous company, we wanted to provide our clients with a PDF guide which had in-document jump links (which, in the world of HTML, would be called "URI fragment links") and also a functional table-of-contents in the form of PDF "bookmarks."
But I ran into two major blockers:
First, Microsoft Word is almost the only non-Adobe product which is capable of producing such PDFs, and only when _saving_ as a PDF, not when _printing_ as a PDF (which reduces the document to little more than would be printed on a page).
Second, the only in-browser PDF viewer I could find which supports these features was, somewhat surprisingly, the one which is provided in WordPress. It supports both.
A similar story played out among mobile and desktop PDF viewers which weren't Adobe.
So for our beautiful, accessibility-compliant, featureful PDF, we had to provide very strict instructions on how to view it properly. When provided for viewing online, it _had_ to be hosted in a WordPress instance. And when offered for download, it _had_ to be accompanied by loud instructions explaining the situation and requiring users to install the free Adobe Reader.
You likely dodged a bullet by avoiding the use of any advanced PDF feature.
> Even if you did get it working, there is a very good chance that only Adobe Reader/Acrobat would support it.
I'm not sure about this. At least on Linux, where I just tested - I have in-document jump links working across Chromium, Firefox, Evince, Okular, and even KOReader. Tested on a random arxiv PDF[0]. Chromium and KOReader don't highlight links, but clicking them still works.
I didn't test on Linux, since we only permitted BYO Linux machines exceptionally.
And the PDF feature support landscape may have changed in the last year, since it was Q1 of last year (2022), I believe, when I last checked the in-browser PDF viewers in Google Drive, OneDrive, HubSpot, and Chrome for macOS and Windows. I suppose it might have been longer since I did the actual comparative testing.
> we wanted to provide our clients with a PDF guide
How often do you think they printed this guide, and of those instances, how often do you think they cared if the layout/pagination/etc. was identical to seeing it electronically? If that number is sufficiently low, I'd argue that the guide should've just been HTML.
I was told that we needed it (a computer requirements document) in PDF for legal reasons. I pushed back and legal confirmed that they did, in fact, need it to be in PDF format.
I suspect it had something to do with accreditation, accessibility, and/or student aid policy compliance, since this was a school.
But legal may also have found the relative transience of HTML documents to be a liability if a student threatened suit based on frequently changing policies, because I updated the requirements document twice yearly. PDFs made versioning very straightforward from a legal perspective, because the filename and download link always "needed" to be different between versions, without requiring dev work.
> Microsoft Word is almost the only non-Adobe product which is capable of producing such PDFs
LaTeX works great for links, automatic table of contents, references, and the rest. Basically just have the line `\usepackage{hyperref}` and include a `\tableofcontents` and you're set.
This severely limits valid use-cases because users have become acclimatized to relying on in-browser viewers embedded in a web app (e.g. that of Google Drive, OneDrive, Dropbox, HubSpot, etc.) or built into the browser itself. These almost always are highly minimalistic implementations.
For example, in a previous company, we wanted to provide our clients with a PDF guide which had in-document jump links (which, in the world of HTML, would be called "URI fragment links") and also a functional table-of-contents in the form of PDF "bookmarks."
But I ran into two major blockers:
First, Microsoft Word is almost the only non-Adobe product which is capable of producing such PDFs, and only when _saving_ as a PDF, not when _printing_ as a PDF (which reduces the document to little more than would be printed on a page).
Second, the only in-browser PDF viewer I could find which supports these features was, somewhat surprisingly, the one which is provided in WordPress. It supports both.
A similar story played out among mobile and desktop PDF viewers which weren't Adobe.
So for our beautiful, accessibility-compliant, featureful PDF, we had to provide very strict instructions on how to view it properly. When provided for viewing online, it _had_ to be hosted in a WordPress instance. And when offered for download, it _had_ to be accompanied by loud instructions explaining the situation and requiring users to install the free Adobe Reader.
You likely dodged a bullet by avoiding the use of any advanced PDF feature.