Fop
  1. Fop
  2. FOP-1223

Invalid extra page break creates an undesired empty page

    Details

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

      Description

      When there is an <fo:block break-after="page"/> and nothing after it in the
      flow, a new page is still created, whereas section 7.19.1 of the recommendation
      states that it should be the case only if there is material to typeset
      afterwards. See the attached fo sample.
      The result is the same if we replace break-after by break-before.
      Same result also if we remove the indenting such that all the closing tags after
      the block are sticked together, so this is not a whitespace handling issue.

      I guess that a Knuth penalty of value -infinity is generated for such a block,
      and this doesn't play well with the (infinite glue, -infinite penalty) pair
      which is probably added at the end of the page sequence. The penalty should
      probably be only generated if there is also some box after it, and before the
      ending pair.

      If nobody takes this bug I'll have a look at it after the GSoC.

      1. break-after.fo
        0.6 kB
        Vincent Hennebert
      2. block_break-after_nested.xml
        2 kB
        Vincent Hennebert

        Activity

        Hide
        Glenn Adams added a comment -

        resetting P2 open bugs to P3 pending further review

        Show
        Glenn Adams added a comment - resetting P2 open bugs to P3 pending further review
        Hide
        Vincent Hennebert added a comment -

        It (In reply to comment #6)
        > vincent, should this stay open, or is it waiting for an assignment to a dev to
        > fix?

        It still needs to be fixed.

        Show
        Vincent Hennebert added a comment - It (In reply to comment #6) > vincent, should this stay open, or is it waiting for an assignment to a dev to > fix? It still needs to be fixed.
        Hide
        Glenn Adams added a comment -

        vincent, should this stay open, or is it waiting for an assignment to a dev to fix?

        Show
        Glenn Adams added a comment - vincent, should this stay open, or is it waiting for an assignment to a dev to fix?
        Hide
        Vincent Hennebert added a comment -

        Attachment block_break-after_nested.xml has been added with description: Testcase showing the regression

        Show
        Vincent Hennebert added a comment - Attachment block_break-after_nested.xml has been added with description: Testcase showing the regression
        Hide
        Vincent Hennebert added a comment -

        (In reply to comment #3)
        > Should be fixed by:
        > http://svn.apache.org/viewvc?rev=598558&view=rev

        This change introduces a regression: if a block has break-after="odd-page" and a child block that has break-after="page", the following content will be on the next page instead of the next odd page. See upcoming attachment.

        Show
        Vincent Hennebert added a comment - (In reply to comment #3) > Should be fixed by: > http://svn.apache.org/viewvc?rev=598558&view=rev This change introduces a regression: if a block has break-after="odd-page" and a child block that has break-after="page", the following content will be on the next page instead of the next odd page. See upcoming attachment.
        Hide
        Jeremias Maerki added a comment -
        Show
        Jeremias Maerki added a comment - Should be fixed by: http://svn.apache.org/viewvc?rev=598558&view=rev
        Hide
        Andreas L. Delmelle added a comment -

        (Here I go again )
        I think this could be handled before layout even kicks off...

        FOTreeBuilder could keep track of whether the currentFObj has area-generating content --shouldn't
        prove too hard to come up with a set of conditions that have to be satisfied.
        I'm thinking much in the same direction as the 'inMarker' instance member I recently added to
        FOEventHandler: a switch that is updated in the start- or endElement() event for each FObj. If it does
        not have any content, and the currentPropertyList contains a break-before/break-after property,
        instruct the current or the previous FO to discard that property (maybe log a warning, because it's not
        incorrect to specify it)
        Maybe we'd have to add a reference to the previousFObj/previousPropertyList to FOTreeBuilder as well,
        but that would be a small price to pay, and may open up perspectives in other areas.

        Sorry if I keep nagging about these 'normalizations' in the FOTree... :/

        I guess my underlying goal is: whatever layoutengine/renderer combination processes our FOTree, we
        should try to offer it a representation of the tree that would be difficult to 'misrender'.

        Show
        Andreas L. Delmelle added a comment - (Here I go again ) I think this could be handled before layout even kicks off... FOTreeBuilder could keep track of whether the currentFObj has area-generating content --shouldn't prove too hard to come up with a set of conditions that have to be satisfied. I'm thinking much in the same direction as the 'inMarker' instance member I recently added to FOEventHandler: a switch that is updated in the start- or endElement() event for each FObj. If it does not have any content, and the currentPropertyList contains a break-before/break-after property, instruct the current or the previous FO to discard that property (maybe log a warning, because it's not incorrect to specify it) Maybe we'd have to add a reference to the previousFObj/previousPropertyList to FOTreeBuilder as well, but that would be a small price to pay, and may open up perspectives in other areas. Sorry if I keep nagging about these 'normalizations' in the FOTree... :/ I guess my underlying goal is: whatever layoutengine/renderer combination processes our FOTree, we should try to offer it a representation of the tree that would be difficult to 'misrender'.
        Hide
        Vincent Hennebert added a comment -

        Attachment break-after.fo has been added with description: Sample file demonstrating the problem

        Show
        Vincent Hennebert added a comment - Attachment break-after.fo has been added with description: Sample file demonstrating the problem

          People

          • Assignee:
            Unassigned
            Reporter:
            Vincent Hennebert
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:

              Development