cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Steve Schwarz" <>
Subject Re: FOP with embeded SVG doesn't render at correct size in Cocoon
Date Fri, 05 Mar 2004 01:57:02 GMT
Sorry for the delay in replying...

>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.
I am using Cocoon 2.1.2 with the Cocoon 2.1.4 batik/fop jars (looks like 
they didn't change since 2.1.2 anyway).

>>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?
Sorry for the confusion. I meant (fop-0.20.5.jar and batik.jar). That is, 
the Batik from the FOP release and the Cocoon FOP jar.
>>get a No Such Method in Batik.
>>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 
>Hmm, head *or* branch :) I guess you mean the recent stuff from the branch.
Yep. latest from the FOP maintenance 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 ...
I agree it's really nasty...but I can seem to make these play together 
>>>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.
I spent a lot of time trying to work around the <svg:use> bug, but to no 
It looks like for these specfic SVG input files the PDF document processing 
will always be "write once" on file upload so I can use an action to 
generate them via exec'ing an external FOP and they will never change for 
the document life. Then I can serve them up through <map:read>.

Thanks again for your help.

Fast. Reliable. Get MSN 9 Dial-up - 3 months for the price of 1! 
(Limited-time Offer)

View raw message