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.
Introduction
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.
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
GdkPixbuf
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
positive reception.
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.
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.
Summary
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.
Not bad except for the odd ‘problem’. Anyway as pretty much mentioned, what’s holding SVG back is incomplete implimentations. Even in the closed-source world.
the gnome website is down atm, just for peoples info.
5 stars
thank you for this very good article.
cheers,
So what is the gtk theme that dom created? (third page) Anyone know?
All these SVG graphics are amazing and beautiful. If you havn’t tried the gartoon icon theme. Try it! NOW!
Also the graphics for monkey bubble, gnome’s mahjongg, mime sweeper, and lines are also finger-lickin` sweet.
This is really one of the exciting parts of gnome and the linux desktop where OSS is really ahead then both Macos and windows. (btw, the macos ‘scalable’ icons, arn’t really svg type icons, they are just multiple renderings at different sizes, but they are not scalable)
Haven’t RTFA yet, will in a minute. The issue of vector graphics keeps coming up though, and as a designer with 7 years solid experience with tools such as Flash, Freehand, Fireworks, Illustrator and ToonBoomStudio, I wanted to weigh in on the conversation. Vector graphics are great up to a point. Once you start adding layers, transparency, gradients, path complexity (i.e. detail) you can get very bogged down. There comes a point when bitmapped artwork is actually more efficient. Any designer will tell you that with vector tools alone, it is much more difficult to create realistic imagery than it is to create such graphics in a program like Photoshop (bitmap). It will be an interesting space to watch, but I wouldn’t expect vector graphics to be the “holy grail” of UI features.
What advantages does it have over *existing* Metafile format (WMF, MET, EMF, WPG, CGM and many more…) other than being hyped by XML?
At first I thought SVG that it was a replacement for VRML (or it’s multiple offsprings.)
I don’t think the idea is to convert the WORLD to SVG. There’s very little photorealism in GUI’s and their eye candy. I think for most of the applications mentioned in the article – games, themes, icons – that SVG is fantastic.
And really, SVGifying the games for which they showed screenshots makes them look top-notch professional. I’ve not seen a more beautiful-looking mahjong.
“Vector graphics are great up to a point. Once you start adding layers, transparency, gradients, path complexity (i.e. detail) you can get very bogged down. There comes a point when bitmapped artwork is actually more efficient. Any designer will tell you that with vector tools alone, it is much more difficult to create realistic imagery than it is to create such graphics in a program like Photoshop (bitmap).”
Well SVG can embed bitmaps, also an OpenGL based renderer will help with the speed issues.
NeXT computer used Display PostScrpt (SVG was `rpòsed by Adobe based in PS).
Mac OS X uses PostScript to draw in the screen (and printer).
So you can have an idea of what is possible with vector graphics in the desktop.
Well I guess that depends on how important a free and open standard is to you. The ability to work with other XML standards is also a plus. Also VRML is 3D; SVG is 2D.
“Well SVG can embed bitmaps, also an OpenGL based renderer will help with the speed issues.”
Not to be argumentative, believe me, I’m all for vector art – but wouldn’t embedding a bitmap kinda defeat the “S” in SVG? And yes, OpenGL can definitely help – In ToonBoom Studio for instance, using selecting OpenGL acceleration in the preferences *greatly* enhances performance.
IIRC, KDE’s crystal icons are developed as SVG and then ‘rendered’ to a bitmap format for actual use. So you get the best of both worlds.
Thanks Christian for a great survey of SVG world!
Well I think they put that in so it wouldn’t be limited. As you pointed out the world is both bitmap (photos) and vector (Flash). Also including a bitmap doesn’t have to be limiting. The bitmap could be tileable.
[Anonymous (IP: —.server.ntli.net)]
Technicall it all ends up as a bit map. Or at least until I can hook my Tektronix scope up.
“Well SVG can embed bitmaps, also an OpenGL based renderer will help with the speed issues.”
I’m not sure why so many people think that SVG is slow. It doesn’t have to be, even without hardware acceleration. I’ve done tests of librsvg vs. libpng:
Given a SVG image $s. Transform it into a PNG image $p using librsvg, Batik, or something similar. Run “gdk_pixbuf_new_from_file()” on both $p and $s. This will turn $s and $p into identical RGBA images. Time this operation. Lather, rinse, repeat.
Generally, it is no slower (if not faster!) to render $s than $p. This surprised me and quieted many “Vector graphics are too slow for the desktop” pundits.
That was a good read. Thanks!
http://cvs.gnome.org/lxr/source/librsvg/gtk-engine/
The theme *engine* is aptly called “svg”. There are currently no GTK+ *themes* that use this engine other than my demo theme. Trust me, you don’t want to see it. There’s a reason why I don’t install it
I’m not an artist, so my test case is just two really ugly gradients. You’d swear that I was colorblind. But this shouldn’t stop those of you who are more artistically inclined from making SVG themes using this engine, and filing bugs against things that you think could be done better.
Incomplete implementations are one concrete reason why SVG isn’t catching on as quickly as it could.
Then again, it would be folly to think that Los Angeles-sized sprawling specifications also have something to do with the problem as well. In my opinion, SVG can’t decide whether it wants to challenge RGBA, PS/PDF, Flash, all of the above, or something else entirely. It makes it hard when a conforming viewer has to handle the complete DOM spec, CSS, animations, SVG print, and a hundred esoteric little features that no one will ever use.
What we’re reaching now is a common ground between SVG renderers and editors. We’re reaching equal footing, and we’ve defined many of the things we think are essential for our users. Because of this, I think that you’ll see increased SVG adoption in many areas since the necessary feature set has been “felt out”.
Euginia, please require special contributers to proofread their work prior to submission; I don’t want to be a troll, but this article had so many errors in it I couldn’t finish it. It looked like it had great content nonetheless.
Someone pointed out that Vector graphics have been used in a desktop system by both NeXT and Mac OS X. To clarify, wherever else they have been used in the desktop system, I do not believe the icons in either of those systems are vector format images. I know they are bitmaps in OS X, and I know that in NeXT when I create a new Icon it is done with a bitmap editor. Perhaps some of the icons in NeXT are vector format images, but I doubt it.
However, Yellowtab Zeta and the Fat Tracker hack for BeOS which it bases its tracker on do put SVG icons on the desktop. They also put large bitmap icons on the desktop – you can choose either. That was the first place I saw SVG icons, and man are they sweet.
I actually did try to proofread the article and I had someone else go over it too. But when you have gone trough something as many times as I did that article you ‘go blind’ on it after a while. Not being a native english speaker probably didn’t help me either. Sorry that the spelling mistakes turned you off the article
Few reasons from top of head:
1. It is free (as in beer & speech)
2. It is standarised, by entity we can trust
3. It can be (and is) adopted freely, because choosing SVG isn’t tying you to any particular company and its proprietary solution
4. It is XML based, with all goodies that come from that fact
5. It is designed to explicitly take advantage of being XML (using CSS, integration with XForms, possibility of creating compound SVG + anything documents)
6. It’s xplatform, with many implementations to choose from
Thanks to all the svg developers.
Being able to scale the desktop is a big thing for useability. For people like my father it will make a huge difference. He used 800×600 on a 17″ monitor, and now uses 1024×768 on a 21″ monitor. Anything smaller and he has trouble reading it. This kind of makes lcd monitors useless to him since their native resolutions are way to high for him. I look forward to the day when monitor resolution and window size are not tied together.
On a similar note I wish there was a may to scale webpages better. Like how you can zoom in opera, but done automatically based on you dpi. Right now websites are the prime offenders of not scaling well, and even if the rest of the desktop scales perfectly it could still be ruined by some jackass that thinks -2 is a readable font size.
Man, you’re nitpicking. Few typos, and some grammar mistakes – so what? Not everyone out there is native speaker, and honestly it wasn’t so painful as to make it impossible to read
http://www.apple.com/macosx/features/quartzextreme/
“Quartz delivers device-independent and resolution-independent rendering of anti-aliased text, bitmap images and vector graphics.”
Kinda clears it all up doesn’t it (?)
Anyone here who can truly explain why this is more/less impressive than the solutions coming out?
Whatever the case, we’ll all have something similar before MS – that’s what really matters!
As a web designer (who works primarily in Illustrator) I concur … there will always be a place for bitmaps which allow basically limitless freedom of creativity … but at the same time I have been eagerly watching SVG ever since the Adobe released its browser plugin in 2001.
Unfortunately, it’s still the only thing close to a full implementation of SVG. And Illustrator is still the only thing close to a full-featured authoring tool (I know the article is primarily about Gnome, but it might have been mentioned).
SVG could replace HTML *tomorrow* if web browsers only supported it … and I would step over my own mother to see this happen. No more cutting up pages into images, no more reimplementing design elements as block-level elements, background colors or (ugh) table cells. Web sites in 1/10 the time, easy.
Or as a screen display engine, like Apple’s Quartz or Microsoft’s Longhorn … it would mean the end of different monitor sizes or different monitor resolutions. You could set screen text to be a quarter of an inch high and forget it.
Kudos to the Gnome developers for all their hard work, but by focusing on icon sets and 2D office toy games, I think they’ve completely missed the point. They’re putting vector-based shapes where they make the least sense and ignoring the proverbial “killer apps.”
I mean, icon sets? I’m sure there’s a place for some vector elements here … but icons are by their definition relatively small … that’s why Apple uses big TIFFs for its icons (big enough so they only get scaled down, not up) even though its overall rendering engine (Quartz) is vector-based. Just like artists embed bitmap pieces into vector-based compositions all the time. But Gnome is doing the opposite, which is completely bass-ackwards … you completely rob vector shapes of their scability if you embed them in a fixed, bitmapped framework. You’re just condemning vector-originated images to a bitmapped Xwindows prison … at that point you could flatten your precious vectors to 400×400 pixel bitmaps and no one would be able to tell the difference. And in the meantime, you’ve limited your creativity to what can be created using vector shapes and gradient fills.
And for games? I’m sorry, but think of SVG’s inherent artistic limitations … it’s not like people were creating games in PostScript before SVG came on the scene. Pretty much every commercial game out there (i.e. any first-person shooter) has been 3D vector-based for 5 or 10 years, and the game developers of the world aren’t exactly clamoring to give up DirectX and move to 2D vectors. OK, maybe just for Mahjongg.
“I’m all for vector art – but wouldn’t embedding a bitmap kinda defeat the “S” in SVG?”
No — any normal illustrator mixes the two all the time … open up any magazine and look at one of the ads. Or the page layouts for that matter. How does it happen? Photos and hand illustrations are digitized and mixed with type, vector shapes, gradients etc. Or another common technique is to take a bunch of vector-based art and hand-shade it in Photoshop to get realistic shades and tones.
The value of SVG comes from its ability to create the visual framework (a magazine layout, a web page, an application UI) not from drawing the standalone pieces (illustrations, icons) that might be embedded in it.
Quartz uses the PDF drawing model, so much of what you’re seeing on screen is really “vector images”. This is similar to X11’s Cairo (http://www.cairographics.com) rendering engine and also similar to what MSFT is using in their (perenially) upcoming OS, Longhorn.
However, Mac OSX does not use vector-based icons, at least not by default. It ships various versions of its icons at different sizes. Its dock, for example, picks which icon would be “best” for the dock’s current size, and then applies a raster scaling operation to resize the icon. The result still looks pretty good, but gernally requires penning N versions of any given icon, all at different sizes.
Um, I am not sure you understand what we are trying to do. The point is that we are not putting SVG’s into a fixed bitmapped framework. The idea is that as we progress you will be able to scale all your gui’s. I even mention this in the article. So that the toolbars, stock icons, fonts etc. all scale. Which I think is very usefull on things like high resolution displays where sometimes your windows and toolbars can get to small.
Ok, no flame fest here please. I just don’t know what the differences are. I have seen/used GUIs using both of these before but don’t know what the differences are. Enlighten me please.
Yeah, I like your ideas JH, you should definitely speak up. This would be really sweet for web pages, and UI’s I think. Perhaps even better than XAML. The use for Visual framework could be an amazing speedup for designing UI’s and for allowing designers to do this compeletly separate from teh underlying engine code.
I think we need to see better SVG renderers though. Mozilla SVG, adobe SVG, batik, and ksvg (KDE) are very good for web SVG content but are utterly unoptimized for displaying the general interface or painting icons.
Meanwhile, librsvg (which gnome uses), is quite fast for painting icons, but isn’t complete enough to make any sort of general purpose svg engine.
We need something with the completeness of adobe SVG or batik, the web integration of mozilla svg and ksvg, and the speed of rsvg .
With microsoft coming out with new graphics in 2006? it is good to see open source people already on the job. Open source has an untested strength that allows those of great talent to express themselves as they wish rather than having to produce a cog for a company or a boss. Programming at the cutting edge is truly both science and ART. I honor those that can do it and prey they continue for it.
I tend to think that Vector graphics make a lot of sense for icon sets. Things like panels, menus, toolbars, etc… often have the ability to adjust their sizes. The Gnome Panel, for example, can be 24px high or 240px high. Sure, you could achieve something similar by creating a huge TIFF and scaling it down. However, I think that is a horribly inelegant solution. Icon scalability is especially important for visually-impaired users who want large, high-resolution images.
No one is going to replace OpenGL or DirectX with SVG, nor should they. Those are 3D rendering engines. SVG is 2D. Quake is a 3D game. Majohng is generally thought of as a 2D game. There is room in the world for both 2D and 3D games. Having the ability to scale the Majohng tileset is an interesting feature. It’s not clear that you’d want to write Majohng in OpenGL. It’s not a first person shooter…
Finally, if you’re interested in something like magazine layout, what you really want is something like XSL-FO controlling the layout of child SVG, TIFF, and text elements. You probably do not want to solely rely on SVG for that. See the Apache XSL-FO project and Batik for more information on the subject.
Of course, this is beside the fact that no published SVG recommendation supports color profiles (like CMYK and ICCM) that are essential for any real publishing or pre-press uses. The SVG draft 1.2 does, but that is a few months away from becoming a bona-fide recommendation and probably years away from widespread adoption and implementation. YMMV.
If you’re going to try and get Eugenia to address spelling mistakes in articles you might have a better chance if you spell her name right.
Apologies. SVG 1.1 has ICC color profile support. Yet another thing to implement
“I’m all for vector art – but wouldn’t embedding a bitmap kinda defeat the “S” in SVG?”
No — any normal illustrator mixes the two all the time … open up any magazine and look at one of the ads. Or the page layouts for that matter. How does it happen? Photos and hand illustrations are digitized and mixed with type, vector shapes, gradients etc. Or another common technique is to take a bunch of vector-based art and hand-shade it in Photoshop to get realistic shades and tones.
Forgive me, but – Duh! I guess that makes me a “normal” illustrator. The “S” in SVG stands for Scalable. The bitmaps in the work get chunky when scaled up, negating the benefit of scalability.
>> “Another alternative would be to use one of the existing SVG icons themes in GNOME 2.8”
Oooh yeah, Gartoon please!
There are some points in this article which I’d like to correct:
“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.”
We started work on converting Crystal to CrystalSVG in May/June 2002. At that point of time we aimed for using SVG in our default icon theme as soon as possible (ideally by KDE 3.1). Although we had the SVG-icon engine working right in time for KDE 3.1 we considered the risk too high to ship an SVG icon engine which wasn’t very thoroughly tested and which would eventually create slowdowns and crashes (like those experienced in Nautilus) for some users in our _default_ theme. That’s why we enabled the bitmap engine only and shipped KDE 3.1 with bitmap icons instead. More than 150 icons of these were rendered using ksvgtopng in various sizes from SVG’s. SUSE 8.1 was the first distribution to use these bitmap icons rendered from SVG sources. Actually a few dozen SVGz’s made their way into kdelibs by that time (and were at least shipped in the KDE3.1 source tarballs IIRC).
> In fact, most of the theme is still not available as SVGs
and as this theme is the _default_ theme (and therefore requires the highest number of icons in use) this comes to no surprise. I still have to see a Gnome SVG theme which covers all possible default icons either … In addition KDE makes more use of icons than Gnome does.
Unfortunately Everaldo created quite a lot of icons in Illustrator using some stuff in AI that doesn’t export well to SVG so there is still some work to be done to convert those remaining ones.
> 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.
While I didn’t check the performance claims (KSVG has got various aims in addition to performance) I’d just like to mention that for rendering icons KDE doesn’t use the full blown KSVG but a subset of KSVG which is optimized for icons (you don’t need text in icons e.g. — actually you even must not use text in icons at all).
And of course you forgot as well to mention that KDE 3.2 is the first desktop ever released which uses SVGs at least partially in its default theme 😉
Greetings,
Torsten Rahn
<quote>Dom Lachowicz has also made a SVG-based GTK+ theme engine</quote>
OK,
but what about cairo-gtk-engine
which one is to be included?
No one is going to replace OpenGL or DirectX with SVG, nor should they. Those are 3D rendering engines. SVG is 2D. Quake is a 3D game. Majohng is generally thought of as a 2D game. There is room in the world for both 2D and 3D games. Having the ability to scale the Majohng tileset is an interesting feature. It’s not clear that you’d want to write Majohng in OpenGL. It’s not a first person shooter…
Are you kidding? Gnome Majohng in OpenGl would be a killer application, just check http://www.kyodai.com/
Now that’s a killer Majohng 3D game, although is written for Windoew using directX. If only the gnome game were like that.
Could someone please, please answer the qestion. What is the difference between SVG and PNG?????? Or if that is just too lowly of a qestion to be asking, at least point to someplace that I can find out.
few comment
few comments mentioned about it is difficult to make vector-based graphics looks realistic, and i agree with that argument.
but, imho, i don’t think any GUI component (widgets or whatsoever) needs to be that realistic.
people recognize symbol faster than its real photo.
as good icon should not has too much detail.
just look at traffic/street signs.
so i think vector-based graphic is good (enough) for GUI.
(for games, it just depends on which type of game.)
[PNG]
http://www.libpng.org/pub/png/
[SVG]
http://www.w3.org/Graphics/SVG/
Basically PNG is a binary description of an image, while SVG is a textual description of an image.
Basically PNG is a binary description of an image, while SVG is a textual description of an image.
Or PNG is a rastorized image (color this pixel 0x3e2321, color this pixel 0x83a30c, etc, etc for every pixel in the image), where as SVG describes the image using XML tags; ie: <circle cx=”100″ cy=”100″ r=”50″ style=”stoke:green;stroke-width:3″ />
That’s a circle, centered at (100,100) with a radius of 50, and it’s green with a 3 pixel border.
SVG is a format for vector graphics. PNG is a format for raster graphics.
http://en.wikipedia.org/wiki/Raster_graphics
http://en.wikipedia.org/wiki/Vector_graphics
so why did they have an svg implementation before the completion of acceptance of the standards for svg specification version 1.0?
Really, honestly, beos in the future will do a better svg than gnome. Gnome is very slow. Kde is less so, but no matter. It’s bound to bust someone’s bubble and I know people can’t handle a pardigm shift.
SVG would be great for web graphics, not so good for complete web pages. You would lose a lot of the semantics and structure that (X)HTML offers. Writing a web page by hand in SVG would really suck — kind of like coding PostScript by hand. SVG is for (vector) graphics, not for text documents.
Why bother page scaling when you can set your default font size in Preferences. I run my resolution at 1280 x 1024 with my minimum Opera Font setting at 14pt. Enough for me but those who need bigger can try higher font settings. This then makes pages readable and keeps images at 100% scaling (-:
While vectors do scale very well, there *is* a limit to how well they scale visually. Most of the times I’ve created a reasonably complex drawing in Illustrator and scaled it a significant amount, I’ve had to make at least a few small adjustments to make it look right (most often changing the stroke, and the leading if there’s text involved). Perhaps this is just a problem with Illustrator and there are vector apps capable of proportionationally scaling the stroke as well. But there are probably still some cases when it makes more sense to make raster versions at different sizes.
For those that took the time to respond to my question.
Thanks! Learned something new.
I’m wondering why hinting isn’t being used? Works for fonts when dome right.
SVG graphics combined with GNOME desktop icons its cool, specially because every single icon can be resized independent from the other, for example, my trash can icon its bigger than the others, and its good, but it wouln’t look good rendered in PNG just with SVG.
am i the only one reminded of RIP? (remote imaging protocol)
sigh.
Um, I am not sure you understand what we are trying to do. The point is that we are not putting SVG’s into a fixed bitmapped framework. The idea is that as we progress you will be able to scale all your gui’s. I even mention this in the article. So that the toolbars, stock icons, fonts etc. all scale. Which I think is very usefull on things like high resolution displays where sometimes your windows and toolbars can get to small.
I understand this is where you are going and definitely support it! My point was that all this fiddling over icon sets is distracting from this goal. I think OS X got it right by not worrying about vectorizing all the icons and focusing on the core things like screen drawing, window compositing etc. I mean, how big is an icon going to get? Say huge, 4 inches wide, then say you want it to look crisp on a 1200 dpi printer at that size — that’s about a 300 lpi dot screen, so you need 4 times 300 = a 1200×1200 pixel icon. Of course today’s reality is a 1×1 inch icon at 96dpi screen res is fine, so that 1200×1200 pixel icon has a long life ahead of it before it’ll ever need to be scaled up! My other point is that pushing artists to use only SVG vector shapes cuts out all sorts of creative techniques (hand illustration, photography) that could be used to create interesting icons. A 1200×1200 pixel PNG is a blank canvas … the SVG spec is like limiting you to a set of really good cookie cutters.
Plus there’s this fallacy about infinite scalability … just because something is vector-based doesn’t mean it can, should or ever will be used at *any* size. Say you wanted a picture of an airplane half a centimeter high … you could just type one using a dingbat font. But if you wanted one for a poster, obviously the dingbat wouldn’t look good at all, it would have no detail, dimension or modeling whatsoever — it would just look like a blown-up dingbat. Or if you took a detailed picture of an airplane (like a photo) and shrunk it to half a centimeter, it would just look like a tiny blob. Graphic designers make things the right size with the right amount of detail for the job.
An icon is an icon, not a mural … a 1200×1200 pixel icon is just as sharp and “scalable” in the 1-2 inch range at 96dpi screen res as a vector-drawn icon.
Good job with the article, got me thinking.
Zerblat, I agree coding a web page in SVG by hand would suck! Kind of reminds me of writing POV-Ray code like 10 years ago, before there were any GUI tools. But the whole beauty of SVG is that it’s XML-based, so it isn’t separate from the XML — you can take an SVG export for Illustrator or Sodipodi or whatever and immediately use it as a layout template, i.e. XSLT or with a scripting language like PHP … there are sites and especially intranet apps doing this already with Flash — of course with all the obvious downsides like extra (proprietary) server software you need to generate the Flash dynamically, binary file format that doesn’t degrade to text/isn’t repurposeable, closed spec vs. open standard etc.
The problem with just setting the font size is that it breaks the layout on poorly designed sites.
I also like having the images scaled. For small changes it does look ugly, but when I crank the resolution and scale to 150%-200% the scaling artifacts are much harder to see since the pixels are so small. It all comes down to personal taste, and I prefer a slightly distorted image that is big enough to see over a perfect but tiny image.
My problem with SVG icons is that they’re cartoonish. I still haven’t seen an SVG icon set that is detailed (and preety) as Tiggert’s set, or even standard Windows icons. This seems to be a problem with all SVG images that I’ve seen, not just icons.
Does SVG allow gradients, and other tricks people can use when creating bitmaps?
If so, is this a simple choice of style, or lack of attention to detail in the artists?
People with practical experience with both standards – can you create an SVG image with the same detail as a PNG one? If not, what does SVG lack?
“Generally, it is no slower (if not faster!) to render $s than $p. This surprised me and quieted many “Vector graphics are too slow for the desktop” pundits.”
The issue here is no matter what you have on the image a bitmap of 48×48 pixels will take pretty much the same time to render. For vectors it really depends on the complexity of the artwork.
And once you start using stuff like the new filters and alpha masks and aim for realistic looking icons (something close to Industrial’s folder) you start seeing SVG requiring a lot more time.
It’s important to choose your media depending on the artwork. You wouldn’t want to start using jpegs for your lineart just because they work so well for photos…
“My problem with SVG icons is that they’re cartoonish. I still haven’t seen an SVG icon set that is detailed (and preety) as Tiggert’s set, or even standard Windows icons.”
That is simply because the vector media is used properly. Cartoonish styled icons are ideal for SVG implementation.
Yes you could do detailed icons in vector to save on doing the icon in multiple sizes like we do in gnome-icon-theme. But then you’re better off rendering those icons into bitmaps because they will take less time to render.
Eventually the speed hit will become smaller comapred to the advantage of having to do a single icon instead of doing it in multiple sizes. You may start seeing more complex vector icons in future.
Just took a run at Sodipodi, initially looks easy to use and promising. Is there a similar tool for font creation? Would an SVG based font system be a big waste of time or lead to a very easy path for folks to get involved in creating decent fonts?
We are in the middle of developing web-based intranet applications and are using Gecko-based Mozilla as the client because it has *the* best DOM and CSS support among all viable browser engines (Gecko, KHTML, Opera, IE).
We have also decided to SVG in our web application. Unfortunately, we currently have not been very successful using Adobe’s buggy SVG plugin on Linux, and so we are waiting impatiently for good native SVG support in Mozilla. I hope the developers can provide this soon!
If you just need static SVG you can test the librsvg Mozilla PlugIn.
http://librsvg.sourceforge.net/
http://www.inkscape.org/ another excellent svg editor.
IRIX has had vector based icons for years.
<blatant plug>
However, if you don’t have an SGI you can still get a Gnome iconset of the IRIX icons from
http://www.webninja.com/files/Iris-0.4.tar.bz2
You can see a screenshot of some of the icons here
http://www.webninja.com/files/fti2svg.png
And you can get the perl script that turns IRIX .fti icons into .svg files here
http://www.webninja.com/files/fti2svg.pl
</blatant plug>
SVG (and vector in general) compresses very well compared to bitmap images. It is perfect for the desktop, where drawing things such as icons, borders, etc are all implicitly vector. When will we see a DisplaySVG engine where the tree can be manipulated through the W3C DOM API?
Congrats to the author. And with this article I discovered two great sites:
http://zeus.qballcow.nl/ and http://www.users.monornet.hu/linux/
The second site has the gtk the best themes I have ever seen!
Check that out immediately people!
> My problem with SVG icons is that they’re cartoonish.
> I still haven’t seen an SVG icon set that is detailed
> (and preety) as […] standard Windows icons.
I’m pretty sure that many of the icons for Windows XP (maybe even all of them) were made with a vector drawing tool.
What lizenze have the IRIX icons?
Hi,
may I point the author to another implentation of SVG, based on opengl ?
ok, I’m the author of svgl, it sounds a bit like a free ad, and, yes, it is one.
http://www.tls.cena.fr/~conversy/research/svgl
works on macosx, linux and used to work on win32…
stéphane
For thos interested in seeing examples of SVG and an interesting way of displaying and creating them fou UI development visit:
http://www.deerring.com
Sincerely;
James
That’s good, James. We need more like that, to prove to people that SVG is a technology worth pursuing.