In article <[EMAIL PROTECTED]>, Thomas DeWeese <[EMAIL PROTECTED]> wrote:
I agree this is a bug, but it appears to be in the Mac OS X JVM not in Batik.
It is getting really frustrating to keep hearing this as an excuse for why Batik doesn't work. Even if it's true, it indicates that Batik is
archutected to depend on the underlying platform too tightly.
By using the facilities provided by java.awt.Graphics2D? How else do you want us to draw things? We certainly aren't about to rewrite Java2D from the ground up.
The whole point of a JVM is provide independence from the underlying platform the problem is that currently the Mac OS JVM doesn't do a very good job of this, especially in the graphic arena. People just need keep the pressure on Sun/Apple to fix the areas of serious divergence.
I actually think Apple is doing the right thing by reimplementing Java2D on top of Quartz but they need to keep at it and deal with all these lingering issues.
Isn't there any hope of something like batik-rasterizer that will produce pixel-for-pixel identical results on all platforms?
If someone want's to provide a pure Java implementation of the Graphics2D interface it would be trivial to use that instead of the platform provided version - but this is a huge undertaking - and likely that version would also have bugs in corner or degenerate cases not to mention almost certainly being much slower (currently essentially all drawing is done in native code).
In the end you would likely end up with three different renderings - the pure software - the Window/UNIX - the Mac OS - because they would all have differnt code under the hood - some would work better some worse, sure it might be nice to be able to pick and choose but who is writting a pure Java version of Graphics2D (and most of the rest of java.awt?).
Sorry but I won't take responsability for these issues!
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
