Re: cvs commit: xml-fop/test/layoutengine/testcases normal-breaking5.xml
Jeremias Maerki wrote: While I was investigating this earlier I modified AbstractBreaker to set the "force" parameter to "false" on the findBreakingPoints() call. I found out now that this had the interesting side-effect that footnotes7.xml produces the same footnotes on both page 1 and page 2. It seems that the footnote handling relies on the force parameter to be set to "true". Don't know if this means anything. I simply thought I'd share this. I reverted that change on my working copy. (sorry for not answering before) That's quite a strange behaviour ... :-/ I'm going to investigate its causes. By the way, I also would like to work a little bit more on footnotes. The recommendation (6.10.1.3.) states that "There may be limits on how much space conditionally generated areas can borrow from the region-referencearea. It is left to the user agent to decide these limits." At the moment, FOP has an implicit limit, as each page will contain at least a line from the normal flow, but I would like the limit to be settable in the document itself: as there are documents with many long footnotes (for example, a commented version of Dante's divine comedy) I think it should be the user to decide whether he likes more having at least some (and how many, precisely) content lines in each page, or to create "footnote pages" so that the next content lines will be placed in a page where their cited footnote can be placed too. Regards Luca
Re: cvs commit: xml-fop/test/layoutengine/testcases normal-breaking5.xml
Luca, your pointers were 100% on target! It took a few other things around that but the issue seems to be fixed now. If you look at the code, you can see that this functionality could theoretically also be useful for line-breaking. Especially when we have side floats some day this could be very useful to avoid text to overflow into the side-flow. Even today, there are some constellations where this behaviour would make sense. But I think we'd need some additional code to handle every situation properly. For the moment, I've disabled the "part overflow recovery" (for lack of a better description) for line breaking. I've also disabled it for side region layout and block-containers since we want the overflow in these areas. Parts n > 0 will just be dropped anyway. Thanks for your help. On 22.06.2005 14:42:42 Luca Furini wrote: > Jeremias Maerki wrote: > > > Before I waste a lot of time trying to figure out how I should fix that, > > I thought I'd just drop in a test case. Luca, for you it's probably very > > easy to say at which point I should hook in to create pages with empty > > content so the non-fitting content is simply pushed to the next page. In > > the end, that "pushing-loop" need an upper limit (like 50 iterations or > > so) after which it throws a layout exception complaining about too > > little room to place content (This check used to be in FlowLM [1]). I'm > > somewhat stuck in PageBreakingAlgorithm.removeNode(). Intuitively, I'd > > say I'd have to create a new KnuthNode that somehow results in an empty > > page or something like that. > > At the moment, the test fails because the algorithm stops and restarts > from lastTooLong (a page break involving content overflow), so I think > that the right point could be BreakingAlgorithm.findBreakingPoints() > at line #368. > > Instead of using lastTooLong, a node representing an empty page should be > created and lastForced should be made equal to that new node. > > I did not try if this works, but here is my idea to do that: > > - lastTooLong would create a page whose content overflows, so the last >"good" break poing is lastTooLong.previous > - create a new node whose .position is lastTooLong.previous.position, >.line is lastTooLong.previous.line + 1, .previous is >lastTooLong.previous (the other values could be 0, I think) > - this could be the node representing an empty page, from which the >algorithm can restart > > > BTW, Luca, I haven't forgotten your post about keep-with-previous in > > tables. Thank you for that one. ATM I'm swimming in another lake trying > > to remain on top. :-) > > I know that kind of situation ... :-) > > Regards > Luca Jeremias Maerki
Re: cvs commit: xml-fop/test/layoutengine/testcases normal-breaking5.xml
While I was investigating this earlier I modified AbstractBreaker to set the "force" parameter to "false" on the findBreakingPoints() call. I found out now that this had the interesting side-effect that footnotes7.xml produces the same footnotes on both page 1 and page 2. It seems that the footnote handling relies on the force parameter to be set to "true". Don't know if this means anything. I simply thought I'd share this. I reverted that change on my working copy. On 22.06.2005 14:42:42 Luca Furini wrote: > Jeremias Maerki wrote: > > > Before I waste a lot of time trying to figure out how I should fix that, > > I thought I'd just drop in a test case. Luca, for you it's probably very > > easy to say at which point I should hook in to create pages with empty > > content so the non-fitting content is simply pushed to the next page. In > > the end, that "pushing-loop" need an upper limit (like 50 iterations or > > so) after which it throws a layout exception complaining about too > > little room to place content (This check used to be in FlowLM [1]). I'm > > somewhat stuck in PageBreakingAlgorithm.removeNode(). Intuitively, I'd > > say I'd have to create a new KnuthNode that somehow results in an empty > > page or something like that. > > At the moment, the test fails because the algorithm stops and restarts > from lastTooLong (a page break involving content overflow), so I think > that the right point could be BreakingAlgorithm.findBreakingPoints() > at line #368. > > Instead of using lastTooLong, a node representing an empty page should be > created and lastForced should be made equal to that new node. > > I did not try if this works, but here is my idea to do that: > > - lastTooLong would create a page whose content overflows, so the last >"good" break poing is lastTooLong.previous > - create a new node whose .position is lastTooLong.previous.position, >.line is lastTooLong.previous.line + 1, .previous is >lastTooLong.previous (the other values could be 0, I think) > - this could be the node representing an empty page, from which the >algorithm can restart > > > BTW, Luca, I haven't forgotten your post about keep-with-previous in > > tables. Thank you for that one. ATM I'm swimming in another lake trying > > to remain on top. :-) > > I know that kind of situation ... :-) > > Regards > Luca > Jeremias Maerki
Re: cvs commit: xml-fop/test/layoutengine/testcases normal-breaking5.xml
Thanks, Luca. Looks like my intuition was right. I'll have a look at it shortly. On 22.06.2005 14:42:42 Luca Furini wrote: > Jeremias Maerki wrote: > > > Before I waste a lot of time trying to figure out how I should fix that, > > I thought I'd just drop in a test case. Luca, for you it's probably very > > easy to say at which point I should hook in to create pages with empty > > content so the non-fitting content is simply pushed to the next page. In > > the end, that "pushing-loop" need an upper limit (like 50 iterations or > > so) after which it throws a layout exception complaining about too > > little room to place content (This check used to be in FlowLM [1]). I'm > > somewhat stuck in PageBreakingAlgorithm.removeNode(). Intuitively, I'd > > say I'd have to create a new KnuthNode that somehow results in an empty > > page or something like that. > > At the moment, the test fails because the algorithm stops and restarts > from lastTooLong (a page break involving content overflow), so I think > that the right point could be BreakingAlgorithm.findBreakingPoints() > at line #368. > > Instead of using lastTooLong, a node representing an empty page should be > created and lastForced should be made equal to that new node. > > I did not try if this works, but here is my idea to do that: > > - lastTooLong would create a page whose content overflows, so the last >"good" break poing is lastTooLong.previous > - create a new node whose .position is lastTooLong.previous.position, >.line is lastTooLong.previous.line + 1, .previous is >lastTooLong.previous (the other values could be 0, I think) > - this could be the node representing an empty page, from which the >algorithm can restart > > > BTW, Luca, I haven't forgotten your post about keep-with-previous in > > tables. Thank you for that one. ATM I'm swimming in another lake trying > > to remain on top. :-) > > I know that kind of situation ... :-) > > Regards > Luca > Jeremias Maerki
Re: cvs commit: xml-fop/test/layoutengine/testcases normal-breaking5.xml
Jeremias Maerki wrote: Before I waste a lot of time trying to figure out how I should fix that, I thought I'd just drop in a test case. Luca, for you it's probably very easy to say at which point I should hook in to create pages with empty content so the non-fitting content is simply pushed to the next page. In the end, that "pushing-loop" need an upper limit (like 50 iterations or so) after which it throws a layout exception complaining about too little room to place content (This check used to be in FlowLM [1]). I'm somewhat stuck in PageBreakingAlgorithm.removeNode(). Intuitively, I'd say I'd have to create a new KnuthNode that somehow results in an empty page or something like that. At the moment, the test fails because the algorithm stops and restarts from lastTooLong (a page break involving content overflow), so I think that the right point could be BreakingAlgorithm.findBreakingPoints() at line #368. Instead of using lastTooLong, a node representing an empty page should be created and lastForced should be made equal to that new node. I did not try if this works, but here is my idea to do that: - lastTooLong would create a page whose content overflows, so the last "good" break poing is lastTooLong.previous - create a new node whose .position is lastTooLong.previous.position, .line is lastTooLong.previous.line + 1, .previous is lastTooLong.previous (the other values could be 0, I think) - this could be the node representing an empty page, from which the algorithm can restart BTW, Luca, I haven't forgotten your post about keep-with-previous in tables. Thank you for that one. ATM I'm swimming in another lake trying to remain on top. :-) I know that kind of situation ... :-) Regards Luca
Re: cvs commit: xml-fop/test/layoutengine/testcases normal-breaking5.xml
Before I waste a lot of time trying to figure out how I should fix that, I thought I'd just drop in a test case. Luca, for you it's probably very easy to say at which point I should hook in to create pages with empty content so the non-fitting content is simply pushed to the next page. In the end, that "pushing-loop" need an upper limit (like 50 iterations or so) after which it throws a layout exception complaining about too little room to place content (This check used to be in FlowLM [1]). I'm somewhat stuck in PageBreakingAlgorithm.removeNode(). Intuitively, I'd say I'd have to create a new KnuthNode that somehow results in an empty page or something like that. BTW, Luca, I haven't forgotten your post about keep-with-previous in tables. Thank you for that one. ATM I'm swimming in another lake trying to remain on top. :-) [1] http://cvs.apache.org/viewcvs.cgi/xml-fop/src/java/org/apache/fop/layoutmgr/FlowLayoutManager.java?r1=1.9&r2=1.10&diff_format=h On 21.06.2005 15:10:36 jeremias wrote: > jeremias2005/06/21 06:10:36 > > Modified:test/layoutengine disabled-testcases.txt > Added: test/layoutengine/testcases normal-breaking5.xml > Log: > In page breaking, content that doesn't fit, should move to the next page > even if that means creating empty pages. > > > > This test checks normal breaking. It checks whether elements that > don't fit on a > page are sent over to the next if that one has more room (indirectly > checks > changing available BPD, too). > > > > http://www.w3.org/1999/XSL/Format"; widows="0" > orphans="0"> > >page-width="120pt"> > > >page-width="120pt"> > > > > > > > > > > > Apache > FOP is a great tool to create PDF documents with. > Apache > FOP is a great tool to create PDF documents with. > Apache > FOP is a great tool to create PDF documents with. > Apache > FOP is a great tool to create PDF documents with. > last line in new > block > > > > > > > > > > "/> > "/> > "/> > > Jeremias Maerki
