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

Reply via email to