You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Joerg Heinicke <jo...@gmx.de> on 2004/03/03 00:40:16 UTC

Re: FOP with embeded SVG doesn't render at correct size in Cocoon

On 28.02.2004 19:18, Steve Schwarz wrote:

> Thanks for the info.
> 
> I tried replacing the Cocoon jars: batik-all-1.5.jar  fop-0.20.5.jar
> with the FOP 0.20.5 jars (fop.jar batik.jar) in that case no SVG is 
> rendered at all because there is a problem with use and url(#), even 
> though the reference is resolved within the same <svg> element (and 
> resolves correctly when using FOP standalone...must be relying on 
> different behavior than the Cocoon URI resolving provides?).

That's strange as no Cocoon URI resolving does not take part here. 
Sylvain tried to replace the resolver with the Cocoon one for usage of 
Cocoon pseudo protocols, but this broke the local URIs (#), so it was 
reverted. It lived from Feb, 4th, to Feb 8th - I hope your Cocoon is not 
from that time. Cocoon 2.1.4 does not contains this.

> If I just try to use the FOP version of Batik (Cocoon fop-0.20.5.jar) I 

What does it mean? No Batik at all? Cocoon's fop JAR as standalone?

> get a No Such Method in Batik.
> java.lang.NoSuchMethodError: 
> org.apache.batik.bridge.UnitProcessor.createContext(Lorg/apache/batik/bridge/BridgeContext;Lorg/w3c/dom/Element;)Lorg/apache/batik/parser/UnitProcessor$Context; 
> 
> 
> So it looks like Cocoon's version of FOP is using a different (newer?) 
> version of Batik. But that raises the question, was the Cocoon version 
> of FOP taken from CVS and is really post 0.20.5 release?

It's the 0.20.5 release, but built with our Batik 1.5. I guess the FOP 
people must clarify if this made any sense or not. IIRC we had the 
released Fop jar in our CVS and got complaints for problems with Batik 
after Batik update. So we rebuilt Fop with this new Batik and the 
problems seemed to be gone. The FOP 0.20.5 release uses Batik 1.5 beta 4.

> I also tried with the maintenance branch CVS head of FOP with no 
> difference.

Hmm, head *or* branch :) I guess you mean the recent stuff from the branch.

> I think I'll look into writing a Serializer that invokes the standalone 
> FOP as though it was an external program so I can pickup the versions of 
> FOP/Batik I need to make this work.

Not a very integrative solution ...

>> From: "J.Pietschmann"
>>
>>>> Can anyone tell me how the Cocoon fop and batik jar files are 
>>>> generated and how that is different from the jars supplied with FOP?
>>
>>
>> THere were some Cocoon releases which shipped with a different
>> Batik jar than the corresponding FOP release, partly due to
>> interface changes in Batik which forced FOP to use a CVS
>> snapshot. I don't know of the current state, but the latest
>> Batik was released after the latest FOP release, if Cocoon
>> grabbed the latest Batik jar, there are certainly some differences.

After Batik 1.5 b 2 we had b5 and the 1.5 release in use. The latter two 
are newer then FOP 0.20.5 and its Batik 1.5 b4. I would like to see this 
solved for Cocoon finally.

For Steve it should work to use Fop 0.20.5's jar and its batik.jar (the 
1.5 b4) and to replace the Cocoon's versions of these two jars.

Joerg

Re: FOP with embeded SVG doesn't render at correct size in Cocoon

Posted by Joerg Heinicke <jo...@gmx.de>.
On 03.03.2004 22:20, J.Pietschmann wrote:

> Joerg Heinicke wrote:
> 
>> It's the 0.20.5 release, but built with our Batik 1.5. I guess the FOP 
>> people must clarify if this made any sense or not. IIRC we had the 
>> released Fop jar in our CVS and got complaints for problems with Batik 
>> after Batik update. So we rebuilt Fop with this new Batik and the 
>> problems seemed to be gone.
> 
> 
> Odd. If it compiles, it shouldn't complain about missing methods
> at run time. There may be behaviour changes though, has someone
> checked the Batik change log?

I guess no, at least I didn't it. But our CVS contains a sample with an 
image and this works for me after my recent commit for the image path 
that was wrong: http://127.0.0.1:8888/samples/fop/misc/minimal.pdf. 
Probably it happens only for embedded SVG?

I searched for some more messages on this issue, but they always end at 
the same place:
http://archives.real-time.com/pipermail/cocoon-devel/2003-September/thread.html#19117
http://koala.ilog.fr/batik/mlists/batik-dev/archives/threads.html#03368

Batik has changed an interface and broke the dependency of FOP on it. 
The Cocoon dev thread ended with the question of downgrading. But as you 
said: "If it compiles, it shouldn't complain about missing methods at 
run time."

Joerg

Re: FOP with embeded SVG doesn't render at correct size in Cocoon

Posted by "J.Pietschmann" <j3...@yahoo.de>.
Joerg Heinicke wrote:
> It's the 0.20.5 release, but built with our Batik 1.5. I guess the FOP 
> people must clarify if this made any sense or not. IIRC we had the 
> released Fop jar in our CVS and got complaints for problems with Batik 
> after Batik update. So we rebuilt Fop with this new Batik and the 
> problems seemed to be gone.

Odd. If it compiles, it shouldn't complain about missing methods
at run time. There may be behaviour changes though, has someone
checked the Batik change log?

J.Pietschmann