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

Reply via email to