- From: Chris Lilley <chris@w3.org>
- Date: Thu, 24 Jan 2013 14:30:25 +0100
- To: "Tab Atkins Jr." <jackalmage@gmail.com>
- CC: Doug Schepers <schepers@w3.org>, www-svg <www-svg@w3.org>
Hello Tab, Wednesday, January 23, 2013, 11:55:04 PM, you wrote: > On Wed, Jan 23, 2013 at 2:52 PM, Doug Schepers <schepers@w3.org> wrote: >> Hi, Tab- >> >> Just one thing for consideration (there are surely many others): >> >> When using stroke with text, typically authors would prefer to have the >> stroke underneath the fill, rather than on top of it, as it is now. >> Otherwise, it gets too muddled. It also wildly changes the perceived shape of the glyphs. > Strongly agree - I think it's extremely easy to show by example why an > "outside" stroke is much more pleasing than a "both sides" stroke, Yes > and > you can simulate the former by painting the fill over the stroke. Which works as long as the fill is fully opaque. Otherwise, you get an unusual double stroke effect that may not be desirable. However, we have also talked about a property that allows the size of the inner and outer portions of stroke to be separately adjusted (the initial values would be 50% of stroke-width in each case) or having a property that shifts the stroke inside or outside (the initial value would be no shift). Either option would give correct stoked and filled text, even with non-opaque fill or stroke. >> We plan to add the capability to SVG 2 to allow the stroke to be under the >> fill, along with other stroke properties. The mechanism we're using is >> ultimately Vector Effects, but I think many of us see value in having some >> "canned effect" properties for common things like stroke-under-fill, >> multi-stroke, non-scaling-stroke, and other things. I'd like to see this >> explored as part of CSS. Yes. Since this is such a common requirement it should certainly be exposed in a convenient syntactic sugar way. And since there may be a need to tweak the defaults, sometimes substantially, its better to have this be a shorthand for vector effects. > This is actually exposed already as part of the paint-order property, > right? You can just specify "paint-order: stroke fill" and it'll > work. Sort-of work. I would prefer to see a more robust solution going forward, that doesn't depend on opaque fill mostly obscuring the artifacts. -- Best regards, Chris mailto:chris@w3.org
Received on Thursday, 24 January 2013 13:30:26 UTC