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