On Jan 4, 2013, at 7:28 PM, "Rik Cabanier" <caban...@gmail.com<mailto:caban...@gmail.com>> wrote:
On Fri, Jan 4, 2013 at 5:42 PM, Dirk Schulze <dschu...@adobe.com<mailto:dschu...@adobe.com>> wrote: On Jan 4, 2013, at 5:24 PM, Rik Cabanier <caban...@gmail.com<mailto:caban...@gmail.com>> wrote: > > > On Fri, Jan 4, 2013 at 2:57 PM, Ian Hickson > <i...@hixie.ch<mailto: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. That is a problem. Now you will have to set the parameter before the clip and set it back again right after (since you can't use save/restore since it blows away the clip) I don't see the problem here. That is how canvas works currently. fill() and clip() use the currentPath. Seems to be more natural to use the property then. > 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. I agree. However, user agents didn't have to really think about this before but they will have to in the future. Making it part of the state will make it much more difficult to implement cleanly. Not at all, as demonstrated with the patch. > 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. Core graphics has indeed no support for paths (just like the current canvas implementations) However, it does have 'CGContextEOClip' and 'CGContextEOFill' that works on the current path which is what I propose we should do. No, because the path is already applied to the context. That makes the property so natural and easy to implement. 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 agree. However, if people didn't follow that mailing list, they would think that everything is sorted out since Ian emailed this list to say that it is in the spec . Right. 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. If it's for PDF, then a graphic state variable is not the way to go since PDF does not have this either. PDF.js - the JavaScript library. Not PDF the standard. And the library uses it already according to previous posts. Greetings, Dirk Greetings, Dirk > _______________________________________________ > webkit-dev mailing list > webkit-dev@lists.webkit.org<mailto: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
