Re: [whatwg] Stroking algorithm in Canvas 2d

On Wed, Oct 9, 2013 at 9:52 PM, Ian Hickson <ian@hixie.ch> wrote:

>
> On Fri, 27 Sep 2013, Rik Cabanier wrote:
> > On Fri, Sep 27, 2013 at 3:35 PM, Ian Hickson <ian@hixie.ch> wrote:
> > >
> > > The idea here is that this line:
> > >
> > >   ------------------------------
> > >
> > > ...would result in this dash (assuming equally spaced on-off):
> > >
> > >   ---   ---   ---   ---   ---
> > >
> > > ...while this line, dashed with the same stroke:
> > >
> > >   ---   ---   ---   ---   ---
> > >
> > > ...would result in this different line, rather than result in no
> change:
> > >
> > >   ---         ---         ---
> > >
> > > ...and this line, dashed with the same stroke:
> > >
> > >   --  --  --  --  --  --  --  --
> > >
> > > ...would result in something more like:
> > >
> > >   --  -       --  -       --  -
> > >
> > > ...rather than, again, resulting in no change.
> >
> > Yep, this is where assumptions went wrong. Dashes are calculated per
> > subpath, not per 'line'/whole path.
>
> On what basis are you asserting this?
>

see this fiddle: http://jsfiddle.net/6eGxU/25/


>
>
> On Thu, 12 Sep 2013, Rik Cabanier wrote:
> >
> > Currently the spec says:
> >
> > 1 Let width be the aggregate length of all the lines of all the subpaths
> in
> > path, in coordinate space units.
> > 2 Let offset be the value of the styles lineDashOffset, in coordinate
> space
> > units.
> > 3 While offset is greater than width, decrement it by width.
> > 4 While offset is less than width, increment it by width.
> >
> > For 1, dashing should be applied to each subpath. As the PDF reference
> > manual says:
>
> What's the relevance of the PDF spec here?
>

I think most (all?) graphics libraries traces their root back to PostScript.
PDF, Core Graphics, Cairo and Direct2D all follow the same algorithm.


>
>
> > 2 - 4 are not correct. From the PDF reference:
>
> Again, I don't see the reference of PDF to this.
>
>
> On Fri, 27 Sep 2013, Rik Cabanier wrote:
> > > > > > 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"?
> > >
> > > The dictionary definition is what I intended. To grow, increase in
> > > size, get bigger in all directions. Inflate.
> > >
> > > If you have any better suggestion for how to word this, I'm all for
> > > it.
> >
> > I think Stephan could come up with a formula.
>
> I don't really think it needs a formula. The concept is pretty simple. You
> have a line. You just need the path that describes the area that would be
> covered if a line of length equal to the line width was swept along the
> path, while being kept at an angle such that it is orthogonal to the path
> being swept.
>
> I've replaced the text with new text that tries to define this better
> without using "inflate".
>

They're not always lines though. What about curves?


>
>
> > > > A stroked bezier curve is no longer a bezier and has to be
> > > > calculated.
> > >
> > > Yes. The idea of defining it in terms of the earlier path is that
> > > there's no need to be explicit about the maths here.
> >
> > How is a UA going to implement that? I can imagine many ways to
> > "inflate" a path
>
> Is the new text unambiguous enough? If not, what interpretation can you
> come up with which match the new text?


I'm unsure. Stephan, what do you think?

Received on Thursday, 10 October 2013 05:36:23 UTC