- From: Doug Schepers <schepers@w3.org>
- Date: Fri, 26 Dec 2008 14:50:50 -0600
- 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 UTC