Hi, Folks-
As I understand it, this treatment of stoke-over-fill and inner-and-outer stroke is a pretty standard convention. It's certainly the way that Adobe Illustrator handles stroke and fill, which is why (I believe) SVG does it that way. But when it comes down to it, it is an arbitrary decision... they had to specify one particular behavior.
That said, we recognize that content authors may wish to have some different options, which is why we are specifying Vector Effects... to allow fine-grained control over the appearance.
A couple more comments inline...
Jasper van de Gronde wrote (on 6/5/10 4:15 AM):
Why not take it to the SVG mailing list directly? (Note that I've taken the liberty to change the subject.) My guess would be that SVG does it for simplicity, but I'm definitely not sure.
Bryan Hoyt | Brush Technology wrote:
That particular oddity has annoyed me a few times. I for one like your way much better, Juan. But I guess I'd be in favour of sticking with the standards if the standards people have no room for movement. Usually safest ;-)
It is absolutely too late to change SVG to have different behavior here, even if everyone agreed that this should be the expected behavior. With the new options through Vector Effects, I think we can meet all the use cases. Authoring tools could then choose which behavior to have as a default, depending on what makes sense for the anticipated users.
There's a related oddity in Inkscape's rendering (and probably the standards), the fact that the border is drawn so that it overlaps the fill rather than surrounding it. To be honest, the idea of the stroke surrounding the fill (non-overlapping) makes a lot more intuitive sense to me, especially when you've got thick and/or translucent strokes like Juan's example.
There are ways in SVG 1.1 to get the different effects you're describing, based on combining properties. If you set the 'fill-opacity' and 'stroke-opacity' separately, they are composited together *after* the opacity is applied, but if you set them simultaneously with the 'opacity' property, they are composited together *before* the opacity is applied, so they will be treated as a single graphic primitive (i.e. there won't be any fill visible through the stroke). You can see this in the example file I threw together [1].
Is somebody able to explain why the overlapping method is used, either for intuitive reasons or technical reasons? Or is it just an arbitrary choice by those who write the standards?
As mentioned, it's an arbitrary (but logical) choice, based on pre-existing implementations of vector graphics.
Bryan Hoyt, /Web Development Manager/ -- Brush Technology *Ph:* +64 3 942 7833 *Mobile:* +64 21 238 7955 *Web:* brush.co.nz http://brush.co.nz/ On Sat, Jun 5, 2010 at 01:48, Juan Vuletich <juan@...2357... mailto:juan@...2357...> wrote:
Hi Folks,
Inkscape and other SVG renderes draw shapes by drawing first the fill, and then drawing the border on top. As Ivan noted recently (in ""), at http://dev.w3.org/SVG/modules/vectoreffects/master/SVGVectorEffectsPrimer.ht...
and http://www.w3.org/TR/SVGTiny12/render.html#PaintingShapesAndText , it is clear that the standard requests to do that.
I didn't know that, and took the time to render this svg: http://www.jvuletich.org/Morphic3/rects.svg like this: http://www.jvuletich.org/Morphic3/rectsInM3.png . It is a bit more complicated, but I feel it is better.
What do you think? Should I simplify my code and just draw one over the other? Or should the standard be changed, and Inkscape and other renderers do what I did?
I strongly suggest you not exhibit non-standard behavior. That's what standards are for... so content authors can rely on predictable behavior across implementations.
[1] http://schepers.cc/svg/opacity-tests.svg
Regards- -Doug Schepers W3C Team Contact, SVG and WebApps WGs