Computer 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
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
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
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
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
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
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.
Chapter 3: Enter the metathemes
At this point in time I decided to join the fray and see if I could do
anything to help accelerate the SVG effort. Through combining the Bluesphere
and Crystal SVG icons, I created a GNOME metatheme called Spheres and Crystals, which gave librsvg a substantial testbed.
Dom and I did a tag-team effort in order to get librsvg to render all the icons. Dom and Matthias Clasen created a
loader on top of librsvg which made SVG graphics available everywhere in the GNOME desktop, but the loader and themes
exposed bugs and needed features throughout the GNOME desktop. A lot of time was
spent filing bug reports and talking with maintainers to get them to
fix their applications and libraries. Eventually most major issues are
fixed both in librsvg, Sodipodi and in GNOME and in February
2003 we released the first version of Spheres and Crystals, which recieved a
We continued working on Spheres and Crystals and used it
as our main vehicle for exposing scalablilty issues in GNOME.
At the same time Jakub Steiner rejuvenated his Gorilla SVG theme (screenshot)
and it becomes the first theme in a new module called gnome-themes-extras. At
this point in time more vector graphics based icon sets starts seeing
the light of day and I decided to try and create more GNOME metathemes
using them. I also decided to kill off Spheres and Crystal feeling it had
outlived its usefulness. It was, after all, a mismatch of icons from various
packages and felt rather inconsistent. The availability of the new
iconsets made me want to try making something that felt more integrated
and polished. To pool efforts and facilitate the creation of these
metathemes, I contacted Jakub Steiner and became co-maintainer of the
gnome-themes-extras package. Combining the beautiful icon work of David Vignoni‘s Lush (screenshot)
and Nuvola (screenshot)
icons and Mathew McClintock‘s
BeOS style icons (screenshot)
with new Gtk and Metacity themes using Andrew Johnson’s slick new GTK+
theme engine Smooth
we shiped the first release of gnome-themes-extras on June 12, 2003.
Later, we added a metatheme based on Michael Doches Amaranth (screenshot)
iconset to the package.
After this things really started to pick up for using SVG on the
desktop. We made many new releases of gnome-themes-extras with many fixes and new icons.
The iconsets became quite popular, and to this day are showing up
in screenshots all over the place. Things were not standing still in
the KDE camp either, and thanks to the relentless effort of Rob Buis, KDE
announced that it will start shipping the KSVG
rendering engine with KDE 3.2.
While not as fast as librsvg, KSVG supports parts of the SVG
specification that librsvg still does not. These traits make KSVG the
perfect tool to provide SVG rendering for KDE’s web browser, Konqueror,
but not so good for on-demand rendering of SVG icon themes.
Chapter 4: Beyond icons
With the basics starting to fall into place, more and more people become
aware of SVG and begin to the possibilities this format offers for desktop computing. The game Monkey-bubble (screenshot)
was relased in October 2003 and helps open people’s eyes to the
possibility of using SVG graphics in games and other types of graphic-intensive software.
That same month, I conspired with Lauris Kaplinski and Bryce Harrington to bring SVG to the forefront of the GNOME desktop.
For a long time, the Sodipodi website had hosted a small
collection of flags. We decided it would be great to have a more
complete collection as a resource for people in a lot of different
situations and settings. So during October 2003 we launch the Sodipodi-flag
collection and send out a call for people to contribute flags under the
Creative Commons Public domain
dedication. Within a few months the collection grew from its initial
20-30 flags to over 330 thanks to the effort of artists like Tobias
Jakobs, Caleb Moore, Patricia Fidi and many others. This flag project helps both to
increase interest in SVG graphics and bring in more developers to the
related projects. The flag collection got quite wide coverage due to
its usefulness beyond free software development, including garnishing a nice
endorsement from Lawrence Lessig.
All is not well in the house of roses though and later that month the
Sodipodi development team splits into two groups, and the Inkscape project is born.
This gives us two SVG editors/Vector drawing applications.
Long running disagreements on topics ranging from GUI design, use of
external libraries, project goal and direction, programming language
used, and more resulted in the developers feeling that they would be happier and
more productive if they worked on two separate projects.
Sodipodi and Inkscape aren’t the only players in town. In
November the Gimp gets some SVG import
support using via librsvg, starting with a basic SVG plugin by Dom
Lachowicz. Sven Neumann later rewrote this plugin, which now also imports SVG paths as Gimp paths (screenshot).
This leads up to to a flurry of activity from Gimp developer Sven
Neuman with many new SVG related functions getting added to the Gimp
allowing it to be used to create some basic SVG drawings. The news of
Gimp’s SVG support gets coverage on most linux art sites and on Slashdot.
November 2003 also turns out to be the month when another important
project gets started. Iago Rubio starts a project called cssed which is a CSS2 editor. Rapid
development follows and cssed is already a useful application.
This application will probably prove very handy for us moving forward with
the plans I will outline in chapter 5.
Based on the example set by Monkey-Bubble and the general excitement
around SVG, the GNOME-games team starts migrating the games to SVG with
Richard Hoelscher as the main artistic force behind the SVG’ification effort with Callum McKenzie taking care of the coding. Three
games have SVG support in the GNOME-games version to be
shipped with GNOME 2.6 – namely Lines (screenshot),
GNOME mines (screenshot)
and Mahjong (screenshot).
The plan is to SVG’ify all the games after GNOME 2.6
and also make sure the games’ GUIs take advantage of the
flexibility of this new graphics format.
Chapter 5: Plans ahead – tasks and visions
Currently, librsvg is working on all sorts of improvements, such as filters and masks.
has proven to be
a superb hacker, having been the major force behind these improvements.
Caleb came on board as a result of the flag collection project and
basically forgot to leave 🙂 He is a welcome addition to the project.
On the issue of themes, we are rounding off the gnome-themes-extras package with the Gartoon icon set by
Kuswanto. Something we really want to get working is the ability to use CSS stylesheets in
conjunction with the icon themes. If, for instance, we could get all
icons in a theme to refer to one css file for their color information,
then we could let users change the coloring tint of their icons easily.
An idea here is to offer something similar to Metacity which can refer
to GTK+ theme colors instead of actual color codes/names. If
we add support for this to libcroco, then your SVG icons could
change their colors in the same fashion as most Metacity themes
change their colors based on your GTK+ theme.
A prerequisite for this would be (currently unimplemented) functionality in Sodipodi and Inkscape
that makes it easy to create and maintain such a shared stylesheet. We have
gotten positive responses from both Sodipodi developers and Inkscape
developers on this idea and Dodji Seketeli of libcroco is willing to help as needed.
This could also have accessibility uses as it would allow people with specific color blindness issues to adjust
the GUI to fit them perfectly by making a high-contrast versions of
these themes using CSS stylesheets.
Another thing we hope to engage the wider community in is the concept of scalable
GUI’s. As screens get higher and higher resolutions, many people want and need high-resolution, scalable GUIs.
Using traditional bitmaps, this would quickly give GUI’s with rather pixellated look – for instance, consider the
double-size mode of XMMS.
Using SVG graphics, we will be able to offer this with
icons that scale up nicely. Work on this is already underway in some of
the GNOME games. Hopefully the games will become ambassadors for the
usefulness of such a feature.
Another thing Jakub Steiner and I want to see happen for GNOME 2.8
is moving the default GNOME theme to SVG. This will probably be done as
a step-by-step process by replacing the existing GNOME stock icons one-by-one
with SVG ones yet in order to preserve GNOME’s current look and feel.
Another alternative would be to use one of the existing SVG icons themes in GNOME 2.8. The
exact solution needs to be discussed although I guess the first
solution is the most likely. Dom Lachowicz has also made a SVG-based GTK+ theme engine,
which should hold some interesting possibilities for SVG based widget themes for GTK+ and GNOME.
The Mozilla project recently announced that they are renewing their SVG effort
and plan to gett the Mozilla SVG rendere enabled by default. This is
essential for promoting the use of SVG on the Internet and to help
motivate artists and tools developers to focus more on scalable, accessible graphics. The
integrated SVG engine in mozilla is important as it allows closer integration of
SVG with the rest of the web technologies found in Mozilla, which can be used to
provide various forms of media enhanced web experiences.
Librsvg maintainer Dom Lachowicz has also been created a
librsvg-based Mozilla plugin(screenshot1,screenshot2) which had its first release in librsvg
2.7.0. It is a solution that works and is available today and can be
used to view any SVG images online, such as the w3c conformance tests.
The final SVG effort we have underway is also by Dom Lachowicz who
has created a fully functional SVG backend to gnome-print based
on the w3c SVGPrint
specification. This means that in GNOME 2.7, any gnome-print enabled application will be able to print your
documents as a SVG. The backend mostly works today, but we need to enable support for SVGPrint
documents in librsvg to have something to actually render them with on-screen. Currently there are no free renderers
available that handle SVGPrint documents. In the long-term it would be interesting to include
support for viewing SVGPrint documents in the planed merged GGV/GPDF
viewer (GNOME Ghostscript (Postscript) and GNOME PDF viewer) so that we would have
one application that can handle all these 3 major print-related technologies.
While originally designed with the web in mind, SVG seems to be have
a strong future on the desktop. Free software is taking the lead in
adopting and popularizing this open format and there are already
multiple implementations available with different strengths and uses.
The wider free software community should seize this chance to help us
reach our goals. The basic parts are there, but much work is still
needed to produce stable, mature SVG libraries and editors. This
includes more work on projects such as Sodipodi or Inkscape. Or tools
for creating the CSS using metathemes or more animation oriented tools
for making SVG animations.
Intersted artists should also be aware of the newly started freedesktop
clipart project. The project is at the following freedesktop mailing list
for the time being, but our hope is to turn it into a shared package of
public domain SVG clipart for use in various applications like GNOME
Office, KDE Office or Open Office.
If you have questions or comments on this article the author
and many of the people from the projects mentioned in this article tend
to hang out in the #librsvg IRC channel on irc.gimp.net. Please feel
free to drop by.