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

Reply via email to