DO NOT REPLY [Bug 23883] - SVG embedded in FO cannot handle large (6digit) translates
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=23883. 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=23883 SVG embedded in FO cannot handle large (6digit) translates [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE --- Additional Comments From [EMAIL PROTECTED] 2003-11-12 23:40 --- Tom, Your patch fixed things quite well in 0.20.5--I tested it--*but* the nightly maintenance version of 0.20.5 has a different Batik library (a version of a couple of months ago, that we had to update because of an API change) that your patch would *not* fix. We're going to pass on making the change in 0.20.5 (maintenance is mostly frozen anyway). Your patch has the same problems with 1.0, which has an even newer Batik library, however, there may be also other issues in 1.0 causing the problem there.) There may be other issues as well with the patch you supplied, namely the loss of the third method which allows one to choose the number of desired decimal points--I'm unsure how needed it is right now. (Also, I'm unclear how exponential notation is an issue with the double data type--that should be understood inherently with that datatype, correct? Nonetheless, your patch *did* fix the problem.) Some of our more experienced SVG developers may be able to comment on this later for 1.0. The bug below has gotten too huge for anyone to look at, so I just took the relevant points and redid the bug in #24666. Clearly, this is something that needs fixing but we'll concentrate on making sure it will be OK in 1.0 instead. Thanks, Glen *** This bug has been marked as a duplicate of 24666 ***
DO NOT REPLY [Bug 23883] - SVG embedded in FO cannot handle large (6digit) translates
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=23883. 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=23883 SVG embedded in FO cannot handle large (6digit) translates --- Additional Comments From [EMAIL PROTECTED] 2003-11-06 12:06 --- (1.) You mentioned another bug earlier in this thread, separate from this issue, that fails in *both* 6.0 and 5.5--it may be good to add that issue in a separate Bugzilla report so it isn't forgotten. (2.) Would you like me to hold off on this patch until you have it working for 6.0? IIRC the code *was* working OK in 6.0 but failing in 5.5--I wouldn't want to apply a patch that would cause the reverse to occur. To start with item (2), the fix solves a bug that generates wrong PDF (incorrect rounding, this could be seen as the spikes pointing north from the text items). The generated PDF is wrong for any PDF viewer, so the fix can and should be applied now. It should not break any existing test-cases, the PDF-output could be larger though, because the rounding process is more conservative. The original code rounded to 1 decimal digit in some cases, I always round to 8 decimal positions, but trailing zeros are omitted, so the PDF should not grow much. Not that the original code was rounding incorrectly in some cases, my code is rounding correctly, but also more conservative. This could perhaps be optimised, but I think correctnes is more important for now. Now for item (1), the original bug STILL exists. FOP will generate PDF in some cases of embedded SVG which exceeds the capabilities for certain PDF-viewers, c.q. violates the formal PDF specs/constraints. My fix is NOT related to this behaviour. Acrobat 6 is more tolerant than Acrobat 5 for large translations. In Acrobat 5 text and filled areas are drawn correctly, despite large translations (32000), but path objects are drawn incorrectly. In acrobat 6 also path object are drawn better, but still not correct. GNU ghostscript DOES draw the PDF-output correct. I think we agree that the generated PDF should be viewable with at least the recent Adobe products, so a fix for FOP still has to be written, although it probably isn't very easy. (I'm not a PDF-expert, perhaps it IS easy to solve...)
DO NOT REPLY [Bug 23883] - SVG embedded in FO cannot handle large (6digit) translates
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=23883.
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=23883
SVG embedded in FO cannot handle large (6digit) translates
--- Additional Comments From [EMAIL PROTECTED] 2003-11-04 15:13 ---
OK, the cause of the bug is a buggy doubleOut() implementation which
does not expect scientific notation (1.0E-4) for small numbers. The next
implementation (tested in 0.20.5) looks to solve most problems, although
lines are still drawn wrong with at least Acrobat5. I cannot test
with Acrobat6, cause that's not installed at this workstation.
(I'll look at that at home)
=pdf/PDFNumber.java
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);
}
}
DO NOT REPLY [Bug 23883] - SVG embedded in FO cannot handle large (6digit) translates
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=23883. 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=23883 SVG embedded in FO cannot handle large (6digit) translates --- Additional Comments From [EMAIL PROTECTED] 2003-11-04 15:18 --- Created an attachment (id=8916) new output after fix
DO NOT REPLY [Bug 23883] - SVG embedded in FO cannot handle large (6digit) translates
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=23883. 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=23883 SVG embedded in FO cannot handle large (6digit) translates --- Additional Comments From [EMAIL PROTECTED] 2003-11-04 22:06 --- Tom, Couple of comments: (1.) You mentioned another bug earlier in this thread, separate from this issue, that fails in *both* 6.0 and 5.5--it may be good to add that issue in a separate Bugzilla report so it isn't forgotten. (2.) Would you like me to hold off on this patch until you have it working for 6.0? IIRC the code *was* working OK in 6.0 but failing in 5.5--I wouldn't want to apply a patch that would cause the reverse to occur. Thanks, Glen
DO NOT REPLY [Bug 23883] - SVG embedded in FO cannot handle large (6digit) translates
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=23883. 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=23883 SVG embedded in FO cannot handle large (6digit) translates --- Additional Comments From [EMAIL PROTECTED] 2003-10-27 17:16 --- The warnings about the fonts on the Mac turn out to be sth Mac-specific (happens with a number of FOs containing embedded SVG), so I guess this remark can be ignored WRT to this bug... Being quite intrigued by this, I decided to do a little reading in the PDF spec, and found this little note (4.2.3 Graphics - Coordinate Systems - Transformation Matrices) : q When rendering graphics objects, it is sometimes necessary for a viewer application to perform the inverse of a transformation -—that is, to find the user space coordinates that correspond to a given pair of device space coordinates. Not all transformations are invertible, however. For example, if a matrix contains a, b, c, and d elements that are all zero, all user coordinates map to the same device coordinates and there is no unique inverse transformation. Such noninvertible transformations are not very useful and generally arise from unintended operations, such as scaling by 0. Use of a noninvertible matrix when painting graphics objects can result in unpredictable behavior. /q Wonder if this has got sth to do with it... Just an idea... We'll keep looking.
DO NOT REPLY [Bug 23883] - SVG embedded in FO cannot handle large (6digit) translates
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=23883. 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=23883 SVG embedded in FO cannot handle large (6digit) translates --- Additional Comments From [EMAIL PROTECTED] 2003-10-26 08:56 --- Created an attachment (id=8739) SVG result from FO2SVG transformation
DO NOT REPLY [Bug 23883] - SVG embedded in FO cannot handle large (6digit) translates
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=23883. 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=23883 SVG embedded in FO cannot handle large (6digit) translates --- Additional Comments From [EMAIL PROTECTED] 2003-10-25 11:10 --- Indeed a *very* annoying one... ( thx for supplying these extended test files, this was more what I meant :) ) Must correct my earlier mail to fop-dev: the polylines don't get drawn at all, and some of the text-elements have problems
DO NOT REPLY [Bug 23883] - SVG embedded in FO cannot handle large (6digit) translates
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=23883.
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=23883
SVG embedded in FO cannot handle large (6digit) translates
--- Additional Comments From [EMAIL PROTECTED] 2003-10-25 20:28 ---
-Original Message-
From: Thomas DeWeese [mailto:[EMAIL PROTECTED]
Glen Mazza wrote:
to find where Batik is wrong. So far, Squiggle has
drawn the SVG correct *all* the time. But comments
always welcome, and it's good for you to be aware of
the issue.
At least one of the issues is with the PDFGraphics2D.
in PDFGraphics2D.java:632 in draw(shape s). There is
a check for a newTransform which inexplicably decides that
if the new transform is the Identity transform there is
no change.
snip/
I believe the above problem is responsible for the issue
with the blue box. Why the text is 'shifted' is still a bit
of a mystery to me.
'Shifted' - that's indeed what is happening! The rest of the text still
gets 'drawn', but suddenly shifts to coördinates off the scale...
BTW:
Running the map example fo through FOP 0.20.5 on a Mac, I get a few warnings
like the following :
{timestamp} java[837] Font GB18030Bitmap: in _readBasicMetricsForSize, claims 0
max-advance but is fixed-pitch
{timestamp} java[837] Warning: Font LucidaSans-TypeWriterBold claims fixed-
pitch with 0 max advance!
I know Apple's JVM deals with awt differently than Sun's, and since no font is
being specified anywhere in the svg, the awt libs are most probably being used
to obtain a font from the platform for the text to be drawn. Leading to this
output (perhaps these warnings are suppressed on other platforms?)
(Obviously, because of the use of outlined text, strokeSVGText cannot be set to
false. I tried anyway, but that was a killer :) )
In the process, I also noticed that when you run the fo with the embedded svg
through fop to deliver a new svg, then add the resulting svg to a fo via
fo:external-graphic, the text problem disappears.
( the polylines still don't get rendered when viewing with Acrobat 5.0 PC, but
I see them perfectly on Adobe Reader 6.0 Mac ). This was not the case when
using fo:external-graphic on the original svg.
DO NOT REPLY [Bug 23883] - SVG embedded in FO cannot handle large (6digit) translates
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=23883. 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=23883 SVG embedded in FO cannot handle large (6digit) translates [EMAIL PROTECTED] changed: What|Removed |Added AssignedTo|[EMAIL PROTECTED] |[EMAIL PROTECTED] --- Additional Comments From [EMAIL PROTECTED] 2003-10-24 18:30 --- Setting back to fop-dev, so these issues get sent to the developer's list as well. (Also, others may be able to help out... ;)
DO NOT REPLY [Bug 23883] - SVG embedded in FO cannot handle large (6digit) translates
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=23883. 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=23883 SVG embedded in FO cannot handle large (6digit) translates --- Additional Comments From [EMAIL PROTECTED] 2003-10-21 08:50 --- Created an attachment (id=8647) Equivalent SVG file which renders correct with Batik
DO NOT REPLY [Bug 23883] - SVG embedded in FO cannot handle large (6digit) translates
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=23883. 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=23883 SVG embedded in FO cannot handle large (6digit) translates [EMAIL PROTECTED] changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|WONTFIX | --- Additional Comments From [EMAIL PROTECTED] 2003-10-21 08:57 --- Common guys, this has nothing to do with unreasonable precisions. I added the svg file which renders correctly with Batik and Adobe-plugin, as you can see the red line is drawn incorrectly in the FOP PDF result. This is because of the translation is larger than 32768 (16Bit signed!), so there is a short calculation/cast in the part of FOP that renders lines. Note that text and polygons ARE DRAWN CORRECTLY, so this is polyline/PDF-path specific and it only happens in FOP, not in Batik. This bug makes it impossible to render geographic data in GML format, which normally has a large coordinate-space in meters or feet...
DO NOT REPLY [Bug 23883] - SVG embedded in FO cannot handle large (6digit) translates
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=23883. 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=23883 SVG embedded in FO cannot handle large (6digit) translates --- Additional Comments From [EMAIL PROTECTED] 2003-10-21 15:56 --- 1. Remark : We don't have *any* use for the SVG. What we *do* need is a small FO, but not so small that it doesn't show what the error is... If the error only becomes apparent when adding text (or the like), please add the text to the sample FO. 2. Question : What does Batik do with this if you use its rasterizer to make a PDF out of the SVG? Does it render correctly? (If not, this might be due to the 1/72 inch point size...) 3. Remark : You seem to already have a fairly good idea where the problem lies... perhaps you could provide us with a patch to solve it (?) 4. Possible workaround : rasterize the SVG to another graphic format with Batik, then add that to the FO by use of fo:external-graphic.
DO NOT REPLY [Bug 23883] - SVG embedded in FO cannot handle large (6digit) translates
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=23883. 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=23883 SVG embedded in FO cannot handle large (6digit) translates [EMAIL PROTECTED] changed: What|Removed |Added AssignedTo|[EMAIL PROTECTED] |[EMAIL PROTECTED] Status|REOPENED|NEW
DO NOT REPLY [Bug 23883] - SVG embedded in FO cannot handle large (6digit) translates
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=23883. 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=23883 SVG embedded in FO cannot handle large (6digit) translates --- Additional Comments From [EMAIL PROTECTED] 2003-10-18 10:00 --- It's still quite difficult to resolve, unless a more detailed explanation can be given of what exactly the error is here. The supplied FO renders without error messages, the pdf doesn't *show* what is actually going wrong. Is it possible for you to describe in more detail what the intended result is, and to what extent the obtained result deviates from what one would expect? (Also, could it be that the standard PDF point size is causing difficulty here? 1/72 inch. All embedded SVG is inserted as rasterized pdf graphics... Does the same error occur when using the AWT Renderer?)
DO NOT REPLY [Bug 23883] - SVG embedded in FO cannot handle large (6digit) translates
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=23883. 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=23883 SVG embedded in FO cannot handle large (6digit) translates [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WONTFIX --- Additional Comments From [EMAIL PROTECTED] 2003-10-18 17:35 --- Q Note that only the OUTLINE of a polyline is drawn incorrectly (this is not clear from the example). /Q Not clear indeed--like Andreas, I can't see the problem. If I had a 57-inch monitor and blew up the document to 2000% I might be able to see it, but it appears that you're just moving beyond the reasonable mathematical capabilities of FOP and PDF. Again, FOP uses Batik for all SVG--we don't code this. At any rate, your high precision demands would probably suggest you need to explore a commercial alternative.
DO NOT REPLY [Bug 23883] - SVG embedded in FO cannot handle large (6digit) translates
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=23883. 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=23883 SVG embedded in FO cannot handle large (6digit) translates --- Additional Comments From [EMAIL PROTECTED] 2003-10-17 08:44 --- Created an attachment (id=8603) example of incorrect PDF output
DO NOT REPLY [Bug 23883] - SVG embedded in FO cannot handle large (6digit) translates
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=23883. 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=23883 SVG embedded in FO cannot handle large (6digit) translates --- Additional Comments From [EMAIL PROTECTED] 2003-10-17 10:31 --- Note that only the OUTLINE of a polyline is drawn incorrectly (this is not clear from the example). The interior of polylines with 3 or more points is drawn correctly when fill != none. Also text, etc, is drawn correctly so this bug is outline specific.
DO NOT REPLY [Bug 23883] - SVG embedded in FO cannot handle large (6digit) translates
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=23883. 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=23883 SVG embedded in FO cannot handle large (6digit) translates --- Additional Comments From [EMAIL PROTECTED] 2003-10-17 21:11 --- Sir, did you run the SVG portion within Batik (using their Squiggle app) to confirm the problem is indeed with FOP and not Batik? FOP uses Batik for all its SVG--generally speaking, any error within fo:instream-foreign-object tends to be with the tool processing it, here, Batik. You may wish to reroute this bug to the Batik team.
DO NOT REPLY [Bug 23883] - SVG embedded in FO cannot handle large (6digit) translates
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=23883. 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=23883 SVG embedded in FO cannot handle large (6digit) translates --- Additional Comments From [EMAIL PROTECTED] 2003-10-18 05:31 --- The same SVG code runs correctly with Batik so this behaviour is FOP specific
