[whatwg] fillRule changes

[Rik Cabanier]

On Thu, Apr 25, 2013 at 6:00 PM, Ian Hickson <ian at hixie.ch> wrote:

>
> Since browsers implemented a different fillRule API than what the spec
> had, I've updated the spec to better match implementations.
>
> Because the browsers just went ahead and implemented this, I didn't end up
> responding to the feedback on this topic, since the reply to all that
> feedback is "the spec now says what the browsers implemented". :-)
>
> Comments below on orthogonal comments in those same e-mails:
>
> On Thu, 3 Jan 2013, Rik Cabanier wrote:
> > > > > On Wed, 2 Jan 2013, Rik Cabanier wrote:
> > > > > >
> > > > > > this features is not a trivial as it seems. Adding this will
> > > > > > necessitate updates to the algorithms that deal with paths and
> > > > > > the outlining of strokes and text.
> > > > >
> > > > > Can you elaborate on what updates are needed? I couldn't see any
> > > > > that actually needed to be changed.
> > > >
> > > > One of the intents of the path object is so you can 'accumulate' the
> > > > regions that were drawn so you can set them up as hit regions.
> > >
> > > It is? I don't think that's one of the use cases I've seen before.
> > > It's an interesting use case, though, true.
> >
> > A region can be a bunch of shapes so I assumed that the path object was
> > designed to accommodate this. For instance a stroked rectangle would be
> > a region and consist of a rect path and the stroked rect path.
>
> Well you can certainly do that, sure, and we could provide an API that
> combines paths as a union rather than just adding the path segments
> (indeed at one point we had that in one of the earlier strawman
> proposals), but that's not one of the use cases that Path was originally
> designed for. The idea is that you'd just create separate regions for each
> of the paths, rather than combining them and having one region. The net
> result is the same.
>

I think an author would expect that 'addPathByStrokingPath' and other path
methods render as if you stroked/outlined directly on the canvas context.
Same goes for 'addPath'.

I believe very few people actually want the current behavior that's in the
spec.


>
>
> > I think the spec needs to mention that
> > - sections of the path where both edges are filled should be removed
> > - winding needs to be done so eofill and fill give the same result
>
> I've filed a bug for adding something like this:
>
>    https://www.w3.org/Bugs/Public/show_bug.cgi?id=21835
>
> I'm not sure exactly what the algorithm should be (as we discussed on IRC
> today), so if anyone has any input here, please don't hesitate to comment.
>

I can help if needed. I know the skia people are working on this as well.

The algorithm is fairly straightforward to describe in prose.
Implementation is very hard though...


>
>
> On Wed, 9 Jan 2013, James Ascroft-Leigh wrote:
> >
> > How can the presence of the winding rule parameter of the fill() and
> > clip() operations be detected by client code?  Perhaps I missed
> > something in the discussion.
>
> On Wed, 9 Jan 2013, Boris Zbarsky wrote:
> >
> >   var ruleArgSupported = false;
> >   try {
> >    ctx.fill({ defaultValue: function() { ruleArgSupported = true; return
> false; } });
> >   } catch (e) {
> >     // Really shouldn't happen, but who knows
> >   }
>
> Since the browsers ended up implementing this as an enum, this will work:
>
>   var ruleArgSupported = false;
>   c.fill({ toString: function() { ruleArgSupported = true; return
> 'evenodd'; } });
>
>
> On Tue, 15 Jan 2013, Simon Sarris wrote:
> >
> > The current *fillRule *rules in the specification seem incomplete or at
> > least ill-defined with respect to consideration of hit regions.
>
> I've added a fillRule argument to the HitRegionOptions dict.
>
> --
> Ian Hickson               U+1047E                )\._.,--....,'``.    fL
> http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
> Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
>