> -----Original Message-----
> From: Glen Mazza [mailto:[EMAIL PROTECTED]
>
>
Hi Glen,
(Apologies in advance if the post seems a bit long; really don't mean to
bore you ;-) )
<snip />
> 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 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).
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.
If the content fits in one page --sufficiently low bpd or indefinite
page-height-- no additional pages are requested from the PSLM.
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)
c. instruct FLM to resume layout where it left off, handing it the freshly
created viewport as a blank canvas
(step a. is always performed, b. and c. depend on the nature of the message
the PSLM receives from the FLM --break forced? empty page needed?
descendants left?)
The real 'page-breaking' is done by the PSLM, but not completely
out-of-the-blue. It just creates the pages on-demand, using page-masters
defined higher up, but *as needed* by the FLM. 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.
To revisit the implementation of spans:
My idea would be to insert a class between AbstractLM and
FlowLM(/StaticContentLM?) --a subclass of the first, superclass of the
latter-- that offers the interface for handling multi-column/span layout.
The FlowLM (and StaticContentLM?) would take care of forced column-breaks
within the page the PageSequenceLM has created for them (or: whether a
region to which the flow/static content is assigned has multiple columns, is
ultimately determined in the page-master...).
The inter-class' functionality would contain the default logic for handling
one-column layout, and more...
WRT implementing footnotes and floats, I see a few possibilities:
1) The FLM first performs layout, ignoring the footnotes/floats.
(not really 'ignoring', but storing them in a map at page-level)
When the page is full, redo the layout for this page, _starting_
with footnotes/before-floats, then moving on to the normal areas.
2) The FLM performs layout for the normal areas, _until_ a
footnote/float is encountered, and restarts layout for this page,
starting with the footnote/float (etc.)
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.
Depending on the number of footnotes/floats for a page, option 2) could mean
a significant overhead (since layout must be paused/restarted multiple
times). Option 1) could also become very tricky...
Option 3) seems the better bet so far. It results in all info necessary to
process the page being available after one pass --IIC, at most some
re-arranging of the created areas is needed, if we can't do it on-the-fly,
that is (i.e. instead of merely 'subtracting' the bpd for a before-float,
also immediately adjust the top co-ordinates for the normal areas already
generated for this page)
If anyone sees another alternative for this, I'm all ears...
<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 could be handled by the SCLM --since the SCLM would perform its tasks
*after* the FLM has done its job for the page, it 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
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).
Cheers,
Andreas
