Simon Pepping wrote:
>+=== Space specifiers ===
>+
>+When the space specifiers resolve to zero around a page break, we are
>+in the same situation as that of a word space in line breaking. It is
>+represented by the sequence `box - glue - box`.
I add just a few thoughts about this subject.
If there cannot be a break between the two block (the first has
keep-with-next || the second has keep-with-previous || their block father
has keep-together), the representation can be box - infinite penalty -
glue - box.
>+=== Possible page break between content elements ===
>+
>+Here the most general situation is that when the content is different
>+with and without page break:
>+ * content Cn when there is no page break,
>+ * content Ca at the end of the page before the page break,
>+ * content Cb at the start of the page after the page break.
>+
>+An example of this situation is a page break between table rows:
>+
>+{{{
>+no page break: page break:
>+
>+--------- ---------
>+ row 1 row 1
>+--------- ---------
>+ border n border a
>+--------- ---------
>+ row 2 footer
>+--------- ---------
>+ page break
>+ ---------
>+ header
>+ ---------
>+ border b
>+ ---------
>+ row 2
>+ ---------
>+}}}
>+
>+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(inf, 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.
Regards
Luca
