indexterm — A wrapper for an indexed term.
- Sequence of:
indexterm identifies text that is to be
placed in the index. In the simplest case, the placement of the
indexterm in the document identifies the location of
the term in the text. In other words, the
is placed in the flow of the document where the
indexentry in the
point. In other cases, attributes on
used to identify the location of the term in the text.
indexterm marks either a single point in the
document or a range. A single point is marked with an
indexterm placed in the text at the point of
reference. There are two ways to identify a range of text:
indextermat the beginning of the range with
startofrangeand give this term an
xml:id. Place another
indextermat the end of the range with
startrefpointing to the
xml:idof the starting
indexterm. This second
indextermmust be empty.
The advantage of this method is that the range can span unbalanced element boundaries. (For example, a range could span from the middle of one paragraph to the middle of the next.)
indextermanywhere you like and point to the element that contains the range of text you wish to index with the
zoneattribute on the
indexterm. Note that
zoneis defined as
IDREFS, so a single
indextermcan point to multiple ranges.
indexterms are suppressed in the primary
text flow, although they contribute to the population of an index and
serve as anchors for cross-references. Under no circumstances is the
actual content of
indexterm rendered in the primary
flow. For example, consider:
When rendered, either on paper or in online form, this paragraph always appears without any of the content of the index terms:
USB and Firewire are common interface technologies for external hard drives, although eSATA is also used.
For most elements, the processing expectations of an
indexterm are straightforward: the location of the
term serves as an anchor for the cross-reference from the index. If
the word “Firewire” appears on page 75 of the document, then page 75
appears in the index entry for “Firewire”. In an online presentation,
there’s an anchor for “Fireware” immediately after that word in the
Several aspects of index markup require special attention: whitespace around index terms, “See” and “See also” entries, index markup in repeating and floating elements, and multiple indexes.
Whitespace around index terms
Special care should be taken when entering
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
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:
1 <para>…long, rambling paragraph about wood ducks 2 <indexterm><primary>ducks</primary><secondary>wood</secondary> </indexterm> and the habitat that they occupy, etc., etc., etc. 4 </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
1 <para>…long, rambling paragraph about wood 2 ducks<indexterm><primary>ducks</primary><secondary>wood</secondary> </indexterm> and the habitat that they occupy, etc., etc., etc. 4 </para>
Index terms between block and floating elements
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.
Index terms in repeating and floating elements
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
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,” then any
indexterm occurring in
that element should generate an anchor at each location where the
content is repeated.
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
that floats to the top of some following page, the anchor is on the
page where the figure actually occurs.
“See” and “See also” entries
1 <indexterm> 2 <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:
2 Ubiquitous networking, 34, 44, 173-199
Universal Serial Bus, 50-55
4 Up time, 2, 5
USB, see Universal Serial Bus
6 Useless bits, 304, 411
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:
2 Entering markup, 14, 18, 22-33
eSATA, 56, 58-61
4 (see also Serial ATA)
evaluating expressions, 44
It’s entirely possible for a term to have several
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
Identifies the class of index term
Enumerated values: “singular”
A singular index term
Indicates the page on which this index term occurs in some version of the printed document
Specifies the scope of the index term
Enumerated values: “all”
The global index (as for a combined index of a set of box)
The local index (the index for this document only)
Specifies the significance of the term
Enumerated values: “normal”
Specifies the target index for this term
Specifies the IDs of the elements to which this term applies
These elements contain
1 <article xmlns='http://docbook.org/ns/docbook'> 2 <title>Example indexterm</title> 4 <para>The Tiger<indexterm> <primary>Big Cats</primary> 6 <secondary>Tigers</secondary></indexterm> is a very large cat indeed. 8 </para> 10 </article>
An example of a zone.
1 <chapter xmlns='http://docbook.org/ns/docbook'> 2 <title>Example Chapter</title> 4 <indexterm zone="a1"><primary>Network Configuration</primary></indexterm> 6 <!-- other content here --> 8 <section xml:id="a1"><title>Configuring Your Network</title> <para>…</para> 10 </section> 12 </chapter>
No elements in DocBook V5.0 have these semantics.