Hi Andreas, 

In my case, I don't need the index before the pages are created (and as far as 
I understood, other implementations of this feature only relayout the index 
pages, leaving empty pages, if too many lines are cleaned). And I don't mind 
implementing a FOP1.1 feature, but I do feel a bit like Frodo in Rivendell when 
reading the specification. 

For example, according to the specification, what should happen if two 
referenced block following each other are in the same page-sequence as the 
index and after the index and at the beginning of a new page? When merging, one 
block would move to the previous page, therefore the page number would change, 
therefore no merging, so the block moves back one page, then the numbers could 
be merged, but the the block would move again. I think I'm getting a headache.  

Regards,
 
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: Andreas Delmelle [mailto:[email protected]] 
Gesendet: Mittwoch, 4. März 2009 22:46
An: [email protected]
Betreff: Re: AW: Index and Pagenumbers


On 04 Mar 2009, at 19:39, Andreas Delmelle wrote:

FWIW:

> On 04 Mar 2009, at 14:56, Georg Datterl wrote:
> <snip />
> I once started gathering some thoughts on the topic, but didn't get 
> very far...
> See: 
> http://wiki.apache.org/xmlgraphics-fop/FormattingObjectsForIndexing

Re-reading this and the original question:
If we would have fo:index-page-citation-list, fo:index-key-reference and the 
index-key/ref-index-key property pair, the solution would be fairly simple.
Adapt the stylesheet to append the node's id to the index-key attribute, so 
that we get an index-key that maps 1-on-1 to the id. A basic 
index-page-citation-list is all that is needed to produce sequences without 
duplicates.
Merging sequential page-numbers is already a nice-to-have. By itself, once the 
basic mechanism proves to be working, this should become easy.
The priority after basic implementation (2 objects + 2 properties) should 
probably go to implementing different separator-sequences.  
(NTS: may need to adapt that order on the Wiki). I consider it to be on the 
same level as index-ranges in terms of complexity, but different separators 
suddenly look more useful...

> By itself, the implementation of the 'index-key' property is not that 
> difficult. It is its treatment further on during layout/ rendering 
> that will be a challenge.

As Jeremias hinted, especially layout/rendering.
We will get a LayoutManager whose content can be partly or entirely unresolved 
(like the PageNumberCitationLM), and can grow significantly in case of large 
documents. Sometimes reaching one or more lines. This could mean that the 
layout for all the following pages may need to be revisited, which is something 
FOP is currently not equipped to do...

It would be easy enough to have such a LayoutManager merge a sequence of 
citations into one, keeping track of and eliminating duplicates, but the 
possible side-effects of a mix of resolved and unresolved elements, without 
somehow redoing the layout, cannot be so easily avoided in the current design.


Regards

Andreas

---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]


---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to