Chris, On Mon, May 24, 2004 at 01:57:34PM +0100, Chris Bowditch wrote: > Hi Luca, > > I have managed to apply your patch. Testing has not gone well. Firstly, I > had trouble compiling, due to BLM using the old constructor for LLM with > FObj as the first argument. This is easily corrected, but I would have > expected a change to BLM in your patch file. Also I found a few calls to > getLogger in the LMs, which dont compile. I hit the problem of not being > able to call getLogger in the LM code myself recently. So I added a > getLogger method to AbstractLM.
I changed the constructor call as well. I changed the logger calls from getLogger() to log. log is a member of AbstractLayoutManager. These are changes applied by Glen, and apparently Luca made his diff before they were applied. > Once compiled I tried testing with a complex document, but that fell over. > Previously it was working, albeit without markers. I then tried one of your > more simple test cases and that fell over too. Here is the stack trace, > which is the same for both documents: > > Exception in thread "main" java.lang.NullPointerException > at > org.apache.fop.layoutmgr.LineLayoutManager$Paragraph.startParagraph(L > ineLayoutManager.java:249) > at > org.apache.fop.layoutmgr.LineLayoutManager.getNextBreakPoss(LineLayou > tManager.java:351) > at > org.apache.fop.layoutmgr.BlockLayoutManager.getNextBreakPoss(BlockLay > outManager.java:202) > > Any thoughts would be appreciated. No exceptions. I ran Luca's test fo files successfully. Note that the test files erroneously specify the language as "eng"; this should be "en". I am not surprised that your complex document did not run well. If I understand the situation well, then the patch works for LineLM with TextLM childLMs. It does not work with any other childLM. I expect the other childLMs to use the null implementation of getNextKnuthElement() and therefore to contribute no areas. This does not explain that it causes an exception, though. > Is anyone else on the team planning on making large commits over the next > couple of days? I would be grateful if you could hold off for a couple of > days whilst the problems with this large patch are resolved. I dont want to > have to re-apply the changes. Let me know if this causes any problems.... I do not believe that the patch is mature for committing to the trunk code. See above. Luca, do you share my view? If I see it right, then Luca should work on his patch some more. Perhaps others could help with that work if he would want that. In such a situation it may be a good strategy to commit the patch to a branch of the HEAD of the trunk, so that it can be developed without problems with other work. Regards, Simon -- Simon Pepping home page: http://www.leverkruid.nl
