[whatwg] Stroking algorithm in Canvas 2d

[Ian Hickson]

On Fri, 27 Sep 2013, Rik Cabanier wrote:
> On Fri, Sep 27, 2013 at 3:35 PM, Ian Hickson <ian at 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?


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?


> 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".


> > > 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?

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'