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