Hi Andreas:

--- "Andreas L. Delmelle" <[EMAIL PROTECTED]>
wrote:

> [Glen:]
> > With an FLM-centric approach, what I'm seeing is
> > something like either of these two:  (pseudocode)
> >
> > a) Within PSLM:
> >
> > FlowLayoutManager flm = new
> > FlowLayoutManager(simplePageMaster);
> >
> > while (pv = flm.getNextPageViewport() != null) {
> >    addStaticContent(pv);  // done for *every* PV
> >    areaTreeModel.renderPage(pv);
> > }
> 
> I don't quite get this...
> With the FLM controlling layout for a subset of the
> descendants of an
> fo:flow, 

I was thinking of the FLM controlling layout for *all*
the FO descendants of the fo:flow.  One and only one
FLM instance for the fo:flow of an fo:page-sequence. 
It returns PageViewport instances to PSLM as it does
its processing.


> I didn't exactly mean there should be a
> one-to-one relation between
> FLMs and those subsets (or even between the FLMs and
> the
> pages/page-masters).

I'm unsure what you mean by subsets--while forced
page-breaks may cause the Knuth algorithms to need to
group up the PageViewports generated by the FLM into
subsets for each subset to get optimized, that is IMO
an FLM-specific implementation detail that PSLM
ideally shouldn't need to be concerned about.

> More like: the FLM holds a reference to the entire
> set of descendants, which
> it may or may not be able to layout all on one page
> --depending on the
> properties of the page-master that is used to create
> the first page-viewport
> that the PSLM provides it with.

IMO the FLM is a PageViewport-generating (and
-returning) machine--with the number of pages it needs
dependent upon the FLM's implementation, page breaking
strategies, etc.  My FLM may return 54 PV's to the
PSLM for a given page-sequence -- your might return 50
for example.


> If the content fits in one page --sufficiently low
> bpd or indefinite
> page-height-- no additional pages are requested from
> the PSLM.

This is all FLM needs to do to create a fully
initialized PV:  PV pv = new PV(spm);  Why bother
having PSLM declare and feed it to FLM each time? 
Just another unneeded moving part.  FLM can fill up
the BodyRegion and send it back to PSLM for it to do
the StaticContent/SideRegions.


> If it doesn't fit in one page --bpd too high or
> forced page-breaks-- the FLM
> signals to the PSLM if and when it needs a new page,
> so that the PSLM can:
> a. finish up the current one --> instruct SCLMs to
> layout their content to
> the assigned region-viewports.
> (and if there's any content left in the flow)

> b. create a main viewport for the next page(s)

Actually, PSLM doesn't do that anymore.  PV creates
itself interally, including its subareas.  That's what
allows us to discuss creating PV's in either FLM or
PSLM.  PSLM has way too much logic to handle than to
get into the irrelevant minutae of creating a PV. 
(You may be forgetting also that PSLM will also need
to handle Flow Maps in the future.)

> c. instruct FLM to resume layout where it left off,
> handing it the freshly
> created viewport as a blank canvas
> 

This is what is driving me crazy:  I said three weeks
ago, let's call FLM BodyRegionLM instead, because it
is just doing page-by-page layout, with everything
being controlled by PSLM and you said "no, no, no--it
processes the entire Flow--so call it FLM".

Now, you disagree in having FLM process the entire
flow, you want FLM to be page-by-page, i.e., a
BodyRegionLM but not called that.  I can accept either
implemention--although I do prefer having the FLM
now--but its name should be consistent with what it
does.


> It just creates the pages
> on-demand, using page-masters
> defined higher up, but *as needed* by the FLM. 

Be careful, never say pages unless you are talking
about the physical medium.  Say
PageViewports/page-viewport-areas instead.

Also, page-masters are not defined "higher-up", they
are defined *separately* (in fo:layout-master-set) and
should be available for any LM that references their
values.

> So,
> in a sense, the
> 'page-breaking' can also be considered to take place
> at levels far deeper
> than the FLM --fo:blocks with forced page-breaks.
> 

That granularity I'm not at yet to be able to
comment--I currently just prefer it to be outside of
PSLM in FLM. 

> To revisit the implementation of spans:

<snip/>

This I also don't have an opinion on right now, other
than to say that since the since fo:s-c can
unfortunately be redirected to the fo:region-body, it
will eventually need to handle columns as well.  Your
idea may very well take care of this issue--I haven't
an alternative ATM.

> 
> WRT implementing footnotes and floats, I see a few
> possibilities:
> 1) The FLM first performs layout, ignoring the
> footnotes/floats.

I don't think it can ignore it, at the very least it
will need the BPD that the separators take up in order
to do its space calculations when footnotes/floats
occur.

I suspect the PSLM will pre-create each SCLM instance
for footnote/float separators.  (i.e., we don't create
and initialize these objects for every page), so the
FLM could call the PSLM to add the layout for the
separators.  

> 3) The FLM performs layout for the normal areas, and
> upon
>    encountering footnotes/floats, immediately
> performs layout for
>    them, and subtracts the resulting bpd from the
> total bpd available
>    for the remaining normal areas.
> 

You're missing the BPD for the separators here, needed
for the calculations.

> <snip />
> > Also:  PSLM needs to provide FLM the following:
> > 1.) getBeforeFloatSeparator();
> > 2.) getFootnoteSeparator();
> >
> > How these two are provided I'm not sure at the
> moment:
> >  have PSLM render these two by calling a SCLM,
> have
> > FLM render them by calling a SCLM, etc. -- I don't
> > know.
> 
> If the mentioned separators can be considered part
> of the static content,

They are--they are created by an fo:static-content
with predefined flow-names indicating that they are
separators.

> has all info WRT the
> presence of floats/footnotes for the given page at
> its disposal.
> If, OTOH, the separators do not/cannot have an
> effect on the placement of
> the static content --which I would intuitively
> presume to be the case, but

Yes, most apparently the footnotes/before floats go at
the before- and after-edges.

> I'll have to check the Rec for certainty--, then it
> would seem more logical
> to have the FLM process the separators (if and when
> processing the
> before-floats/footnotes themselves).

+1 

I don't like having PSLM call the activation of
separators, because (1) FLM would then be returning
PV's whose BodyRegions are not complete, and it is
messy to insert separators after-the-fact between the
float and main-reference-area and between the MRA and
the footnote, and (2) it requires PSLM to know more
about the implmentation details of the FLM that would
be desirable--did it finish with floats/footnotes,
etc.  Best IMO to just have PSLM provide methods to
generate the separators that FLM can call if/when
needed. 

> 
> 
> Cheers,
> 
> Andreas
> 
> 

Many thanks,
Glen

Reply via email to