You need an HTML CANVAS addon
A <CANVAS>scrapbook:
Exploring the HTML5 CANVAS element

Collected examples

My examples

• resizeable VOGLE plots
• Animated Plasma
• fill rule example
• large numbers of vectors
• Footnote: early problems with simple resizing

Other's examples (locally cached and slightly modified)

• A public-domain Hershey font routine (You'll need this)
• GUI-like elements
• interactive scribbling(Simple doodle tool)
• handwriting recognition
• Canvas Painter (Drawing Tool)
• Conway's Game of Life
• clever borders around hardware text
• dynamic analog clock
• rotating an image
• Image overlay animation (Solar System)
• Image transforms
• Yusuke Kawasaki's animation effect
• Mandelbrot Set in HTML 5 Canvas

Other examples (remote)

• A clone of Microsoft Paint!
• Blob Sallad!
• great image effects
• moon lander
• Yusuke Kawasaki's animation effect
• sliding plot animation
• MSX emulator
• polyhedra models
• 3d car drive
• Unreal Soccer
• Arkanoid game
• Star fields
• image manipulation
• 3d collada
• Experimental shooter game
• image puzzles

References

• forums.whatwg.org (suggest changes, discuss, ....
• www.whatwg.org
• developer.mozilla.org
• html5.org
• JavaScript graph library
• Yahoo! pipes (draw-and-drop interface)
• Kevin Hoyt - Exploring the HTML 5 Canvas Element

Other

• taking the canvas to another dimension

non-native support

• rhino-canvas.sourceforge.net

alternatives and related links

• cgmVA - A CGM Viewer Applet
• wikipedia -> SVG (Scalable Vector Graphics)
• wikipedia -> VML (Vector Mark-up Language)
• Vector Magic (convert pixmaps to vectors)

Released: Fri Dec 25 2007; John S. Urban

I've lost my share of time wrapped up in the HTML CANVAS/ SVG / VML / WebCGM /Adobe PDF /FLASH .... battle for the hearts of developers and users who are trying to create web-based (or at least web-friendly) vector-based graphics. I've learned a few things while sorting through these options. What follows is a (currently ongoing) chronical of what I have experienced while exploring the role of the HTML CANVAS element.

First, I created a CANVAS driver for the simple C/Fortran-centric VOGLE graphics library. I have only tested the driver with the opera(1) and firefox(1) browsers at this point. I found that the HTML5 CANVAS element standard lets me produce a static vector-based plot quite satisfactorily with a small amount of intellectual capital and time required to do the development, assuming I have a higher-level library or product generating the file. The lines display nicely anti-aliased in the browsers I tried (although the HTML5 specification does not appear to require that). I'm convinced any product that currently can produce simple vector-based graphics output can quickly be changed to produce CANVAS files.

I use my version of the VOGLE library very heavily. The driver is useful. So far so good. But I'm hoping for more than a high-resolution snapshot of my VOGLE plots. And who can leave well-enough alone? So I added rescaling features. The results of the 1.2 driver are in the sample file vogle4.html . Then I manually edited the file and added a few other things manually (the info+ mode and the monochrome mode and the "points" options).

I am fortunate that my graphics library of choice supports software dash codes and stroked fonts because the CANVAS element is a little too simple. Absolutely no native text support? No dashcode support? no points? No object definition or display list? One polygon fill algorithm? Well, if being simple means CANVAS elements can quickly become a part of the HTML standard and be widely adopted I can live with those limits (look how nice and simple HTML 2.0 was). Someone can muck it up and make it way too complicated later. So at least I can get as far as I could with a pen plotter years ago.

First and foremost -- are CANVAS elements really going to be supported by all graphic browsers? Well, if anything is this will be. It's proposed as part of HTML5 and is so simple you have to be hard-pressed to justify not doing it. You write a browser that supports JavaScript and VML or SVG and CSS style sheets and plug-ins and you can't support this? Universal support is such a key issue that I have no need to go further if I don't think a CANVAS element will become as standard as an HTML IMG element.

What about animation and panning and zooming? Can I make a GUI with a CANVAS that's better than a simple HTML form? Are their GUI-builders for this? Can I make utilities to dynamically draw graphs and plots? How interactive can I make my interfaces? How about interfaces to server-side codes and client-side applications? Any chance any editor or tool is going to let me read a document with CANVAS elements and edit the graphics interactively? How popular is this solution? How long will it be supported? More importantly, can I do it more simply (or maintainably or flexibly or portably) than if I use Java applets or VML or SVG or FLASH or Adobe PDF or whatever comes out next week? It looks like it's easy enough to find out at least a few answers by simply trying them.

Why hold out hope?

You will note a thread of pessisism. I remember when Display PostScript seemed to solve a lot of the needs a CANVAS element appears to address; then IGES and CGM files; Tcl/Tk; VRML; OpenGL; Java/Applets ... As I've mentioned, I've looked at other solutions that do everything a CANVAS element does and then some. The VOGLE library could already write a simple PostScript, CGM, Adobe PDF, SVG or VML file, for example. So what value do I see in a CANVAS element?

As I alluded to, potential "universality" is the primary appeal; the (theoretically) human-readable text-based simplicity has it's uses and attractions; and the easy access from JavaScript and integration with HTML is the other significantly appealing feature. It is nice to have the option to add the graphics right into a single HTML file with the text. If CANVAS elements are destined to be part of HTML5 my hopes are high that CANVAS plots should soon work in any graphical browser. That's a big plus. Everyone will have the display platform. And what about (some) of the missing basic features? I can extend the CANVAS vocabulary with JavaScript routines. I've got routines around that draw dashed lines and vector-based fonts like the classic Hershey fonts. So if something simple is not there I can add it, or maybe find it.

Of course, all roads lead to the non-proprietary browser interface, and that is where we find the CANVAS element. And we've established that the apparent simplicty is misleading because the sum of the parts (other HTML elements, JavaScript, CSS, ...) is greater than the whole and all that. So the ever-expanding great integrator (the extensible open-standards "Internet Browser") is coming through. But some red flags immediately become apparent as you browse for CANVAS resources on the Web. Why isn't there a larger collection of JavaScript "CANVAS" routine links off what appear to be the main CANVAS references ( www.whatwg.org, developer.mozilla.org ) for example? This CANVAS element has been out there for a while.

A few notes on the most unexpected things I found while making the VOGLE driver before I move on...

• PERFORMANCE: The CANVAS method of drawing a polyline is verbose and somewhat slow for lines with many points in them (for example, 100,000 pts.) I found empirically that creating arrays and then processing them let me make files at least 50% smaller, and they appear to render at least three times faster for large files. Results varied considerably between the opera(1) and firefox(1) browsers. The curve with 100,000 points in it took a long time to display in opera(1), and parts of the image were displayed long before others with no indication the entire plot was not visible. firefox(1) displayed the frame in a much more tolerable timeframe and showed that it was busy until the entire frame was rendered.
• POINTS: Neither browser showed a line of zero length, even when it contained two points (The HTML5 proposal currently says to ignore a path with "less than two" points in it; it does not imply lines of null length are ignored though). In order to make points easy to render I think a path composed of just a move and/or a move and then draws(s) to the same point should show a circle with a diameter equal to the current line width or a square with a side equal to the current line width or a minimum of one pixel in order to make points visible. Maybe an option to display markers of different styles at such "points" would be nice (an X, a +, a hollow circle, ...)
• RESIZE PROBLEMS: Requests to resize the canvas using HTML events did not have the results I expected. The sample vogle4.html file link above shows a solution is possible, but this link shows the travails I encountered because I assumed the simple things that worked with other HTML elements like IMG would also work for the CANVAS element.
• NO EVEN-ODD POLYGON FILL: I dislike not being able to use other polygon fill rules. At least an even-odd fill should be available.
• TEXT: Well, there is no text procedure. That's silly. A CANVAS element should have at least as much functionality as an ancient CALCOMP library. Anyone ever hear of vector-based fonts? I'm trying to decide whether it is worth it to write JavaScript versions of the Hershey font routines to emulate "hardware" text to keep the text editable and searchable and to reduce file size. Along those lines, look at this copy of an

  eye-catching demo that mixes HTML hardware text and CANVAS graphics.

  Well, I found some references on the Web that indicate I will be reinventing the wheel if I do this so I need to look around further. A public-domain Hershey font routine could be quiet useful if a simple ASCII font is suitable. I'm never going to add all the glyphs to a vector-based font solution for all the fonts out there, so alternatives like this are definitely worth studying.

Summary

What's my perspective? The most exciting thing about the HTML CANVAS element is that it complements JavaScript instead of creating yet another complex standard from scratch, that the plots can be placed directly into a single HTML document, and that it is simple and can be edited with a text editor. You can pretty much know everything there is to know about drawing static HTML CANVAS elements in a few hours. The entire specification is a few pages. Figuring out how it integrates with JavaScript and HTML, what you can do with CSS to style borders and positions and such, and whether browser implementations let you get fancy (portability, animation, performance, memory or size limits, ....)? A couple of days of putz`in and browsing Internet examples should suffice to answer your questions.

Something on my list is to see if I can make a large number of components displayed in <IFRAME> elements using different products talk to each other and process files on both the server and client efficiently and securely. That is, I still want Unix in a browser.

FOOTNOTES: When you do not want the plot data integral to the document

While sometimes being in-line is an advantage, occasionally I want something in a separate file like SVG or IMG files; especially if it is something I can reuse. There are at least two straight-forward solutions -- make an HTML file that just shows the CANVAS and then use it in other documents with an IFRAME element, or make everything into a javascript *.js file.and include it with a HTML SCRIPT element. The following clock is completely defined in a separate file and invoked with a simple IFRAME element, for instance.

If the clock and solar system examples are not running as animations and you are using the opera(1) browser try re-loading the page (until I find a solution for this problem).

On the other hand, this demo is based on overlaying images instead of drawing vectors. Click on the graphic and slide it up with the arrow keys to read about some portability issues I encountered ...

I really need to evaluate the GOOGLE excanvas.js interface that uses VML (mostly) to process CANVAS elements.