Re: SVG 1.2 Comment: 4 Flowing text and graphics

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