- From: Ian Hickson <ian@hixie.ch>
- Date: Wed, 10 Nov 2004 11:50:59 +0000 (UTC)
- To: Thomas DeWeese <Thomas.DeWeese@Kodak.com>
- Cc: Tobias Reif <tobiasreif@pinkjuice.com>, www-svg@w3.org
On Fri, 5 Nov 2004, Thomas DeWeese 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 Right -- but again, this is someone saying "Adobe is better, please improve your antialiasing", not "Please implement Adobe's antialiasing algorithm". The point being you could implement an algorithm _even better_ than Adobe's, and then people would complain to Adobe (assuming Adobe's algorithm isn't above the "good enough" level at which point people don't care anymore). This is why I don't think SVG particularly needs to state specific algorithms -- not just not for line breaking, but also not for many of the areas where it has "rendering hint" properties. Just let the UAs work out the best algorithm, or range of algorithms, and when to apply them. > 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. The same will be able to happen with user stylesheets that specify large font sizes, etc. Defining the exact word wrapping algorithm doesn't solve this. > 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. I am finding it very hard to believe that an explicit word wrapping algorithm, or lack thereof, would have any effect here. I could be wrong, of course, but it seems unlikely. Authoring techniques would probably evolve to say "always include at least one extra line for when the fonts are slightly bigger than you expect", but that's no big deal, it happens today with HTML. -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Received on Wednesday, 10 November 2004 11:51:02 UTC