- From: Ian Hickson <ian@hixie.ch>
- Date: Thu, 3 Jan 2013 23:38:01 +0000 (UTC)
- To: Chris Jones <cjones@mozilla.com>, James Ascroft-Leigh <jwal@jwal.me.uk>, Dirk Schulze <dschulze@adobe.com>, Rik Cabanier <cabanier@gmail.com>
- Cc: whatwg@whatwg.org
On Fri, 10 Jun 2011, Chris Jones wrote: > > In 2D canvas, determining whether a point is "inside" a path is > currently always done using the non-zero winding rule. I propose > extending 2D canvas to allow determining inside-ness using the even-odd > rule. I've added this to the spec. On Wed, 2 Jan 2013, Dirk Schulze wrote: > > There was a complain on the webkit bug report if fillRule should be part > of the graphics state or not. Did you investigate what current 2d > graphics libraries do (qt, Cairo, CG, ...)? Is it part of the graphics > state there? 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. 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. > 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. > In addition, the path object will need to be extended so it can deal > with this idiom. Can you elaborate on how this affects the Path object? It seems like it would be somewhat orthogonal. > 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". :-) 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? > (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... > Dirk and I did a bit more research and found that SVG, PDF, Flash, > PostScript, Skia, Core Graphics and Direct2D all have the winding rules > as part of the fill operator. It seems strange that canvas would choose > to have a different interface... People using the canvas API are more likely to know the canvas API, and thus want extensions to be consistent with the canvas API, than they are to be familiar with PDF, Flash, PostScript, Skia, Core Graphics, or Direct2D. Incidentally, of those, I'm only familiar with SVG, and SVG is similar to what I specced (indeed I don't see how it could be part of the operator since it's a declarative language). -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Received on Thursday, 3 January 2013 23:38:25 UTC