W3C home > Mailing lists > Public > whatwg@whatwg.org > October 2013

Re: [whatwg] Stroking algorithm in Canvas 2d

From: Justin Novosad <junov@google.com>
Date: Wed, 16 Oct 2013 09:58:04 -0400
Message-ID: <CABpaAqQtiXdKTBv3BfDg_BrjDJbnzcdQg5vEv3Pb4hkgtUeYeg@mail.gmail.com>
To: Ian Hickson <ian@hixie.ch>
Cc: "whatwg@whatwg.org" <whatwg@whatwg.org>
On Tue, Oct 15, 2013 at 7:18 PM, Ian Hickson <ian@hixie.ch> wrote:

>
> On Thu, 10 Oct 2013, Rik Cabanier wrote:
> > On Thu, Oct 10, 2013 at 12:25 PM, Justin Novosad <junov@google.com>
> wrote:
> > >
> > > http://jsfiddle.net/ZxR6P/1/
> >
> > Yes, that looks like "Align dashes to corners and path ends"
>
> I've filed a bug for this:
>    https://www.w3.org/Bugs/Public/show_bug.cgi?id=23528
>
> This thread now is mainly about what the default should be.
>

Great, thanks!


>
> 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
> is
> > 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 [3] 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.
Received on Wednesday, 16 October 2013 13:58:31 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 17:00:12 UTC