You are viewing a plain text version of this content. The canonical link for it is here.
Posted to fop-users@xmlgraphics.apache.org by Georg Datterl <ge...@geneon.de> on 2009/02/20 15:47:47 UTC
span is influencing page breaking?
Hi everybody, especially Vincent.
Attached fo-file contains a red block which is printed on the first page, although there's not enough space left. If I remove the span="all" for the block, it is printed on the next page. Can you tell me why span="all" is influencing the page break here?
Regards,
Georg Datterl
------ Kontakt ------
Georg Datterl
Geneon media solutions gmbh
Gutenstetter Stra�e 8a
90449 N�rnberg
HRB N�rnberg: 17193
Gesch�ftsf�hrer: Yong-Harry Steiert
Tel.: 0911/36 78 88 - 26
Fax: 0911/36 78 88 - 20
www.geneon.de
Weitere Mitglieder der Willmy MediaGroup:
IRS Integrated Realization Services GmbH: www.irs-nbg.de
Willmy PrintMedia GmbH: www.willmy.de
Willmy Consult & Content GmbH: www.willmycc.de
Re: span is influencing page breaking?
Posted by Vincent Hennebert <vh...@gmail.com>.
Hi Georg,
Georg Datterl wrote:
> Hi Vincent,
>
> I thought of a workaround and found a new problem. Since the problem is caused by a span change, I inserted a new empty block with span="all" before the offending block. Voilá, table moves to the next page. Problem avoided.
That’s ‘Voilà’ :-P
Clever. The empty block generates a box of 0 length, which should
provide that too-short node I was talking about in my previous answer
(didn’t re-run a debug session to check though...).
> And then I decided to push my luck and see what happens, when I play with keeps...
>
> <fo:block >
> <fo:inline>Table headline</fo:inline>
> </fo:block>
> <fo:block span="all" background-color="blue" keep-with-next.within-page="always" keep-with-previous.within-page="always" />
> <fo:block span="all" background-color="red"> Here's my table...</fo:block>
>
> I'm not quite sure what I expected in this case, Most likely the table being moved back to the first page, less likely (but more preferable in my case) the table and the headline on the second page. Maybe your expectations are different.
That’s the latter: the table and the headline should both be moved to
the second page, since the table is unbreakable and doesn’t fit on the
first one.
> What I got was: The same picture as before. Headline on one page, table on the second page. Still no change when adding a span="all" to the headline:
>
> <fo:block span="all" >
> <fo:inline>Table headline</fo:inline>
> </fo:block>
> <fo:block span="all" background-color="blue" keep-with-next.within-page="always" keep-with-previous.within-page="always" />
> <fo:block span="all" background-color="red"> Here's my table...</fo:block>
You’re hitting the same bug again. Move the empty block before the
headline and that should work fine. Of course, if in your real-life
document you must actually keep the last block of the multi-column part
with the spanning table, then you’re stuck I’m afraid.
> Only when I added a span to the headline AND a new spanning block before the headline, I got what I wanted, headline and table on a new page:
>
> <fo:block span="all" />
> <fo:block span="all" >
> <fo:inline>Table headline</fo:inline>
> </fo:block>
> <fo:block span="all" background-color="blue" keep-with-next.within-page="always" keep-with-previous.within-page="always" />
> <fo:block span="all" background-color="red"> Here's my table...</fo:block>
The second empty block shouldn’t be necessary. Just put the keep on the
block containing the headline.
> If you expected this results, I'd be happy if you could give me an explanation, if you did not expect the results either, maybe they'll help you with the new logic or somebody else (or me, if I find a problem I can't navigate around) when fixing the bug.
A thing I’m not sure of is if keeps between a multi-column part and
a span have been implemented at all...
<snip/>
HTH,
Vincent
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
AW: span is influencing page breaking?
Posted by Georg Datterl <ge...@geneon.de>.
Hi Vincent,
I thought of a workaround and found a new problem. Since the problem is caused by a span change, I inserted a new empty block with span="all" before the offending block. Voilá, table moves to the next page. Problem avoided.
And then I decided to push my luck and see what happens, when I play with keeps...
<fo:block >
<fo:inline>Table headline</fo:inline>
</fo:block>
<fo:block span="all" background-color="blue" keep-with-next.within-page="always" keep-with-previous.within-page="always" />
<fo:block span="all" background-color="red"> Here's my table...</fo:block>
I'm not quite sure what I expected in this case, Most likely the table being moved back to the first page, less likely (but more preferable in my case) the table and the headline on the second page. Maybe your expectations are different.
What I got was: The same picture as before. Headline on one page, table on the second page. Still no change when adding a span="all" to the headline:
<fo:block span="all" >
<fo:inline>Table headline</fo:inline>
</fo:block>
<fo:block span="all" background-color="blue" keep-with-next.within-page="always" keep-with-previous.within-page="always" />
<fo:block span="all" background-color="red"> Here's my table...</fo:block>
Only when I added a span to the headline AND a new spanning block before the headline, I got what I wanted, headline and table on a new page:
<fo:block span="all" />
<fo:block span="all" >
<fo:inline>Table headline</fo:inline>
</fo:block>
<fo:block span="all" background-color="blue" keep-with-next.within-page="always" keep-with-previous.within-page="always" />
<fo:block span="all" background-color="red"> Here's my table...</fo:block>
If you expected this results, I'd be happy if you could give me an explanation, if you did not expect the results either, maybe they'll help you with the new logic or somebody else (or me, if I find a problem I can't navigate around) when fixing the bug.
Regards,
Georg Datterl
------ Kontakt ------
Georg Datterl
Geneon media solutions gmbh
Gutenstetter Straße 8a
90449 Nürnberg
HRB Nürnberg: 17193
Geschäftsführer: Yong-Harry Steiert
Tel.: 0911/36 78 88 - 26
Fax: 0911/36 78 88 - 20
www.geneon.de
Weitere Mitglieder der Willmy MediaGroup:
IRS Integrated Realization Services GmbH: www.irs-nbg.de
Willmy PrintMedia GmbH: www.willmy.de
Willmy Consult & Content GmbH: www.willmycc.de
-----Ursprüngliche Nachricht-----
Von: Vincent Hennebert [mailto:vhennebert@gmail.com]
Gesendet: Montag, 23. Februar 2009 18:08
An: fop-users@xmlgraphics.apache.org
Betreff: Re: span is influencing page breaking?
Hi Georg,
Georg Datterl wrote:
> Hi Vincent,
>
>> This is very probably another manifestation of bug #46322:
>> https://issues.apache.org/bugzilla/show_bug.cgi?id=46322
>> See discussion here:
>> http://mail-archives.apache.org/mod_mbox/xmlgraphics-fop-dev/200812.m
>> box/<49...@gmail.com>
>
> I remember. But back then I thought, that would only be a problem with one line.
>
>> The bug is triggered even if the previous blocks also span the whole
>> page. The fact that you didn't explicitly specify span="all" on the
>> previous block makes the code believe that there is a change in the
>> spanning, which triggers some special (and buggy) page break
>> handling.
>> You found the workaround already. Hopefully it doesn't upset your
>> whole tool chain. That's all I can say for now :-\
>
> No, I have not yet found the workaround. Only in the stripped example there's one column. Actually I get the problem in my two-column layout and there I can't remove the span="all".
>
> Can you think of a different workaround?
No, sorry,
> Can you guess when your new pagebreaking mechanism will be finished?
Not any time soon I'm afraid. I'm still at an experimental stage.
> Do you have a hint where I can find this special (and buggy) page break handling?
What happens more precisely is the following: at the first legal break, the adjustment ratio is -infinity, since there's not enough room on the page to make the table fit, and it can't be shrunk. So the breaking algorithm enters a recovery mode where it selects some fall back node, gathered earlier in the breaking process. Preferably a too-short one (which will result in an underfull page, but with no loss of content), otherwise a too-long one. In the present case there's no previous node (thus no too-short one) so the current too-long node is selected, and the breaking algorithm is restarted on the next page, trying to put the content of that too long node there.
To do that, the index into the sequence of Knuth element is reset to the value of the previous node + 1 (to simplify). However, in this situation the previous node is the first one, representing a virtual break before the content. And the index value for that node is 0, which is basically wrong but works in regular cases.
The problem is: naively setting it to -1 triggers an IndexOutOfBoundsException elsewhere, and even hacking the index modification at a place where it should work doesn't give the expected results. There seems to be another problem later in the process, when adding the areas.
I can't get more clue about what's going on without diving further into the code, which I don't have enough of free time for at the moment I'm afraid. You may want to give it a try based on the indications above; start from o.a.f.layoutmgr.BreakingAlgorithm.findBreakingPoints() and follow the method calls. But granted, this part of the code is very complicated.
Sorry,
Vincent
> Regards,
>
> Georg Datterl
>
> ------ Kontakt ------
>
> Georg Datterl
>
> Geneon media solutions gmbh
> Gutenstetter Straße 8a
> 90449 Nürnberg
>
> HRB Nürnberg: 17193
> Geschäftsführer: Yong-Harry Steiert
>
> Tel.: 0911/36 78 88 - 26
> Fax: 0911/36 78 88 - 20
>
> www.geneon.de
>
> Weitere Mitglieder der Willmy MediaGroup:
>
> IRS Integrated Realization Services GmbH: www.irs-nbg.de
> Willmy PrintMedia GmbH: www.willmy.de
> Willmy Consult & Content GmbH: www.willmycc.de
> -----Ursprüngliche Nachricht-----
> Von: Vincent Hennebert [mailto:vhennebert@gmail.com]
> Gesendet: Montag, 23. Februar 2009 12:39
> An: fop-users@xmlgraphics.apache.org
> Betreff: Re: span is influencing page breaking?
>
> Hi Georg,
>
> Georg Datterl wrote:
>> Hi everybody, especially Vincent.
>>
>> Attached fo-file contains a red block which is printed on the first page, although there's not enough space left. If I remove the span="all" for the block, it is printed on the next page. Can you tell me why span="all" is influencing the page break here?
>
> This is very probably another manifestation of bug #46322:
> https://issues.apache.org/bugzilla/show_bug.cgi?id=46322
>
> See discussion here:
> http://mail-archives.apache.org/mod_mbox/xmlgraphics-fop-dev/200812.mb
> ox/<49...@gmail.com>
>
> The bug is triggered even if the previous blocks also span the whole page. The fact that you didn't explicitly specify span="all" on the previous block makes the code believe that there is a change in the spanning, which triggers some special (and buggy) page break handling.
>
> You found the workaround already. Hopefully it doesn't upset your
> whole tool chain. That's all I can say for now :-\
>
>
> Vincent
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
Re: span is influencing page breaking?
Posted by Vincent Hennebert <vh...@gmail.com>.
Hi Georg,
Georg Datterl wrote:
> Hi Vincent,
>
>> This is very probably another manifestation of bug #46322:
>> https://issues.apache.org/bugzilla/show_bug.cgi?id=46322
>> See discussion here:
>> http://mail-archives.apache.org/mod_mbox/xmlgraphics-fop-dev/200812.mbox/<49...@gmail.com>
>
> I remember. But back then I thought, that would only be a problem with one line.
>
>> The bug is triggered even if the previous blocks also
>> span the whole page. The fact that you didn't explicitly
>> specify span="all" on the previous block makes the code
>> believe that there is a change in the spanning, which
>> triggers some special (and buggy) page break handling.
>> You found the workaround already. Hopefully it doesn't
>> upset your whole tool chain. That's all I can say for now :-\
>
> No, I have not yet found the workaround. Only in the stripped example there's one column. Actually I get the problem in my two-column layout and there I can't remove the span="all".
>
> Can you think of a different workaround?
No, sorry,
> Can you guess when your new pagebreaking mechanism will be finished?
Not any time soon I’m afraid. I’m still at an experimental stage.
> Do you have a hint where I can find this special (and buggy) page break handling?
What happens more precisely is the following: at the first legal break,
the adjustment ratio is -infinity, since there’s not enough room on the
page to make the table fit, and it can’t be shrunk. So the breaking
algorithm enters a recovery mode where it selects some fall back node,
gathered earlier in the breaking process. Preferably a too-short one
(which will result in an underfull page, but with no loss of content),
otherwise a too-long one. In the present case there’s no previous node
(thus no too-short one) so the current too-long node is selected, and
the breaking algorithm is restarted on the next page, trying to put the
content of that too long node there.
To do that, the index into the sequence of Knuth element is reset to the
value of the previous node + 1 (to simplify). However, in this situation
the previous node is the first one, representing a virtual break before
the content. And the index value for that node is 0, which is basically
wrong but works in regular cases.
The problem is: naively setting it to -1 triggers an
IndexOutOfBoundsException elsewhere, and even hacking the index
modification at a place where it should work doesn’t give the expected
results. There seems to be another problem later in the process, when
adding the areas.
I can’t get more clue about what’s going on without diving further into
the code, which I don’t have enough of free time for at the moment I’m
afraid. You may want to give it a try based on the indications above;
start from o.a.f.layoutmgr.BreakingAlgorithm.findBreakingPoints() and
follow the method calls. But granted, this part of the code is very
complicated.
Sorry,
Vincent
> Regards,
>
> Georg Datterl
>
> ------ Kontakt ------
>
> Georg Datterl
>
> Geneon media solutions gmbh
> Gutenstetter Straße 8a
> 90449 Nürnberg
>
> HRB Nürnberg: 17193
> Geschäftsführer: Yong-Harry Steiert
>
> Tel.: 0911/36 78 88 - 26
> Fax: 0911/36 78 88 - 20
>
> www.geneon.de
>
> Weitere Mitglieder der Willmy MediaGroup:
>
> IRS Integrated Realization Services GmbH: www.irs-nbg.de
> Willmy PrintMedia GmbH: www.willmy.de
> Willmy Consult & Content GmbH: www.willmycc.de
> -----Ursprüngliche Nachricht-----
> Von: Vincent Hennebert [mailto:vhennebert@gmail.com]
> Gesendet: Montag, 23. Februar 2009 12:39
> An: fop-users@xmlgraphics.apache.org
> Betreff: Re: span is influencing page breaking?
>
> Hi Georg,
>
> Georg Datterl wrote:
>> Hi everybody, especially Vincent.
>>
>> Attached fo-file contains a red block which is printed on the first page, although there's not enough space left. If I remove the span="all" for the block, it is printed on the next page. Can you tell me why span="all" is influencing the page break here?
>
> This is very probably another manifestation of bug #46322:
> https://issues.apache.org/bugzilla/show_bug.cgi?id=46322
>
> See discussion here:
> http://mail-archives.apache.org/mod_mbox/xmlgraphics-fop-dev/200812.mbox/<49...@gmail.com>
>
> The bug is triggered even if the previous blocks also span the whole page. The fact that you didn't explicitly specify span="all" on the previous block makes the code believe that there is a change in the spanning, which triggers some special (and buggy) page break handling.
>
> You found the workaround already. Hopefully it doesn't upset your whole tool chain. That's all I can say for now :-\
>
>
> Vincent
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
AW: span is influencing page breaking?
Posted by Georg Datterl <ge...@geneon.de>.
Hi Vincent,
> This is very probably another manifestation of bug #46322:
> https://issues.apache.org/bugzilla/show_bug.cgi?id=46322
> See discussion here:
> http://mail-archives.apache.org/mod_mbox/xmlgraphics-fop-dev/200812.mbox/<49...@gmail.com>
I remember. But back then I thought, that would only be a problem with one line.
> The bug is triggered even if the previous blocks also
> span the whole page. The fact that you didn't explicitly
> specify span="all" on the previous block makes the code
> believe that there is a change in the spanning, which
> triggers some special (and buggy) page break handling.
> You found the workaround already. Hopefully it doesn't
> upset your whole tool chain. That's all I can say for now :-\
No, I have not yet found the workaround. Only in the stripped example there's one column. Actually I get the problem in my two-column layout and there I can't remove the span="all".
Can you think of a different workaround?
Can you guess when your new pagebreaking mechanism will be finished?
Do you have a hint where I can find this special (and buggy) page break handling?
Regards,
Georg Datterl
------ Kontakt ------
Georg Datterl
Geneon media solutions gmbh
Gutenstetter Straße 8a
90449 Nürnberg
HRB Nürnberg: 17193
Geschäftsführer: Yong-Harry Steiert
Tel.: 0911/36 78 88 - 26
Fax: 0911/36 78 88 - 20
www.geneon.de
Weitere Mitglieder der Willmy MediaGroup:
IRS Integrated Realization Services GmbH: www.irs-nbg.de
Willmy PrintMedia GmbH: www.willmy.de
Willmy Consult & Content GmbH: www.willmycc.de
-----Ursprüngliche Nachricht-----
Von: Vincent Hennebert [mailto:vhennebert@gmail.com]
Gesendet: Montag, 23. Februar 2009 12:39
An: fop-users@xmlgraphics.apache.org
Betreff: Re: span is influencing page breaking?
Hi Georg,
Georg Datterl wrote:
> Hi everybody, especially Vincent.
>
> Attached fo-file contains a red block which is printed on the first page, although there's not enough space left. If I remove the span="all" for the block, it is printed on the next page. Can you tell me why span="all" is influencing the page break here?
This is very probably another manifestation of bug #46322:
https://issues.apache.org/bugzilla/show_bug.cgi?id=46322
See discussion here:
http://mail-archives.apache.org/mod_mbox/xmlgraphics-fop-dev/200812.mbox/<49...@gmail.com>
The bug is triggered even if the previous blocks also span the whole page. The fact that you didn't explicitly specify span="all" on the previous block makes the code believe that there is a change in the spanning, which triggers some special (and buggy) page break handling.
You found the workaround already. Hopefully it doesn't upset your whole tool chain. That's all I can say for now :-\
Vincent
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
Re: span is influencing page breaking?
Posted by Vincent Hennebert <vh...@gmail.com>.
Hi Georg,
Georg Datterl wrote:
> Hi everybody, especially Vincent.
>
> Attached fo-file contains a red block which is printed on the first page, although there's not enough space left. If I remove the span="all" for the block, it is printed on the next page. Can you tell me why span="all" is influencing the page break here?
This is very probably another manifestation of bug #46322:
https://issues.apache.org/bugzilla/show_bug.cgi?id=46322
See discussion here:
http://mail-archives.apache.org/mod_mbox/xmlgraphics-fop-dev/200812.mbox/<49...@gmail.com>
The bug is triggered even if the previous blocks also span the whole
page. The fact that you didn’t explicitly specify span="all" on the
previous block makes the code believe that there is a change in the
spanning, which triggers some special (and buggy) page break handling.
You found the workaround already. Hopefully it doesn’t upset your whole
tool chain. That’s all I can say for now :-\
Vincent
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
Re: span is influencing page breaking?
Posted by Andreas Delmelle <an...@telenet.be>.
On 22 Feb 2009, at 20:33, Andreas Delmelle wrote:
> <snip />
> FWIW: I've been playing a bit with the sample file. For another
> reason, though. I'm quite puzzled as to why the leading space in the
> innermost inlines is preserved...
OK, upon a closer look, no problem there. Just noticed that it is
actually a NBSP, which of course is not XML white-space, and is always
preserved. :-)
Cheers
Andreas
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
Re: span is influencing page breaking?
Posted by Andreas Delmelle <an...@telenet.be>.
On 22 Feb 2009, at 20:33, Andreas Delmelle wrote:
> Suddenly, I bumped into this:
> One of the influencing factors for the issue described by Georg,
> seems to be the column with zero width in the outer table. If you
> change that to a very low value, like "proportional-column-
> width(0.001)", then the table is moved to the second page.
Another influencing factor: the inner table is made wider than the
column in which is it is supposed to fit (6cm vs. 4cm). Changing that
explicit 6cm to 100% also produces the right result.
Cheers
Andreas
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
Re: span is influencing page breaking?
Posted by Andreas Delmelle <an...@telenet.be>.
On 20 Feb 2009, at 18:55, Andreas Delmelle wrote:
> On 20 Feb 2009, at 18:31, Andreas Delmelle wrote:
>
>> On 20 Feb 2009, at 15:47, Georg Datterl wrote:
>>> Attached fo-file contains a red block which is printed on the
>>> first page, although there's not enough space left. If I remove
>>> the span="all" for the block, it is printed on the next page. Can
>>> you tell me why span="all" is influencing the page break here?
>>
>> I don't know why exactly, but the good news is that with FOP Trunk,
>> I cannot reproduce the issue.
>
> Sorry, ignore this. I tried with my local sandbox copy, which has a
> few changes that influence the behavior of the span-property.
FWIW: I've been playing a bit with the sample file. For another
reason, though. I'm quite puzzled as to why the leading space in the
innermost inlines is preserved...
Suddenly, I bumped into this:
One of the influencing factors for the issue described by Georg, seems
to be the column with zero width in the outer table. If you change
that to a very low value, like "proportional-column-width(0.001)",
then the table is moved to the second page.
Cheers
Andreas
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
Re: span is influencing page breaking?
Posted by Andreas Delmelle <an...@telenet.be>.
On 20 Feb 2009, at 18:31, Andreas Delmelle wrote:
> On 20 Feb 2009, at 15:47, Georg Datterl wrote:
>
> Hi Georg
>
>> Attached fo-file contains a red block which is printed on the first
>> page, although there's not enough space left. If I remove the
>> span="all" for the block, it is printed on the next page. Can you
>> tell me why span="all" is influencing the page break here?
>
> I don't know why exactly, but the good news is that with FOP Trunk,
> I cannot reproduce the issue.
Sorry, ignore this. I tried with my local sandbox copy, which has a
few changes that influence the behavior of the span-property.
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
Re: span is influencing page breaking?
Posted by Andreas Delmelle <an...@telenet.be>.
On 20 Feb 2009, at 15:47, Georg Datterl wrote:
Hi Georg
> Attached fo-file contains a red block which is printed on the first
> page, although there's not enough space left. If I remove the
> span="all" for the block, it is printed on the next page. Can you
> tell me why span="all" is influencing the page break here?
I don't know why exactly, but the good news is that with FOP Trunk, I
cannot reproduce the issue. The block with the red background is moved
to the second page, even with the span specified.
Cheers
Andreas
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org