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="greenRect"><svg: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: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
_________________________________________________________________
Learn how to help protect your privacy and prevent fraud online at Tech Hacks & Scams. http://special.msn.com/msnbc/techsafety.armx
