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.
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.
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?
A few notes on the most unexpected things I found while making the VOGLE driver before I move on...
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.
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.VALIDATE