Special care should be taken when entering indexterms into text, especially when one of the final output formats for your document is paginated. Most processing systems are forgiving about the amount of whitespace that you use. Outside of “line-specific” environments such as literallayout and programlisting, you can indent lines, insert tabs or spaces at will, and otherwise rely on the processor to coalesce multiple spaces into a single space.

However, when the processor is determining where a line or page break will occur in a long block of text, it’s an almost universal convention that such breaks occur where whitespace occurs in the markup. Sometimes words have to be hyphenated, of course, but usually it’s sufficient to break a line at a space and break a page between lines.

This means that you want to avoid extraneous spaces between index terms and the words with which they are associated. Consider this example:

<para>…long, rambling paragraph about wood ducks
<indexterm><primary>ducks</primary><secondary>wood</secondary>
</indexterm> and the habitat that they occupy, etc., etc., etc.
</para>

At first glance this seems fine, but consider what happens if the processor needs to break this paragraph across two pages. There is a small, but nonzero, chance that the page break will occur at the space (introduced by the line break) following the word “ducks”. If this happens, the anchor associated with the entry “ducks, wood” will appear on the page following the relevant words. To avoid this situation, never insert whitespace between the term and the indexterm:

<para>…long, rambling paragraph about wood
ducks<indexterm><primary>ducks</primary><secondary>wood</secondary>
</indexterm> and the habitat that they occupy, etc., etc., etc.
</para>

The whitespace after the indexterm is necessary, of course. Without it, when the indexterm is removed for presentation, the words “ducks” and “and” will appear to run together.

Just as extraneous whitespace can lead to indexing errors, placing index terms between block elements may lead to indexing errors.

If an index term occurs between two paragraphs, and a page break occurs between those two paragraphs, the processing system may associate the index entry with either page.

This problem can be exacerbated by floating elements. Suppose an index term appears between two figures, both of which float to subsequent pages. There is no reliable way to predict what page the processing system will associate with that index term.

If the index term in question marks the beginning or end of a range, the resulting range may contain too few, too many, or perhaps even only the wrong pages!

As a general rule, it’s best to avoid placing index terms between block elements that may be broken across multiple pages.

When an indexterm appears in an element whose content may be repeated in more than one place, the anchor is only associated with what would be considered the “primary” presentation (or presentations) of the element in the flow of the text. For example, in a traditional printed book, the title of a chapter might appear in the table of contents, in the running header, and in the body of the book on the first page of the chapter. If an indexterm is placed in the title, it serves as an anchor to only the first page of the chapter.

If the processing expectations of an element are that it may be repeated several times and that each of these occurrences is equally “primary,”^[4] then any indexterm occurring in that element should generate an anchor at each location where the content is repeated.

If an indexterm appears in an element whose content may float, the anchor is to the location where the term occurs in the floated text. For example, if an indexterm occurs in a figure that floats to the top of some following page, the anchor is on the page where the figure actually occurs.

The use of see and seealso elements in an indexterm also has special semantics.

A see entry directs the reader to another location in the index. In Example 31, “Example index terms”, the entry for USB:

<indexterm>
<primary>USB</primary><see>Universal Serial Bus</see>
</indexterm><indexterm>

directs the reader to the entry for Universal Serial Bus. The resulting index will look something like this:

…
Ubiquitous networking, 34, 44, 173-199
Universal Serial Bus, 50-55
Up time, 2, 5
USB, see Universal Serial Bus
Useless bits, 304, 411
…

There are no page numbers associated with a see entry. In most environments, if there is at least one see entry for a particular term, it is an error to have any other kind of entry for that term.

A seealso entry, on the other hand, directs the reader to other, possibly related terms in the index. We expect the index for “eSATA” to look something like this:

…
Entering markup, 14, 18, 22-33
eSATA, 56, 58-61
  (see also Serial ATA)
evaluating expressions, 44
…

It’s entirely possible for a term to have several seealso entries.

Authors can choose to have several types of indexes: for example, function, command, and concept indexes. This can be achieved in DocBook with the type attribute. All of the indexterms with a particular type will be collected together in the index with the same type.