> -----Original Message----- > From: Glen Mazza [mailto:[EMAIL PROTECTED] >
<snip /> > I was thinking of the FLM controlling layout for *all* > the FO descendants of the fo:flow. One and only one > FLM instance for the fo:flow of an fo:page-sequence. OK, clear now and fully agreed on this. > It returns PageViewport instances to PSLM as it does > its processing. And here the viewpoints differ, it seems... You would have the FLM create the actual PageViewports, on the basis that _it_ needs them anyway, and the PSLM would, strictly speaking, only need them when they are 'filled' --as a return value. The described approach is that the PSLM creates these viewports (or 'catches' them when they are created), passes them to the FLM and SCLM, and the latter merely 'signal' when their work is done with that viewport and whether they need another one. > > 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). > > I'm unsure what you mean by subsets... Yaa, sorry about that. It's just to give a name to a set of descendants of an fo:flow that, when fully rendered, would more or less correspond to one page in the output. It's merely of conceptual use, doesn't correspond to a real variable somewhere. > --while forced page-breaks may cause the Knuth > algorithms to need to group up the PageViewports > generated by the FLM into subsets for each subset > to get optimized, that is IMO an FLM-specific > implementation detail that PSLM ideally shouldn't > need to be concerned about. 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'. > > > 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. > > IMO the FLM is a PageViewport-generating (and > -returning) machine 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 :-/ > --with the number of pages it needs > dependent upon the FLM's implementation, page breaking > strategies, etc. My FLM may return 54 PV's to the > PSLM for a given page-sequence -- your might return 50 > for example. Well, your FLM would generate viewports filled with areas, where mine would layout areas *to* one or multiple viewports... Which one makes more sense? I really can't say right now. > > > If the content fits in one page --sufficiently low > > bpd or indefinite page-height-- no additional pages > > are requested from the PSLM. > > This is all FLM needs to do to create a fully > initialized PV: PV pv = new PV(spm); Why bother > having PSLM declare and feed it to FLM each time? Because it _feels_ right :-) No, seriously: because the PageSequenceLM corresponds to the fo:page-sequence, and the fo:page-sequence... Well, the Rec states it best: "6.4.1.4 Flows and Flow Mapping ... The processing of the fo:flow flow is what determines how many pages are generated to hold the fo:page-sequence. The fo:page-sequence-master is used as the generator of the sequence of page-masters into which the flow children content is distributed." ...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). > 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...? Well, anyway, that would work equally well in both approaches. <snip /> > Actually, PSLM doesn't do that anymore. PV creates > itself interally, including its subareas. That's what > allows us to discuss creating PV's in either FLM or > PSLM. PSLM has way too much logic to handle than to > get into the irrelevant minutae of creating a PV. > (You may be forgetting also that PSLM will also need > to handle Flow Maps in the future.) 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... > > > c. instruct FLM to resume layout where it left off, > > handing it the freshly created viewport as a blank > > canvas > > > > This is what is driving me crazy: Good, me too! ;-P Errm, no wait a minute... > I said three weeks ago, let's call FLM BodyRegionLM > instead, because it is just doing page-by-page layout, > with everything being controlled by PSLM and you said > "no, no, no--it processes the entire Flow--so call it FLM". Yes --your point being? I mean: what am I saying now that contradicts what I stated a few weeks ago? As I stressed back then, my main reason for preferring the distinction Flow/StaticContent to BodyRegion/SideRegion was the marker-mechanism... > > Now, you disagree in having FLM process the entire > flow, No, I don't... Do I? > you want FLM to be page-by-page, i.e., a > BodyRegionLM but not called that. 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. > I can accept either implemention--although I do prefer > having the FLM now--but its name should be consistent > with what it does. But it _is_ consistent, depending on how you look at it. Even if you do get into a situation where you have multiple flows for one page-sequence, the PageSequenceLM seems the best fit to manage/balance the different 'page-breaks' that the flows push upward. > > It just creates the pages > > on-demand, using page-masters > > defined higher up, but *as needed* by the FLM. > > Be careful, never say pages unless you are talking > about the physical medium. Say > PageViewports/page-viewport-areas instead. Sorry, syntax error :-) > Also, page-masters are not defined "higher-up", they > are defined *separately* (in fo:layout-master-set) and > should be available for any LM that references their > values. > Yes, a layout-master-set on the same level, but earlier, in the FOTree as/than the page-sequence (not the flow). <snip /> > I suspect the PSLM will pre-create each SCLM instance > for footnote/float separators. (i.e., we don't create > and initialize these objects for every page), so the > FLM could call the PSLM to add the layout for the > separators. Exactly! Well, what you describe below makes it seem like the PSLM would just provide a method call that would trigger the StaticContentLM in question... Exactly! > > > 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. > > You're missing the BPD for the separators here, needed > for the calculations. Oh yes, those too... > > I don't like having PSLM call the activation of > separators, because (1) FLM would then be returning > PV's whose BodyRegions are not complete, and it is > messy to insert separators after-the-fact between the > float and main-reference-area and between the MRA and > the footnote, and (2) it requires PSLM to know more > about the implmentation details of the FLM that would > be desirable--did it finish with floats/footnotes, > etc. Best IMO to just have PSLM provide methods to > generate the separators that FLM can call if/when > needed. +1 Cheers, Andreas
