PDF In-Depth

PDF Best Practices #3: Learn to Link

December 12, 2001


Links are a key element of interactive PDFs, enabling quick access to resources within the current PDF, in other PDFs or in outside sources (such as the Web).

What items should be linked in an interactive PDF?

As the bare minimum:

  • All navigational items -- such as Table of Contents, Index, List of Figures, List of Tables and List of Procedures.

  • Infographics -- such as roadmaps or troubleshooting diagrams

  • Cross-references to headings, figures and tables

  • Web and FTP addresses; e-mail addresses should also be clickable, with default fields populated.

  • Footnotes

With a more complex interactive design, additional items such as buttons and images may be linked.

Link Properties

Links must be visible in a consistent manner, or else it will be practically impossible for the reader to take advantage of the linking capability.

On the other hand, as links are embedded in the actual text or graphics content, care should be taken not to make links too noticeable or too numerous, to the extent of disturbing the flow of reading. Another consideration is the impact on printed output, if this is part of the anticipated use.

Visual properties of links include:

  • Text attributes such as color, font and/or underline -- a common convention being blue/underline. The underline is best avoided, as it is may be displayed with inconsistent thickness in Acrobat, as well as being prominent in printed output. It can also cause excessive disruption of reading flow. Different colors may be used to indicate link type, e.g. one color for internal links and another for external links that may require a Web connection.
  • When assigning properties, take care to only apply these to the actual link text, and not to entire sentences or phrases (e.g. when making a reference to a heading, the heading text should be displayed differently, but not the insignificant items such as "see," "refer to" or "on page 7").
  • Link borders may also be visible, even though this will generally be distracting; border color and thickness can be controlled for a softer appearance.
  • Links can have different highlighting styles. While for regular text the standard invert highlighting style may be fine, an outline style can be more subtle in many cases. With buttons, the push style may be more appropriate. With round buttons or graphic items covering non-rectangular items, specifying no highlight is best, since Acrobat links are always rectangular and a highlight will emphasize the lack of correlation between the item shape and the link shape.

Link Area

For professional appearance, the link area should precisely match the specific link text, button or graphic item. When the highlight style is not set to none, a discrepancy between the area and the underlying item is noticeable, with an unpleasant visual effect. This is an issue with links created manually, but also with links created automatically by different products/add-ons -- split to multiple segments, or offset (often due to missing fonts or font metrics problems).

The link area should also be applied consistently -- for example, in a linked table of contents, heading text and page numbers should both be linked; if only one of the two is linked and visible, this may be fine too as long as this is consistent. However, inconsistencies as to what is active and what is not will adversely affect the usability of such a table of contents for navigation purposes.

Link Functionality

Bad links have a negative impact on the user experience. Apart from being frustrating, they cause users to distrust other links and refrain from using them. Bad links will be noticed while viewing a PDF in Acrobat in one of three forms:

  • Links which cause an error message to be displayed -- such links point to files which are not present in the end-user system (for different reasons, including files that are renamed, merged, missing).

  • Links which point to the wrong place, without displaying an error message -- this is the case when Acrobat finds the target file but cannot locate the specific destination in that file (and points to the default opening page of that file, usually page 1).

  • Links which do not do anything.

Depending on the specific process used to create links and to finalize the PDF document(s), there may be different reasons why links become bad.

Testing link validity on a random click here and there basis is of very limited value. The systematic validation of links (and all interactive features) using a PDF link checker, together with additional techniques, must be done as part of the testing phase to ensure quality.

Advanced Link Options and Issues

When designing an interactive PDF, additional aspects may be taken into account:

  • Link presentation -- how to reduce the noise associated with links and too many options and minimize disturbances to reading while enabling easy navigation to related topics. This can be done, for example, with a button which, when clicked, presents a list of with context-related choices, or placing links in a separate area and not embedded as visible links in the text itself.
  • Cross-file links -- opening target PDFs in the same window or in a separate window. While there are ways to control this on a global basis in Acrobat/Reader (through local preferences or JavaScript), specifying this behavior on a specific link basis is not currently supported by Acrobat and can only be done with advanced techniques or add-ons.
  • Link modifiers (such as Alt or Shift keys) -- enable the same single link to launch two different actions.
  • Controlling the link target display -- a single page vs. continuous mode.
  • Relying on standard Acrobat interface items, or duplicating some of these as part of the design -- for example: Next/Previous Page, Back or Search buttons.
  • Advanced linking through form fields, with benefits such as tool tips and multiple triggers (enter area, click, exit area), pop-ups with more information (e.g. glossary definitions), sound integration, and multiple appearances.
  • Print-related aspects -- how to suppress the appearance of links and buttons in the printed output.

Analysis of Link Usage in Acrobat 5 CD PDFs

NOTE: The versions of the PDFs cited in these examples are those available on the Acrobat 5 CD; in some cases, newer versions may be available online.

Acrobat Help PDF

The Acrobat 5 CD has 42 PDFs, including the Acrobat Help File and the Acrobat SDK documentation (Acrobat SDK files are also available for download through the Adobe Solutions Network (ASN)).

The PDFs were authored in FrameMaker (mostly 5.5.6 and 6.0); one PDF was authored in Microsoft Word. FrameMaker is capable of automatically generating links from cross-references and hypertext markers; Word with PDFMaker has similar capabilities. It seems that links in these PDF were not added or enhanced using additional techniques (whether manual or through add-on products); as the numerous bad links indicate, links were not tested methodically.

Common problems are:

    Duplicate links
  • Unintentional links
  • Bad links
  • Missing links
  • Link visibility
  • Excessive "Named Destinations" supporting links
  • Web links
  • Inconsistent link area
Duplicate Links

Acrobat 5 Help

The Acrobat help PDF (Acrohelp.pdf) has two pairs of next page / previous page buttons on each page (top and bottom); each of these four buttons is duplicated -- i.e. has another link with an identical action underneath it. Turning on Acrobats Link tool, you can drag each Next/Previous page link to reveal a duplicate link underneath. While in this case the duplicate links do not cause problems, these extra links -- duplicated on each page -- take up around 140K; regardless of job options used, Acrobat does not compress data related to interactive items, such as links, bookmarks and destinations. (A separate, design-related question is why there is a need to place six links -- Using Help, Contents, Index, Back, Previous Page and Next Page -- twice in each page, in the header as well as in the footer).

This duplication is the result of a user error, the links having already been duplicated in the source FrameMaker file. In many other PDFs, some links are duplicated as a result of a FrameMaker bug (fixed in version 6.0). As one example out of many, open the Acrobat Forms API Reference (FormsAPIReference.pdf) and activate Acrobats Link tool. In the Contents pages v-ix, you can see duplicate links in the bottom area of the page -- the last link on each page duplicated on the next page. These duplicate links may overlap useful links, or be placed in an area where there is no text, depending on specific text layout in each page. On page vii, under OLE Automation Methods, the Field heading has two overlapping links -- one (valid) pointing to page 107, the other one pointing to page 77 (last entry on previous page). The exact cursor location when clicking will determine which link is activated. A similar problem is evident in the index of the CoreAPIReference where the last link in every page is duplicated in the bottom right corner of the next page. While this problem is common in Contents and Indexes, it may appear in other locations.Lapped links

Unintentional Links

The CoreAPIReference.pdf file also contains unintentional links -- links created automatically from cross-references used for purposes not related to interactivity. 2750 pages have a footer with the book title -- Acrobat Core API Reference -- linked to the title on page 1. These links serve no purpose other than helping inflate the file size -- 17.4 MB, out of which about 15% is attributed to links. (This practice is repeated in several PDFs; for the purpose of referring to a book title, FrameMaker variables should be used instead of cross-references). In some cases, these unintentional links even become bad links (DevelopmentOverview.pdf).

Bad Links

The Acrobat Development Overview (DevelopmentOverview.pdf) can be used to demonstrate Links that point to non-existing files: see page ix, under How This Document Is Organized -- when clicked, links display the "The specified file does not exist" error message. (Incidentally, the items being pointed to are present in the same PDF file, but the links point elsewhere).

The Acrobat Core API Overview (CoreAPIOverview.pdf) has many links that point to the right file, but where a mismatch exists as to the destination to be located in the target file. When Acrobat finds the file but not the destination, it opens the file at the default opening page (usually first), without indicating that there is a problem with this link.

Missing Links

Missing Links

You would expect that the CoreAPIReference.pdf, being a 2750 page PDF, would have a detailed and fully-linked table of contents, making it easier to locate items or navigate in a document of this scope. The Table of Contents is slightly longer than one page (!) -- it has 19 items in total. And to make it even more absurd, these items are not even linked.

Link Visibility

In fairness to the CoreAPIReference.pdf, it does have extensive linking of function names, clearly and consistently visible as links, which does make it easier to jump find more information while reading. Some other PDFs are less consistent, with the PDF Reference manual (PDFReference.pdf) being a striking example of invisible (and therefore useless) links.

The Acrobat Help, on the other hand, overdoes visibility -- likely the result of employing automation with lack of attention to details. Throughout, the entire link is blue/underline, including the on page xx part. Page number information is usually redundant in an online document, as clicking the link takes you there anyway. Even if this information is kept for print purposes, attention should be drawn to the heading text only, reducing unnecessary interference with the flow of reading. (In the authoring stage, this could have been changed globally in one operation, in a matter of seconds).

Excessive Named Destinations Supporting Links

Space Audit

To support automatic links in generated files, such as table of contents, FrameMaker adds a named destination for each and every paragraph, regardless of its actual use. This is the case even with empty paragraphs (such as in empty table cells). In typical books, only a small percent of the paragraphs is used as the target of links in generated lists. As each named destination takes up around 100 bytes or more, having lots and lots of named destinations has a high price tag. In the 17.4MB CoreAPIReference.pdf, about 35% (!) of the file size is reported to be used for named destinations, out of which only a small portion is actually used.

Web Links

All Web, FTP and e-mail addresses in an online publication should be linked. In the PDFs in the Acrobat 5 CD, most of these are not clickable. In the Acrobat Help PDF, there are over 25 static Web site addresses; all of the cover pages in the SDK also have a Web site address in print form only. Having a link to the corresponding document/site on the Internet would have made it easier to spot version changes or product-related news. E-mail links with context-related default subject fields make it easier for users to provide feedback.

Inconsistent Link Area

Links in the first pages of PDF Reference Manual (PDFReference.pdf) demonstrate common inconsistencies in link areas. In the Table of Contents (below, left), each of the headings is a link, whereas in the List of Figures and List of Tables (below, right), only the figure/table number is active (with a few random exceptions).

TOC links

No links

Most PDFs in the SDK documentation have a road map showing the different sections of the document collections, with a box for each document. But instead of having the entire box as a link, different segments of the title inside the box are active. While such links are fine functionally, only a portion of the title is highlighted when the title is clicked, and the button area is not entirely active -- with poor visual results.


Overall, links are used in Acrobat 5 PDFs in a mediocre way, taking advantage of only some of the built-in capabilities of authoring tools (FrameMaker and Word/PDFMaker), not to mention adding more complex link capabilities. It seems that the PDF producers did not pay much attention to the final result in Acrobat and how it serves the user or bother to run automatic link validity tests (an absolute minimum with interactive PDFs, but inadequate in itself).

How do these PDFs compare with PDFs produced elsewhere? While there are still many PDFs currently produced out there with no links at all, the Acrobat 5 PDFs seem to be in line with the mainstream mediocre standard, unfortunately.

One could expect Adobe to have a leading role in promoting PDF capabilities by demonstrating the effective use of different features -- as basic as links and bookmarks -- in its own PDFs. The quality of PDFs made available with the current and previous versions of Acrobat indicates that we still have to wait to see this taking place. With Adobe being the developer of PDF, its own PDFs hardly set a standard for others to follow.


PDF In-Depth Free Product Trials Ubiquitous PDF

Debenu Quick PDF Library

Get products to market faster with this amazing PDF developer SDK. Over 900 functions and an equally...

Download free demo

Five visions of a PDF Day

In the world of PDFs or as we like to say Planet (of) PDF, a year isn't a real PDF year without an intense few days of industry knowledge sharing.

May 15, 2018
Platinum Sponsor

Search Planet PDF
more searching options...
Planet PDF Newsletter
Most Popular Articles
Featured Product

Debenu PDF Aerialist

The ultimate plug-in for Adobe Acrobat. Advanced splitting, merging, stamping, bookmarking, and link control. Take Acrobat to the next level.


Adding a PDF Stamp Comment

OK, so you want to stamp your document. Maybe you need to give reviewers some advice about the document's status or sensitivity. This tip from author Ted Padova demonstrates how to add stamps with the Stamp Tool along with related comments.