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

Re: [whatwg] Stroking algorithm in Canvas 2d

From: Justin Novosad <junov@google.com>
Date: Tue, 15 Oct 2013 10:38:32 -0400
Message-ID: <CABpaAqTZ0fPOTLAKXvXkyq-6oNYZQCga2+CfLrfpFhPec3c=9w@mail.gmail.com>
To: Rik Cabanier <cabanier@gmail.com>
Cc: Ian Hickson <ian@hixie.ch>, "Jasper St. Pierre" <jstpierre@mecheye.net>, syhann@adobe.com, "whatwg@whatwg.org" <whatwg@whatwg.org>
On Mon, Oct 14, 2013 at 1:54 PM, Rik Cabanier <cabanier@gmail.com> wrote:

> On Fri, Oct 11, 2013 at 6:17 AM, Justin Novosad <junov@google.com> 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)
> Can you tell me what is wrong with line caps on dashes? Is that your
> proposal to not have dashes on join and endcaps?

I just re-tested this, and it looks like the problem was partially fixed
under my radar (a skia improvement probably?).  There is still the issue
that dashes of length 0 are not being rendered in Chrome. When using round
lineCaps, for example, a dash of length 0 should be rendered as a dot. So
that part still needs to be fixed.  Some devs are currently working around
the issue by using small values (e.g. 0.001) instead of 0.

>> 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.
> Yes, that looked very odd to me too. Usually when you set an array, you
> get the same array values back.
> To bad that it already landed in 3 browsers...

The Abilene paradox strikes again :-(

>> 3) The method of mapping the dash pattern to the path: I suspected this
>> might be a problem, but I didn't really pay much attention to it until this
>> thread started.
>> 4) Inflating paths: this did not worry me at all. I was confident that
>> any differences in results would be negligible and decided not to even
>> investigate unless someone reported a bug.
> True. It didn't really matter for now. However, if we allow getting the
> stroke outlines in the future, we needed a better description how stroking
> is done.
> The current wording of "Sweeping a line" describes how you create a stroke
> region and not an "inflated path".

+1 to that.

Received on Tuesday, 15 October 2013 14:39:00 UTC

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