xmlgraphics-fop-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Stephan Thesing" <thes...@gmx.de>
Subject Re: FOP and large documents (again)
Date Tue, 16 Aug 2011 02:23:47 GMT

indeed, as the code currently is, it will be hard to make this a first
fit layout algorithm for pages.

As the generation of KnuthElements (or ListElements) by the LayoutManagers
seems to be quite interwoven with tasks like page alignment and other stuff, I would rather
not want to adapt this to a "demand driven" generation of Elements as needed by a first fit
Also, the possible IPD changes between pages poses a problem (it is also a problem for the
current code, which is "not nice" for that case).

I would rather change the layout managers to produce KnuthElements in the way TeX does and
leave page alignment to the page collection stage.
I don't see another manageable way to do this but to add to the layout managers a new interface
for this demand driven approach.
Essentially, this would result in a parallel implementation of generating content to the getNextKnuthElements()
and addAreas() interface.

I can spend some effort and since I clearly have a need for a scalable first fit page layout,
I will give this a try.

Best regards

PS: Is there any more in-depth documentation about the way the
layout managers work apart from the Wiki Pages?

-------- Original-Nachricht --------
> Datum: Wed, 3 Aug 2011 10:55:35 +0200
> Von: Simon Pepping <spepping@leverkruid.eu>
> An: fop-users@xmlgraphics.apache.org
> Betreff: Re: FOP and large documents (again)

> On Wed, Aug 03, 2011 at 10:23:48AM +0200, Stephan Thesing wrote:
> > 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?
> Both line and page breaking use the Knuth algorithm of a total fit.
> The algorithm requires the complete content before it can be applied.
> Clearly TeX does not do this; for page breaking it uses a best fit
> approach.
> For FOP it would be better if it could apply either strategy, at the
> demand of the user. But FOP is coded such that it first collects all
> content, in the process doing all line breaking in paragraphs, before
> it starts its page breaking algorithm. Therefore a best fit page
> breaking algorithm does not solve the memory problem. Changing this so
> that page breaking (best or total fit at the user's choice) is
> considered while collecting content has proven too hard (or too
> time-consuming) until now. See e.g.
> http://svn.apache.org/viewvc/xmlgraphics/fop/branches/Temp_Interleaved_Page_Line_Breaking/.
> There is a best fit page breaking algorithm, which is mainly used for
> cases with varying page widths. But it is a hack in the sense that it
> throws away all collected content beyond the current page, and
> restarts the process.
> So, help needed.
> Simon
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
> For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org

Dr.-Ing. Stephan Thesing
Elektrastr. 50
81925 M√ľnchen

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: fop-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org

View raw message