--- 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
