--- "Andreas L. Delmelle" <[EMAIL PROTECTED]> wrote: > > Thomas, > > Can you perhaps have a look at bug 23883? In > embedded SVG, something's going > wrong with translate() when large numbers are used. > Apparently this works > fine for svg:text elements, but a polyline gets > drawn really ugly... >
Andreas, If you're going to ask for someone's help, please *read* the bug again so you know the latest on the issue. There were changes yesterday that made your description of the problem out-of-date. Also, providing a link to the bug is indicated here--asking Thomas to hunt through Bugzilla in order to help us out--these problems are with our code, not his--is somewhat rude. Furthermore, be careful about dragging users onto the FOP-DEV list. Sometimes it can cause the priority of what we're working on to be skewed to the detriment of the project. Thanks, Glen http://nagoya.apache.org/bugzilla/show_bug.cgi?id=23883 Thomas, You needn't bother on this at this time--we have yet 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. Also, there were changes to the problem yesterday that Andreas apparently didn't read--the problem is basically that the same PDF file (containing certain SVG elements such as polyline) generated by FOP renders fine in Acrobat 6.0 but not in 5.5. Adding to the fun, the user yesterday found other problems where Squiggle runs fine but FOP fails, for *all* Acrobat versions. So this will be an ongoing issue for FOP--also, given the scope of changes needed, perhaps we may be able to make just to our 1.0 branch, the one used by the transcoder. Thanks, Glen __________________________________ Do you Yahoo!? The New Yahoo! Shopping - with improved product search http://shopping.yahoo.com
