--- "Andreas L. Delmelle" <[EMAIL PROTECTED]>
> > -----Original Message-----
> > From: Glen Mazza [mailto:[EMAIL PROTECTED]
> >
> Hi Glen,
> > Also, as food for thought, I wonder if the two
> methods
> > Luca has mentioned should eventually be in
> > FlowLayoutManager (FLM) instead.  The break
> properties
> > appear relevant only for fo:flow descendants.
> Interesting idea. The FLM may have more convenient
> access to the information
> needed to deal with exactly this type of
> situation... 

Well, the FLM is the immediate LM child of PSLM, so it
should have everything that PSLM does (except for the
static content, which I don't think we care about when
it comes to page breaking anyway.)  Ideally, FLM
should be the topmost LM that handles the page
breaking, no?  I wonder if the Knuth code should be
out of PSLM completely, i.e., have FLM have this

PageViewport[] generatePages(),

which would be called by PSLM, and once it returns,
PSLM then takes care of static content before sending
each page to the AreaTreeModel for rendering.

(Or, have the FLM feed the pages back to PSLM
one-by-one, after it finishes the flow for that page. 
Same principle here--the FLM would do the breaking.)

Luca, Jeremias, WDYT?

> at the very least,
> it's worth considering moving part of the logic to
> FLM --say, storing a
> state variable indicating whether the last
> page-break was forced or not-- so
> the result of PSLM.needNewPage() would depend on
> FLM.needNewPage() which
> would in its turn depend on 'lastPBForced'.
> OTOH, this state variable could also be stored in
> the PSLM itself...
> Roughly, the logic could become something like
> PSLM.needNewPage(int breakVal) {
>   if( (curPage != null) &&
> (curPage.getPage().isEmpty() ) {
>     if( breakVal == PAGE ) {
>       return (currentPageNum == 1);
>     } else {
>       boolean evenPage = (currentPageNum % 2 == 0);
>       return ((breakVal == (evenPage ? ODD_PAGE :
> EVEN_PAGE)) ||
> lastPBForced);
>     }
>   } else {
>     return true;
>   }
> }

The logic is not as much a concern to me as its
location.  This seems like it should ideally *all* be
in FLM.  I would think FLM is to completely take care
of the fo:flow, including making 47 pages if need be,
doing the incrementing of columns within the span on
each page, etc.  PSLM would just add the static
content after each page-viewport is returned to it by
FLM.  I wonder if PSLM should be so designed that if
we had multiple ways to break up pages--it might mean
multiple FLM implementations, but PSLM would be the
same regardless.


Reply via email to