W3C home > Mailing lists > Public > www-svg@w3.org > November 2004

Re: SVG 1.2 Comment: 4 Flowing text and graphics

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
Message-ID: <Pine.LNX.4.61.0411101145270.8631@dhalsim.dreamhost.com>

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

This archive was generated by hypermail 2.3.1 : Wednesday, 5 February 2014 07:14:52 UTC