--- "Andreas L. Delmelle" <[EMAIL PROTECTED]>
> 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...


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.




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.


Do you Yahoo!?
The New Yahoo! Shopping - with improved product search

Reply via email to