On Jan 4, 2013, at 5:24 PM, Rik Cabanier <caban...@gmail.com> wrote:

> 
> 
> On Fri, Jan 4, 2013 at 2:57 PM, Ian Hickson <i...@hixie.ch> wrote:
> On Fri, 4 Jan 2013, Rik Cabanier wrote:
> >
> > I think this feature was rushed in the spec.
> 
> The specing is usually the first step. You can't rush to spec. :-)
> 
> In this particular case, though, it was the third or fourth step. The
> discussion has been open since June 2011. It's not like people didn't have
> time to comment. It's been shipping in a browser for over a year.
> 
> Any solution we come up with to the issues that were raised regarding Path
> will almost certainly be done in a way that builds on context.fillRule,
> not in a way that removes context.fillRule.
>  
> I was not aware of that discussion.
> There are good reasons to make the fill rule part of the fill operation 
> itself. It does not make sense in the graphic state.
> 
> How about EOClip? That is a construct that is far more used than eofill. Will 
> that get its own parameter too?

It will use the same property, since there is no difference. That is why the 
name could be a bit misleading. windingRule would be a bit more independent of 
the fill operation.

> How about the interaction of stroking and this parameter (if you follow the 
> spec's wording for stroking)?

This needs to change as well to match the new behavior. This is more a 
specification problem and no implementation problem.

> How about ispointinpath? Will that follow the winding rule in the graphic 
> state?

It would depend on the fillRule that you set on the context.

> How about hit regions? How can you specify the winding there?

This is a good point. But it depends if hit region will be implemented as 
specified.

> 
> It's better to follow what almost every other graphics library has done: Add 
> an EOFill and an EOClip.
> I volunteer to add it to Mozilla if it helps.

That is not fully correct. Just Qt and Skia make it explicitly on the Path 
object (which is not necessarily depending on the fill operation itself). CG 
does not bundle EOfill with a path, instead you set it during painting. Which 
is partly as done by the specification, with the exception that it is not part 
of the graphic state, but also not part of the path logic. Cairo graphics has 
the fill rule as part of the graphic state IIRC.

This discussion is a bit misplaced on webkit-dev. Could you continue it on the 
WHAT WG mailing list please?

I would just agree with Rik here, that we should wait a bit more time before 
implementing it in WebKit. Even if following the Firefox implementation and the 
needs of PDF.js is a good reason for implementing as suggested by the spec.

Greetings,
Dirk


> _______________________________________________
> webkit-dev mailing list
> webkit-dev@lists.webkit.org
> http://lists.webkit.org/mailman/listinfo/webkit-dev

_______________________________________________
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev

Reply via email to