> Glen Mazza wrote :
# Andreas L. Delmelle wrote:
> 1.) If FOP is processing a block on the middle of page
> 17 with a break-before value of "even-page", FOP is
> supposed to render this block at the top of page 18
> instead.
I agree.
> 2.) If FOP is processing a block on the middle of page
> *18* with a break-before value of "even-page", FOP is
> supposed to render it at the top of page 20 instead.
I agree.
> 3.) The above processing is done only once for the
> fo:block with this property. I.e., assuming no child
> of fo:block has this property as well, if the block
> takes up multiple pages it will use pages
> 18-19-20-21-22..., for (1) above, and *not*
> 18-20-22-24...
I agree.
I think this is the right behaviour even if the block creates just a few
lines, but the following blocks have no break conditions.
Break conditions in page breaking are quite similar to preserved linefeeds
in line breaking: they divide a fo:page-sequence in smaller sequences,
just as preserved linefeeds make the block create more than one paragraph.
<fo:flow ...>
<fo:block>Block 1 .....</fo:block>
<fo:block break-before="odd-page">Block 2 .....</fo:block>
<fo:block>Block 3 .....</fo:block>
<fo:block>Block 4 .....</fo:block>
<fo:block break-before="even-page">Block 5 .....</fo:block>
</fo:flow>
The break properties divide the content in three different
"sub-page-sequences":
- the first one must start on any page and contains block 1
- the second one must start on an odd page and contains block 2, 3 and 4
- the third one must start on an even page and contains block 5
So, the knuth elements are divided into three different lists, each one
with a variable storing the break value (respectively "any page", "odd
page", "even page").
# I also tried two fo:blocks, first one with break-after="even-page" and the
# second with break-before="even-page", and I don't know exactly what the
# result is supposed to be
Both properties define the same break condition (4.8 in the
recommendation): the first area generated by the second block must be
leading in (i.e. start) an even page.
One of the properties is redundant, the effect is the same as if only one
of them were used, I think.
# Also, a break-before="page" on the very first block in the document seems to
# be ignored. Is that correct behaviour?
I think it is correct: the break condition requires the first area
generated by the block to be leading in any page, and this is true even
without adding an empty page.
> Also, as food for thought, I wonder if the two methods
> Luca has mentioned should eventually be in
> FlowLayoutManager (FLM) instead. The break properties
> appear relevant only for fo:flow descendants.
# Interesting idea. The FLM may have more convenient access to the information
# needed to deal with exactly this type of situation... at the very least,
# it's worth considering moving part of the logic to FLM --say, storing a
# state variable indicating whether the last page-break was forced or not-- so
# the result of PSLM.needNewPage() would depend on FLM.needNewPage() which
# would in its turn depend on 'lastPBForced'.
# OTOH, this state variable could also be stored in the PSLM itself...
I don't know if the methods could be moved to the FLM: besides the break
value, they depend on the current page number and this is known only by
the PageSequenceLM.
The method needEmptyPage() should return true only when we are starting
the layout of a different subsequence, and the next page would not be of
the right kind.
For example:
- the first subsequence creates an only page
- when we start the pagination of the second subsequence (having break
value "odd page") we realize that the next page (#2) would not be ok, so
we must add an empty one
- if this subsequence creates more than a page, needEmptyPage must return
always false (or maybe it should not be called)
- needEmptyPage could return true (or be called again) only when we start
the layout for the third subsequence, which must start on an even page.
> the FLM is the immediate LM child of PSLM, so it
> should have everything that PSLM does (except for the
> static content, which I don't think we care about when
> it comes to page breaking anyway.) Ideally, FLM
> should be the topmost LM that handles the page
> breaking, no? I wonder if the Knuth code should be
> out of PSLM completely
I need some more time to reflect on this idea, but I write a quick answer
anyway.
My first impression is that I would find somewhat strange that the *page*
breaking is not in the *Page*SequenceLM! :-)
A more serious comment is that some formatting objects (footnotes and
before floats) generates "page-level-out-of-line-areas", whose placement,
according to the recommendation (4.2.5), "is controlled by the
fo:page-sequence ancestor"; so, if the PSLM must handle footnotes and
before floats (influencing the available bpd for the normal areas) it must
handle the whole page breaking process.
Regards
Luca
