Re: Adding winding rules to Canvas

On 1/15/2013 11:24 PM, Charles Pritchard wrote:
> On 1/15/2013 3:13 PM, Rik Cabanier wrote:
>>
>> It’s great to see a proposal here. I strongly feel we should allow 
>> developers to select either non-zero winding rule or even-odd rule, 
>> just like other graphics technologies. I prefer this proposal instead 
>> of introducing new functions for developers to learn, e.g., eoFill(), 
>> eoIsPointInPath(), and eoClip().
>>
>
> By and large, we've switched to even-odd and there are some strange 
> patents covering the conversion process.

Sorry about the lack of editing (my poor writing/posting) -- what I ment 
is that we've gone with non-zero for many years....

This was introduced as a method many years ago when ttf and other fonts 
were converted to t1a and used successfully to generate text, before 
canvas supported fillText.

fillText and the hit testing regions allowed for additional measures to 
be taken on the OS side -- which is really what I'd like to see the API 
focused on -- items where transparency to the OS is necessary.
It's a requirement that text be passed to the OS for a11y.

With issues like conversion of paths, it's merely a matter of 
pre-processing or of algorithms. Other issues very much depend upon the 
transparency or opacity of implementation layers.

I'll further remind the list that the WHATWG API was solely written by 
one author in reflection of group discussions about use cases. While I 
have previously commented that the WHATWG proposal was written by two 
people (Atkins and Hixie), it's been very publically stated that the 
current draft was written by one author and in no way reflects an API 
written by any other person. This API has not been implemented by any 
vendor and is quite flexible to input.

If we want to make extensions, nothing is written in stone, nor is it 
written in code.

I think we've made great progress in developing consensus around the 
need for a path method that accepts SVG strings. We've further agreed to 
delegate the meaning of SVG strings to the SVG/FX working group.

This is a good move; the code path and the responsibility for 
development rests with SVG. Other items might be better discussed over 
on that end.

In the meantime, it'd be great to see simple methods implemented in 
current browsers, like IE, Opera, Mozilla, Chrome and Safari.

-Charles