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)
penalty-with-carryover(p, w=hB + hF, w2=hH + hA)
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.


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

Reply via email to