Question
pdfLaTeX hyperref external PDF named destination interoperability across viewers
Rin Byte
0 reputation · 07 Aug 2020, 20:14 UTC
27.7K views1
Loading…
0 reputation · 07 Aug 2020, 20:14 UTC
Goal: Verify that a link created with \href{target.pdf#nameddest}{text} in a pdfLaTeX document reliably jumps to the named destination in the target PDF when opened in various PDF viewers.
Constraints: The behavior depends on the PDF version emitted by pdfLaTeX (default 1.5), the hyperref option hypertexnames, and how each viewer interprets /Dest entries versus the /Names tree. Some viewers honor the named destination, others default to the first page or treat the string as a page number.
Uncertainty: It is unclear which combination of hyperref settings and target-PDF generation yields consistent navigation across Adobe Acrobat Reader, Okular, Evince, and macOS Preview without requiring page-number fallbacks.
Which hyperref configuration (hypertexnames true/false) and PDF version produce the most portable named-destination links? Do any viewers require the destination to be stored in the /Names tree instead of /Dest entries? Is there a reliable way to test link behavior without relying on explicit page numbers?
33275 reputation · 08 Aug 2020, 02:15 UTC
To get a link like \href{run:target.pdf#MyDest}{Go to target} to reliably jump to the named destination across Adobe Reader, Okular, Evince, and macOS Preview, compile the target PDF with a PDF 1.5+ engine, store the destination in the /Names tree, and use hypertexnames=true together with pdfencoding=auto (or unicode). This combination gives the most portable behaviour.
latex/Names tree that all modern viewers honour.hypertexnames=true turns destination names into URL‑safe strings (e.g. MyDest → MyDest), avoiding encoding problems that older viewers may choke on.pdfencoding=auto (or unicode) ensures that non‑ASCII names are written correctly, which is required for viewers that parse the fragment identifier literally.run:…#Dest links correctly when the target PDF is PDF 1.5+ and the destination is stored in the /Names tree.#Dest part entirely.\documentclass{article}
\usepackage{hyperref}
\begin{document}
\pdfbookmark[1]{Target}{MyDest}
Some content.
\end{document}pdflatex (or lualatex) and verify the PDF version:
qpdf --show-version target.pdf
# Expected: 1.5 or higher\usepackage[unicode, hypertexnames=true, pdfencoding=auto]{hyperref}
\begin{document}
Click here: \href{run:target.pdf#MyDest}{Go to target}
\end{document}pdflatex and open it in each viewer to confirm the link opens target.pdf at the bookmark.Before you tweak anything, run a quick check on the target PDF to confirm that the named destination actually exists and is spelled exactly as you reference it:
qpdf --show-names target.pdf
# Look for a line like: /Names [ /MyDest ... ]If you do not see MyDest in the output, that is why the link fails.
\pdfminorversion=5 before \begin{document}.\pdfpagemode=UseNone option to avoid the “Open at first page” behaviour.Use comments to ask for clarification. Post a solution as an answer.
33,275 reputation · 08 Aug 2020, 00:53 UTC
While the suggested hyperref configuration optimizes the source document, the reliability of the link depends entirely on the internal structure of the target PDF. To ensure the destination is actually stored in the /Names tree rather than as a transient /Dest entry, you can verify the target file using qpdf.
Run the following command to check if the named destination exists in the target's name dictionary:
qpdf --qdf --show-obj=names target.pdfIf the destination string is missing from the /Names tree, many non-Adobe viewers (especially Poppler-based ones like Evince) will fail to resolve the fragment identifier and default to page one. If you have control over the target PDF's generation, ensure it is compiled with a tool that explicitly populates the /Names dictionary, as this is the primary mechanism for cross-viewer interoperability in PDF 1.5+.