OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

docbook-apps message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: Re: [docbook-apps] indexterm with zone attribute


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">
    <indexterm zone="intro foo">
      <primary> ... </primary>
    <sect2 xml:id="bla"> ... </sect2>
    <sect2 xml:id="foo"> ... </sect2>

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">
    <indexterm xml:id="idx.intro" class="startofrange"> 
      <primary> ... </primary>
    <sect2 xml:id="bla"> ... </sect2>
    <sect2 xml:id="foo">
      <!-- Some paras, figures, etc. -->
      <indexterm class="endofrange" startref="idx.intro"/>

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. :-)


Thomas Schraitle

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]