On Wed, 21 Sep 2005 02:50 pm, Jeremias Maerki wrote: > On 20.09.2005 23:50:12 Andreas L Delmelle wrote: > > Hi, > > <snip/> > > > > Here goes: > > I get the impression that the elements for borders and those for > > the content of the cells are created in one single pass, which > > seems to be the source of the so-called 'interaction problem' > > --IIC, this refers to the situation where, for example, we have > > already generated the AFTER border elements for the first two > > cells, while it's only when generating the elements for the third > > cell that a break is triggered. So, the obtained border- and > > content-elements become invalid, and need to be re-evaluated > > (possibly taking the footer into account). Is this a correct > > assessment of the issue? > > Unfortunately not. I get the impression that you haven't understood, > yet, how the Knuth approach works. We don't reevaluate any decisions > in this approach, but rather calculate ALL(!) possible decisions > beforehand and incorporate them into the element list we generate. > The breaker will merely choose a break possibility and the addAreas > stage will paint the results given the break decision.
Andreas, FWIW I struggled with a similar misconception when doing the conditional borders on inline elements (with is a very simplified version of of your problem). Luckily Luca set me straight very quickly. At every break possibility (space, hyphen, hyphenation point, ... for the ipd) you have to add all the Knuth elements required to model a) what happens if a break is inserted and b) what happens if no break is created. Amazingly the Knuth approach of just using box, penalty and glue elements can handle that. However, the only thing the Knuth elements and the line breaking algorithm do is to reserve the correct amount of space. Adding the actual borders is done when the areas are created. > 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? 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? 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? <snip/> > Jeremias Maerki Manuel
