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:
      46240

      Description

      Attached you will find a small fo-file containing one simple page master and two pages. Although the page master has a column-count=2, both pages should be single-column, therefore span=all is used. Both pages should start at an odd page, therefore break-before=odd-page is used.

      The unexpected result: The text on the first page uses both columns, the second page is empty, but the text on the third page uses only one column. When I remove the first page or break-before, the second text uses both columns.

      1. publication.fo
        1 kB
        Georg Datterl

        Activity

        Georg Datterl created issue -
        Hide
        Georg Datterl added a comment -

        Attachment publication.fo has been added with description: Test case

        Show
        Georg Datterl added a comment - Attachment publication.fo has been added with description: Test case
        Hide
        Andreas L. Delmelle added a comment -

        Doing a bit of preliminary debugging, the problem seems to be that (see FlowLM.getNextKnuthElements()):

        a) the span change is detected (FlowLM.currentSpan == EN_ALL), so the returnList is handed over to the PageBreaker
        b) the next time it is called, currentSpan will already be EN_ALL, so no span change, but ... AbstractBreaker.getNextBlockList() will have explicitly reset the LayoutContext a bit earlier on (signalSpanChange(NOT_SET)), so the processing continues as if no span had been specified

        Show
        Andreas L. Delmelle added a comment - Doing a bit of preliminary debugging, the problem seems to be that (see FlowLM.getNextKnuthElements()): a) the span change is detected (FlowLM.currentSpan == EN_ALL), so the returnList is handed over to the PageBreaker b) the next time it is called, currentSpan will already be EN_ALL, so no span change, but ... AbstractBreaker.getNextBlockList() will have explicitly reset the LayoutContext a bit earlier on (signalSpanChange(NOT_SET)), so the processing continues as if no span had been specified
        Hide
        Andreas L. Delmelle added a comment -

        Fixed in FOP trunk, see r719110.

        Thanks for reporting!

        Show
        Andreas L. Delmelle added a comment - Fixed in FOP trunk, see r719110. 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:
            Georg Datterl
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development