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?



--- [EMAIL PROTECTED] wrote:
> gmazza      2005/03/29 16:06:30
>   Modified:    src/java/org/apache/fop/area Tag:
>                         Temp_KnuthStylePageBreaking
>                src/java/org/apache/fop/layoutmgr
> Tag:
>                         Temp_KnuthStylePageBreaking
>   Log:
>   Removed the curSpan instance variable -- now
> obtainable via curPage.

Reply via email to