Re: [XML Graphics - FOP Wiki] Updated: PageLayout
Jeremias Maerki wrote: 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. Ops, you are right, the penalty should have a 0 penalty value (or maybe greater, anyway not infinite), otherwise it is completely useless to set its width, as it will never be used! 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. Yes, line breaking has not something analogous to the repeated header in a table, although the elements representing spaces in centered effect (which have effect only if there is a break between them) are somewhat similar. But I think that the main point is to have a representation whose height is correct: the representation is not the content, its only purpose is to allow the creation of pages satisfying the constraints (orphans, widows, keep, ...): what to put into the pages concerns the LMs. I'm a bit sceptical that the code will be able to identify such special conditions reliably. I think it would not be that difficult: for example, the penalty (whose width is header height + footer height) could have a conventional Position. In the addAreas phase, if the last position in the iterator is that particular Position, the LM will know that the table has been split between pages and, according to the value of table-omit-*-at-break, will add header and footer. Regards Luca
Re: [XML Graphics - FOP Wiki] Updated: PageLayout
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 2footer
+- -
+ 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
Re: [XML Graphics - FOP Wiki] Updated: PageLayout
Simon, I've tried to think your example through. If I read the spec
right about space resolution then I get the impression that we may need
to do more in this area than find a suitable box/glue/penalty
combination. There may be several spaces which need to be taken into
account during resolution. There's the precedence and the conditionality
that needs to be evaluated. I think we may need to create special
elements that can hold this information (or reference it). They need to
be distinguishable so we can apply the resolution rules properly.
I believe your example should then look like this:
- box
- penalty (w=0, p=infinite)
- space
- glue (w=0, y=0, z=0)
- space
- penalty (w=0, p=infinite)
- box
A more complex example would look like this:
fo:block space-after=5pt
fo:blocka line/fo:block
fo:block space-after=3pt
blah blah
/fo:block
/fo:block
fo:block space-before=10pt
blah bla
/fo:block
- box (a line)
- box (blah blah)
- penalty (w=0, p=infinite)
- space (w=3pt, ref to the space property)
- penalty (w=0, p=infinite)
- space (w=5pt, ref to the space property)
- glue (w=0, y=0, z=0)
- space (w=10pt, ref to the space property)
- penalty (w=0, p=infinite)
- box
The algorithm would have to track down the space element before and
after the break and then apply the space resolution rules. The space
elements would behave much like glue elements.
What do you think?
On 25.02.2005 22:50:17 SimonPepping 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`.
+
+When the space specifiers do not resolve to zero around a page break,
+we are in the same situation as that of a word space in line breaking
+in the case of centered lines. It is represented by the sequence
+{{{
+box - infinite penalty - glue(ha) - zero penalty - glue(hn-ha-hb) - zero
width box - infinite penalty - glue(hb) - box
+}}}
+where ha is the bpd of
+the space-after before the page break, hb is the bpd of the
+space-before after the page-break, hw is the space when there is no
+page break.
Jeremias Maerki
Re: [XML Graphics - FOP Wiki] Updated: PageLayout
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 2footer
+- -
+ 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
