[whatwg] Stroking algorithm in Canvas 2d
junov at google.com
Wed Oct 16 06:58:04 PDT 2013
On Tue, Oct 15, 2013 at 7:18 PM, Ian Hickson <ian at hixie.ch> wrote:
> On Thu, 10 Oct 2013, Rik Cabanier wrote:
> > On Thu, Oct 10, 2013 at 12:25 PM, Justin Novosad <junov at google.com>
> > >
> > > http://jsfiddle.net/ZxR6P/1/
> > Yes, that looks like "Align dashes to corners and path ends"
> I've filed a bug for this:
> This thread now is mainly about what the default should be.
> Fair enough. I've changed the spec to reset at new subpaths.
> On Fri, 11 Oct 2013, Justin Novosad wrote:
> > So far, there are a few differences between the spec and the graphics
> API I
> > work with (skia) that attracted my attention:
> > 1) the line caps on individual dashes: this is not yet resolved, and it
> > pretty far on my to do list (low volume of complaints)
> My understanding is that the specced behaviour here matches SVG, right?
Yes the spec is fine in this respect, and it turns out that Blink is not as
broken as I initially thought it was when I wrote that.
> > 2) the way of handling dash sequences with an odd number of elements
> > (concatenate the sequence onto itself to make it even): this was easy to
> > resolve, although I have reservations about this. I think it may feel
> > unnatural to many graphics designers.
> What's the alternative? Implying a zero at the end? I don't have a strong
> opinion on this, though it does seem more useful to treat  as [3,3]
> than as [3,0].
No, I don't mean an implied zero. I meant that at every iteration over the
dash pattern, the pattern is inverted if it has an odd number of elements
(blanks become dashes and vice versa). This would render exactly the same
as what is currently in the spec, which is consistent with SVG. The only
difference is that there is no doubling of the array. If the array needs
to be doubled in order to work with the underlying graphics API, that
should be the UA's business and it should be hidden under the hood.
More information about the whatwg