Mailing-List: contact fop-users-help@xmlgraphics.apache.org; run by ezmlm
Precedence: bulk
Reply-To: fop-users@xmlgraphics.apache.org
Received-SPF: pass (nike.apache.org: domain of thesing@gmx.de designates
 213.165.64.23 as permitted sender)
Content-Type: text/plain; charset="utf-8"
Date: Fri, 05 Aug 2011 16:43:52 +0200
From: "Stephan Thesing" <thesing@gmx.de>
In-Reply-To: <20110803085535.GA2591@leverkruid.eu>
Message-ID: <20110805144352.207980@gmx.net>
MIME-Version: 1.0
References: <20110803082348.183170@gmx.net>
 <20110803085535.GA2591@leverkruid.eu>
Subject: Re: FOP and large documents (again)
To: fop-users@xmlgraphics.apache.org
Content-Transfer-Encoding: 8bit

Hi,

since I will need a scalable first-fit algorithm for page layout I will
look into this (or have a student look at it).
I can live with the suboptimal page layout the first-fit will produce.


Best regards
   Stephan

-------- 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
GERMANY

NEU: FreePhone - 0ct/min Handyspartarif mit Geld-zurück-Garantie!		
Jetzt informieren: http://www.gmx.net/de/go/freephone

---------------------------------------------------------------------
To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org