--- "Andreas L. Delmelle" <[EMAIL PROTECTED]> wrote: > > > > 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'
No, no, no... BodyRegionLM will handle fo:flow and fo:static-content equivalently. SideRegionLM will handle fo:flow and fo:static-content equivalently. BodyRegionLM and SideRegionLM would handle these objects very differently. > 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 :-/ I'm going to withdraw my suggestion anyway. I have a lot more studying to do on this before continuing. I am clearly not on solid enough ground for this. If FlowLayoutManager is currently responsible for the layout of an entire fo:flow object, no matter what region it is placed on and no matter how many pages are needed, I completely agree it should be called FlowLayoutManager. But if this class is just to layout a single BodyRegion of a page, and multiple instances of it are activated by PSLM while it is processing its own fo:flow object, then it should be called BodyRegionLM. Studying the current logic in PSLM and FLM, it appears to be half-and-half. A single FlowLayoutManager instance is indeed in memory for the entire fo:flow, but PSLM is doing the job of parsing out the fo:flow on to multiple pages, and also apparently even collecting the areas that make up the fo:flow. So FlowLayoutManager and StaticContentLayoutManager it will remain under the current logic. I'm dropping my suggestion--I clearly have a lot more studying to do on this. Thanks, Glen
