Hi Laurent, 

The index page is indeed the very last page, but since I still have the fo 
file, I can add further indizes and cover pages later. I just don't have them 
at the moment and I don't need them for the correct page numbers of the index, 
so I can look for the last page. You might as well use a table to display your 
entries and find the table by id instead of the page. Actually, I wouldn't need 
to find the page at all, since I search for the entries directly in my xpath 
statement, but stripping the unneeded nodes reduces the time needed to find all 
the page numbers from 2 hours to 2 minutes with even medium sized documents!

prod-id is the area tree name for the id attribute of fo-elements. Each 
page-number-citation element gets a (of course) unique id and I keep a map of 
which elements belong to which entries. Then I get the ids and the actual page 
numbers from the area tree and can strip page-number-citation elements from the 
fo file. Using id/prod-id is robust, since it can't be confused by user content 
and fop requires ids to be unique anyway.

Mit freundlichen Grüßen
 
Georg Datterl
 
------ Kontakt ------
 
Georg Datterl
 
Geneon media solutions gmbh
Gutenstetter Straße 8a
90449 Nürnberg
 
HRB Nürnberg: 17193
Geschäftsführer: Yong-Harry Steiert 

Tel.: 0911/36 78 88 - 26
Fax: 0911/36 78 88 - 20
 
www.geneon.de
 
Weitere Mitglieder der Willmy MediaGroup:
 
IRS Integrated Realization Services GmbH:    www.irs-nbg.de 
Willmy PrintMedia GmbH:                            www.willmy.de
Willmy Consult & Content GmbH:                 www.willmycc.de 
-----Ursprüngliche Nachricht-----
Von: Laurent Caillette [mailto:[email protected]] 
Gesendet: Mittwoch, 19. August 2009 18:15
An: [email protected]
Betreff: RE: Referencing multiple pages for index entries


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

Reply via email to