Looking at the current spec [1], I see that Ian updated how dashing is calculated (thanks!)
I still have a couple of questions: 1. Step 4: Add a straight closing line to each closed subpath in path connecting the last point and the first point of that subpath; change the last point to a join (from the previously last line to the newly added closing line), and change the first point to a join (from the newly added closing line to the first line). Is this needed? A closed subpath already drew a line [2]. Maybe it could be simplified to: If a subpath is marked as closed, replace all points with joins. 2. Calculating dashing is a bit strange For instance, let's say with have a dash array of [5 5 3 3] with a dash offset of 0 and apply it to a path of length 20. According to the spec: - pattern width = 16 - subpath width = 20 - offset = *16* (from step 3: "While offset is less than pattern width, increment it by pattern width") - position = *-16* (from step 5: "Let position be zero minus offset.") If you follow the steps, you have to go through the loop twice before drawing starts. Maybe we can change step 3: While offset is greater than pattern width, decrement it by pattern width. While offset is less than *zero*, increment it by pattern width. 3. Step 20: If position is greater than width, then jump to the step labeled convert. I think that should be: If position is greater than *subpath *width, then jump to the step labeled convert. 1: http://www.whatwg.org/specs/web-apps/current-work/multipage/the-canvas-element.html#trace-a-path 2: http://www.whatwg.org/specs/web-apps/current-work/multipage/the-canvas-element.html#dom-context-2d-closepath On Sun, Oct 27, 2013 at 7:36 PM, Rik Cabanier <caban...@gmail.com> wrote: > Can we pick this up again? > > I think we should update the algorithm [1] so the problem is broken into > stages: > 1. For each subpath, use the dash array to break it into a smaller > subpaths + remember the direction of the path (for 0 length dashes). The > default will use 0 + the dashoffset of each subpath, a TBD option allows > you to remember the phase were you left off. This left-off phase is added > when starting the next sub path > 2. For each of the new subpaths, draw an area that is derived from > sweeping a line across the direction of the path. > 3. For each of the new subpaths, draw the end caps > 4. For each of the new subpaths, draw the line joins > > For each stage, we should also provide pictures. > > Deriving a path from a stroke is tricky, but I think we can say that it is > derived by outlining the region of the stroke. The outline should be done > in such a way that it is not affected by winding. > > 1: > http://www.whatwg.org/specs/web-apps/current-work/multipage/the-canvas-element.html#trace-a-path > > > On Wed, Oct 16, 2013 at 6:58 AM, Justin Novosad <ju...@google.com> wrote: > >> On Tue, Oct 15, 2013 at 7:18 PM, Ian Hickson <i...@hixie.ch> wrote: >> >> > >> > On Thu, 10 Oct 2013, Rik Cabanier wrote: >> > > On Thu, Oct 10, 2013 at 12:25 PM, Justin Novosad <ju...@google.com> >> > wrote: >> > > > >> > > > http://jsfiddle.net/ZxR6P/1/ >> > > >> > > Yes, that looks like "Align dashes to corners and path ends" >> > >> > I've filed a bug for this: >> > https://www.w3.org/Bugs/Public/show_bug.cgi?id=23528 >> > >> > This thread now is mainly about what the default should be. >> > >> >> Great, thanks! >> >> >> > >> > Fair enough. I've changed the spec to reset at new subpaths. >> > >> > >> > On Fri, 11 Oct 2013, Justin Novosad wrote: >> > > >> > > So far, there are a few differences between the spec and the graphics >> > API I >> > > work with (skia) that attracted my attention: >> > > 1) the line caps on individual dashes: this is not yet resolved, and >> it >> > is >> > > pretty far on my to do list (low volume of complaints) >> > >> > My understanding is that the specced behaviour here matches SVG, right? >> > >> >> Yes the spec is fine in this respect, and it turns out that Blink is not >> as >> broken as I initially thought it was when I wrote that. >> >> >> > > 2) the way of handling dash sequences with an odd number of elements >> > > (concatenate the sequence onto itself to make it even): this was easy >> to >> > > resolve, although I have reservations about this. I think it may feel >> > > unnatural to many graphics designers. >> > >> > What's the alternative? Implying a zero at the end? I don't have a >> strong >> > opinion on this, though it does seem more useful to treat [3] as [3,3] >> > than as [3,0]. >> > >> >> No, I don't mean an implied zero. I meant that at every iteration over the >> dash pattern, the pattern is inverted if it has an odd number of elements >> (blanks become dashes and vice versa). This would render exactly the same >> as what is currently in the spec, which is consistent with SVG. The only >> difference is that there is no doubling of the array. If the array needs >> to be doubled in order to work with the underlying graphics API, that >> should be the UA's business and it should be hidden under the hood. >> > >