[ https://issues.apache.org/jira/browse/FOP-2060?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14574810#comment-14574810 ]
Andreas L. Delmelle edited comment on FOP-2060 at 6/5/15 4:54 PM: ------------------------------------------------------------------ FWIW -- I agree with that line of thinking. The original issue, as reported, concerns a successive break-after and break-before. The diagnosis at that time was: there is an extra sequence of one empty box that serves no purpose or should not be there. Correct, but instead of removing it, the better solution would probably have been to prevent it from getting added to begin with. Investigate BlockLM.getNextKE(), which for the outer block in the initial example in the description is called 5 times. Each time means it is called by FlowLM, so implies a return to the PageBreaker... The layout engine processes all bits in between two forced breaks, if you will, so the solution is to avoid that empty bit, erroneously assumed to be 'in between' the break-after of the second and break-before of the third block, from being processed and triggering a return to the PageBreaker. Given the following sample (= the initial example, but with ids): {code:language=xml} <fo:block id="outer"> <fo:block id="inner-one">page 1</fo:block> <fo:block id="inner-two" break-before="page" break-after="page">page 2</fo:block> <fo:block id="inner-three" break-before="page" break-after="page">page 3</fo:block> <fo:block id="inner-four">page 4</fo:block> </fo:block> {code} The following sequence of BlockLM.getNextKE() calls is the result: {code} 1. id="outer" 2. id="inner-one" 3. id="inner-two" 4. id="outer" (re-entry after break-before) 5. id="inner-two" 6. id="outer" (re-entry after break-after) 7. id="inner-three" 8. id="outer" (re-entry after break-before) 9. id="inner-three" 10. id="outer" (re-entry after break-after) 11. id="inner-four" {code} The appropriate solution would be to avoid at least call 8. from ever occurring. was (Author: adelmelle): FWIW -- I agree with that line of thinking. The original issue, as reported, concerns a successive break-after and break-before. The diagnosis at that time was: there is an extra sequence of one empty box that serves no purpose or should not be there. Correct, but instead of removing it, the better solution would probably have been to prevent it from getting added to begin with. Investigate BlockLM.getNextKE(), which for the outer block in the initial example in the description is called 5 times. Each time means it is called by FlowLM, so implies a return to the PageBreaker... The layout engine processes all bits in between two forced breaks, if you will, so the solution is to avoid that empty bit, erroneously assumed to be 'in between' the break-after of the second and break-before of the third block, from being processed and triggering a return to the PageBreaker. Given the following sample (= the initial example, but with ids): {code:language=xml} <fo:block id="outer"> <fo:block id="inner-one">page 1</fo:block> <fo:block id="inner-two" break-before="page" break-after="page">page 2</fo:block> <fo:block id="inner-three" break-before="page" break-after="page">page 3</fo:block> <fo:block id="inner-four">page 4</fo:block> </fo:block> {code} The following sequence of BlockLM.getNextKE() calls is the result: {code} 1. id="outer" 2. id="inner-one" 3. id="inner-two" 4. id="outer" (re-entry after break-before) 5. id="inner-two" 6. id="outer" (re-entry after break-after) 7. id="inner-three" 8. id="outer" (re-entry after break-before) 9. id="inner-three" 10. id="outer (re-entry after break-after) 11. id="inner-four" {code} The appropriate solution would be to avoid at least call 8. from ever occurring. > adjoining blocks with break-before="page" break-after="page" cause extra > empty page > ----------------------------------------------------------------------------------- > > Key: FOP-2060 > URL: https://issues.apache.org/jira/browse/FOP-2060 > Project: FOP > Issue Type: Bug > Components: layout/unqualified > Affects Versions: trunk > Environment: Operating System: All > Platform: All > Reporter: Luis Bernardo > Fix For: trunk > > Attachments: 2060-empty-block-issue.xml, test.fo, test.pdf > > > This causes five pages instead of four: > <fo:block> > <fo:block>page 1</fo:block> > <fo:block break-before="page" break-after="page">page 2</fo:block> > <fo:block break-before="page" break-after="page">page 3</fo:block> > <fo:block>page 4</fo:block> > </fo:block> > The empty extra page happens between page 2 and page 3. -- This message was sent by Atlassian JIRA (v6.3.4#6332)