Graphing in SVG with the PEAR Image_Graph Package
Submitted by rob on Thu, 2006-04-20 19:09
I haven't done a whole lot with this yet, but I thought I'd share a quick tip. I just started getting into some PEAR packages the other day and found the Image_Graph package which says it supports SVG output because it works with Image_Canvas. I had no trouble installing the packages and testing them out on my 1and1 shared hosting, but the example I used worked on top of GD library instead of SVG.
I couldn't find any info in the documentation on how to switch the output to SVG, but I had a quick look in the source and it turned out to be very easy.
In the example they create the initial graph like so:
// create the graph
$Graph =& Image_Graph::factory('graph', array(400, 300));
All I did (after some reading) was change the line as follows:
$Graph =& Image_Graph::factory('graph',
array(array('width' => 400, 'height' => 300, 'canvas' => 'svg')));
Watch the syntax, it's a double array.
After the change I noticed that the example seemed to deliver the results a lot faster in the browser. I don't know if the script ran faster on the server or if the resulting SVG was just a lot smaller than the equivalent PNG and JPEG images that I'd been making.
The other tip that can save a lot of time is that you can store the output of the graph in a file instead of sending it to the browser. In the same example change:
$Graph->done();
to:
$Graph->done(array('filename' => './output.svg'));
But note that the resulting graph won't show in the browser until you browse to output.svg.
Comments
Why are you surprised?
Why are you surprised? ;)
The fact that it processes much quicker using SVG should come as no surprise. The SVG file is likely MUCH smaller than the resultant raster. Generally the task between querying of data to generation of SVG is pretty small (just take the data, stuff them into <path> d attributes and wrap them in <g>s to scale them properliy).
To me, this is one of the main benefits of SVG: Dynamic, data-driven graphs leverage the horsepower of the client rather than taxing a server's CPU for a graph that will only be used by that one client. Think Google driving directions... On the other hand, static images that require no interaction make a case for server processing them into rasters (why slow down the rendering at the client for every user)?
The word is that when the SVG switch is thrown on the new Google Maps API that the processing is much faster for driving directions/paths. At Google server loads this is incredibly important. Let the client do some lifting by telling it what to draw (the SVG file).
On the other hand, static
On the other hand, static images that require no interaction make a case for server processing them into rasters (why slow down the rendering at the client for every user)?
That makes sense for some applications, and rasterization for some apps on the server does make sense. Adobe has a product for this (not sure if they maintain it) and Apache Batik can do this. There's a PEAR library, but it relies on Batik as well.
At some point, most
At some point, most developers have a need to create graphs.JpGraph is probably the most well-known, but it can require a commercial licence.The graphs, charts and plots produced by Image_Graph are highly customizable, and can be any of area, band, bar, box and whisker, candlestick, impulse, map, line, pie, radar, scatter, smoothed line and step.
Post new comment