On 18.01.2008 00:09:14 Andreas L Delmelle wrote:
> On Jan 17, 2008, at 20:57, Simon Pepping wrote:
> > On Thu, Jan 17, 2008 at 12:27:11AM +0100, Andreas L Delmelle wrote:
> >> 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.
> >>
> >> 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.
> >
> > I would rather pass a reference to the page breaker in the
> > getNextKnuthElements call. Each LM can then append Knuth elements in a
> > callback to the pagebreaker. At each such append callback, the page
> > breaker can decide to run the Knuth algorithm and ship pages. When
> > this callback finishes, the LM can continue. Running the Knuth
> > algorithm intermittently makes no sense in a total-fit algorithm.
> Right. Running the algorithm intermittently may make no sense /in/ a  
> total-fit algorithm, the implementation of which currently takes for  
> granted the fact that a given sequence S will always be complete, so  
> we can immediately move on from end-of-layout to building the area  
> tree for the page-sequence. Suppose, however, that this will no  
> longer be guaranteed.
> Also, I would see the basic strategy evolve in such a way that we  
> have some check on the list's eventual size to determine whether to  
> use best-fit or total-fit. Implementing this logic inside the LMs or  
> the breaking-algorithm seems out-of-place. As Jeremias mentioned, we  
> would have to have some mechanism for limiting memory consumption.  
> Keeping total-fit as the default strategy for the layout-engine is  
> fine by me, as long as we also can switch to best-fit at the  
> appropriate point. This point is unrelated to anything layout- 
> specific, so I was thinking that a separate data structure would help  
> make the implementation of such a mechanism much cleaner. If this  
> check becomes part of each childLM's getNextElements(), this might  
> turn out to become a pain to maintain... If we implement it as part  
> of the add() and remove() of that hypothetical structure, it remains  
> nicely separated from both the LM-logic and the breaking-algorithm.  
> Two places where it does not belong.

Please note that total-fit is not possible if the available IPD changes
from page to page as this will require regeneration of part of the
element list(s) after a page break decision. So part of the check
whether total-fit can be used must be the inspection of the
layout-master-set. This will add further complexity. The
layout-master-set creates further complications anyway: page-position
"last"/"only" processing are non-trivial especially is column balancing
and span changes come into play (one part where FOP is still incomplete

BTW, has anyone checked how the XSL 1.1 flow-map functionality impacts
all this? I haven't had the chance.


Jeremias Maerki

Reply via email to