On Wed, Jan 16, 2008 at 01:20:36AM +0100, Andreas L Delmelle wrote:
> So, on top of that, I'm thinking of making b) less of a monolithic process.
> At the moment, we always wait for an endPageSequence() call on the
> AreaTreeHandler, which works fine for small to medium-sized page-sequences,
> but is definitely not scaleable to larger ones consisting of a lot of FOs.
> I think we should take a look at implementing endFlow(), for instance, or
> startFlow(). At those points, we are already guaranteed to have at least
> the part of the FOTree that is necessary to perform some basic preliminary
> layout (the *ahem* Pagination and Layout FOs).
At the moment our only page breaking strategy is the total-fit
algorithm. It will by its design wait until all Knuth elements of the
page sequence are available. Then it makes no difference if the layout
engine is called at endPageSequence or more frequently.
One of my goals is to enable another page breaking strategy, a
best-fit algorithm per page. That would enable one to complete layout
and area building for parts of a page sequence. But the current layout
engine first collects all Knuth elements for the page sequence and
then starts the page breaker. Making the LMs return their Knuth
elements to the page breaker immediately is required to finish pages
early. But that is another major refactoring effort.
home page: http://www.leverkruid.eu