- From: Simon Pieters <simonp@opera.com>
- Date: Mon, 04 Feb 2008 01:54:50 +0100
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
Received on Sunday, 3 February 2008 16:54:50 UTC