Re: [whatwg] Stroking algorithm in Canvas 2d

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