[whatwg] Basic technical graphing features (canvas)

[Simon Pieters]

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