Fop
  1. Fop
  2. FOP-1619

page-position="last" can cause an extra blank page.

    Details

    • Type: Bug Bug
    • Status: Closed
    • Resolution: Fixed
    • Affects Version/s: trunk
    • Fix Version/s: None
    • Component/s: page-master/layout
    • Labels:
      None
    • Environment:
      Operating System: All
      Platform: All
    • External issue ID:
      46489

      Description

      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.

      1. unwantedpage.fo
        50 kB
        Chris Bowditch
      2. b46489.fo
        3 kB
        Andreas L. Delmelle

        Activity

        Hide
        Chris Bowditch added a comment -

        Attachment unwantedpage.fo has been added with description: Sample FO to reproduce bug

        Show
        Chris Bowditch added a comment - Attachment unwantedpage.fo has been added with description: Sample FO to reproduce bug
        Hide
        Andreas L. Delmelle added a comment -

        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.

        Show
        Andreas L. Delmelle added a comment - 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.
        Hide
        Andreas L. Delmelle added a comment -

        Attachment b46489.fo has been added with description: modified sample; demonstrating the influence of tables

        Show
        Andreas L. Delmelle added a comment - Attachment b46489.fo has been added with description: modified sample; demonstrating the influence of tables
        Hide
        Andreas L. Delmelle added a comment -


        If we remove tables from the picture, the issue disappears as well.

        Show
        Andreas L. Delmelle added a comment - If we remove tables from the picture, the issue disappears as well.
        Hide
        Andreas L. Delmelle added a comment -

        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++; }

        ...

        Show
        Andreas L. Delmelle added a comment - 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++; } ...
        Hide
        Andreas L. Delmelle added a comment -

        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).

        Show
        Andreas L. Delmelle added a comment - 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).
        Hide
        Andreas L. Delmelle added a comment -

        (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!

        Show
        Andreas L. Delmelle added a comment - (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!
        Hide
        Glenn Adams added a comment -

        batch transition pre-FOP1.0 resolved+fixed bugs to closed+fixed

        Show
        Glenn Adams added a comment - batch transition pre-FOP1.0 resolved+fixed bugs to closed+fixed

          People

          • Assignee:
            fop-dev
            Reporter:
            Chris Bowditch
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development