Problems with break conditions and empty pages
It seems there is a bug affecting the creation of the right kind of page for documents containing blocks with break-* = odd-page or even-page. If break-before = odd-page *each* page with some content is odd; even pages are all empty. If break-before = even-page the content is placed only on even pages, while odd pages are empty; moreover, if the block with break-before is the first one in the document it is placed on the first page (which is odd!), without adding an empty page before. The same happens with break-after. I think this could depend on the conditions tested in the methods PSLM.needEmptyPage() and PSLM.needNewPage(); in particular, the first one should return false if the first page has already been created, while now it seems to return always true. I'll look at this again next week, obviously unless someone finds a fix before! :-) Regards Luca
Re: Problems with break conditions and empty pages
Just so I understand how this is supposed to work, will someone please confirm my assumptions below: 1.) If FOP is processing a block on the middle of page 17 with a break-before value of even-page, FOP is supposed to render this block at the top of page 18 instead. and 2.) If FOP is processing a block on the middle of page *18* with a break-before value of even-page, FOP is supposed to render it at the top of page 20 instead. and 3.) The above processing is done only once for the fo:block with this property. I.e., assuming no child of fo:block has this property as well, if the block takes up multiple pages it will use pages 18-19-20-21-22..., for (1) above, and *not* 18-20-22-24... Thanks, Glen --- Luca Furini [EMAIL PROTECTED] wrote: It seems there is a bug affecting the creation of the right kind of page for documents containing blocks with break-* = odd-page or even-page. If break-before = odd-page *each* page with some content is odd; even pages are all empty. If break-before = even-page the content is placed only on even pages, while odd pages are empty; moreover, if the block with break-before is the first one in the document it is placed on the first page (which is odd!), without adding an empty page before. The same happens with break-after. I think this could depend on the conditions tested in the methods PSLM.needEmptyPage() and PSLM.needNewPage(); in particular, the first one should return false if the first page has already been created, while now it seems to return always true. I'll look at this again next week, obviously unless someone finds a fix before! :-) Regards Luca
Re: Problems with break conditions and empty pages
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. Glen --- Glen Mazza [EMAIL PROTECTED] wrote: Just so I understand how this is supposed to work, will someone please confirm my assumptions below: 1.) If FOP is processing a block on the middle of page 17 with a break-before value of even-page, FOP is supposed to render this block at the top of page 18 instead. and 2.) If FOP is processing a block on the middle of page *18* with a break-before value of even-page, FOP is supposed to render it at the top of page 20 instead. and 3.) The above processing is done only once for the fo:block with this property. I.e., assuming no child of fo:block has this property as well, if the block takes up multiple pages it will use pages 18-19-20-21-22..., for (1) above, and *not* 18-20-22-24... Thanks, Glen --- Luca Furini [EMAIL PROTECTED] wrote: It seems there is a bug affecting the creation of the right kind of page for documents containing blocks with break-* = odd-page or even-page. If break-before = odd-page *each* page with some content is odd; even pages are all empty. If break-before = even-page the content is placed only on even pages, while odd pages are empty; moreover, if the block with break-before is the first one in the document it is placed on the first page (which is odd!), without adding an empty page before. The same happens with break-after. I think this could depend on the conditions tested in the methods PSLM.needEmptyPage() and PSLM.needNewPage(); in particular, the first one should return false if the first page has already been created, while now it seems to return always true. I'll look at this again next week, obviously unless someone finds a fix before! :-) Regards Luca
RE: Problems with break conditions and empty pages
--- Andreas L. Delmelle [EMAIL PROTECTED]
wrote:
-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
method:
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.
Thanks,
Glen
