--- "Andreas L. Delmelle" <[EMAIL PROTECTED]> wrote: > > Indeed not. The FlowLM should definitely keep track > of this, when > applicable --in my description: the FlowLM would > store the reference to its > last processed descendant before the page overflow, > and the PageSequenceLM, > upon finishing one total page-vp, would simply > instruct the FlowLM to > 'continue, wherever it left off'.
OK. Not a problem here. > No, the 'M' is for 'Manager'... From the POV of the > FlowLM, the constraints > on the total layout dimension of the areas geneated > by its descendants is > not something it *needs* to have any control over > itself --let alone: create > at will :-/ > Well I think different FLM's would make different judgment calls in terms of page breaking mechanisms and/or column balancing, at least. > > ...and the fo:page-sequence-master is linked in > too-many-ways-to-mention to > the fo:page-sequence directly (not, or only > indirectly to, the fo:flow). > I don't think this matters all that much. > > Just another unneeded moving part. FLM can fill > up > > the BodyRegion and send it back to PSLM for it to > do > > the StaticContent/SideRegions. > > Or it can fill up the readily created BodyRegion, > and signal the PSLM that > the layout for the static content may begin... Hmm, > maybe the real fun of it > is: if you would really like to wait until the end > of the PageSequence to > layout the static content for all pages...? No...do it after each page is done...because that is how it is sent to the AreaTreeModel for rendering. However, and this is where the main issue will be, the FLM may need to juggle three or four PV's at a time while it is determining optimal Knuth page breaks, etc. Once all that is determined, *then* send them back one-by-one to PSLM. However, I will stay out of this issue for the moment and await comments from Luca and/or others on the team. This is outside my scope of knowledge. > > So, there will be a possible N flows for one > page-sequence...? All the more > reason, it seems, to centralize the page-generation > at the 'one' end of that > branch... > I think they will be used more commonly for fo:static-content objects (print the same information in both the region-before and region-after, etc.) > > Yes and no :-) > It performs layout for the entire flow, on a > page-by-page basis, in close > co-operation with the PageSequenceLM --and the > StaticContentLM, if necessary > for static-content float/footnote separators. > Start-pause-resume-pause-resume... It flows its > content, bit by > bit --reporting to PSLM, and handing over control > every page or so. > OK--sounds good. Thanks, Glen
