Subject: AW: span is influencing page breaking?



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@xxxxxxxxx]
Gesendet: Montag, 23. Februar 2009 18:08
An: fop-users@xxxxxxxxxxxxxxxxxxxxxx
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/<49352982.4070100@xxxxxxxxx>
>
> 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@xxxxxxxxx]
> Gesendet: Montag, 23. Februar 2009 12:39
> An: fop-users@xxxxxxxxxxxxxxxxxxxxxx
> 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/<49352982.4070100@xxxxxxxxx>
>
> 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@xxxxxxxxxxxxxxxxxxxxxx
For additional commands, e-mail: fop-users-help@xxxxxxxxxxxxxxxxxxxxxx


---------------------------------------------------------------------
To unsubscribe, e-mail: fop-users-unsubscribe@xxxxxxxxxxxxxxxxxxxxxx
For additional commands, e-mail: fop-users-help@xxxxxxxxxxxxxxxxxxxxxx



Privacy