Re: [docbook-apps] Indexing.

[davep <davep@dpawson.co.uk>]

On 05/05/12 18:57, Richard Hamilton wrote:
> Dave,
>
> Regarding the markup mechanics, here are two possibly unexpected things to look out for:
>
> 1) When you are doing a range, the closing index term in the range cannot follow a section close. I.e., If you have the following
>
>          <para>  some text.</para>
>       <!-- indexterm ok -->
>      </section>
>   <!-- indexterm not ok -->
> </section>
>
> Generally this is not a problem, since you can move the index term up in a case
>like this without changing its position in the resulting text.
          ^^^^^^^^^^^^^^^^^^
> It happens because the grammar doesn't allow much after a section closes except
>another section and a couple of other elements.

I guess this is the key bit. 'Guess' where the page number will be and 
align the element in a valid position.
Being a singleton it can 'cross' section boundaries though...




> 2) If you have space (including newlines) between index terms, you will get extra space
> in the output. E.g.,
> In Shakespeare's Hamlet,<indexterm><primary>Shakespeare</primary></indexterm>
> <indexterm><primary>Hamlet</primary></indexterm>
> <indexterm><primary>plays, Shakespeare</primary></indexterm>
> everyone (nearly) dies in the end.
>
> In PDF output, you will get "In Shakespeare's Hamlet,^^^^ everyone (nearly) dies in the end."
> The "^" characters are space characters that come through in the output.
> You can avoid this by not leaving any space/newlines between 
successive index terms.
> In the Definitive guide, you will find things like the following, 
where an indexterm is
> opened on one line and then continued (space inside are ok):
> In Shakespeare's Hamlet,<indexterm><primary>Shakespeare</primary></indexterm><indexterm>
> <primary>Hamlet</primary></indexterm><indexterm>
> <primary>plays, Shakespeare</primary>
> </indexterm>  everyone (nearly) dies in the end.
>
> I think this happens because the parser sees the white space between the index terms
> (and in front or after) as distinct instances of white space that need to be preserved.


Rather more subtle Richard, thanks. I can see the logic.
... Just to check, it is the space *inbetween* <indexterm/>'s that is 
causing the problem? Despite the fact that it shows (visually) at the 
end of the indexterm. Space between <indexterm>
<primary> is insignificant ws.




> Neither is hard to avoid, but they can be frustrating (esp. the second one)
> if you're not expecting them.

Certainly I wouldn't be expecting the second one.
Thanks Richard.



regards

--
Dave Pawson
XSLT XSL-FO FAQ.
http://www.dpawson.co.uk