You are viewing a plain text version of this content. The canonical link for it is here.
Posted to fop-dev@xmlgraphics.apache.org by bu...@apache.org on 2003/11/13 00:19:45 UTC
DO NOT REPLY [Bug 24666] New: -
fo:instream-foreign-object: SVG w/6-digit translates not rendering well
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: fop-dev@xml.apache.org
ReportedBy: glenmazza@yahoo.com
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.