--- "Andreas L. Delmelle" <[EMAIL PROTECTED]>
wrote:
>
> Hmm.. This does seem to be one of those situations
> where the logic could be
> placed anywhere. However, taking into account Luca's
> remarks, I would be
> inclined to see it as:
>
> "The PSLM creates the page-viewports, and passes
> them on to
> 1. the FLM --which controls layout of a subset of
> the areas
> generated by descendants of the fo:flow
> (ultimately also floats/footnotes)
> 2. the SCLMs --which control layout of the areas
> generated
> by the descendants of the fo:static-contents
> (+ possible retrieved markers from the subset
> processed
> by the FLM)"
>
I like this.
> In this respect, the page-breaking logic is already
> at its most appropriate
> place.
> The FLM needs only a part of the total page-vp, so
> it makes sense to handle
> the creation/initialization of the viewport one
> level up.
>
Actually, "creating/initializing" a PageViewport is
not a big deal anymore--all PSLM does these days is:
PageViewport pv = new PageViewport(simplePageMaster);
That's it. The details of setting up
region-reference-areas, page-reference-areas, etc., is
all automatically done in PageViewport and related
Area classes. So this one-line initialization can be
done by FLM or PSLM wherever convenient.
If we go this route--and it's primarily dependent on
whether Luca is comfortable with it and sees
sufficient benefits to it--the total number of
pageViewports needed for a page-sequence would be a
function of the page-breaking and layout strategy of
the *FLM*, not the PSLM. For example, FLM may not
immediately be able to support multiple columns and
column balancing--output is single-column only. Once
we have columns & column-balancing implemented in FLM,
probably a different number of PV's would be needed
for a given page-sequence. Or, different Knuth
implementations in FLM result in a different PV count.
Also, (say) Finn, via our pluggable layout manager
mechanism, decides to implement a different FLM, again
changing the number of PV's needed, etc., etc. PSLM
can remain the same regardless of FLM implementation.
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);
}
(getNextPageViewport() returns one PV object with its
flow information populated.)
b.) Or, have a "push" mechanism in PSLM:
FlowLayoutManager flm = new flm(simplePageMaster);
flm.doLayout();
public void pageViewportFinished(pv) { // called by
FLM
addStaticContent(pv); // done for *every* PV
areaTreeModel.renderPage(pv);
}
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.
Thanks,
Glen
