[whatwg] Dashed strokes on <canvas>

[David Flanagan]

Philip,

You have a reasonable point. I still think that an implementation would 
be trivial, but you're right that there is more complexity for the 
specification than simply defining one more method API.  On the other 
hand, I think it is legitimate to take the SVG-Tiny route and leave 
specific rendering details to the implementation.  After all, you're not 
specifying line and curve drawing algorithms down to the pixel, are you?

 > There are other missing features that people are actively implementing
 > workarounds for, like drawing text, which is a good indicator of
 > demand. Are there examples where people are currently fighting against
 > the lack of dashed lines?

The problem of layering text on top of a canvas is a solvable one, so 
people are solving it.  I don't think that dashed lines can really be 
worked around. If there is no native support, they're not worth doing. 
To me the killer use-case for dashed lines is this: displaying multiple 
data series in a line chart that will be printed in black-and-white. 
People have been using dashed lines for that since Rene Descartes 
invented the coordinate system!

I come to this from an admittedly theoretical perspective, but the need 
for dashed lines just seems self-evident to me. I assume that the 
omission of dashed lines was simply an oversight in the original Apple 
implementation, and I'm really surprised by the resistance to adding 
this from whatwg.

     David

Philip Taylor wrote:
> On 09/05/07, David Flanagan <david at davidflanagan.com> wrote:
>> Ian Hickson wrote:
>> > On Wed, 17 May 2006, David Flanagan wrote:
>> >> What surprises me about the omission of dashed lines is that every
>> >> graphics API I'm familiar with (Xlib, PostScript, Java 2D) supports
>> >> dashed lines. Unless there is some important platform out there that
>> >> does not support them in the underlying graphics library, it seems 
>> to me
>> >> that it would have been trivial to add dashed lines to the API.
>> >>
>> >> And, I can't think of any simple or efficient way to simulate dashed
>> >> lines without having them in the API.  And while dashed lines may 
>> not be
>> >> a high-use feature, I wouldn't say they're infrequently used.  For
>> >> example: when drawing a line chart with multiple lines which is 
>> intended
>> >> to be printed on a black-and-white laser printer.
>> >
>> > There are many styles that aren't supported -- dashes aren't an 
>> exception.
>> > For example, there's no support for having defined markers repeated 
>> around
>> > the stroke. Similarly, we don't havenative  support for rounded 
>> corners,
>> > or for many shapes (e.g. circles).
>>
>> Dashes would be trivial to add--it is just a single additional line
>> style property.
> 
> I don't think it's entirely trivial to add, to the detail that's
> necessary in a specification. The common graphics APIs (at least
> Cairo, Quartz and java.awt.Graphics, and any SVG implementation) all
> have dashes specified by passing an array of dash lengths (alternating
> on/off), so that should be alright as long as you define what units
> it's measured in and what happens when you specify an odd number of
> values and how errors are handled and what happens if you update the
> array later. But after that, what does it do when stroking multiple
> subpaths, in terms of offsetting the dashes? When you use strokeRect,
> where is offset 0? Does moveTo reset the offset? How does it interact
> with lineCap/lineJoin? All the potential issues need test cases too,
> and the implementations need to make sure they handle any edge cases
> that the underlying graphics library does differently. (SVG Tiny 1.2
> appears to skip some of the problems by leaving things undefined and
> allowing whatever behaviour the graphics library has.)
> 
>> > You can do dashed lines using paths.
>>
>> This is true only in theory. Way too much computation is necessary to
>> transform a path into a dashed path.
> 
> That's particularly a problem for Bezier curves - decomposing them
> into fixed-length segments in JS wouldn't be any fun. At least it's
> not difficult for straight lines (and someone could write a pure-JS
> canvas extension library to provide that kind of feature), but I have
> no idea how often people want dashed curves compared to dashed lines.
> 
>> > Without more demand for this feature,
>> > it's not clear that it's worth us putting it into the language.
>>
>> It is just one more method on CanvasRenderingContext2D.  And the
>> implementation would almost certainly be trivial.  You'll see the demand
>> for dashed lines when Canvas becomes standardized without it, and people
>> start wondering how to do dashes.  It truly seems strange to me that
>> this feature has been omitted.
> 
> It's one method plus detailed specification and tests and multiple
> implementations and bugs and documentation - none of those are
> especially difficult, but all the work adds up, so there has to be
> enough justification in order to add a feature.
> 
> There are other missing features that people are actively implementing
> workarounds for, like drawing text, which is a good indicator of
> demand. Are there examples where people are currently fighting against
> the lack of dashed lines?
> 
> (I think a number of the features already in the spec fail the
> usefulness requirements, or aren't specified to the detail necessary
> for interoperability, but that's not a reason to add more.)
> 
>>    David Flanagan
>