This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
Strokes are not done using winding. I've posted a couple of posts on the mailing list that list how the current algorithm for stroking is not correct. However we finally figure out how it should be done, isPointInStroke should not say anything about winding.
isPointInStroke converts the path to another path, and then tests for a hit inside the area of that other path. You need to use a winding to test for a hit inside a path.
(In reply to Ian 'Hixie' Hickson from comment #1) > isPointInStroke converts the path to another path, and then tests for a hit > inside the area of that other path. You need to use a winding to test for a > hit inside a path. It seems that we're going in circles. Your algorithm is not correct and produces paths that can't be expressed as path primitives. The spec should just describe how the path should look. The code that converts this to a path should outline it and produce paths that can be filled with any fill rule.
Is the problem with the algorithm filed as a bug, or as e-mail? If as a bug, please mark this one as blocked on that one. If e-mail, can you remind me of the subject line so I can look up whether or not it's still in my pending folder?
(In reply to Ian 'Hixie' Hickson from comment #3) > Is the problem with the algorithm filed as a bug, or as e-mail? If as a bug, > please mark this one as blocked on that one. If e-mail, can you remind me of > the subject line so I can look up whether or not it's still in my pending > folder? email. See thread: http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2013-September/040920.html
I didn't see anything in those e-mails that explained why the algorithm "produces paths that can't be expressed as path primitives". Can you elaborate on that? > The spec should just describe how the path should look. The code that > converts this to a path should outline it and produce paths that can be > filled with any fill rule. As far as I can tell, that's what it does. Can you be more specific about how it doesn't do that? Feel free to close this bug and just move the discussion to e-mail if you like. Or to reply to the e-mail in this bug instead of by e-mail.
(In reply to Ian 'Hixie' Hickson from comment #5) > I didn't see anything in those e-mails that explained why the algorithm > "produces paths that can't be expressed as path primitives". Can you > elaborate on that? From one of the threads: A stroked bezier curve is no longer a bezier and has to be calculated. So, curve become higher order and have to be approximated with beziers. > > > The spec should just describe how the path should look. The code that > > converts this to a path should outline it and produce paths that can be > > filled with any fill rule. > > As far as I can tell, that's what it does. Can you be more specific about > how it doesn't do that? It's partly there. It's just skipping over the difficult parts (such as inflating) and wrong about others (such as dashing). By 'describe', I mean that it should have drawings of how the strokes, line caps and line joins should look and be silent on how to actually implement it.
> So, curve become higher order and have to be approximated with beziers. Sure, so? Why is approximating a problem? It's not like we're doing pure math paths here, they're all approximated at the end of the day. The spec doesn't specify how you implement it exactly, it just requires that we have consistent results that, within the limitations of the hardware (e.g. only 1 pixel for every 10 microns) are indistinguishable from the theoretical results. > > > The spec should just describe how the path should look. The code that > > > converts this to a path should outline it and produce paths that can be > > > filled with any fill rule. > > > > As far as I can tell, that's what it does. Can you be more specific about > > how it doesn't do that? > > It's partly there. It's just skipping over the difficult parts (such as > inflating) The spec text has changed on this (see the e-mail). If there's ambiguity left, let me know (either on the e-mail, or, reply to the e-mail here and we'll move all the discussion to one place). > wrong about others (such as dashing). That's unclear to me. See the e-mail. Feel free to reply either in the e-mail or here (please not both though...). > By 'describe', I mean that it should have drawings of how the strokes, line > caps and line joins should look and be silent on how to actually implement > it. Why would _drawings_ be better than normative text? That makes no sense. You can't write normative specifications with sample drawings. Or at least, if you can, I certainly haven't seen it done before. Spec by example is not the level of quality that we expect at the WHATWG.
Are there any remaining issues to deal with for this bug, or was it solved by the thread in the WHATWG?
(In reply to Ian 'Hixie' Hickson from comment #8) > Are there any remaining issues to deal with for this bug, or was it solved > by the thread in the WHATWG? This was clarified by your latest changes and me better reading the spec.
Cool, thanks.