[jira] [Comment Edited] (FOP-2060) adjoining blocks with break-before="page" break-after="page" cause extra empty page
[ https://issues.apache.org/jira/browse/FOP-2060?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14575394#comment-14575394 ] Andreas L. Delmelle edited comment on FOP-2060 at 6/5/15 11:53 PM: --- There is indeed nothing about "generating an empty area before jumping to the next page" in XSL 1.1, but that is not what is happening there either, I think. It is also not the same thing as blank-or-not-blank, which does not apply to either case mentioned here. What may be confusing is that the second page in Matthias' example is not really "empty". It does have content, namely one "empty" normal block area. True, you can indeed not start a document with an empty page by one such block, since the break condition is immediately satisfied by the empty block area being the first in the page area. On the other hand, two consecutive ones would do that job nicely, if I understand correctly. The last example... It depends on what comes before and after that block. The single "empty" normal block area would always end up on its own page, and that page would not be "empty". Perhaps _that_ was a bit unclear before. EDIT - It all makes perfect sense once you factor in borders and/or padding. It's not because they are zero that the holder, the area is not there... If they are non-zero, the fact that the page is not really empty just becomes more visible. All that said, the originally reported issue *was* definitely valid *and* resolved by the fix. was (Author: adelmelle): There is indeed nothing about "generating an empty area before jumping to the next page" in XSL 1.1, but that is not what is happening there either, I think. It is also not the same thing as blank-or-not-blank, which does not apply to either case mentioned here. What may be confusing is that the second page in Matthias' example is not really "empty". It does have content, namely one "empty" normal block area. True, you can indeed not start a document with an empty page by one such block, since the break condition is immediately satisfied by the empty block area being the first in the page area. On the other hand, two consecutive ones would do that job nicely, if I understand correctly. The last example... It depends on what comes before and after that block. The single "empty" normal block area would always end up on its own page, and that page would not be "empty". Perhaps _that_ was a bit unclear before. All that said, the originally reported issue *was* definitely valid *and* resolved by the fix. > 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: > > page 1 > page 2 > page 3 > page 4 > > The empty extra page happens between page 2 and page 3. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (FOP-2060) adjoining blocks with break-before="page" break-after="page" cause extra empty page
[ https://issues.apache.org/jira/browse/FOP-2060?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14575394#comment-14575394 ] Andreas L. Delmelle commented on FOP-2060: -- There is indeed nothing about "generating an empty area before jumping to the next page" in XSL 1.1, but that is not what is happening there either, I think. It is also not the same thing as blank-or-not-blank, which does not apply to either case mentioned here. What may be confusing is that the second page in Matthias' example is not really "empty". It does have content, namely one "empty" normal block area. True, you can indeed not start a document with an empty page by one such block, since the break condition is immediately satisfied by the empty block area being the first in the page area. On the other hand, two consecutive ones would do that job nicely, if I understand correctly. The last example... It depends on what comes before and after that block. The single "empty" normal block area would always end up on its own page, and that page would not be "empty". Perhaps _that_ was a bit unclear before. All that said, the originally reported issue *was* definitely valid *and* resolved by the fix. > 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: > > page 1 > page 2 > page 3 > page 4 > > The empty extra page happens between page 2 and page 3. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (FOP-2060) adjoining blocks with break-before="page" break-after="page" cause extra empty page
[ https://issues.apache.org/jira/browse/FOP-2060?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14575384#comment-14575384 ] Luis Bernardo commented on FOP-2060: I still stand by my comment. The statement from the page I provided is the following: There is nothing in the XSL 1.1 Recommendation that has an fo:block generating an empty area before jumping to the next page. It doesn't say anything about nested blocks. I think it is more general than that. For me it makes sense because in general, for the situations where you want an empty page, you can use the blank-or-not-blank property. Similarly, you cannot start a document with an empty page by starting the document with a: Also, the following should not add an empty page: > 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: > > page 1 > page 2 > page 3 > page 4 > > The empty extra page happens between page 2 and page 3. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Issue Comment Deleted] (FOP-2060) adjoining blocks with break-before="page" break-after="page" cause extra empty page
[ https://issues.apache.org/jira/browse/FOP-2060?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matthias Reischenbacher updated FOP-2060: - Comment: was deleted (was: Hm, could be. But are you sure? Before your change the output was 3 pages. From what I understand about https://www.w3.org/Bugs/Public/show_bug.cgi?id=6276 it clarifies mainly breaks when nesting blocks. I also agree that your test case should produce a 4 page output. But two sibling blocks, like in my case: Shouldn't that generate two page breaks? Btw: I tested with AntennaHouse and my test cases produced a 3 page output.) > 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: > > page 1 > page 2 > page 3 > page 4 > > The empty extra page happens between page 2 and page 3. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (FOP-2060) adjoining blocks with break-before="page" break-after="page" cause extra empty page
[ https://issues.apache.org/jira/browse/FOP-2060?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14575352#comment-14575352 ] Matthias Reischenbacher commented on FOP-2060: -- Hm, could be. But are you sure? Before your change the output was 3 pages. From what I understand about https://www.w3.org/Bugs/Public/show_bug.cgi?id=6276 it clarifies mainly breaks when nesting blocks. I also agree that your test case should produce a 4 page output. But two sibling blocks, like in my case: Shouldn't that generate two page breaks? Btw: I tested with AntennaHouse and my test cases produced a 3 page output. > 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: > > page 1 > page 2 > page 3 > page 4 > > The empty extra page happens between page 2 and page 3. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (FOP-2060) adjoining blocks with break-before="page" break-after="page" cause extra empty page
[ https://issues.apache.org/jira/browse/FOP-2060?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14575351#comment-14575351 ] Matthias Reischenbacher commented on FOP-2060: -- Hm, could be. But are you sure? Before your change the output was 3 pages. From what I understand about https://www.w3.org/Bugs/Public/show_bug.cgi?id=6276 it clarifies mainly breaks when nesting blocks. I also agree that your test case should produce a 4 page output. But two sibling blocks, like in my case: Shouldn't that generate two page breaks? Btw: I tested with AntennaHouse and my test cases produced a 3 page output. > 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: > > page 1 > page 2 > page 3 > page 4 > > The empty extra page happens between page 2 and page 3. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (FOP-2060) adjoining blocks with break-before="page" break-after="page" cause extra empty page
[ https://issues.apache.org/jira/browse/FOP-2060?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14575346#comment-14575346 ] Andreas L. Delmelle commented on FOP-2060: -- Hmm, I think the expectation of 3 is correct. The empty middle block still generates one normal block area, which happens to have no descendant line areas. That block area shifts to the next page due to the specified break-before. The next block's first area then, cannot be the first area on that same page. So, in order to satisfy that second break-before, there *has* to be an empty second page. It is definitely not the same situation that is mentioned in the bug at w3.org, since that seems to concern cases of nesting. Now, if the empty block had both break-before and break-after specified, then the next block's break-before would be suppressed. In that case, there should not be 2 empty pages. I would say that, yes, the fix stands as in 'fixes the original issue'. It just had an unintended side effect that was not covered by the layout engine tests, so nothing that could have alerted anyone. No harm done. > 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: > > page 1 > page 2 > page 3 > page 4 > > The empty extra page happens between page 2 and page 3. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (FOP-2060) adjoining blocks with break-before="page" break-after="page" cause extra empty page
[ https://issues.apache.org/jira/browse/FOP-2060?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14575267#comment-14575267 ] Andreas L. Delmelle edited comment on FOP-2060 at 6/5/15 9:53 PM: -- Actually, I was thinking the very same thing about using that flag in the LC to pass the information. Since a similar 'difficulty' (related to having to explicitly having to copy that flag) was also reported in the context of FOP-2469, what I think definitely needs a closer look, is all the points where a new LC is created, and make sure they are all aligned. I would expect said flag to be copied, for example, if you use LC.copyOf(), which appears to be the case. So, where that method is used to instantiate a child LC, it _should_ be OK (note: just theory here; haven't checked). There are two other methods to create LCs, where either no base context is passed (= newInstance()) or the passed context is largely ignored, save for one boolean flag (= offspringOf())... If a full copy would be wasteful or undesirable in some cases, perhaps we should have a method similar to copyPendingMarksFrom(), for copying the flags from a base context. Something like that? EDIT - Looking a bit closer at the usage of newInstance() vs. copyOf() shows 19 vs. 6... Makes one wonder whether it is really required and such a good idea to disperse all that LC init logic across the different LMs. Definitely needs a closer look. was (Author: adelmelle): Actually, I was thinking the very same thing about using that flag in the LC to pass the information. Since a similar 'difficulty' (related to having to explicitly having to copy that flag) was also reported in the context of FOP-2469, what I think definitely needs a closer look, is all the points where a new LC is created, and make sure they are all aligned. I would expect said flag to be copied, for example, if you use LC.copyOf(), which appears to be the case. So, where that method is used to instantiate a child LC, it _should_ be OK (note: just theory here; haven't checked). There are two other methods to create LCs, where either no base context is passed (= newInstance()) or the passed context is largely ignored, save for one boolean flag (= offspringOf())... If a full copy would be wasteful or undesirable in some cases, perhaps we should have a method similar to copyPendingMarksFrom(), for copying the flags from a base context. Something like that? > 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: > > page 1 > page 2 > page 3 > page 4 > > The empty extra page happens between page 2 and page 3. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (FOP-2060) adjoining blocks with break-before="page" break-after="page" cause extra empty page
[ https://issues.apache.org/jira/browse/FOP-2060?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14575276#comment-14575276 ] Luis Bernardo commented on FOP-2060: Not adding the empty box in the first place is a good thing. I didn't do it because removing it later seemed simpler to implement. But I am confused about the relevance of the 2060-empty-block-issue.xml example... The correct output should be 2 pages, not 3, so I think the fix stands. Comments? > 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: > > page 1 > page 2 > page 3 > page 4 > > The empty extra page happens between page 2 and page 3. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (FOP-2060) adjoining blocks with break-before="page" break-after="page" cause extra empty page
[ https://issues.apache.org/jira/browse/FOP-2060?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14575267#comment-14575267 ] Andreas L. Delmelle commented on FOP-2060: -- Actually, I was thinking the very same thing about using that flag in the LC to pass the information. Since a similar 'difficulty' (related to having to explicitly having to copy that flag) was also reported in the context of FOP-2469, what I think definitely needs a closer look, is all the points where a new LC is created, and make sure they are all aligned. I would expect said flag to be copied, for example, if you use LC.copyOf(), which appears to be the case. So, where that method is used to instantiate a child LC, it _should_ be OK (note: just theory here; haven't checked). There are two other methods to create LCs, where either no base context is passed (= newInstance()) or the passed context is largely ignored, save for one boolean flag (= offspringOf())... If a full copy would be wasteful or undesirable in some cases, perhaps we should have a method similar to copyPendingMarksFrom(), for copying the flags from a base context. Something like that? > 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: > > page 1 > page 2 > page 3 > page 4 > > The empty extra page happens between page 2 and page 3. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (FOP-2060) adjoining blocks with break-before="page" break-after="page" cause extra empty page
[ https://issues.apache.org/jira/browse/FOP-2060?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14575232#comment-14575232 ] Matthias Reischenbacher commented on FOP-2060: -- Andreas: I played around with the SUPPRESS_BREAK_BEFORE flag of the LayoutContext in order to avoid the break-before of the third block being processed. I check inside the AbstractBreaker if the last element list terminates with a forced break and if it does, I set the SUPPRESS_BREAK_BEFORE flag to true. What makes me doubt, if this is a valid approach, is that I have to take care that the flag is copied to all the LayoutContexts of the child LMs. What do you think? > 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: > > page 1 > page 2 > page 3 > page 4 > > The empty extra page happens between page 2 and page 3. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (FOP-2060) adjoining blocks with break-before="page" break-after="page" cause extra empty page
[
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}
page 1
page
2
page
3
page 4
{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}
page 1
page
2
page
3
page 4
{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:
>
> page 1
> page 2
> page 3
> page 4
>
> The empty extra page happens between page 2 and page 3.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (FOP-2060) adjoining blocks with break-before="page" break-after="page" cause extra empty page
[
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}
page 1
page
2
page
3
page 4
{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}
page 1
page
2
page
3
page 4
{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:
>
> page 1
> page 2
> page 3
> page 4
>
> The empty extra page happens between page 2 and page 3.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (FOP-2060) adjoining blocks with break-before="page" break-after="page" cause extra empty page
[
https://issues.apache.org/jira/browse/FOP-2060?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14574810#comment-14574810
]
Andreas L. Delmelle commented on FOP-2060:
--
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}
page 1
page
2
page
3
page 4
{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:
>
> page 1
> page 2
> page 3
> page 4
>
> The empty extra page happens between page 2 and page 3.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Closed] (FOP-2474) [PATCH] AFP Logical element tag incorrect character encoding
[ https://issues.apache.org/jira/browse/FOP-2474?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] simon steiner closed FOP-2474. -- Resolution: Fixed > [PATCH] AFP Logical element tag incorrect character encoding > > > Key: FOP-2474 > URL: https://issues.apache.org/jira/browse/FOP-2474 > Project: FOP > Issue Type: Bug >Affects Versions: trunk >Reporter: Thanasis Giannimaras > Attachments: test.fo, tleEncoding.patch, trunk.afp, trunkFix.afp > > > The dollar sign in the attribute value of the Tag Logical Element Structure, > is not being displayed correctly (the "cent sign" is being showed instead). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (FOP-2474) [PATCH] AFP Logical element tag incorrect character encoding
[ https://issues.apache.org/jira/browse/FOP-2474?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14574549#comment-14574549 ] simon steiner commented on FOP-2474: http://svn.apache.org/viewvc?view=revision&revision=1683762 > [PATCH] AFP Logical element tag incorrect character encoding > > > Key: FOP-2474 > URL: https://issues.apache.org/jira/browse/FOP-2474 > Project: FOP > Issue Type: Bug >Affects Versions: trunk >Reporter: Thanasis Giannimaras > Attachments: test.fo, tleEncoding.patch, trunk.afp, trunkFix.afp > > > The dollar sign in the attribute value of the Tag Logical Element Structure, > is not being displayed correctly (the "cent sign" is being showed instead). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Issue Comment Deleted] (FOP-2474) [PATCH] AFP Logical element tag incorrect character encoding
[ https://issues.apache.org/jira/browse/FOP-2474?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] simon steiner updated FOP-2474: --- Comment: was deleted (was: http://svn.apache.org/viewvc?view=revision&revision=1683760) > [PATCH] AFP Logical element tag incorrect character encoding > > > Key: FOP-2474 > URL: https://issues.apache.org/jira/browse/FOP-2474 > Project: FOP > Issue Type: Bug >Affects Versions: trunk >Reporter: Thanasis Giannimaras > Attachments: test.fo, tleEncoding.patch, trunk.afp, trunkFix.afp > > > The dollar sign in the attribute value of the Tag Logical Element Structure, > is not being displayed correctly (the "cent sign" is being showed instead). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (FOP-2475) [PATCH] Tagged PDF footnote separator incorrect order
[ https://issues.apache.org/jira/browse/FOP-2475?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] simon steiner closed FOP-2475. -- Resolution: Fixed > [PATCH] Tagged PDF footnote separator incorrect order > -- > > Key: FOP-2475 > URL: https://issues.apache.org/jira/browse/FOP-2475 > Project: FOP > Issue Type: Bug >Affects Versions: trunk >Reporter: Thanasis Giannimaras > Attachments: after.pdf, before.pdf, footSep.patch, fop.xconf, test.fo > > > For most cases footnote separator is being treated as an artifact so this is > a non issue. But in cases where you have text working as footnote separator > and not being labelled as an artifact, then the read out loud function > (acrobat reader) reads it in the wrong order. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (FOP-2475) [PATCH] Tagged PDF footnote separator incorrect order
[ https://issues.apache.org/jira/browse/FOP-2475?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14574541#comment-14574541 ] simon steiner commented on FOP-2475: http://svn.apache.org/viewvc?view=revision&revision=1683760 > [PATCH] Tagged PDF footnote separator incorrect order > -- > > Key: FOP-2475 > URL: https://issues.apache.org/jira/browse/FOP-2475 > Project: FOP > Issue Type: Bug >Affects Versions: trunk >Reporter: Thanasis Giannimaras > Attachments: after.pdf, before.pdf, footSep.patch, fop.xconf, test.fo > > > For most cases footnote separator is being treated as an artifact so this is > a non issue. But in cases where you have text working as footnote separator > and not being labelled as an artifact, then the read out loud function > (acrobat reader) reads it in the wrong order. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (FOP-2474) [PATCH] AFP Logical element tag incorrect character encoding
[ https://issues.apache.org/jira/browse/FOP-2474?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14574540#comment-14574540 ] simon steiner commented on FOP-2474: http://svn.apache.org/viewvc?view=revision&revision=1683760 > [PATCH] AFP Logical element tag incorrect character encoding > > > Key: FOP-2474 > URL: https://issues.apache.org/jira/browse/FOP-2474 > Project: FOP > Issue Type: Bug >Affects Versions: trunk >Reporter: Thanasis Giannimaras > Attachments: test.fo, tleEncoding.patch, trunk.afp, trunkFix.afp > > > The dollar sign in the attribute value of the Tag Logical Element Structure, > is not being displayed correctly (the "cent sign" is being showed instead). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (FOP-2060) adjoining blocks with break-before="page" break-after="page" cause extra empty page
[ https://issues.apache.org/jira/browse/FOP-2060?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matthias Reischenbacher updated FOP-2060: - Attachment: 2060-empty-block-issue.xml The attached file produces a 2-page output with the change of this ticket. Previously it was a 3-page-output. Perhaps it would be better to avoid adding the auxiliary positions in the first place, instead of removing them in the AbstractBreaker. Do want me to have a look in this direction, Luis? Or can you? > 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: > > page 1 > page 2 > page 3 > page 4 > > The empty extra page happens between page 2 and page 3. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (FOP-2476) [PATCH] Tagged pdf: Tags are showing in the wrong order in the acrobat's pro order panel
[ https://issues.apache.org/jira/browse/FOP-2476?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] simon steiner closed FOP-2476. -- Resolution: Fixed > [PATCH] Tagged pdf: Tags are showing in the wrong order in the acrobat's pro > order panel > > > Key: FOP-2476 > URL: https://issues.apache.org/jira/browse/FOP-2476 > Project: FOP > Issue Type: Bug >Affects Versions: trunk >Reporter: Thanasis Giannimaras > Attachments: after.pdf, before.pdf, fop.xconf, svnregionorder.patch, > test.fo > > > If you open before.pdf using acrobat pro, you can see tha the order that the > tags appear in the order panel ( view-> navigational panel -->order or > Advanced -->accessibility --> TouchUp reading order) is incorrect, which > creates issues with 508 compliance (section 3.2 > http://www.hhs.gov/web/508/accessiblefiles/checklistpdf.html) . That is > happening because of the order that content appears in the pdf content > stream! By changing the order that the regions are rendered in > AbstractRenderer this can be easily fixed. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (FOP-2476) [PATCH] Tagged pdf: Tags are showing in the wrong order in the acrobat's pro order panel
[ https://issues.apache.org/jira/browse/FOP-2476?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14574521#comment-14574521 ] simon steiner commented on FOP-2476: http://svn.apache.org/viewvc?view=revision&revision=1683758 > [PATCH] Tagged pdf: Tags are showing in the wrong order in the acrobat's pro > order panel > > > Key: FOP-2476 > URL: https://issues.apache.org/jira/browse/FOP-2476 > Project: FOP > Issue Type: Bug >Affects Versions: trunk >Reporter: Thanasis Giannimaras > Attachments: after.pdf, before.pdf, fop.xconf, svnregionorder.patch, > test.fo > > > If you open before.pdf using acrobat pro, you can see tha the order that the > tags appear in the order panel ( view-> navigational panel -->order or > Advanced -->accessibility --> TouchUp reading order) is incorrect, which > creates issues with 508 compliance (section 3.2 > http://www.hhs.gov/web/508/accessiblefiles/checklistpdf.html) . That is > happening because of the order that content appears in the pdf content > stream! By changing the order that the regions are rendered in > AbstractRenderer this can be easily fixed. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (FOP-2476) [PATCH] Tagged pdf: Tags are showing in the wrong order in the acrobat's pro order panel
[ https://issues.apache.org/jira/browse/FOP-2476?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] simon steiner updated FOP-2476: --- Summary: [PATCH] Tagged pdf: Tags are showing in the wrong order in the acrobat's pro order panel (was: [PATCH] Tagged pdf: Tags are showing inthe wrong order in the acrobat's pro order panel) > [PATCH] Tagged pdf: Tags are showing in the wrong order in the acrobat's pro > order panel > > > Key: FOP-2476 > URL: https://issues.apache.org/jira/browse/FOP-2476 > Project: FOP > Issue Type: Bug >Affects Versions: trunk >Reporter: Thanasis Giannimaras > Attachments: after.pdf, before.pdf, fop.xconf, svnregionorder.patch, > test.fo > > > If you open before.pdf using acrobat pro, you can see tha the order that the > tags appear in the order panel ( view-> navigational panel -->order or > Advanced -->accessibility --> TouchUp reading order) is incorrect, which > creates issues with 508 compliance (section 3.2 > http://www.hhs.gov/web/508/accessiblefiles/checklistpdf.html) . That is > happening because of the order that content appears in the pdf content > stream! By changing the order that the regions are rendered in > AbstractRenderer this can be easily fixed. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (FOP-2482) Read out loud not working with 256 bit encryption and accessibility
[ https://issues.apache.org/jira/browse/FOP-2482?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14574454#comment-14574454 ] simon steiner commented on FOP-2482: http://svn.apache.org/viewvc?view=revision&revision=1683746 > Read out loud not working with 256 bit encryption and accessibility > --- > > Key: FOP-2482 > URL: https://issues.apache.org/jira/browse/FOP-2482 > Project: FOP > Issue Type: Bug >Reporter: simon steiner > Attachments: fop.xconf, test.fo > > > Read out loud in adobe reader wont say text -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (FOP-2482) Read out loud not working with 256 bit encryption and accessibility
[ https://issues.apache.org/jira/browse/FOP-2482?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] simon steiner closed FOP-2482. -- Resolution: Fixed > Read out loud not working with 256 bit encryption and accessibility > --- > > Key: FOP-2482 > URL: https://issues.apache.org/jira/browse/FOP-2482 > Project: FOP > Issue Type: Bug >Reporter: simon steiner > Attachments: fop.xconf, test.fo > > > Read out loud in adobe reader wont say text -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (FOP-2482) Read out loud not working with 256 bit encryption and accessibility
simon steiner created FOP-2482: -- Summary: Read out loud not working with 256 bit encryption and accessibility Key: FOP-2482 URL: https://issues.apache.org/jira/browse/FOP-2482 Project: FOP Issue Type: Bug Reporter: simon steiner Read out loud in adobe reader wont say text -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (FOP-2482) Read out loud not working with 256 bit encryption and accessibility
[ https://issues.apache.org/jira/browse/FOP-2482?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] simon steiner updated FOP-2482: --- Attachment: test.fo fop.xconf > Read out loud not working with 256 bit encryption and accessibility > --- > > Key: FOP-2482 > URL: https://issues.apache.org/jira/browse/FOP-2482 > Project: FOP > Issue Type: Bug >Reporter: simon steiner > Attachments: fop.xconf, test.fo > > > Read out loud in adobe reader wont say text -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (FOP-2481) AssertionError at BalancingColumnBreakingAlgorithm.getInitialBreaks
[ https://issues.apache.org/jira/browse/FOP-2481?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] simon steiner updated FOP-2481: --- Summary: AssertionError at BalancingColumnBreakingAlgorithm.getInitialBreaks (was: AssertionError at BalancingColumnBreakingAlgorithm.getInitialBreaks) > AssertionError at BalancingColumnBreakingAlgorithm.getInitialBreaks > --- > > Key: FOP-2481 > URL: https://issues.apache.org/jira/browse/FOP-2481 > Project: FOP > Issue Type: Bug >Reporter: simon steiner > Attachments: exception.fo > > > AssertionError > at > org.apache.fop.layoutmgr.BalancingColumnBreakingAlgorithm.getInitialBreaks(BalancingColumnBreakingAlgorithm.java:171) > export FOP_OPTS=-ea > fop exception.fo out.pdf -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (FOP-2481) AssertionError at BalancingColumnBreakingAlgorithm.getInitialBreaks
[ https://issues.apache.org/jira/browse/FOP-2481?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] simon steiner updated FOP-2481: --- Attachment: exception.fo > AssertionErrorat BalancingColumnBreakingAlgorithm.getInitialBreaks > > > Key: FOP-2481 > URL: https://issues.apache.org/jira/browse/FOP-2481 > Project: FOP > Issue Type: Bug >Reporter: simon steiner > Attachments: exception.fo > > > AssertionError > at > org.apache.fop.layoutmgr.BalancingColumnBreakingAlgorithm.getInitialBreaks(BalancingColumnBreakingAlgorithm.java:171) > export FOP_OPTS=-ea > fop exception.fo out.pdf -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (FOP-2481) AssertionError at BalancingColumnBreakingAlgorithm.getInitialBreaks
simon steiner created FOP-2481: -- Summary: AssertionErrorat BalancingColumnBreakingAlgorithm.getInitialBreaks Key: FOP-2481 URL: https://issues.apache.org/jira/browse/FOP-2481 Project: FOP Issue Type: Bug Reporter: simon steiner AssertionError at org.apache.fop.layoutmgr.BalancingColumnBreakingAlgorithm.getInitialBreaks(BalancingColumnBreakingAlgorithm.java:171) export FOP_OPTS=-ea fop exception.fo out.pdf -- This message was sent by Atlassian JIRA (v6.3.4#6332)
