On 21.09.2005 09:52:00 Manuel Mall wrote: > On Wed, 21 Sep 2005 02:50 pm, Jeremias Maerki wrote: <snip/> > > The only > > reevaluation will happen if we start to implement support for the > > "changing available IPD" problem, i.e. when the available IPD is > > different from page to page within the same page-sequence. In this > > case we will need to be able to recreate the element list from an > > arbitrary former break possibility on forward which means that all > > decisions are reevaluated from this point on due to changed > > environmental factors (the IPD). Even the line-breaking has to be > > redone, although the inline element list will not have to be > > recreated. > > > > Jeremias, can you explain to me why we have to reevaluate?
Let me explain by showing the flow of events for a simple block with a long text in it: - BlockLM.getNextKnuthElements is called indirectly by the PSLM which provides the available IPD in the layout context. - The BlockLM calls on the LineLM to do the line-breaking passing on the available IPD. - The LineLM creates the element list for its content. (IPD is irrelevant here) - The LineLM does the line breaking (by using the IPD value in the layout context) and creates a box element for each created line and penalties between lines. - The BlockLM receives the element list from the LineLM and integrates it into it own element list. - The resulting element list is returned to the parents until we're back in the PSLM which invokes the breaker. All break decisions for the whole sequence are generated at this point. - Let's assume the contents don't fit in the first page and we get at least one break point. Let's assume further that the first page is an A4 portrait page and the second is an A4 landscape page, i.e. the available IPD is bigger on the second page. - The first page is generated normally, all lines are properly generated. - The second page has the problem that the available IPD is different, but the line breaks have all been done for the IPD of the first page, because the LineLM has no chance of knowing on which page it will end up. because the break decisions in b-p-direction are done later. - Now the layout has to be backtracked to the point of the first break after which the available IPD is different. From there on the lines have to be rebroken to get line boxes which work with the right IPD. Note that the element list for the inline stuff doesn't have to be recreated. Only the line breaker gets a new available IPD. Due to different break decisions you get a different set of b-p-d elements which also have to be broken over the pages. It might be possible to optimize the amount of lines that are precreated to avoid unnecessary work in these conditions but these will be heuristics and guesses and most of all only approximations. At the very least this will get messy. The biggest problem will be tables whose LMs have to be made restartable . The other LM will probably be easier. We used to have a restart mechanism before introducing the Knuth approach. Something like that will need to be reintroduced at some point.  http://wiki.apache.org/xmlgraphics-fop/TableLayout/BreakHandling > Can't the > line breaking code simply ask the LM for the new IPD when it inserts a > page break and then continue with the new IPD? It's not that immediate as the LineLM has to do the line breaking before the page breaking can be done. > Yes, the question on the > new IPD when ask of a LM may have to "ripple up" the LM chain until we > get to a LM which can actually answer it. But is that conceptually > flawed? It doesn't work that way with the Knuth approach. HTH Jeremias Maerki