[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [docbook-apps] indexterm with zone attribute
Hi, On Samstag, 28. Juni 2008, Dave Pawson wrote: > Thomas Schraitle wrote: > > Dave, I think you miss a point. :-) The TDG[1] has to say: > > > > »Place the indexterm anywhere you like and point to the element > > that contains the range of text you wish to index with the zone > > attribute on the indexterm. Note that zone is defined as IDREFS > > so a single indexterm can point to multiple ranges.« > > > > The zone attribute is IDREFS (plural), > > I was addressing the formatter issues. They are real > Seems like docbook is ahead of the game as usual. > > <block xml:id> > > > 2 pages later on > </block> > <block xml:id/> > > So the second id would need to be that of the following-sibling[1] ? > > Makes sense. Yes, that was my idea. > </block xml:id='endOfRange'> > Perhaps not ;-) :-) To be a bit more concrete, I was thinking of something like this: <sect1 xml:id="intro"> <title>...</title> <indexterm zone="intro foo"> <primary> ... </primary> </indexterm> <sect2 xml:id="bla"> ... </sect2> <sect2 xml:id="foo"> ... </sect2> </sect1> Ok? I'm not sure how accurate it will be in the final PDF regarding the page numbers. I never tried it. The sect2 foo could be very long, for example. For this case, I generally use in my books the class attribute with "startofrange" and "endofrange". The above code can be rewritten like this: <sect1 xml:id="intro"> <title>...</title> <indexterm xml:id="idx.intro" class="startofrange"> <primary> ... </primary> </indexterm> <sect2 xml:id="bla"> ... </sect2> <sect2 xml:id="foo"> <title>...</title> <!-- Some paras, figures, etc. --> <indexterm class="endofrange" startref="idx.intro"/> <sect2> </sect1> So actually you have 2 methods creating index ranges. As always, both have advantages and disadvantages. The second method is probably a bit more verbose but I think it is also more accurate. You have to think a bit, where to set the 2nd indexterm. For example, if you have an additional sect3, you have to move it *into* the sect3 section as the content modell doesn't allow it inbetween sections. Another disadvantage is profiling: If the last section ("foo" in this case) is removed from the profiling step, the end indexterm will be removed too. This leads to an accidently missing end point and the range can not be created. I'm searching for a XSLT method to insert the last indexterm automatically, but that's a different story. Just some weird thoughts about this topic. :-) Tom -- Thomas Schraitle
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]