Programmer Musings

SVG Lives: A Follow-up

At the end of 2008, I did a series of posts arguing that SVG still lives despite predictions of it's downfall. I had been hearing these dire predictions for years, and wanted to provide a decent rebuttal: Reports of SVG's death exaggerated.

Last year, I had the good fortune to go to SVG Open 2009. Despite following SVG for years and working with it where ever I could, I was still astounded at the creativity and power of the technology shown by many of the experts that were at the conference.

This year I had the opportunity to present at YAPC::NA on the topic Data Visualization with Perl and SVG. I expected a handful of attendees, and was surprised to be presenting to a packed room containing over 50 people. Apparently, there is quite a bit of interest in SVG.

There have also been a couple of changes in the world of SVG lately that should finally lay to rest the claims of SVG's demise.

* HTML 5 will include SVG support in-line with the HTML.
* IE 9 will finally begin supporting SVG natively.

As with many technologies, it looks like SVG has survived its first ten years and is about ready to break out into the mainstream.

SVG: Coming of Age

In the past few months, I have been focusing more on SVG. The most important reason was the SVG Open 2009 conference the first weekend of October.¹

Some truly amazing demos and research are being done in this area despite nay-sayers claiming that the technology is dead. Some of the biggest announcements leading up to the conference included two solutions for the one major browser that does not yet have native SVG support.

* SVG Web a JavaScript library for running SVG in any browser.
* Google Chrome Frame a plugin that gives IE support for SVG, canvas, HTML5, etc.

The presentations ranged from interesting uses of vector graphics to great tools for business or government to jaw-dropping effects that you would have had to see to believe. Some of the presentations are already available from the SVG Open website, with others hopefully following soon.

One of the most profound things I got out of the conference is the large number of people that have not been deterred by the pessimism that has seemed to surround SVG in recent years. These people are doing amazing work and getting things done, despite inconsistent browser implementations and one, big holdout among the major browsers. Everyone seemed excited that browser implementations are becoming more complete and consistent with every release. The HTML 5 specification is defining the ability to write SVG inline.

Truly, SVG is coming of age.

[1] Disclaimer: I was on the organizing committee.

More SVG and Perl

In my last post, I talked about a quick little project that has grown into experimenting with several new tools/processes.

I finally got a reasonable release out on CPAN as SVG::Sparkline version 0.30. This version supports 6 different sparkline types: Area, Bar, Line, RangeArea, RangeBar, and Whisker. It also has better documentation in the form of a manual and a cookbook.

Proving once again that you never know who's watching, Jeff Schiller (of SVG fame) commented on my last post that I needed a demo. <grumble/> I had a little demo application that I was using to print a primitive gallery of sparklines for my own debugging purposes. I've cleaned up the output and put the Sparkline Gallery on-line.

I also found that the module did not have as high Kwalitee as I expected. So, I did some cleanup to improve that value. (If you haven't run across kwalitee before, you might think it's a misspelling. Actually, it's a part joke/part serious measure for Perl modules. Check out the article for details.

I would have had this version finished sooner, if another SVG project had not distracted me. David Dailey mentioned the idea of a Friendly Little Intermittent Clockfest. The last few times this subject came up, I was not tempted. For some reason, this time it bit me. Sometime soon, I'll probably be adding an SVG clock gallery to my site as well.

Every now and then the programming muse shows up and the ideas start flowing.<grin/>

Update: Thanks to a minor failure on my part the 0.30 release was missing the Manual. I've released 0.31 to fix that.

SVG Sparklines in Perl

For the last few weeks, I've been working on a Perl module for creating Sparklines* in SVG. The original purpose of the project was a demonstration of working with SVG from Perl. It was intended to be an example in a talk I was going to give for our local Perl Mongers group. As usual, it has grown to be much more than that. (I still hope to get back to that talk.<shrug/>)

In the process, I've been exploring a few other ideas that were not part of the original plan. I planned to develop the module as I usually do and then release it to CPAN. I released an early version (something I normally do not do) and got feedback from an interested developer within 24 hours. This was on a barely functional module.

Based on that email exchange and conversations with some local developers, this is turning into a much more robust and flexible module than originally intended. The interface has improved dramatically. There will be more types than originally planned. There are more ways to configure the look of the generated Sparklines. There is now a cookbook explaining how to generate different effects.

I've also put the module on Github as svg-sparkline. Although I've been playing with git off and on for a few months now, this is the first time I've tried to use with it seriously.

Unlike many of my past projects, this one requires more visual design thought than I normally need. In a way, this quick, little project has turned into a way to experiment with several new ideas and skills at once. We'll have to see how this one turns out.

Note:
* A Sparkline is an intense, word-sized graphic intended to convey useful information inline within text. The concept was proposed by Edward Tuft in his book Beautiful Evidence. For more on sparklines, see Tuft's article on the subject.

SVG Lives: the Summary

This is the last in a series of posts refuting some recurring claims about the death of SVG, In the first post, I gave a brief overview of SVG. In the subsequent posts, I refuted each of the major claims that I have seen for the death of SVG.

Those claims were:

1. Death by lack of GUI Widget Claim
2. Death by lack of the 3D Graphics Claim
3. Death by lack of the Video or Audio Playback Claim
4. Death bby lack of the Internet Explorer support Claim

I hope by now you can seem that these recurring myths are based mostly on misunderstanding or misinformation. SVG is a very effective technology, but it is not designed to do everything. Its popularity and usefulness have been growing for almost a decade now. Despite regular doom-sayers proclaiming the death of SVG, it lives on and grows stronger every year.

If you are interested in learning more about SVG, you should check out the following resources:

• Planet SVG from the SVG Interest Group
• The SVG Wiki
• Scalable Vector Graphics (SVG) at the World Wide Web Consortium site: the definitive reference
• State of the Art: An SVG Primer for Today's Browsers (It's long but it contains both simple and amazing examples.)
• KevLinDev: lots of examples and tutorials
• SVG Basics Tutorial
• SVG.org

You could also search the web for SVG, new sites and resources pop up every day.

SVG Lives: the Internet Explorer Claim

This is the next in a series of posts refuting some recurring claims about the death of SVG, In the first post, I gave a brief overview of SVG. Each subsequent post takes a claim and refutes it.

The Claim

SVG is dead because it is not supported by Internet Explorer

This argument is possibly the most complicated. For a long time, almost the only way to view SVG in a browser was by using the ASV plugin that worked best under IE. Adobe has not improved this plugin in years and Microsoft has done nothing to make it easier to use. Meanwhile, the other major browsers (Firefox, Opera, and Safari, to name a few) have steadily been improving their native support for SVG.

At present, IE seems to be the only browser without any native support for SVG. Despite the fact that IE is the dominant browser, it's popularity has been falling in recent years (down to around 80% from the upper 90% range a few years ago). For some sites, the proportion of IE visitors is even lower.

Several companies and individual groups have been revisiting the idea of developing a new SVG plugin for IE. When one of these projects completes, users of IE would have the same access to SVG as users of other browsers.

That isn't the whole story though. SVG has actually spread in places other than the web. SVG has been growing in popularity among cell phone systems, especially outside the United States. SVG is very popular in the cartography community. Some companies are using SVG behind the scenes, because it is relatively easy to manipulate from code, and then rasterizing the results.

Once upon a time, lack of support in IE would have meant the death of almost any web format. Now, IE is not the only game on the web. More importantly, the market for SVG as a vector format has spread beyond the web to phones, maps, and even operating systems (the KDE window manager on Linux makes extensive use of SVG.)

Next time: Summary

SVG Lives: the Video/Audio Claim

This is the next in a series of posts refuting some recurring claims about the death of SVG, In the first post, I gave a brief overview of SVG. Each subsequent post takes a claim and refutes it.

The Claim

SVG is useless because it doesn't support video or audio.

It's time to go back to our original SVG definition. SVG is, first and foremost, a vector image format. Although SVG does provide some animation support, it is not a multimedia control language. The ability to play external video or audio is not necessary for doing 2D vector graphics. While this ability may be nice, it has nothing to do with SVG's design goals.

Saying this is a flaw in SVG is more or less equivalent to saying the JPEG format is useless because it doesn't support playing external audio. No one would seriously expect a raster image format to play external audio. That does not stop this claim for the death of SVG.

Many people have done very impressive work making animations with SVG. Although, the full SMIL language was designed to coordinate multimedia presentations, SVG only included a subset that was appropriate to animating vector graphics. While powerful, this subset does not include the ability to play external video or audio.

The fact that SVG has no support for video or audio playback doesn't impact its use in static vector images or even animated vector images. Despite the claim, SVG is strong and healthy.

Next time: The Internet Explorer Claim

SVG Lives: the 3D Graphics Claim

This is the next in a series of posts refuting some recurring claims about the death of SVG, In the first post, I gave a brief overview of SVG. Each subsequent post takes a claim and refutes it.

The Claim

SVG is useless because it doesn't support even basic 3D features

This claim makes a little more sense than the previous one, but not much. The focus of SVG was on 2 dimensional vector graphics. It is obviously possible to render 3D objects by projecting them onto a 2D representation. After all, that's how 3D graphics are always displayed on a monitor. You can use SVG as the 2D representation. However, SVG does not provide any particular help for projections or 3D objects, because its focus is 2D graphics..

All of the image manipulation supported by SVG is designed to support 2D vector graphics. This means that there is no support for perspectives or non-linear transforms. The painting model does not support explicit z-ordering. There is no support for 3D coordinates. None of these things are required for 2D vector graphics, so they do not exist in SVG.

There are some separate projects that target 3D vector formats (VRML and X3D are probably the most complete). X3D has even been written with a goal of being compatible with SVG.

The fact that SVG doesn't support 3D does not reduce its utility as a 2D vector image format. Despite this claim, SVG is still alive and well.

Next time: The Video/Audio Claim

SVG Lives: the Widget Claim

This is the second in a series of posts refuting some recurring claims about the death of SVG, In the last post, Reports of SVG's death exaggerated, I gave a little history and refresher on SVG. This time I will try to tackle one of the claims about the death of SVG.

The Claim

SVG is useless because it doesn't have a widget toolkit for building GUIs

This argument seems to resurface every year or so. Invariably it is floated either by someone trying to build a website completely on SVG or by someone trying to compare SVG to a GUI-building technology (recently that has been Microsoft's XAML).

The argument normally starts by asking for a particular widget in SVG. A few people will show how they have constructed something, which leads to complaints about having to actually build what are obviously primitive tools. Next come the demands for a widget set in SVG. After several rounds of emails, the person decides that SVG is completely useless, because it doesn't even have radio buttons or a text-entry field.

The important point here is that SVG is a vector image format. It was never designed to replace GUI widgets. It is just an extremely powerful format for specifying 2D images. This claim makes as much sense as saying PNG will never amount to anything because it doesn't support scroll bars and drop down boxes. Obviously, no one would make this claim. But, this reason for claiming the death of SVG keeps recurring.

Amusingly enough, the KDE window manager for Linux uses SVG extensively for graphical elements in its user interface. One reason is because vector formats are very efficient for stylized images that may need to scale to multiple sizes. This describes many of the graphical elements that display on most desktops.

The fact that SVG does not have a built-in set of GUI widgets does not detract from its utility as a vector image format. As KDE has shown, SVG can be used to build parts of a graphical user interface. That is not because it has built-in support for GUI widgets. It is because SVG supports 2D graphics and many GUI elements are basically 2D graphics with behavior.

This claim is about SVG not having support for something it was not designed for. Obviously, this is not proof that the format is dead. SVG is alive and well.

Next time: The 3D Graphics Claim

Reports of SVG's death exaggerated

A message appeared recently on the SVG Development mailing list that, once again, predicts the death of SVG. This meme comes up pretty regularly on the various mailing lists for SVG. Most of them are trolls, of course. But this one got me thinking again about what SVG is and what it is not.

I thought it might be interesting to consider some of these claims and try, once again, to put them to rest. I'll cover each claim in a separate entry over the next few posts. To do that, we need a little background material.

What is SVG

Let's start off with the basics. SVG stands for Scalable Vector Graphics. It is an open XML-based vector graphics format described by a World Wide Web Consortium (W3C) recommendation. Unlike the formats you may be more familiar with (JPEG, PNG, GIF, etc.), SVG is not a grid of colored pixels or raster format. SVG describes graphical objects through lines, curves, and manipulations of objects.

This gives a number of advantages. The first is part of the name: scalable. When you scale a normal raster format larger, the image gets worse (jaggies). When you scale a raster format smaller, you lose information. This isn't a bug, it is a property of all raster formats. Vector formats, on the other hand, are described by mathematical entities like lines and circles. You can scale them to any size without visual artifacts or loss of data.

SVG also supports three other features in addition to the scalability that is part of being a vector format. First, SVG supports declarative animation based on the SMIL W3C recommendation. Secondly, SVG supports scripting through ECMAscript. These two features mean SVG can be used for dynamic images as well as static images. Finally, SVG supports declarative filter effects that can be used to create visually complex images.

The Claims

In the next few posts, I'll explore some of these claims.

1. SVG Lives: the Widget Claim
2. SVG Lives: the 3D Graphics Claim
3. SVG Lives: the Video/Audio Claim
4. SVG Lives: the Internet Explorer Claim

Finally, I'll summarize the discussion: SVG Lives: the Summary

Review of SVG Essentials

SVG Essentials
J. David Eisenberg
O'Reilly, 2002

A little over a year ago I bought and read SVG Essentials by J. David Eisenberg. At the time, I was moving from dabbling in SVG to beginning a contract which required the use of SVG.

This book provides a good working overview of SVG. I have seen several articles that showed how to produce specific effects or that explored a piece of SVG functionality. I've also read the W3C specifications. This book provides the practical information you need to actually use SVG.

One interesting point about the book is it's lack of spectacular graphics. The author states that this is by intent. Most of the pictures only illustrate one, or a small number, of features at a time. He also states that he doesn't want the pictures to overwhelm the novice SVG user that would be discouraged by not being able to produce beautiful work equal to the art in some books.

If you need a refresher on vector graphics or if you want to explore this new XML application, this book is definitely recommended.

SVG and CSS

In most of the SVG I've seen people either prefer to use the style attribute or set the individual style attributes. I don't see much use of CSS classes and I wonder why.

Most of the criticisms I've seen of the use of CSS fall into four categories:

1. It's not XML.
2. It's too verbose to use CSS on all elements.
3. It's not as easily scripted or animated.
4. It's inconsistently supported.

It's not XML

Let's take these one at a time. The first is one of my favorite non-arguments. I don't use XML for every piece of data in my life. For example, most of the words I type do not use characters that are explicitly marked up. Even more amazing, the individual digits of most numbers I use aren't marked up in XML, either.

All sarcasm aside, XML is a good format for some things and a lousy one for others. Sometimes raw text is better. Sometimes a comma-separated values (CSV) file is better. And, sometimes XML is best. So I don't consider this to be a useful argument.

It's too verbose to use CSS on all elements.

Well, that was true of CSS and HTML as well. In fact, I remember people using that as a reason to go ahead and use <font> tags in HTML. (Which were even more verbose.)

People with a bit more experience, or people that are too lazy to style everything explicitly (like me), often use CSS classes to solve that problem. Instead of a large number of individual style properties, you only need one class attribute. This also simplifies changing the look of many elements by modifying the class they are associated with.

It's not as easily scripted or animated.

This is often true. I believe there are viewers and libraries that allow you to modify CSS on the fly, but I don't know that the methods are consistent across tools. The key is to not use CSS for things that you want to be dynamic. In many cases, a large amount of the elements in the display don't change (or some of the styling is static even on elements that do change), style those with CSS classes or with direct styles. Put the things you plan to change in attributes.

In my experience, most of the things I animate or script, I do by changing either individual XML attributes or whole classes of styling. But, I don't usually directly modify styling information. In fact, changing one class attribute can result in a drastic change to an element, effectively modifying a large number of style properties all in one call.

The one downside, of course, is that you need to set up the CSS classes in advance.

It's inconsistently supported.

This is definitely true. I have run across lax CSS features in ASV3 which cause difficulty displaying SVG written for ASV3 on other viewers. But, from what I've heard and seen of newer viewers, that situation seems to be improving. Of course, if we use that excuse we need to stop working on the web. Support and rendering of HTML is still inconsistent. And, in the past, I remember people using invalid HTML to get the visual effects they wanted on certain browsers.

My experience

I've tried to use CSS classes in SVG for most of my own work, and I find it works quite well. I also use the style attribute to override the class values for a few elements.

Finally, if I need to do a lot of scripting or animation on an element I tend to rely on the styling attributes.

In fact each of these approaches has its own strengths and weaknesses. Playing with them allows you to develop a sense for when each could be the right tool for your particular job.

Perl as a "dinosaur"?

Someone asked a question about updating SVG dynamically from a server on the SVG Developers list this morning. One of the (many) responses pointed to an article on SVG server-side.

As usual, I went to check it out to see if it might hold some tidbits I could use. Or maybe, it could be a resource I might recommend. While scanning the article, I found this little quote

Perl is the dinosaur among web scripting languages, its market share (when it comes to server side web scripting) getting smaller...

They go on to point out that in Perl you have to manually set the header.

I find it amusing that people that want to show Perl in a bad light ignore modules like CGI.pm that help to give Perl most of the support you need for web scripting. CGI.pm has been out there for a long, long time. It's been part of the standard distribution since version 5.004.

To give the authors credit, they do mention the SVG.pm Perl module for generating SVG using Perl objects.