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?)
RE: Document Name when printing
-Original Message- From: Clay Leeds [mailto:[EMAIL PROTECTED] Excellent idea. I've never used that fo tag (I'm sure there are many I've never used! I should go take another look at the spec.). It could be as simple as if fo:title[.!=''] 'PrintJobName' = fo:title; else 'PrintJobName'='FOP Document' or something. It could also be toggled with a arg/flag (defaulted to OFF for security reasons!). Michael Reiche wrote: On Tue, 2003-10-07 at 23:53, Clay Leeds wrote: Wouldn't content of fo:title be a logical source of information to append? This remark had got me thinking, and is now responsible for my promised patch taking a bit longer than I first intended... I suppose one would want to have the option of selecting the type of printjob description from the command-line as well. Three options: - 'FOP Document' - 'FOP Document - ' + sourceXML/FO name - 'FOP Document - ' + fo:title Anyway, just realized this can wait. As the FOP Compliance page indicates this object to be unimplemented for the moment... (I *am* reading this right, not? ;)) So don't start relying on that tag just yet. Greetz, Andreas
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.
