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/<49352982.4070...@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:vhenneb...@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/<49352982.4070...@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-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org
