Re: Why a stroke on top of a fill?

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@jvuletich.org
>> <mailto:juan@jvuletich.org>> 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.html
>>
>> 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

Received on Saturday, 5 June 2010 19:12:13 UTC