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.
With a more complex interactive design, additional items such as
buttons and images may be linked.
Links must be visible in a consistent manner, or else it will be
practically impossible for the reader to take advantage of the
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
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.
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
Advanced Link Options and Issues
When designing an interactive PDF, additional aspects may be taken
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
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
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.
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:
Excessive "Named Destinations" supporting links
Inconsistent link area
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.
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).
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.
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.
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
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.
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
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).
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.
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.