Now I got it. Thanks for taking the time to explain. Damn, am I uncreative sometimes.
On 31.03.2005 22:01:47 Simon Pepping wrote: > On Thu, Mar 31, 2005 at 11:03:19AM +0200, Jeremias Maerki wrote: > > While replaying the whole scenario for tables I stumbled over the table > > breaking penalty problem again. Luca proposed to handle this without > > introducing additional Knuth elements. Luca, you are certainly right > > that the element list does not have to be an exact representation of the > > content generated during addAreas(). But I think there's one problem > > with the fact that you propose appending the elements for table header > > and border-before to the end of the list. This works when you have max 2 > > pages. But as soon as the table spans more than two pages I think this > > will not work. The appended elements would end up on the wrong pages. > > They would pile up at the end of the list. Or am I missing something? > > If I understands Luca's argument correctly, then it works OK. > > > > box(h1) - penalty(p, hH + hA + hB + hF) - glue(hN) - box(h2) - box(hB + > > > hF) - box(hH + hA) > > box(hB + hF) - box(hH + hA) are the only header and footer that are > certain. Luca's argument selects the header and footer on the last > page as the certain ones. All other pages are uncertain; they only > appear if the table stretches over more than one page, one additional > header and footer for each page break. Therefore the header and footer > of those pages are in a penalty. They are only contributed if the > penalty falls at a page break. > > The complete sequence is: > > ( box(h1) - penalty(p, hH + hA + hB + hF) - glue(hN) - box(h2) )* > - box(hB + hF) - box(hH + hA) > > where the star is the multiplicity of possible break points. > > Regards, Simon > > -- > Simon Pepping > home page: http://www.leverkruid.nl Jeremias Maerki
