posted by Christian F.K. Schaller on Tue 23rd Mar 2004 19:25 UTC
IconComputer graphics have long been dominated by bitmapped images. However, the free software community has taken an innovative lead by adopting scalable graphic formats on its desktops. Inthis article I cover the history and rise of scalable graphics on the desktop from my angle - as a proponent of its use in the GNOME platform. This article mostly focuses on SVG's progress from a GNOME point of view, both because GNOME has progressed the furthest and because I am most knowledgable with GNOME's efforts. I will however mention major landmarks in other projects where appropriate.


The rise of scalable graphics on the desktop has been enabled by many factors. First and foremost is the W3C SVG XML based vector graphics format. SVG provides us with an open, standard based format for creating such graphics. Using SVG has numerous advantages over other scalable formats. Because it is an XML based file format, SVG allows the creator to conveniently embed arbitrary information inside of the file. For instance by using this inherent feature, an author can store accessibility information or categorization information inside the SVG file - two things that are useful for the indexing engines such as Medusa and for query systems such as Dashboard.

For those of you unfamiliar with SVG, it is a file format for scalable vector graphics developed under the W3C banner as an open and free standard for doing vector graphics and animations on the web. Unlike PNGs and JPEGs, SVG is a vector-based graphics format, which means that its images can scale to almost any size while still retaining a sharp, crisp look. SVG is XML based, which means that it is a human readable format and easily interoperates with other XML based technologies such as XHTML, CSS, DOM and SMIL. SVG's uses are in no way limited to the web, as I hope to outline in this article. In fact, I believe that the effort to popularize SVG on the Linux desktop will turn out to be a critical factor in SVG's success.

Chapter 1: The Levien Years

One of the first persons responsible for bringing native SVG support to Linux was Raph Levien. Raph started with an application he called Gill in the very beginning of 1999. 'Gill' was short for 'GNOME Illustrator' and was the first attempt at creating a free SVG editor and vector drawing application. As part of that effort Raph also started a library called Gdome - an implementation of the W3C DOM standard. Raph was an early adopter, as the first public draft of the SVG specification wasn't released until February 1999.

As the first draft of the SVG spec was released, work on another SVG editor was undertaken - the now well-known Sodipodi drawing application by Lauris Kaplinski. Sodipodi was partially based on Gill. Over the next several months, Sodipodi progressed while Gill came to an end as Raph's attention turned elsewhere.

Adobe came on stage about this time with the first release of their ">SVG browser plugin in March 2000. Being cross plattform it offered a nice way for people to start viewing SVG files in their browsers, although the Linux plugin was never updated often enough to keep up with the rapid changing library stack of Linux, subduing its popularity.

Around the same time a company named Eazel was formed. Part of the their business plan was to develop a new file manager for GNOME, namely Nautilus. With Apple veteran Andy Hertzfeld in charge, Eazel had many plans to revolutionize the desktop experience. As part of their plan, Eazel sought to use vector graphics instead of bitmaps and so hired Raph Levien to create a SVG rendering library to be used in Nautilus. The first version of that code was checked into GNOME CVS in April 2000.

As things would have it, Raph was asked to take over maintainership of the Ghostscript project, a project that had a money-earning commercial venture built up around it. So when Raph left librsvg development and started working on Ghostscript in September/October 2000, librsvg's development went into maintenance mode as the project lost its founder and sole developer.

Chapter 2: SVG renderers galore

At the very end of 2000 Apache's Java-based Batik renderer saw daylight and the world got what was probably the first both complete and free SVG implementation.

Nautilus 1.0 was released with basic/preliminary SVG support on March 15, 2001. At the time, there were no SVG icons or themes. However Nautilus attempted to thumbnail "any" SVG images on your disk as you browsed your directories. At this time librsvg was still very raw and it had a tendency to pull down Nautilus when it came across a SVG file it couldn't render. The combination of librsvg having been abandoned before the library had reached a satisfactory level with general performance issues in its showcasing application Nautilus probably slowed down interest in SVG on the desktop quite a bit although progress in other SVG projects would keep the ball rolling. Around this time, two other SVG projects got underway. The Mozilla SVG project started as part of the Crocodile Mathematics project, although its checkin to Mozilla CVS didn't happen until December 2001. The KDE project began their SVG efforts with KSVG being imported into CVS in August 2001.

Things where looking rather good and a huge boost to SVG development came a month later W3C released the SVG 1.0 specification on 4th September 2001. The first ever SVG icon theme also came into existence as Ximian released the Gorilla SVG theme made by Jakub Steiner in October 2001.

After this follows a period where relatively little happens for over half a year, except for some optimization work on librsvg and Nautilus to get Scalable Gorilla to render faster.

The stage is set for librsvg's return as the primary conductor for the idea of using SVG graphics as Dom Lachowicz took over librsvg maintainership June 2002. Dom had already proved to be a top notch hacker through his work on first Gnumeric then as one of the primary forces behind the Abiword word processor in addition to multiple patches and fixes to low level GNOME libraries. Shortly afterwords, Carl Worth began an effort to create xsvg, a fork of librsvg with the new Cairo X11 extension. This was an amicable fork, as both Dom and Carl collaborated on XSVG's initial design. To this day, Dom plans to use Cairo in librsvg, hoping that he and Carl could pool their efforts. Cairo's immaturity and general unavailability kept for him from doing that. What the future will bring in this regard is still unclear - hopefully the Cairo developers manage to improve Cairo, since it has several shortcomings that make implementing a SVG renderer difficult.

Another effort gets that got started at this time - though not directly related to librsvg or SVG - is libcroco. Libcroco is a CSS2 parsing library by Dodji Seketeli, originally created to use in his mlview XML editor application. Libcroco has proven to be essential to the continued improvement of free software SVG support and is now used by both librsvg and soon KSVG. A second SVG iconset appears in November 2002 when Vladim Plessky begins working on his Bluesphere SVG icons.

The general SVG movement continues as the W3C released its SVG 1.1 recommendation Jan 14, 2003. This was timed well as the KDE project wished to further incorporate SVG in its desktop with its Crystal SVG icon theme by Everaldo Coelho. The theme didn't actually use SVG or vector graphics at all (Its vector claim came from its icons being made using Adobe Illustrator. The icons where then exported as bitmaps). In fact, most of the theme is still not available as SVGs. But since it was presented as being a SVG icon theme, Crystal did have the effect of boosting the mindshare of SVG icons on the desktop.

Table of contents
  1. "SVG, Page 1/3"
  2. "SVG, Page 2/3"
  3. "SVG, Page 3/3"
e p (0)    75 Comment(s)

Technology White Papers

See More