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

Re: [whatwg] Stroking algorithm in Canvas 2d

From: Rik Cabanier <cabanier@gmail.com>
Date: Thu, 10 Oct 2013 13:20:14 -0700
Message-ID: <CAGN7qDCKmxD1cCWTYdN8XZ26cihsQGYvcj+aaHQOzVY8ZYnReg@mail.gmail.com>
To: Dean Jackson <dino@apple.com>, "Robert O'Callahan" <robert@ocallahan.org>, Justin Novosad <junov@chromium.org>
Cc: Simon Fraser <smfr@me.com>, "whatwg@whatwg.org" <whatwg@whatwg.org>, Ian Hickson <ian@hixie.ch>, "Jasper St. Pierre" <jstpierre@mecheye.net>, syhann@adobe.com
Dean, Roc, Justin,

would you change Canvas' stroking behavior so it no longer matches SVG and
CSS and your underlying graphics libraries?


On Thu, Oct 10, 2013 at 12:44 PM, Ian Hickson <ian@hixie.ch> wrote:

> On Thu, 10 Oct 2013, Rik Cabanier wrote:
> > > On Thu, 10 Oct 2013, Rik Cabanier wrote:
> > > > >
> > > > > One way we could address this by adding a new path method that
> > > > > inserts a break in the dashing pattern (without unjoining the
> > > > > subpaths). Also, I think it should be implicit in the rect() path
> > > > > primitive that the corners are joined and that they are also
> > > > > stop/start points for the dashing pattern.
> > > >
> > > > That would break current behavior . We will need a new API or
> > > > additional arguments (a dash array?)
> > >
> > > Can you elaborate? What would break?
> >
> > If you draw a rect with dashes today, the dashing will be applied
> > normally. Justin wants to change this behavior so we will need something
> > to trigger that. Othewise, existing applications that use dashed
> > rectangles will start looking different.
>
> Do we really have enough deployed content using this API that we are
> already constrained? What applications are these?
>
>
> > > It's not how stroking works in PDF, but there's no reason that I can
> > > see that it shouldn't be how stroking works.
> >
> > This is how stroking works *everywhere *including canvas today.
>
> There's three possible arguments for doing something:
>
>  - we have to because there's content depending on it, here is the
>    data supporting that. (That data might be "the browser vendor
>    refuses to implement anything else".)
>
>  - here are some logical reasons for doing it.
>
>  - here is evidence showing that authors want us to do it.
>
> So far I've heard "we have to do that because everyone else does that",
> which isn't any of those three possible arguments.
>
>
> > We can't change the current implementations anyway because they are
> > already used.
>
> If that's true, it trumps all other arguments, and we shouldn't be trying
> to have other arguments. Where's the data showing this?
>
>
> > > Why is approximating a problem? It's not like we're doing pure math
> > > paths here, they're all approximated at the end of the day. The spec
> > > doesn't specify how you implement it exactly, it just requires that we
> > > have consistent results that, within the limitations of the hardware
> > > (e.g. only 1 pixel for every 10 microns) are indistinguishable from
> > > the theoretical results.
> >
> > this is why drawings/pictures of what the stroke should look like are
> > more important.
>
> You can't write normative specifications with sample drawings. Or at
> least, if you can, I certainly haven't seen it done before. Spec by
> example is not the level of quality that we expect at the WHATWG.
>
>
> > Saying "inflate the path perpendicular" is not good enough since it
> > could mean anything.
>
> That's why the spec no longer says that, as noted in my e-mail from
> yesterday.
>
>
> > You either write out the math (which no spec has done afaik) or you give
> > examples (like
> >
> https://developer.apple.com/library/ios/documentation/graphicsimaging/conceptual/drawingwithquartz2d/dq_paths/dq_paths.html
> > )
>
> Or you can give prose that describes it unambiguously, which I believe is
> what the spec does now.
>
> --
> Ian Hickson               U+1047E                )\._.,--....,'``.    fL
> http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
> Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
>
Received on Thursday, 10 October 2013 20:20:38 UTC

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