Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cocoon.apache.org
From: "Steve Schwarz" <saschwarz@hotmail.com>
To: dev@cocoon.apache.org
Bcc: 
Subject: Re: FOP with embeded SVG doesn't render at correct size in Cocoon
Date: Fri, 05 Mar 2004 01:57:02 +0000
Mime-Version: 1.0
Content-Type: text/plain; format=flowed
Message-ID: <Law11-F77SVusApaTia0002996c@hotmail.com>

Joerg,
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.
>>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.
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 
otherwise.
>>>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 
avail.
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/