Re: Problems with break conditions and empty pages
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:blockBlock 1 ./fo:block fo:block break-before=odd-pageBlock 2 ./fo:block fo:blockBlock 3 ./fo:block fo:blockBlock 4 ./fo:block fo:block break-before=even-pageBlock 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
break-before/break-after functioning?
I've just recently checked out the current CVS tree and built FOP. It doesn't seem to be handling the break-before/break-after properties with the value 'page' at all. I've put together a simple test: ?xml version='1.0' encoding='UTF-8' ? fo:root font-size='18pt' xmlns:fo='http://www.w3.org/1999/XSL/Format' fo:layout-master-set fo:simple-page-master master-name='slide' page-width='11in' page-height='8.5in' fo:region-body margin-top='0.5in' margin-bottom='0.5in' margin-right='0.75in' margin-left='0.75in'/ /fo:simple-page-master /fo:layout-master-set fo:page-sequence master-reference='slide' fo:titleBreak Testing/fo:title fo:flow flow-name='xsl-region-body' font-weight=bold fo:blockline1/fo:block fo:blockline2/fo:block fo:block text-align='center' break-before=pageline3/fo:block /fo:flow /fo:page-sequence /fo:root This should generate two pages, but it doesn't. -- Alex Milowski The excellence of grammar as a guide is proportional to the paucity of the inflexions, i.e. to the degree of analysis effected by the language considered. Bertrand Russell in a footnote of Principles of Mathematics
RE: Problems with break conditions and empty pages
-Original Message-
From: Andreas L. Delmelle [mailto:[EMAIL PROTECTED]
snip /
Would we need a 'check' on whether the previous page already
contains areas generated by elements of a given BlockSequence
(or: whether the first area on curPage is also the first area
generated by an element of the BlockSequence)?
Or what about the following in AbstractBreaker.BlockSequence at line 64 :
endBlockSequence() {
...
returnSequence = new BlockSequence(startOn);
...
}
So, when BlockSequence.endBlockSequence() is called, the remaining
KnuthSequences are returned as a new BlockSequence with a startOn equal to
the value which was already set with the construction of the
sequence --maybe this simply needs to be changed to ...?
Cheers,
Andreas
RE: break-before/break-after functioning?
-Original Message- From: Alex Milowski [mailto:[EMAIL PROTECTED] Hi, I've just recently checked out the current CVS tree and built FOP. It doesn't seem to be handling the break-before/break-after properties with the value 'page' at all. Yep! We're currently working precisely at page-breaking (incl. forced breaks). If you want to test the status of the most recent development version, try checking out branch 'Temp_KnuthStylePageBreaking'. If you need to check out the latest release version, you have to check out branch 'fop-0_20_2-maintain'. Cheers, Andreas
RE: break-before/break-after functioning?
-Original Message- From: Alex Milowski [mailto:[EMAIL PROTECTED] Hi, Is there a list of the different code branches somewhere? One very quick way to get all the branches is ViewCVS: http://cvs.apache.org/viewcvs.cgi/xml-fop/ Then at the bottom of the page, you have a drop-down box from which you can select a tag out of all possible branches (and non-branch tags). HTH! Greetz, Andreas
RE: Problems with break conditions and empty pages
-Original Message- From: Luca Furini [mailto:[EMAIL PROTECTED] Hi, snip / 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. Yeah, it was just a thought... I assumed the FlowLM was the place where the actual breakValue was resolved before it was passed to PSLM.needEmptyPage() or .needNewPage() --but looking closer, that's not how it works... (PSLM.handleBreak() is a private method). 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. Further browsing leads me to place my money on AbstractBreaker.BlockSequence. If I get it correctly, the 'startOn' value is set only once for the entire list (at construction time), but that value is returned every time the PSLM.PageBreaker calls BlockSequence.getStartOn() --which happens in PSLM.PageBreaker.startPart() line 205. So, if this method is called every time a new page is created, and *one* BlockSequence spans multiple pages, we would get the wrong breakValue for all pages but the first... Still looking for the optimal way to correct this behaviour. Would we need a 'check' on whether the previous page already contains areas generated by elements of a given BlockSequence (or: whether the first area on curPage is also the first area generated by an element of the BlockSequence)? snip / [Glen :] 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. Both very good points! Let's keep it exactly where it is. Cheers, Andreas
Re: Problems with break conditions and empty pages
--- Luca Furini [EMAIL PROTECTED] wrote: Break conditions in page breaking are quite similar to preserved linefeeds in line breaking: they divide a fo:page-sequence in smaller sequences, Another way of thinking about it would be that the array of page-viewport-areas returned by this FO is divided into smaller arrays, with each smaller array undergoing its own Knuth page breaking process. (I prefer to think of areas being divided rather than FO's.) 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. snip/ 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. Actually, that is now available as a public accessor in the PageViewport object, so any LM working with one has access to the page number. And, within reason, accessors within PSLM could be used by FLM, which maintains a reference to its parent LM. 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! :-) Well, under our current philosophy, our LM's map to the formatting object (here, the page sequence), not the areas they generate. I was reminded a bit on that a few weeks ago by Andreas and Simon. You may recall, I recommended at the time that we have BodyRegionLM and a SideRegionLM instead of a FLM and a StaticContentLM. Under this scenario, PSLM controls complete page-by-page layout, and delegates to the BRLM and SRLM to do the body region or side areas. But if we have an FLM instead, my thinking is that it should perhaps process the entire fo:flow--including the creation of multiple page-viewport-areas in order to consume that flow. 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; I think this is because of the footnote and before-float separators (not the footnotes and before-floats themselves) which are defined in fo:static-content FO's under the page-sequences. The FLM somehow would have to be able to create these separators each time they are needed for each page. As for location controlled by the fo:page-sequence ancestor, that could simply mean that the fo:page-sequence defines the page margins and the side region dimensions. The footnote is just above the region-after, and before-floats are just below the region-before, hence the fo:page-sequence determines its location. This wouldn't necessarily mean that the actual layout of these objects needs to be done by the PSLM. 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. Well, the available maximum bpd can be accessed from the area.BodyRegion child of the PageViewport--this value is calculated automatically upon initialization of a PageViewport. As you can see from section 6.10.1.3[1], these two areas consume space from the main-reference-area. So it appears that all that would be necessary is for the FLM to create a PageViewport, and if a flow has a before-float or footnote, reduce that bpd for the regular normal-reference-areas. (Also, to add the footnote/before-float separators in.) Actually, IMO right now, this work can be done by either PSLM or FLM. If the team's instincts are to remain with PSLM for this, that would OK with me. Thanks, Glen [1] http://www.w3.org/TR/2001/REC-xsl-20011015/slice6.html#pg-out-of-line
