SVGRoundTrip, Part 1: Why Use SVG?

Until recently, whenever I was designing the interface for a new application I'd usually use raster images, normally PNG files, for button icons etc. The advantage of raster images is that I can use many different graphics programs to edit the files and I have control over the appearance of every single pixel. The downside is that the images don't scale well. For example, lets say that I start out using 16x16 pixel images for toolbar buttons. I then realise that as I don't have many buttons it would make more sense to have bigger buttons, say 32x32 pixels. I could just scale the small images up but they would look horrid, so I'd have to go back and create a whole new set of images.

SVG files (Scalable Vector Graphics) do, however, scale well. Their ability to scale comes from the fact that instead of recording pixel information they store shape and colour information -- a square is stored by knowing the points of the four corners. This makes it easy to scale the images without losing quality. The downside is that there are less applications I can use to edit them (Inkscape is the best I've found) and more importantly Java has no native support for displaying them. Fortunately the Batik library from Apache can load and convert SVG files so I can use them in my applications. Unfortunately there are a couple of downsides to using Batik:

1. The Batik distribution is huge, just the main JAR file weighs in at over 3MB. Given that I tend to release applications via Java Web Start I don't really want to add 3MB to the download time.
2. Converting SVG files into a format that Java can display seems to be quite CPU and memory intensive, which leads to slow startup times as soon as you have just a few files to convert.

The Flamingo component suite (that I've used to develop the GUI for both PhotoGrid and 3DAssembler) sidesteps these issues by converting the SVG files into Java classes at development time. This means you don't need Batik at run-time (reducing the download size of the application) and the time/resources to convert the files is done once and not at each application startup. Perfect! Unfortunately the developer of Flamingo has recently announced that he is suspending support and development.

As I don't want to rely on code that is no longer being supported or developed, especially as I know there are some issues with the SVG related code, I've decided to start work on a new library called SVGRoundTrip. The library will be based on Batik and incorporate ideas from Flamingo with the aim of supporting both the display of SVG files in Java applications as well as the production of SVG files from within Java applications. I'm starting by adding support for things I need but will be happy to added support for more features as time goes by.

I'm going to write a number of posts highlighting different aspects of the library but for now I just wanted to show an example of why using SVG files is a much better idea than relying on raster image formats. The image on the left shows five different renderings of the same SVG file: 16x16, 32x32, 48x48, 64x64 and 200x200. The SVG file stores the 48x48 pixel version but as you can see there is no loss in quality as we scale up or down in size.

Whilst SVGRoundTrip is by no means finished the example image was actually produced using the library to load an SVG file into a Java application, draw it a different sizes and then save the image to a PNG file. If you can't wait until the next exciting installment of this blog then you can follow development from the SVGRoundTrip page on my Hudson server, or grab the source from the subversion repository.