Hello,

as we all know, FOP has performance issues when handling documents
with a lot of pages in a page-sequence and/or when pages contain
"forward" references to pages or bookmarks.

Unfortunately, producing shorter page-sequences is not always a viable
option, nor is leaving out forward references.
In my setting, e.g., a TOC is required in the document, which adds forward
references to bookmarks and pages for all page-sequences; also, formal
requirements mandate that page numbers are given in the form "page x of y", 
which adds a forward reference on every page for the last page of the document.

Bluntly, I think FOP should be able to handle this.

Looking at the code (as far as I understand it), for each page-sequence
all KnuthElements are computed first by the layout managers.
This is split only for forced page breaks.
Then on the whole sequence, possible page break positions are searched for.

Only after this are the actual output areas computed and pages produced.

Clearly, this doesn't scale for large page-sequences...

Is there a reason why this approach was chosen, instead of "lazily" (or 
on-demand)computing KnuthElements, putting them on the page and as soon as it 
is filled, pass it to the renderer?

Naturally, this does not solve the problem of forward references, where one 
either needs a Renderer that can handle resolution after the actual page has 
already been rendered, or one needs two layout passes (as TeX does), where the 
first pass collects references and ids, which the second pass can then use.

I am sure I overlooked something, so if there is additional information, I 
would be grateful for a pointer...

Please let me know your view on this:-)

Best regards
   Stephan
-- 
Dr.-Ing. Stephan Thesing
Elektrastr. 50
81925 München
GERMANY

Empfehlen Sie GMX DSL Ihren Freunden und Bekannten und wir
belohnen Sie mit bis zu 50,- Euro! https://freundschaftswerbung.gmx.de

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

Reply via email to