On Jan 16, 2008, at 20:32, Simon Pepping wrote:
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.
<snip />
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.
Indeed, and that is exactly the one that has been on my mind lately.
Right now, the element list is constructed as the result of recursive
calls to getNextChildLM.getNextKnuthElements().
/The/ return list upon which the page breaker operates is the one
that is ultimately returned by the FlowLM.
Instead of that, I've been thinking in the direction of making it a
data structure that exists 'physically' separate from the LMs.
This structure, created and maintained by the PageSequenceLM, would
be passed down into an appendNextKnuthElementsTo() method.
[Come to think of it, but that's an entirely different matter, I've
been thinking about removing the name 'Knuth' from all classes, and
replacing it by extensive references to the Knuth-algorithm in the
javadocs. All his name does in the code is making lines and method
calls unnecessarily longer... :/ Not that I don't like 'Knuth', far
from it, way cool name. Sounds Viking-ish. ;-) For the sake of code-
aesthetics, however... ]
The lower-level LMs can signal an interrupt to the ancestor LMs,
based on information they get through the LayoutContext --forced
breaks being the most prominent.
The FlowLM, instead of simply continuing the loop, could give control
back to the PageSequenceLM, which can run the page breaker over the
list up to that point.
We would also need to be able to determine the likelihood of the
computed page-breaks changing due to additional content, if the
FlowLM stil has childLMs coming up.
Cheers
Andreas
