@Section @Title { Indexes } @Tag { indexes } @Begin @PP Although Lout is not clever enough to guess what entries should go in indexes. @Index { indexes } your index, it will do almost everything else for you: sort the entries and attach the correct page numbers automatically. As for tables of contents, the default setting is to have an index in books but not in other types of documents. This and a few aspects of the appearance of the index can be changed by changing the setup file, as explained at the end of this section. @PP Now, suppose you are discussing Galileo and you want his name in your index. Let's be ambitious and say that you want the index to contain something like this: @ID @OneRow lines @Break { Galileo Galilei life of, 201 telescope, his use of, 201--203 trial of, 205--211, 242, 395 } Each line shows off one of Lout's four tricks: the first is a @I { raw entry } (no page number attached); the second is a @I sub-entry (indented); the third has a @I { page number range } instead of a single page number; and the fourth is a @I { merged entry } (several page numbers or ranges within one entry). @PP We'll take each of them in turn in a moment, but first, let's see how to get a basic entry, like this one: @ID { Galileo Galilei, 201 } To get this into your index, type @ID @Code "galileo @Index { Galileo Galilei }" at the point where you mention Galileo. Nothing will be printed there, but the object following the @Code "@Index" symbol will be placed in the index, with a comma and the correct page number appended automatically. @PP The object preceding the @Code "@Index" symbol is a compulsory key which is used for sorting the index entries, @FootNote { The collating sequence used to decide what comes after what is the collating sequence used by the @Code "memcmp()" library routine (just the underlying binary character codes). Alternatively, the version of Lout installed on your system may use the @Code "strcoll()" collating sequence, which understands accented characters and whose effect depends on your locale. To find out whether @Code "strcoll()" is in use or not, type @Code "lout -V" which prints out several lines of this and similar information. @PP If the sorting you get turns out to be not what you expected, the first thing to try is the replacement of all accented letters in index keys by unaccented ones. Sorting is quite an intractable problem: even if @Code "strcoll()" gets the sorting right for one language, there still remains the problem of sorting multilingual indexes. @PP Lout's database mechanism assumes that the @I tab character is collated before any character that could appear in a sorting key. It seems that there are a few collating sequences in existence which do not satisfy this condition, and in these cases Lout will fail to produce the correct index. } but which is not itself printed anywhere. It is best to construct these sorting keys from lower-case letters and the . character only, beginning with a letter, although multi-word keys are allowed. These sorting keys do not have to be distinct from the tags used in cross referencing; however, they do have to be distinct from each other, unless you want merged entries (see below). @PP Our first trick, raw entries (no page number attached), is very easy: just use @Code "@RawIndex" instead of {@Code "@Index"}. So the first line of our ambitious example is obtained by @ID @Code "galileo @RawIndex { Galileo Galilei }" This could go anywhere, since no page numbers are involved. @PP Another use for @Code "@RawIndex" is to get blank lines into the index between the letters of the alphabet, by inserting phantom entries: @ID @OneRow @Code { "b @RawIndex {}" "c @RawIndex {}" "d @RawIndex {}" "..." "z @RawIndex {}" } In fact there is a symbol called @Code "@IndexBlanks" that makes indexblanks. @Index @Code "@IndexBlanks" exactly these 25 entries. Unfortunately, these blanks will occasionally appear at the top of a column, and if there are no tags beginning with x, for example, there will be two blank lines between the w and y entries. You can start off with @Code "@IndexBlanks" and replace it later by the appropriate subset, if necessary. @FootNote { For Lout to solve this problem automatically, it would need to be told which letter each index entry belongs under, perhaps by symbols {@Code "@AIndex"}, {@Code "@BIndex"}, etc. The author felt that this would have been too tedious. } @PP Our second trick, sub-entries, is also very easy, since a sub-entry differs from an ordinary entry only by having an indent. The symbol is {@Code "@SubIndex"}, so the second line of our ambitious example is produced by @ID @Code "galileo.life @SubIndex { life of }" You should always give sub-entries the same sorting key as their corresponding main entries, plus a . and another word, because then you can be certain that the sorting will place sub-entries directly after their main entries. There is a @Code "@SubSubIndex" symbol that produces a double indent, and there are @Code "@RawSubIndex" and @Code "@RawSubSubIndex" symbols. @PP For our third trick, page number ranges, we use the @Code "to" option of the {@Code "@Index"}, {@Code "@SubIndex"}, and {@Code "@SubSubIndex"} symbols. For example, to produce the sub-entry @ID { telescope, his use of, 201--203 } put @ID @Code { "galileo.telescope @SubIndex to { gt.end } { telescope, his use of }" } at the beginning of the range, and @ID @Code "@PageMark { gt.end }" at the end. You can use any tag you like inside the @Code "to" option, as long as it differs from every other tag (notice that sorting keys do not have to differ from tags, but @Code "to" options do: this is because @Code "to" options go into @Code "@PageMark" like other tags do, and if two tags are the same we would have an ambiguous result of {@Code "@PageOf"}). If both ends of the range fall on the same page, the @Code "to" option is ignored: you will never get 201--201. @PP Our fourth and final trick is the merged entry: @ID { trial of, 205--211, 242, 395 } The main thing to grasp is that this merged entry was originally three separate entries (sub-entries in this case): @ID @OneRow lines @Break { trial of, 205--211 trial of, 242 trial of, 395 } We already know how to produce these three entries, using three @Code "@SubIndex" symbols, one with a @Code "to" option. Now we have discovered that Lout is able to merge several entries into one entry. This raises two questions: how does Lout know which entries to merge? and given those entries, what does the merging produce? @PP The answer to the first question is that Lout merges entries whose sorting keys are equal. The merged entry above is produced by these three entries, placed in the appropriate places: @ID @OneRow @Code { "galileo.trial @SubIndex to { gtrial.end } { trial of }" "galileo.trial @SubIndex { trial of }" "galileo.trial @SubIndex { trial of }" } The entries are merged because they have the same sorting key ({@Code "galileo.trial"}), not because they happen to have the same content ({@Code "trial of"}). In fact, once the page numbers are added the content is not the same at all. @PP Now, having decided that the three entries @ID @OneRow lines @Break { trial of, 205--211 trial of, 242 trial of, 395 } must be merged, what does Lout do? It takes the second entry, discards any initial part that is the same as the first entry ({@Code "trial of,"} in this case), and, if anything remains, it adds a comma, a space, and the remainder to the first entry, producing @ID { trial of, 205--211, 242 } in this case. This process is repeated on this and the third entry, producing @ID { trial of, 205--211, 242, 395 } in this case, and so on. The entries are merged in the order in which their points of origin appear in the final printed document. @PP If nothing remains after discarding the common initial part, nothing is added to the growing merged entry; in effect, the entry that could contribute nothing new is deleted. With this in mind, let us return to our initial, ambitious example: @ID @OneRow lines @Break { Galileo Galilei life of, 201 telescope, his use of, 201--203 trial of, 205--211, 242, 395 } We now know how to produce all four of these entries, but one problem of some practical importance remains. Suppose we delete the section on the life of Galileo. If we had put the entry that produces `Galileo Galilei' in that section, we might inadvertently delete it, and the other two sub-entries will lose their main entry. Before deleting anything, we must hunt through it for index entries and ponder their significance, an error-prone and time-wasting thing to do. @PP The solution is as follows. When an index entry has sub-entries, make it raw, and repeat it just before each of its sub-entries: @ID @OneRow @Code { "galileo @RawIndex { Galileo Galilei }" "galileo.life @SubIndex { life of }" } at the first place, @ID @OneRow @Code { "galileo @RawIndex { Galileo Galilei }" "galileo.telescope @SubIndex { telescope, his use of }" } at the second, and so on. Now it is easy to verify that every sub-entry has a main entry; and when deleting a sub-entry we can and should delete the adjacent main entry. After sorting, our index entries will be @ID @Tab @Fmta { @Col @Code A ! @Col B } { @Rowa A { galileo } B { Galileo Galilei } @Rowa A { galileo } B { Galileo Galilei } @Rowa A { galileo } B { Galileo Galilei } @Rowa A { galileo } B { Galileo Galilei } @Rowa A { galileo } B { Galileo Galilei } @Rowa A { galileo.life } B { {} life of, 201 } @Rowa A { galileo.telescope } B { {} telescope, his use of, 201--203 } @Rowa A { galileo.trial } B { {} trial of, 205--211 } @Rowa A { galileo.trial } B { {} trial of, 242 } @Rowa A { galileo.trial } B { {} trial of, 395 } } The first five entries have the same sorting key, and will be merged as required. @PP The language of the index entry will be the initial language of the document as a whole, which is not necessarily the language at the point where the index entry occurs. To get the correct language you will need a @Code "@Language" symbol following the @Code "@Index" symbol: @ID @Code "galileo. @Index French @Language { Galileo Galilei }" or whatever. If you don't do this your index entry might be hyphenated incorrectly. @PP Although the page numbers in index entries will be kept up to date automatically as the document changes, as all cross references are, it is best to refrain from inserting index entries until the document is complete and an overall plan of the structure of the index can be made. @PP The remainder of this section describes how to change the appearance of the index by setting options in the setup file. For setup files and their options in general, consult Section {@NumberOf setup}. @PP There are five setup file options for the index. Here they are with their default values: @ID @OneRow @Code { "@MakeIndex { No }" "@IndexFont { }" "@IndexBreak { oragged 1.2fx }" "@IndexColumnNumber { 2 }" "@IndexColumnGap { 1.00c }" } The @Code "@MakeIndex" option, which may be @Code Yes or {@Code No}, makeindex. @Index @Code "@MakeIndex" determines whether to produce an index or not. Although the default value is {@Code No}, any type of document may be given an index just by changing it to {@Code Yes}. This has already been done in the @Code book setup file, but not in the others. @PP @Code "@IndexFont" determines the font and font size of index entries indexfont. @Index @Code "@IndexFont" (e.g. {@Code "Times Base 12p"}). Leaving it empty as above produces the same font as the rest of the document. @Code "@IndexBreak" is the indexbreak. @Index @Code "@IndexBreak" paragraph breaking style applied to index entries; @Code oragged is the traditional and best way. @PP @Code "@IndexColumnNumber" and @Code "@IndexColumnGap" determine the indexcolumnnumber. @Index @Code "@IndexColumnNumber" indexcolumngap. @Index @Code "@IndexColumnGap" number of index columns per page, and the gap between them, and are exactly analogous to the @Code "@ColumnNumber" and @Code "@ColumnGap" options described in Section {@NumberOf columns}. @PP Lout offers the possibility of having up to three independent indexes (useful for glossaries, author indexes, etc.). The other two are called index A and index B, and they precede the main index in the output. Just replace @Code Index by @Code IndexA to refer to index A, and by @Code IndexB to refer to index B. For example, @ID @Code "smith.j @IndexA { Smith, John }" will insert an index entry to index A, and @Code "@IndexBBlanks" will insert the usual 25 blank entries into index B. @PP In large projects it might help to rename the @Code "@IndexA" symbol to something else, such as {@Code "@AuthorIndex"}. This can be done by placing @ID @Code { "import @DocumentSetup" "macro @AuthorIndex { @IndexA }" } in the @Code mydefs file. See Section {@NumberOf definitions} for an introduction to the @Code "mydefs" file; the word @Code macro is needed here instead of @Code "def" because we are introducing a new name for an existing symbol, not defining a new symbol. @End @Section