Thanks Georg. As far as I understand your code, the page containing index entries is the very last child of the DOM tree and the ``prod-id`` attribute contains some kind of unique identifier corresponding to a known page. Am I right?
I'd like to allow other page sequences following index entries, and those may span on several pages, so last DOM child may not be the right one to search into. That's why I'm asking for a robust mechanism to surround index keys and page numbers. For sure I could use magic text like "XxxxSTARTxxxX" and "XxxxENDxxxX" but this could be fooled by any user content. Looking at the IF draft on FOP wiki I see there is a "page-name" attribute for the page. Setting such a an attribute value (not necessarily this one) from FO would save me, then. c. -----Message d'origine----- De : Georg Datterl [mailto:[email protected]] Envoyé : mercredi 19 août 2009 15:20 À : [email protected] Objet : AW: Referencing multiple pages for index entries Hi Laurent, > In real world use cases, it's acceptable to support index entries > only at the end of the numbering sequence or in another numbering > sequence, so let's do post-processing. There are plenty of issues > to solve but they are mostly related to `I/Os` and XSL and Novelang > design so I won't discuss them in this list. I'm just thinking: If we are restricted to an index in a separate page-sequence after the actual entries, wouldn't it be possible DURING the layout (when creating the KnuthSequence?) to look forward (or back) and modify the entries (which already should know their page number), and then layout once? > One question left, however. I wonder how to hint FO document for > generating Area Tree or Intermediate Format that I could reparse > easily, for locating pages containing index entries, and extracting > index keys and lists of page numbers. __________ Information provenant d'ESET NOD32 Antivirus, version de la base des signatures de virus 4348 (20090819) __________ Le message a été vérifié par ESET NOD32 Antivirus. http://www.eset.com
