PDF Best Practices #3: Learn to Link

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

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

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,

  • 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

  • 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.


You May Also Like

About the Author: Shlomo Perets

Leave a Reply