DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://nagoya.apache.org/bugzilla/show_bug.cgi?id=24666>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE.
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=24666 fo:instream-foreign-object: SVG w/6-digit translates not rendering well Summary: fo:instream-foreign-object: SVG w/6-digit translates not rendering well Product: Fop Version: 1.0dev Platform: Other OS/Version: Other Status: NEW Severity: Normal Priority: Other Component: svg AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] Tom Vijlbrief has found errors with SVG containing 6-digit translates embedded within FOP 0.20.5 (<fo:instream-foreign-object>) (Problem is also relevant for 1.0). The SVG renders fine with Batik's squiggle application (shows a neighboorhood map.) 1st attachment -- SVG file (view via Squiggle). 2nd attachment -- FO file (which has above, plus one red & one blue rectangle for testing.) 3rd attachment -- (bad) PDF result For 0.20.5, he has proposed this change to the PDFNumber.java class, which he believes will accomodate PDFNumber receiving doubles in scientific notation (e.g., 1E-04). (unsure of the validity of this.) public class PDFNumber { static java.text.DecimalFormat myFormatter = new java.text.DecimalFormat ("#.########"); public static String doubleOut(Double doubleDown) { return doubleOut(doubleDown.doubleValue()); } public static String doubleOut(double doubleDown) { return myFormatter.format(doubleDown); } public static String doubleOut(double doubleDown, int dec) { return doubleOut(doubleDown); } ... other methods in 1.0... } The new class appears to fix the problem when applied to 0.20.5, however will *not* work with nightly build of maintenance (has a different Batik library). Nor will it work with 1.0, because of the (even newer) Batik library in HEAD (as well as perhaps other reasons, 1.0 being incomplete). Another possible problem with the above patch is that it neutralizes the third method in the class (just calls the second method, # decimal points desired is ignored). I'm unsure how important the third method is to FOP. 4th attachment -- PDF result from 0.20.5 modified with PDFNumber as above. Renders well Thomas DeWeese (Batik) commented on this problem earlier, prior to Tom Vijlbrief's patch: see http://marc.theaimsgroup.com/?l=fop-dev&m=106709286423914&w=2. Will keep this bug open for 1.0 to ensure that these types of SVG's can be generated in the new 1.0 version of FOP. Also, the rendering is usually worse in Acrobat Reader 5.0 vs. AR 6.0, so recommended to make sure changes render correctly at least in AR 6.0.
