I've tried to think this case through. Simon's suggestion for a special
penalty is intriguing. It handles the case for table borders where we
don't simply have an x or 0 situation (like penalty and glue provide),
but we have a x or y situation.

On the other side Luca is probably right that we should try to handle as
much as possible with the existing elements. However, Luca's example
does not fully resolve in my brain. The penalty, for example, must not
be infinite or it will not be eligible for break possibility. A "legal
break" is defined by Knuth as "a number b such that either
(i) xb is a penalty item with pb < infinity, or (ii) xb is a glue item
and xb-1 is a box item." As far as I can see Luca's example doesn't
contain any legal break, but I guess that was simply an oversight.

The big problem I still have with both your examples is that the table
header is very special in terms of the standard Knuth model. This model
doesn't allow for conditional items at the beginning of a line. What
Luca did in his example looks to me like forcing the model to do
something it wasn't designed for. I'm a bit sceptical that the code will
be able to identify such special conditions reliably.

In this case I think we would have to introduce a special element that
gets active if such a penalty was triggered on the last line/page (a
"carryover-penalty" or something like that).

In the end I think that all the elements after a chosen break may be
invalid anyway if the available IPD changes (for example when the n+1
page is landscape while the page n was portrait). In this case all
non-finalized elements have to be recalculated due to different break
decisions in the line layout managers and different values coming from
page-number(-citation) elements. [1]

I wonder how other systems cope with this. Information on this seems to
be very rare, at least when googling with the Knuth model in mind.

Head smoking, digging deeper...

[1] http://wiki.apache.org/xmlgraphics-fop/PageLayout/KnuthElementEvaluation

On 28.02.2005 10:15:39 Luca Furini wrote:
> 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

Jeremias Maerki

Reply via email to