Restarting issue about special penalties for table header situations

[Jeremias Maerki <de...@greenmail.ch>]

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?

To find a solution for this I keep coming back to a special kind of
penalty that has an additional value w2 which is the amount of penalty
space added to the next part/page/line when the break happens at that
penalty. So the solution for the problem would look like this:

box(hH + hA)
box(h1)
penalty-with-carryover(p, w=hB + hF, w2=hH + hA)
glue(hN)
box(h2)
box(hb + hF)

Now, when the break is at the penalty, normally you would advance until
the first box on the next part, but with the penalty-with-carryover
you'd first check if the break was at such a penalty and insert an
ad-hoc dummy box with w2 from the penalty just before the first box
after the break when finally rendering the effective sublists.

I believe this wouldn't introduce too much additional complexity into
the overall algorithm but would allow us to handle this case elegantly
without even having to deal with out-of-line elements.

We could probably even redefine a normal penalty as a
penalty-with-carryover since if you set w2 to 0, you have a normal,
old-style penalty.

WDYT?

On 28.02.2005 10:15:39 Luca Furini wrote:
> >+This situation cannot be dealt with using Knuth's box/glue/penalty
> >+model.
> 
> Maybe there is no need to create new kinds of elements (not that it's
> forbidden :-) , only the fewer they are, the simpler the algorithm is).
> 
> Header and footer, with their borders, are duplicated around each break if
> table-omit-*-at-break is false; so, at each break the total height
> increases by (border a + footer + header + border b) and decreases by
> border n.
> 
> Here is a different representation which uses normal penalties; there are
> two rows whose bpd is h1 and h2, header and footer with bpd hH and hF,
> border before the footer , border after the header and border between rows
> hA, hB and hN.
> 
> box(h1) - penalty(p, hH + hA + hB + hF) - glue(hN) - box(h2) - box(hB +
> hF) - box(hH + hA)
> 
> If there is no break, the overall bpd is (hH + hA + h1 + hN + h2 + hB +
> hF), otherwise the first piece has bpd (hH + hA + h1 + hB + hF) and the
> second one (hH + hA + h2 + hB + hF), and the border between the rows is
> ignored.
> 
> The elements representing the header and its border are moved at the end
> of the sequence, but I don't think this is could be a real problem: the
> TableLayoutManager would place it at its right place when adding areas.

Jeremias Maerki

Re: Restarting issue about special penalties for table header situations

[Jeremias Maerki <de...@greenmail.ch>]

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

Re: Restarting issue about special penalties for table header situations

[Simon Pepping <sp...@leverkruid.nl>]

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