Re: span is influencing page breaking?
Georg Datterl wrote:
> Hi Vincent,
>> This is very probably another manifestation of bug #46322:
>> See discussion here:
> I remember. But back then I thought, that would only be a problem with one
>> 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?
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
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
> 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
> 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:
> See discussion here:
> 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 :-\
To unsubscribe, e-mail: fop-users-unsubscribe@xxxxxxxxxxxxxxxxxxxxxx
For additional commands, e-mail: fop-users-help@xxxxxxxxxxxxxxxxxxxxxx