Not necessary. It's a known problem. Please see here: http://www.nabble.com/fop-trunk-svg-problems-t1177182.html
What's new is that Saxon 8 seems to have a similiar problem. Anyway, since the thread quoted above Batik has been fixed in terms of attribute handling but unless Batik does a new release FOP will have this problem and we have to look into the XML parser and XSLT problem to fix the problem. Note: This may be seen as a regression of FOP but FOP is doing something perfectly valid. The code is correct. The problem occurs due to bugs in attribute handling in dependent packages outside FOP's control. I'm looking into why the same problem appears with SAXON 8, too. Richard, are you using the latest SAXON 8 release? On 30.04.2006 06:13:23 Clay Leeds wrote: > Thank you for the report, Richard. Could you provide a small sample > FO file + SVG which demonstrates the problem, so we can recreate the > problem ourselves (and also have something which shows we've "fixed" > the problem!)? > > Thanks! > > On Apr 29, 2006, at 8:29 PM, Richard Kennard wrote: > > Dear All, > > > > There seems to have been a regression in embedded SVG support > > between 0.92beta and 0.91beta? > > > > Using Cocoon 2.1.8, Saxon 8, Batik 1.6 and FOP 0.91beta my FOP with > > embedded SVG renders well. However upgrading to 0.92beta (and > > keeping everything else the same) gives me a stack trace (see below). > > > > I have checked and all <rect> elements definitely do have a "width" > > attribute (and besides it renders fine in 0.91beta). Interestingly > > the problem is related to upgrading FOP (not Batik). > > > > Thanks for an excellent product, Jeremias Maerki --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
