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

Reply via email to