- From: Rik Cabanier <cabanier@gmail.com>
- Date: Sat, 24 Nov 2012 09:03:36 -0800
- To: Ian Hickson <ian@hixie.ch>
- Cc: whatwg@whatwg.org
On Sat, Nov 24, 2012 at 8:36 AM, Ian Hickson <ian@hixie.ch> wrote: > On Sat, 24 Nov 2012, Rik Cabanier wrote: > > > > > > > > How about the strokes? > > > > > > The example in the OP didn't have them, but you'd have to include them > > > in the fill area. With the new Path objects, you'd just use > > > addPathByStrokingPath(), which would be relatively simple. > > > > Unfortunately the winding rules will mess up your shape. (non-zero > > winding) > > > > Take for instance a stroked circle. The stroke which is added with > > addPathByStrokingPath will always create a hole so you end up with a > > donut instead of just a slightly larger circle. > > Right: > > > > So long as they don't overlap, that's not generally a problem. But > > > sure, for some complex shapes you'd need some new feature or other, > > > whether it's in shadows or path construction or elsewhere. > > In the case of a circle, if you wanted to draw the inner shadow over the > stroke and the fill, you'd have to create the path as just a fill with the > radius increased by half the line width. > > That seems like a heavy burden to place on the developer. Hopefully there are no round joins, endcaps or dashes. I think addPathByStrokingPath is almost useless. Those methods should all do unions...
Received on Saturday, 24 November 2012 17:32:44 UTC