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