W3C home > Mailing lists > Public > www-svg@w3.org > December 2008

Re: Antialiasing and adjacent shapes

From: Doug Schepers <schepers@w3.org>
Date: Fri, 26 Dec 2008 14:50:50 -0600
Message-ID: <495543AA.7030506@w3.org>
To: Johannes Rössel <johannes.roessel@uni-rostock.de>
CC: www-svg@w3.org

Hi, Johannes-

I've run into this problem myself many times, and I don't know any
workarounds (though possibly using sub-pixel float values might help).
It occurred even in patterns (at least in the Adobe viewer), like hex
grids, at certain zoom levels; I would have expected that in a pattern,
where the intent was pretty clearly to have adjacent shapes share lines
(or at least optimize anti-aliasing effects), a viewer would not show
these artifacts... but alas, it was not the case.

Maybe there could be some rendering hint added to the language that
specifically addresses adjacent shapes or overlapping strokes... but
honestly, I'm not sure what this could be, or how easily it could be
implemented.  I'd welcome detailed proposals that we could bring to the
SVG WG and implementers, to try to solve this issue; note that the
syntax alone would not be enough... there would have to be some
algorithmic way to address the issue in an interoperable way for
multiple viewers, which would have to account for elements of different
sizes and shapes, which have only short runs of overlapping lines
(either strokes or shape perimeters).  Your example of four rectangles
is pretty much the simplest case, and as you point out, there are much
more subtle shapes, such as diagonals or overlapping curves, that would
also need to be taken into account.

One possible way to express such intent is a rendering hint that
piggybacks on the proposed layout extensions module, where we would
allow shapes to be positioned relative to other shapes (rather than
relative to the viewport alone).  So, if there were a shape with a
concave curve that was positioned relative to a circle, and which shared
a tight border and some of the same curve geometry, setting a rendering
hint would composite the edges relative to the colors of those shapes,
rather than doing antialiasing against the background color.  Or something.

I suspect this is a really tricky problem, but it's a pretty common use
case, and maybe there are known ways to solve it.  I'll bring it up at
an upcoming SVG meeting.

Regards-
-Doug Schepers
W3C Team Contact, SVG and WebApps WGs

Johannes Rössel wrote (on 12/26/08 4:51 AM):
> 
> Hello,
> 
> is there any part of the SVG specification that governs how things like
> 
> <?xml version="1.0" encoding="UTF-8" standalone="no"?>
> <!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.1//EN"
> "http://www.w3.org/Graphics/SVG/1.1/DTD/svg11.dtd">
> <svg xmlns="http://www.w3.org/2000/svg" width="100" height="100">
>   <g fill="#000" stroke="none">
>       <rect x="10" y="10" width="10" height="10"/>
>       <rect x="20" y="10" width="10" height="10"/>
>       <rect x="10" y="20" width="10" height="10"/>
>       <rect x="20" y="20" width="10" height="10"/>
> 
>       <rect x="70" y="70" width="20" height="20"/>
>   </g>       </svg>
> 
> should be rendered? I. e. where shapes are exactly adjacent to each other.
> 
> Intuitively I'd say both visible squares (of 20 px edge length) should
> look exactly the same, but in fact seemingly due to antialiasing
> (shape-rendering='crispEdges' seems to help in FF and WebKit, though not
> in Inkscape) there are lines introduced within the shape. Collapsing
> adjacent shapes into a single path would work as well but this is
> sometimes cumbersome for automatically generating SVG files.
> 
> See http://hypftier.de/temp/svg_adjacent_shapes.png for an image example.
> 
> I see this phenomenon as an unwanted side-effect and setting
> shape-rendering to crispEdges only helps with shapes that only have
> horizontal or vertical edges.
> 
> Or is there another method to suppress this I haven't found yet?
> 
> Regards,
> Johannes Rössel
> 
Received on Friday, 26 December 2008 20:51:01 GMT

This archive was generated by hypermail 2.3.1 : Friday, 8 March 2013 15:54:41 GMT