Re: Index options

[Jeff Kingston]

> Hi,
> 
> I would like to create several indexes in my PhD thesis. After thorough
> reading of section 2.11 of the User's Guide and some experiments, the
> following questions remain unanswered for me:
> 
> 1) Which option do I need to set or change in order to change the title
> of Index A, rather than the main index? At p. 70, the User's Guide does
> not say any more than: "There are setup file options to change the
> titles of indexes." In which setup file can I find this option, when
> producing a book?

Option @IndexAWord in the @BookSetup menu.

> 2) The User's Guide mentions at p. 70 that @IndexA can be renamed to,
> e.g., @AuthorIndex. Which are the implications of this on related
> symbols, i.e. will I have to rename @IndexABlanks to @AuthorIndexBlanks
> (and analogously for all further options) or will these symbols still
> work? Or is it just for the convenience of using a telling name when
> marking the terms to be indexed?

Actually you can't rename @IndexA, you can only introduce a second
name for it, by defining a macro:

    macro @AuthorIndex { @IndexA }

Symbol @IndexA remains available, and this has no effect on any other
symbol, so if you need (e.g.) subindex entries for the author index,
you'll need another macro.

> 3) In the index entries, I don't want the comma to be printed before the
> first page number, as indexes in German typically don't use a comma
> here. It seems, however, that there is no option for changing this.  What
> could I try to get this comma removed?

I don't think there is an option.  You could try changing line 4586 of
file dsf (this is for @Index, not @IndexA, but there is a corresponding
line for each index).  I'm not sure what would happen though!  The Lout
code here is very complicated and when I reviewed it quickly just now I
did not understand it completely.  My advice in these cases is to get to
like what Lout provides, it is a lot easier.

> 4) Being able to show (partial) synonymy between index entries would be
> great. All that is needed for this is a subentry with just a
> cross-reference instead of page ranges ("see also ..." before other
> subentries with page ranges, or "see ..." as the only subentry). To
> create them, I thought of putting something like this into my document:
> 
> basic @RawIndex
>  { Basic, see also tagOfFundamental @CrossLink Fundamental}
> ...
> basic.very @SubIndex { Very Basic }
> ...
> fundamental @RawIndex
>  { Fundamental }
> ...
> fundamental.really @SubIndex { Really Fundamental}
> 
> The problem is, I am not sure how to have the tag tagOfFundamental
> inserted by Lout in the right place, i.e. where the index entry for
> "Fundamental" will be placed. How do you do this?

I've only ever done low-tech index cross-references, i.e.

  basic @RawIndex { Basic, see also Fundamental }

However, if the User's Guide, Section 2.8, is to be believed, then
@CrossLink merely requires that the label to its left be something
that is acceptable to the @PageOf symbol.  This suggests that you
could write

  fundamental @RawIndex { Fundamental @PageMark tagOfFundamental }

and then your use of @CrossLink should work.  I have not tried it.

> (Often or always, bidirectional cross-references for near-synonymy might
> be preferable, but I didn't show this above to keep the example simple,
> and adding the second target is technically trivial.)
> 
> Or do you know of a more clever approach for reflecting (partial)
> synonymy among index terms?

I don't know of anything more clever.  All the indexes that I have
seen merely use "see" and "see also".  My only other suggestion is
that it sometimes pays to review the structure of the index in these
cases.  What is the true relationship between the two terms being
cross-referenced?  Sometimes you can demote one of the terms to being
just something that people might think of looking up in the index, but
the term is not used anywhere in your document, so the index entry is
reduced to something like:

    argument, see actual parameter

In technical writing it is almost always best to define one term and
stick with it.  If two terms are truly needed, then I would want to
be quite clear in my own mind why that is.  Because I am an OO fanatic,
I would try to find an OO model of the terms involved, and use that
as the basis of my index design.  Distinct but closely related terms
are often in a subtype relationship, for example.

Hope this helps.

Jeff