> -----Original Message-----
> From: Glen Mazza [mailto:[EMAIL PROTECTED]
>
> --- Simon Pepping <[EMAIL PROTECTED]> wrote:
> >
> > What Andreas argues here is what I would think as
> > well: The LMs are tied to the formatting objects,
> > not to the page regions they populate.
>
> I don't see it that way, because both an fo:flow and
> an fo:static-content are handled equivalently when
> sent to a SideRegion, and both are handled
> equivalently when sent to the BodyRegion.

Apart from markers, which will always be handled differently for Flow and
StaticContent, whether sent to the BodyRegion or a SideRegion...

>
> SideRegionLM handles the layout of input into a r-r-area
> that does not have spans [...] does the same thing
> regardless of the input coming from an fo:flow or an
> fo:static-content.
>
> NormalFlowLM handles the layout of input into
> multi-column/multi-span areas [...] does the same thing
> regardless of the input coming from an fo:flow or an
> fo:static-content.

Except for ... (see above)? Hmm... Why would we even *need* *two*
*different* LMs?
Don't get me wrong: I'm *not* encouraging you to merge the two classes
completely ;-P

Still can't put my finger on it, but something seems not quite OK with
having two separate LM classes that 'do the same thing, regardless of the
input coming from an fo:flow or an fo:static-content' --solely on the basis
that they layout different page regions, with or without columns/spans...?
I hate to be the show-stopper, but I still need to be convinced that there
is not actually a better way to go about this :-/

If one were to say, for instance, instead of renaming these two classes,
just add a third one --call it RegionBodyLM, SpanLM or whatever-- containing
the logic to deal with multi-column/multi-span, and have this latter one do
its work in close co-operation with the other two and the PSLM... Now, that
would be a different story.

I can't really explain it, but will try... It just seems that, in a few
weeks/months we're bound to find out the hard way that simply renaming two
classes to make them conceptually fit into a processing-flow that doesn't
yet exist, will make the implementation of precisely that processing-flow
all the more difficult. Somehow it looks like we're going to need that extra
class anyway. If that turns out to be true, I'd rather see it added now, and
base it upon the line of thought that:
1) one or more FlowLMs manage layout for an fo:flow
2) one or more SCLMs do the same for the fo:static-contents
3) the PSLM controls both, plus...
4) the SpanLM(?) that takes care of the possible multi-column/-span layout,
in combination with 1) or 2)

The side-regions, IIC, can ATM be handled by the PSLM in conjunction with
FlowLM or SCLM directly --and the intervention of 4) should *depend* upon
multi-column/-span properties being used. If they aren't, the current setup
should work nicely, without any classes being renamed, just a null reference
added.

Long shot... maybe in some future versions of the Rec., the possibility of
multi-column layout will be introduced for the side-regions --why not?
(And if so, your current proposal would turn out to have had ... which
benefit exactly? --No offence intended, just trying to build my case here,
for I see faint images of two separate classes containing lots of duplicate
code...)


Cheers,

Andreas

Reply via email to