See: http://forums.whatwg.org/viewtopic.php?t=141
Summary:
* Missing dashed lines, Hershey/vector fonts, even-odd polygon fill
rules, and points.
* http://home.comcast.net/~urbanjost/canvas/vogle4.html hence uses
workarounds.
* Polyline with no length should result in a circle or square.
urbanjost wrote:
The HTML <canvas> element features seem to be oriented more towards
displaying vector-based art than technical graphics; thereby missing out
on easily supporting a large number of users. Why do I say this? My
first attempt at using the element to support vector-based graphics
produced by a program that dates back at least three decades was
actually more difficult to implement in a <canvas> element that it was
on an HP pen plotter many years ago.
Even though I quickly became a fan of the HTML5 element because of the
ease with which I could interface with standard HTML documents and
ECMAScript/JavaScript, I was surprised there was no built-in support for
dashed lines, Hershey/vector fonts, even-odd polygon fill rules, and
points. And yet gradient fill patterns, opacity control, image
manipulation, and complex clipping regions were all supported (which I
consider more advanced graphic features than a dashed line!).
Yet I found I could quickly create server-side applications or
JavaScript functions that let me get around these problems. The document
found at http://home.comcast.net/~urbanjost/canvas/vogle4.html shows
some simple XY plots containing simple labels, dotted grids, and dashed
lines. This was done with the help of a server-side library, but the
functionality is all very plausibly portable to JavaScript functions.
But everyone does not have routines laying around to do sofware-based
dash codes, ASCII text strings, and grids. However, it looks like others
have already raised these issues except for the topic of points
(although I don't think anyone brought them up together, pointing out
that they are all common elements of any simple XY-plot utility).
Since the other topics have already been breached, I'll make my point
about points!
It is common practice in many graphic formats to represent a polyline
composed of a simple "move2(x,y)" or "move2(x,y) draw2(x,y)" as a point.
Another common solution is to provide a marker(x,y,"name",sz) routine
that can draw various markers at points.
It is quite common for a technical plot to be a so-called "scatter" plot
where the data is marked purely by marker symbols or points. It is also
common to unpredictably have a polyline be just a single point. If dashed
lines are going to be supported, it is important to note that almost all
dash code models support points as part of the dash-code pattern. Every
graphing utility I can thing of supports dotted grids, and so on. Points
are so common in technical plots that I strongly prefer that a polyline
that has no length is represented as a filled circle with a diameter
equal to the current line width or as a square centered on the point
with an edge length equal to the current line width.
Inconveniently, the current <canvas> standard says to ignore a polyline
with no length. This means any code drawing simple curves has to detect
such lines and render them as circles or squares or give them a false
non-zero length.
If others have reasons for not wanting to render lines with zero length,
perhaps the solution would be a new graphics state option that would let
you toggle between the two behaviors.
The other surprise was that there was no display list or object
definition capability. Simple plots usually don't make much use of
these, except to define a marker style, but I find them invaluable in
nearly any nteractive
program.
All that being said, I find the <canvas> element a welcome and overdue
addition to the Web ( I actually liked VML better than either SVG or PDF
or CANVAS because there was a common editor, browser, and drawing
utility immediately available that supported it, but I'm practical
enough to know VML is now destined to be a proprietary MS-centric
product).
--
Simon Pieters
Opera Software