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. Simon -- Simon Pepping home page: http://www.leverkruid.eu
