- From: Thomas DeWeese <Thomas.DeWeese@Kodak.com>
- Date: Fri, 05 Nov 2004 19:56:09 -0500
- To: Ian Hickson <ian@hixie.ch>
- CC: Tobias Reif <tobiasreif@pinkjuice.com>, www-svg@w3.org
Ian Hickson wrote: > That doesn't seem to be a complaint about Batik not matching Adobe's > anti-aliasing algorithm so much as a complaint that Batik's algorithm is > poor. The difference is that by default Batik (well Java2D really) moves the end point to an integer location for stroking operations. This means that the end point moves at most .5 a pixel. This really is in the realm of anti-aliasing. Incidentally, the one that was foremost in my mind was this message: http://nagoya.apache.org/eyebrowse/ReadMsg?listId=53&msgId=1892032 > Mozilla (for instance) gets similar complaints about its line > breaking algorithm ("you don't break this very long word at the hyphen!") > but that doesn't mean the line breaking algorithm needs to be specified. The point is that someone was complaining because in Batik the curve had a pretty minor difference in the way it was rendered. When someone's caption or notation text wraps different the difference will be _quite_ a bit larger and I am certain that they will, quite rightly, complain that it isn't the same. Remember we are in the same space as 'PNG' - where artists can be 100% certain that they get the same thing everywhere. We aren't going to offer pixel level matching but we can't be moving words from one line to another. I don't know if you missed it or not but the main problem I see is that the text can flow 'out the bottom' of a flow region - in which case the text is just gone. In a graphic there is a very big difference between two lines of text and three, this isn't HTML/CSS where the region just grows. Even if we did allow the region to grow there is a good chance that other graphics will cover the 'third' line. > Indeed, it merely makes it an area that renderers can compete in. This is a good thing, to a point, but when renderers produce results that diverge too much artists will stop using it and will return to JPG and PNG - which for images with text is obviously a huge loss.
Received on Saturday, 6 November 2004 00:56:10 UTC