Pros and Cons

SVG Parameters

There is a proposed W3C specification called SVG Parameters, currently in development. The specification has working examples, but they require the use of a shim script that emulates the functionality. This method allows you to use a single SVG image file but pass various strings to it. The HTML code looks like this:

<object type="image/svg+xml" data="square.svg">
  <param name='color' value='green' />
  <param name='number' value='3' />
</object>
  

and the SVG file might look like this. Note that the shim script (param.js) is included in the SVG file, not in the HTML file.

<svg xmlns="http://www.w3.org/2000/svg" version="1.1" xmlns:xlink="http://www.w3.org/1999/xlink"
width="68" height="68">
<rect x="10" y="10" height="48" width="48" stroke="black" stroke-width="1" fill="param(color) red">
</rect>
<rect x="29" y="0" height="10" width="10" fill="black"></rect>
<text x="24" y="46" fill="param(text) black" style="font-size:32px;"
  content-value="param(number) 1">1</text>

<script type="text/ecmascript" xlink:href="param.js" /> 

</svg>

Here are some images drawn using this feature:

This little form will let you try it.

This form uses JavaScript to manipulate the DOM and print the object string including the parameters, but the SVG itself is contained in a separate file and not drawn inline. So, unlike most of the other forms on this site, this form works on Safari 4.1.3 and 5.0.3, older versions that don't support inline SVG. These older browsers draw the SVG with a white background, unlike newer browsers that don't draw a background.

Also, it seems that Internet Explorer 11 won't draw the correct text, but it does apply all the colors correctly. There seems to be a problem in the param.js shim script file. Ironically, inline SVG works fine with IE 11.

There is more information about SVG parameters on the W3C web site.

File Sizes

The GIF files on the mixed-up.com web site weigh about 113 bytes each. The SVG code to generate the same graphic weighs about 330 bytes. So there is an overhead of about 200 extra bytes to render and transfer these as SVG files instead of GIF. However, if we use JavaScript to generate the SVG code, there is only the one-time overhead of transferring the JavaScript file. The 200-byte overhead really comes into play only if we must fall back to a server-side technology to deliver the images.

Scalability

Since SVG are vector graphics, there is no need to create separate images for high-density (retina) screens.

In addition, it is easy to add scaled and transformed versions of graphics in SVG by referencing an exiting object and changing aspects of it. The icons in this project's menus are scaled and rotated versions of the same object.

However, it is difficult to scale inline SVG images on the fly, as we might like to do in with responsive images. For that purpose, it is easier to include the SVG files using the <img> tag than to generate the code inline. In this situation, server-side solutions may be better.

Versatility

The real power of this combination of JavaScript and SVG is seen in its versatility. The GIF files on the mixed-up.com site are 16x16 pixels and they are only in black and white (or maybe gray). If we want to add more colors or sizes, we need to make more image files.

However, if we want to add more colors or sizes to SVG, we just specify them in the parameters. If we need more shapes like circles or ovals, we can write more JavaScript that does that. The size issue is particularly important if we want to use these SVG images as part of an overall responsive image strategy.

Generating PNG images in PHP

PHP has the capability of generating PNG images on a canvas. They are drawn in a way similar to the way we draw SVG images in JavaScript. The main difference is that they are generated as PNG images instead of SVG. This may be a good fallback for very old browsers that don't even support SVG. (Although some of the very old browsers support only GIF and JPG.) The user variables are passed as parameters in URL. The code for including these PHP-generated images looks like this:

<img src="image2.php?dir=top&n=1">
<img src="image2.php?dir=right&n=4">
<img src="image2.php?dir=bottom&n=7">
<img src="image2.php?dir=left&n=2">

<img src="image2.php?shape=o&dir=vert&n=5">
<img src="image2.php?shape=o&dir=horiz&n=8">
<img src="image2.php?shape=o&dir=all&n=3">
<img src="image2.php?shape=o&n=6">

The PHP source code that generates these images is similar to the JavaScript code we use to generate the SVG, but the fonts must be available on the server, and Unix servers have a wide variety of fonts available and not available, and the font we need may not be available on the server where we are trying to deploy. So I wrote some PHP code that draws the numbers as line segments. This limits the number of characters we can draw, because each character we want to use must be encoded as a series of line segments. An outline sketch of the code has elements like this:

Header ("Content-type: image/png");

// hard coded image sizes
$dx = 32;
$dy = 32;
$xpad = 16;
$ypad = 16;

// initialize the libraries
$im = imagecreate ($dx+2*$xpad, $dy+2*$ypad);
$white = ImageColorAllocate ($im, 255, 255, 255);
$black = ImageColorAllocate ($im, 0, 0, 0);
$gray = ImageColorAllocate ($im, 128, 128, 128);

// get the user variables: orientation (o), number (n),
// shape (square or circle), and color
$dir = $_GET['dir'];
$n = $_GET['n'];
$shape = $_GET['shape'];
$color = $_GET['color'];

ImageRectangle ($im, $xpad, $ypad, $dx+$xpad, $dy+$ypad, $black);

if ($dir=="bottom" | $dir=="vert" | $dir=="all")
  ImageFilledRectangle (
    $im, $xpad+$dx/2-4, $dy+$ypad, $xpad+$dx/2+4, $dy+$ypad+8, $black);
// ... and more orientations in similar fashion, not shown here

// ... draw the numbers as segments, not shown here
imagepng ($im);
ImageDestroy ($im);