[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [docbook-apps] no ranges for zoned indexterms?
The FO stylesheet doesn't implement the span feature of the zone attribute. Zone can be used to create out-of-flow indexterms. By that I mean you can put your indexterms anywhere, and the zone attribute can point to any number of ids in the document. The Definitive Guide says that zone implies a span entry that should cover the entire element, but the stylesheet doesn't try to implement that. I'm not sure why. Bob Stayton Sagehill Enterprises DocBook Consulting email@example.com ----- Original Message ----- From: "David Bridgeland" <firstname.lastname@example.org> To: <email@example.com> Sent: Sunday, January 23, 2005 8:44 AM Subject: Re: [docbook-apps] no ranges for zoned indexterms? > Or perhaps this is another case of the FO page numbering shortcomings > Bob Stayton describes in > http://www.sagehill.net/docbookxsl/IndexOutput.html ? > > Dave > > David Bridgeland wrote: > > > When I define a ranged indexterm using startofrange and endofrange, > > like this > > > > <indexterm id="inputmasks2.i" class="startofrange"> > > <primary>editboxes</primary> > > <secondary>input mask</secondary> > > </indexterm> > > ... > > <indexterm startref="inputmasks2.i" class="endofrange"/> > > > > I get a range of page numbers in my resulting PDF index, like this: > > > > editboxes > > input mask, 111-115 > > > > but if I use a zoned indexterm, like this: > > > > <indexterm zone="editboxesetc.editbox> > > <primary>editboxes</primary> > > <secondary>input mask</secondary> > > </indexterm> > > > > the resulting index has no range. It includes only the first page of > > the referenced > > entity, like this: > > > > editboxes > > input mask, 111 > > > > Isn't it supposed to give me a range? Is this a bug in the FO > > stylesheets? Or perhaps am I doing > > something stupid? (The entity does in fact span over the four pages. > > And a quick look at the > > generated FO leads me to believe that the problem is not in the > > subsequent processing of FO to > > PDF.) > > > > Dave Bridgeland > > > > > > >