Joerg, Sorry for the delay in replying...
On 28.02.2004 19:18, Steve Schwarz wrote: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).
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.
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.
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?
Yep. latest from the FOP maintenance branch.
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 agree it's really nasty...but I can seem to make these play together otherwise.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 spent a lot of time trying to work around the <svg:use> bug, but to no avail.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.
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. Steve
_________________________________________________________________
Fast. Reliable. Get MSN 9 Dial-up - 3 months for the price of 1! (Limited-time Offer) http://click.atdmt.com/AVE/go/onm00200361ave/direct/01/
