posted by Christian F.K. Schaller on Tue 23rd Mar 2004 19:25 UTC

"SVG, Page 3/3"

Chapter 5: Plans ahead - tasks and visions

Currently, librsvg is working on all sorts of improvements, such as filters and masks. Caleb Moore 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 Please feel free to drop by.

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