This is all I see left that needs to move out of PSLM.
I now agree though that column balancing should stay in PSLM, because it's a dynamic layout task and because its implementation--unlike the rote setting up of regions for a PageViewport--would most likely differ between PSLM implementations (our pluggable LM's allowing for a different PSLMs to be used). Also, CB will most probably have interactive/corresponding effects with other Spans and/or pages--another signal that this is PSLM's responsibility. Glen --- Jeremias Maerki <[EMAIL PROTECTED]> wrote: > Not an objection but a concern: I get the impression > that more an more > logic wanders off into the area package which should > IMO only be a data > structure plus serialization/deserialization and > reference resolution. > And I believe that column balancing is clearly the > LMs responsibility. > Especially with the Knuth approach this can't even > be done otherwise. I > don't know what the others think. > > On 30.03.2005 02:49:08 Glen Mazza wrote: > > Team, > > > > I'd like to recommend next that we move the > > initialization (*not* population) of the > > page-reference-areas, region-viewport-areas, and > > region-reference-areas from PSLM to > area.PageViewport > > (and possibly some in area.RegionViewport). IOW, > > everything from line 685 to the end of the file > > gone[1], with the remaining few lines of > > createPageAreas() moved to makeNewPage(). > > > > This is all boilerplate routine setup--predefined > > margin widths, etc-- independent of layout > mechanisms, > > and I suspect this work can be more cleanly and > > orderly implemented in area.PageViewport anyway. > > > > Replacing this logic in PSLM eventually will be > more > > flow-mapping logic, both of the future fo:flow-map > and > > even our current 1.0 requirements to be able to > place > > fo:flow data into any of the region areas. > (Perhaps > > the column balancing as well, if the Span object > > cannot handle it by itself.) This is more of > PSLM's > > responsibilities, and it will be quite large > enough in > > accomplishing all of them. But PSLM should more > or > > less be able to just call curPage = new > > PageViewport(), and get a PageViewport with > already > > initialized child region areas. The coding to > create > > this IMHO will be a distraction if kept in PSLM. > > > > Any objections? > > > > Thanks, > > Glen > > > > [1] http://tinyurl.com/4qca3 > > > > --- [EMAIL PROTECTED] wrote: > > > > > > gmazza 2005/03/29 16:06:30 > > > > > > Modified: src/java/org/apache/fop/area Tag: > > > > Temp_KnuthStylePageBreaking > > > PageViewport.java > > > src/java/org/apache/fop/layoutmgr > > > Tag: > > > > Temp_KnuthStylePageBreaking > > > > > > PageSequenceLayoutManager.java > > > Log: > > > Removed the curSpan instance variable -- now > > > obtainable via curPage. > > > > > > > Jeremias Maerki > >
