[whatwg] Dashed strokes on <canvas>

[Philip Taylor]

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

-- 
Philip Taylor
excors at gmail.com