[prev in list] [next in list] [prev in thread] [next in thread] 

List:       fop-dev
Subject:    Re: [XML Graphics - FOP Wiki] Updated:  PageLayout
From:       Luca Furini <lfurini () cs ! unibo ! it>
Date:       2005-02-28 9:15:39
Message-ID: Pine.LNX.4.44.0502281013240.4572-100000 () tebaldo ! cs ! unibo ! it
[Download RAW message or body]


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


[prev in list] [next in list] [prev in thread] [next in thread]