Re: FOP with embeded SVG doesn't render at correct size in Cocoon
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:/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
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/
Re: FOP with embeded SVG doesn't render at correct size in Cocoon
Joerg, Here's an example xml that produces the problems (svg:use url failure for FOP versions of fop/batik jars and scaling problem for Cocoon versions of fop/batik jars): if you call it bar.xml: ?xml version=1.0 encoding=UTF-8? fo:root xmlns:svg=http://www.w3.org/2000/svg; xmlns:xlink=http://www.w3.org/1999/xlink; xmlns:fo=http://www.w3.org/1999/XSL/Format; fo:layout-master-set fo:simple-page-master margin-right=0.5in margin-left=0.5in margin-bottom=0.5in margin-top=0.5in page-width=8.5in page-height=11.5in master-name=all fo:region-body margin-bottom=0.25in margin-top=0.25in/ fo:region-before extent=0.25in/ fo:region-after extent=0.25in//fo:simple-page-master/fo:layout-master-set fo:page-sequence master-reference=all fo:flow flow-name=xsl-region-body fo:block text-align=center fo:instream-foreign-object text-align=center svg:svg xmlns:xlink=http://www.w3.org/1999/xlink; width=6in height=6in viewBox=0 0 1400 1400 svg:defs svg:g style=stroke:green;fill:green id=greenRectsvg:rect x=0 y=0 width=100 height=100//svg:g svg:g id=yellowGreenRect svg:rect x=0 y=0 width=200 height=200 style=stroke:yellow;fill:yellow/ svg:use transform=translate(400,400) xlink:href=#greenRect/ /svg:g /svg:defs svg:rect x=0 y=0 width=1600 height=1600 style=stroke-width:1;stroke:black;fill:red/ svg:use xlink:href=#yellowGreenRect/ /svg:svg /fo:instream-foreign-object /fo:block /fo:flow /fo:page-sequence /fo:root sitemap: map:match pattern=bar.pdf map:generate src=bar.xml/ map:serialize type=fo2pdf / /map:match Thanks, Steve 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:/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 _ Learn how to help protect your privacy and prevent fraud online at Tech Hacks Scams. http://special.msn.com/msnbc/techsafety.armx
Re: FOP with embeded SVG doesn't render at correct size in Cocoon
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
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
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?). If I just try to use the FOP version of Batik (Cocoon fop-0.20.5.jar) I 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? I also tried with the maintenance branch CVS head of FOP with no difference. 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. Thanks for your help, Steve From: J.Pietschmann Torsten Curdt wrote: 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. _ Get fast, reliable access with MSN 9 Dial-up. Click here for Special Offer! http://click.atdmt.com/AVE/go/onm00200361ave/direct/01/
Re: FOP with embeded SVG doesn't render at correct size in Cocoon
Same FOP version? Do you imply other Cocoon versions are working? Nope, I'm implying FOP standalone with the same FOP version as Cocoon uses works correctly :^) ok It looks like when invoked through Cocoon FOP is still reserving the right amount of space (based on the svg with/height attributes) but then when Batik is invoked it is rendering the image at the incorrect scale(my guess?). I tried dropping in the fop and batik jar files from Cocoon 2.1.4 and Cocoon still doesn't render the embedded SVG at large viewBox values correctly. Could you try and use cocoon's fop version as you do with the standalone version? That would be interesting... 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? At least I don't know about any difference... folks? cheers -- Torsten
Re: FOP with embeded SVG doesn't render at correct size in Cocoon
Torsten Curdt wrote: 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. J.Pietschmann
Re: FOP with embeded SVG doesn't render at correct size in Cocoon
I've got a weird problem generating pdfs using FOP from xml containing SVG; but only when processed through Cocoon (2.1.2). Generation directly with FOP is problem free. Same FOP version? Do you imply other Cocoon versions are working? cheers -- Torsten
Re: FOP with embeded SVG doesn't render at correct size in Cocoon
Hi I've got a weird problem generating pdfs using FOP from xml containing SVG; but only when processed through Cocoon (2.1.2). Generation directly with FOP is problem free. Same FOP version? Do you imply other Cocoon versions are working? Nope, I'm implying FOP standalone with the same FOP version as Cocoon uses works correctly :^) It looks like when invoked through Cocoon FOP is still reserving the right amount of space (based on the svg with/height attributes) but then when Batik is invoked it is rendering the image at the incorrect scale(my guess?). I tried dropping in the fop and batik jar files from Cocoon 2.1.4 and Cocoon still doesn't render the embedded SVG at large viewBox values correctly. 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? Thanks for the reply! Steve _ Get fast, reliable access with MSN 9 Dial-up. Click here for Special Offer! http://click.atdmt.com/AVE/go/onm00200361ave/direct/01/
Re: FOP with embeded SVG doesn't render at correct size in Cocoon
Hi Steve: I think it would be fine if you can upgrade to Cocoon 2.1.4. Also if you cannot find the answer here, you can also search or ask in the user list of FOP: http://xml.apache.org/fop/maillist.html or Batik: http://xml.apache.org/batik/mailList.html If I will be able to help, I will post you a better mail, than this. Best Regards, Antonio Gallardo Steve Schwarz dijo: Hi I posted this to the users mail list with no success; I'm hoping someone can here can point me in the right direction...? In the archives I've seen some dev discussions of which Batik to use when rendering embeded SVG in FO and which to use when rendering SVG to PNG/JPEG (but I need to do both...) I've got a weird problem generating pdfs using FOP from xml containing SVG; but only when processed through Cocoon (2.1.2). Generation directly with FOP is problem free. For viewBox values larger than 0 0 525 525 (you know this is going to be weird already...) the generated image within the PDF is proportionally smaller than specified in the svg element's width/height attributes. For example this renders as a black square filled in red and is 7 in on each side: fo:block text-align=center fo:instream-foreign-object text-align=center svg:svg xmlns:xlink=http://www.w3.org/1999/xlink; height=7in width=7in viewBox=0 0 500, 500 svg:rect x=0px y=0px width=500 height=500 style=stroke-width:1;stroke:black;fill:red/ /svg:svg /fo:instream-foreign-object /fo:block But this renders as a black edged square filled in red and is ~6 in on each side: fo:block text-align=center fo:instream-foreign-object text-align=center svg:svg xmlns:xlink=http://www.w3.org/1999/xlink; height=7in width=7in viewBox=0 0 600, 600 !-- rect sized to completely fill viewBox -- svg:rect x=0px y=0px width=600 height=600 style=stroke-width:1;stroke:black;fill:red/ /svg:svg /fo:instream-foreign-object /fo:block Of course the data I'm rendering is in a scale requiring viewBox sizes well over 1000 in width/height. Has anyone got a pointer for me? I took a look at FOPSerializer and it doesn't really do anything suspicious... Thanks Steve _ Click, drag and drop. My MSN is the simple way to design your homepage. http://click.atdmt.com/AVE/go/onm00200364ave/direct/01/
