- From: Ian Hickson <ian@hixie.ch>
- Date: Fri, 4 Jan 2013 00:58:52 +0000 (UTC)
- To: Rik Cabanier <cabanier@gmail.com>
- Cc: whatwg@whatwg.org
On Thu, 3 Jan 2013, Rik Cabanier wrote: > > > > I have made it be part of the graphics state in the spec; it would be > > unusual in the API for it not to be. However, if this doesn't match > > implementations, please let me know. > > Do you mean browser implementations or graphic libraries? AFAIK all > graphic libraries except cairo are different. I'm unsure about the > browsers. Implementations of the spec (i.e. browsers). > > 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. > This means that a hit regions can contain shapes that were drawn with > different winding rules. The current path syntax does not allow you to > store this information so you can't set up a hit region that was drawn > with an [even-odd fill]. The Path objects just store paths, not filled shapes, so you can't really store non-zero-based shapes any more than even-odd-based shaped, if you're going to mix them. If this (the region accumulation thing) is a use case we should support, then we need a way to add paths together in a way that converts all the paths to a specific fill rule type (ideally to be agnostic of the rule). > > > As Dirk mentioned, instead of making it part of the graphics state, > > > it's more likely better to make it part of the fill or clip operator > > > like SVG, PDF and PostScript. > > > > That seems like it would be inconsistent with the rest of the canvas > > API. > > Winding is specific per draw and unlikely to persist across several draw > commands. This makes it different than color or the stroke style. I'd have thought that would make it exactly like the stroke style. > > > The easiest way to implement this, would be to leave the core > > > interface of canvas alone and just extend the path object with > > > winding rules and a method to 'simplify' a path so it can be drawn > > > with any winding rule. > > > > This doesn't seem like it would be easier... in particular, fillRule > > is now implemented in two browsers, so the implementation cost for > > them would be zero, and they don't yet implement Path at all, so the > > implementation cost for Path would be quite high, even without > > "simplify". :-) > > It's easier because of all the other work that's necessary to make this > feature work correctly. So, yes, it is easier now because they don't > rely on the spec to implement stroking and they don't have an > implementation for paths. > > However, the spec is supposed to be followed (right?) and at some point, > paths should be implemented. Going the easy way now will give a headache > later. I'm happy to defer to the browsers vendors on this -- browser vendosr, what would be simpler for you to implement? > > On Wed, 2 Jan 2013, Rik Cabanier wrote: > > > > > > However, just look at how stroke is implemented in the Canvas 2d > > > spec or how you can create paths by stroking or stroked text. > > > They're all affected by the winding rules. > > > > How so? > > For instance, take a figure eight that is stroked. If you draw it out, > you will see that you cross 2 lines to get to the middle which means > that there will be a gap when doing an [even-odd fill]. Could you elaborate on this? How would you propose this should be changed? > > > (The description on how to do strokes in the spec is very wrong, but > > > that can be addressed later) > > > > Can you elaborate on this? If there's a mistake obviously I'd like to > > fix it... > > I'm unsure where to begin... If you could just file bugs for each mistake, that would be great. http://whatwg.org/newbug -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Received on Friday, 4 January 2013 00:59:15 UTC