[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Index options
From: |
Yves Forkl |
Subject: |
Re: Index options |
Date: |
Fri, 17 Apr 2009 21:51:16 +0200 |
User-agent: |
Thunderbird 2.0.0.21 (X11/20090318) |
Jeff Kingston wrote:
[Yves Forkl wrote:]
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.
Now that is strange... Changing the title of the regular index works
perfectly by simply modifying the value to be yielded for Word "index"
in my copy of standard.ld.
But despite having tried it in many ways, I can't change the title of
Index A by introducing a new symbol for it. Which I do to disambiguate
it from the "index" symbol and to allow language-specific values. So
in my copy of the bookf file, I changed
named @IndexAWord { index }
into
named @IndexAWord { myindex }
Unfortunately, Lout seems to take "myindex" as a literal string rather
than a symbol (unlike "index"), so the title of Index A then just
reads "myindex", while Lout ignores the entry in standard.ld I made
for "myindex" as a modified copy of the entry for "index".
Did I miss something? It would be a pity if the title of Index A might
just be specified as a string rather than a symbol that might yield
different values...
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.
I understand that this serves only as a convenience when editing Lout
documents so that the author doesn't mix up the indexes then, right?
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.
Thank you for having taken a look at it. I agree with you that
generally it is advisable to stick with the formatter's default
behaviour. In this case, however, Lout's habit of separating the index
term from the page ranges of its occurrences by inserting a comma
significantly conflicts with typographic rules in quite a number of
languages, e.g. German, French and others. (In fact, I only remember
seeing a comma at this place in English books).
This is why I am striving to get rid of the comma here, though
changing the code might be difficult. Maybe some of the Lout experts
on the list could join in so that we can find a solution together?
Here is what I have found until now. While knowing little about Lout's
internals, I believe that these lines starting at line 4584 of file
dsf are responsible for inserting what comes after an index term (in
the main index):
@IndexFont @Font @IndexBreak @Break pgrange @Case {
"" @Yield { @Body &"0.03fu" {} }
else @Yield { @Body &"0.03fu" address@hidden ,} pgrange }
In the context of the loop in which this occurs, I read this to say
to append the next page range with a comma prepended, or to insert
nothing if no more page ranges are left.
One way to omit the comma before the first page range might be to
combine the page ranges differently: first print out the first page
range (if any), then append each page following range after a comma
until there is only an empty page range left.
How to modify the above code to achieve this? (Would I maybe need
another loop?)
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.
Too sad I wasn't lucky. Lout chokes on this and spits out:
--------
/
fatal error: @SetHeaderComponent contains object of illegal type:
cross reference or cross reference target
\--------
Never mind, linking is not so important to me in this place.
(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? [...] 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.
I agree with you, at least as far as technical writing is concerned,
where concepts are typically well delimited and tend to correspond
mostly to near-synonyms. So the readers probably won't care much if
the term on some page doesn't match exactly the one given in the index
for that page (like in your example "argument" vs. "actual
parameter").
Topics in the humanities (like mine) however often involve a big
number of terms whose precise semantic relationship is not easy to
establish in all cases. This is why it is important for me to index
the pages not by concepts, but rather by all of the (relevant) terms
that they really contain. At the same time, the readers might benefit
from hints in the index that guide them towards terms that are somehow
related but which might not have come to their mind immediately.
This is to say, I'm fine with using @RawIndex in order to show a
textual link that points to a related term (being able to make this a
crossref link would just have been the cherry on the pie).
Any ideas on the unresolved problems, though? (Assigning a new title
to index A via a symbol "myindex", and dropping the comma immediately
after the index term in the index?)
Yves
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- Re: Index options,
Yves Forkl <=