Re: svn commit: r412224 - in /xmlgraphics/fop/trunk: ./ src/java/org/apache/fop/fo/flow/ src/java/org/apache/fop/fo/properties/ test/layoutengine/
Andreas, did you ever add that testcase? On 07.06.2006 00:01:46 Andreas L Delmelle wrote: On Jun 6, 2006, at 23:52, [EMAIL PROTECTED] wrote: Author: adelmelle Date: Tue Jun 6 14:52:19 2006 New Revision: 412224 URL: http://svn.apache.org/viewvc?rev=412224view=rev Log: Fixes Bugzilla 39560: make sure the interaction between FOs and properties is only performed once Fixes the NPE, so the test passes for now. There are still problems unrelated to this particular bug. AFAICT there seem to be problems with the percentage resolution in a retrieved marker (?) Still have to check whether this is a general issue, but all other tests passed, so I consider this one fixed. Testcase demonstrating the remaining problem will be added shortly. Later, Andreas Jeremias Maerki
Re: Error message: Should be first
Jeremias Maerki wrote: One of my clients reported to me that he gets a Should be first error message on the log. This happens in (Page)BreakingAlgorithm.removeNode(). I get the impression that the code there is not finished rather than that is a real error condition. I'll try to extend removeNode() so it really removes the disabled node. That's quite strange ... The reason why the to-be-removed node should be the first one is this: active nodes are ordered by line (page) number and by index of the element where the feasible break can happen, so, for example, a node representing a break for page 13 at element #150 is (or at least it should be) before a break for page 13 at element #152; a node is removed when it is too far from the current feasible break being evaluated (or, in other words, from the node and the current position there is too much content to be placed in a single line / page), so in normal situations nodes are removed in order: for example, if we are evaluating a break at element #180, and we are too far from the node representing the break for page 13 at element #152, we will have already removed the node representing a break at page 13 element #150 (as it will be farther from the current element); this could be no more true when there are footnotes: for example the break at element #152 could represent a page where we have placed one more normal line in page 13, but fewer footnote lines with regard to the break at element #150, so the node coming first allows to place more content than the following one, and we could need to remove the node at #152 *before* the one at element #150 However, this does not explain why this warning shows in what appears to be a very simple document. I'm going to have a closer look ... Regards Luca
DO NOT REPLY [Bug 39608] - NullPointerException when redering .fo file in TableLayoutManager.initialize
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=39608. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=39608 [EMAIL PROTECTED] changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2006-07-11 12:47 --- Should be fixed now: http://svn.apache.org/viewvc?rev=420824view=rev -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee.
Re: [EMAIL PROTECTED]: Project xml-fop (in module xml-fop) failed
No idea why Gump didn't pick up the change in XML Graphics Commons. Maybe just a glitch. On 11.07.2006 13:43:06 Sam Ruby wrote: snip/ [javac] /x1/gump/public/workspace/xml-fop/src/java/org/apache/fop/fo/ElementMappingRegistry.java:71: providers(java.lang.Class) in org.apache.xmlgraphics.util.Service cannot be applied to (java.lang.Class,boolean) [javac] Iterator providers = Service.providers(ElementMapping.class, false); [javac] ^ snip/ Jeremias Maerki
Necessary conditions to defer footnotes
Hi All, there is something I don't get with the handling of footnotes. When there is not enough room on the current page to place all the footnotes, the algorithm tries to find a place where to split them. But there is a condition: it must be possible to defer old footnotes (PageBreakingAlgorithm, l.332). And this is possible only if there is no legal breakpoint between the previous active node and the currently considered breakpoint (checkCanDeferOldFootnotes method). I don't understand this latter condition? And, reading the code, I don't understand if this method's purpose is to determine if it is /allowable/ to defer footnotes (am I authorized to defer footnotes if any), or if it is /possible/ (are there footnotes to defer). Ok, this is a bit subtile, but understanding that would help me get the intent of the algorithm. What is the relation with before-floats? Well, I'm currently refactoring this part of the code to factorize out as much as possible things common to floats and footnotes. And this part of the code, currently applied to footnotes, may well be also applied to floats. Hints? Vincent
Re: Error message: Should be first
I've had another look at this. A few debug outputs shows that the error arises when trying to remove the node KnuthNode at 734 4527603+682968-135942 line:10 prev:687 dem:11527.971465493918 while the list of active nodes contains [ KnuthNode at 734 4527603+682968-135942 line:10 prev:683 dem:11513.226030457132, KnuthNode at 734 4527603+682968-135942 line:10 prev:687 dem:11527.971465493918, ] This removal, however, happens at the end of the algorithm, when the best layout is chosen (just like Vincent pointed out), and in this situation a node could be rightly be removed even if it's not the first one. We could maybe add a boolean parameter to removeNode(), stating whether it is allowed to remove the nodes out of order or not, and only the calls in filterActiveNodes() would have it true. HTH Luca
Re: svn commit: r412224 - in /xmlgraphics/fop/trunk: ./ src/java/org/apache/fop/fo/flow/ src/java/org/apache/fop/fo/properties/ test/layoutengine/
On Jul 11, 2006, at 10:33, Jeremias Maerki wrote: Hi Jeremias, Andreas, did you ever add that testcase? Sorry. Got a bit side-tracked by the marker/percentage-resolution issue (and then ran a bit short of spare time; almost finished though, only a few details and this will be out of the way). OK if I add this along with the rest? Cheers, Andreas
