Created attachment 23092 [details] Sample FO to reproduce bug FO has been checked for obvious causes why blank page is added at the end of the document, i.e. not caused by space-after, break-* properties or force-page-count. Removing the fo:repeatable-page-master-alternatives element in favour of a single repeating page master avoids the blank page. Sample FO that reproduces the problem in trunk has been attached.
Some initial observations: The issue is again with the last page-master. Commenting out only that one, also produces the expected result. This time, it's the combination with the last break-before in the document. Another way to avoid the issue for the moment, is by moving that as a break-after to the last preceding block.
Created attachment 23396 [details] modified sample; demonstrating the influence of tables If we remove tables from the picture, the issue disappears as well.
Upon checking closer: the difference between the scenario with and without tables is that, without tables the break-before has already triggered addAreas() for the preceding parts. With tables, the forced break is included in the complete list, but is preceded by another penalty which seems to confuse things... The restartPoint is set to the point *between* the two penalties, so when we restart the algorithm for the last page, it will encounter the forced break too, as a first element, and produces two pages instead of only one. I managed to hack the issue away locally by a adding a small check for this in PageBreaker.doPhase3WithLastPage(): ... newStartPos = pbp.getLeafPos(); /* hack to avoid producing an extra page after the last */ if (((KnuthElement)effectiveList.get(newStartPos)).isForcedBreak()) { newStartPos++; } ...
In the meantime, I tracked the origin of the superfluous penalty to BlockStackingLM.getNextKnuthElements() (line 350). Avoiding its creation and insertion into the result list does not solve the matter, although we might fare better in general if we only call addInBetweenBreak() in case the returnedList, whose elements will be appended after that call, does not itself already start with a forced break. (A similar thing happens in FlowLM, by the way...) The real issue is that the restarting point is set to the index of the penalty representing the last page-break. Better put: the restarting point is always set to right *before* the last page-break, instead of the immediately *after*. No problem for a regular break-possibility, but this generates the side-effect of the extra page if the break was forced. Therefore, I'm thinking that the newStartPos variable in PageBreaker.doPhase3WithLastPage() should unconditionally be set to (pb.getLeafPos() + 1).
(In reply to comment #4) > Therefore, I'm thinking that the newStartPos variable in > PageBreaker.doPhase3WithLastPage() should unconditionally be set to > (pb.getLeafPos() + 1). This has been committed with r757239. Thanks for reporting!
batch transition pre-FOP1.0 resolved+fixed bugs to closed+fixed