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

Re: [whatwg] Stroking algorithm in Canvas 2d

From: Rik Cabanier <cabanier@gmail.com>
Date: Mon, 9 Sep 2013 12:56:07 -0700
Message-ID: <CAGN7qDDgfZmoZvj9JEwzM764LHWivn=nh_WyGfJOX7SdW31vvg@mail.gmail.com>
To: Ian Hickson <ian@hixie.ch>
Cc: "whatwg@whatwg.org" <whatwg@whatwg.org>, syhann@adobe.com
On Mon, Sep 9, 2013 at 9:33 AM, Ian Hickson <ian@hixie.ch> wrote:

> On Thu, 5 Sep 2013, Rik Cabanier wrote:
> >
> > we've looked over the algorithm in the Canvas spec that describes how
> > strokes are computed. [1]
> > We think that this section is making some incorrect assumptions. For
> > instance, the dashes are calculated over the total lenght of all
> subpaths,
> > but each subpath should be treated separately.
>
> That's intentional, otherwise if you stroke an already-dashed line, you
> get weird results.
>

As Stephan said, when would this happen?
Are you thinking of a case where you did the dashing yourself and then
dash/stroke it again? If so, that is expected to give different results.


>
>
> > It's also a bit strange that the spec is trying to describe how to
> stroke.
>
> It's trying to describe sufficient detail to get interoperable behaviour.
>
>
> > For instance, it goes in minute detail on how dashes are applied but the
> > hardest part of stroking ("inflating the paths in path perpendicular to
> the
> > direction") is not described at all.
>
> Is there any ambiguity in the part that's not described?
>

Yes. What is "inflating"? A stroked bezier curve is no longer a bezier and
has to be calculated.


>
>
> > Wouldn't it be better to remove all these steps and simply show the
> > desired effect?
>
> Yes. I try to do this as much as possible, but whenever I can't figure out
> a way to describe something declaratively, I describe it imperatively
> instead. If you have a way to describe it that is as precise, covers all
> the same cases, yet is declarative, please don't hesitate to suggest it. I
> unfortunately find that describing things declaratively is usually only
> able to get one 90% of the way to a complete description.
>

That's certainly reasonable.
I looked at several graphics libraries (CoreGraphics, PDF, Postscript, D2D,
Cairo) and none of them really say how they stroke.
They just show the result of stroking and at best describe how dashing,
joins and endcaps should look.

Stephan and I can describe how stroking process but are not familiar with
writing it down as normative text.


>
>
> > If not, what would be the best way to fix the wording?
>
> What's wrong with the wording?
>
>
> > The mailing list or a bug?
>
> Either is fine and equivalent. (Don't do both, though, please!).
>

:-)
We'll continue this on the mailing list. That way it's more visible and
people can chime in.
Received on Monday, 9 September 2013 19:56:33 UTC

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