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