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

Reply via email to