Slashdot Mirror
SVG And The Free Desktop (s)
unmadindu writes "Christian Schaller has written an interesting article on SVG's current and possible uses on the GNU/Linux desktop. Though the article concentrates mostly on GNOME, it does mention the excellent work the KDE developers have been doing with KSVG, and refers to the upcoming SVG support in Mozilla too."
Not exactly. Linux is the kernel, X Windows is the GUI, and KDE (or GNOME) is the Desktop Environment. The whole package together is called GNU/Linux, but most people just call it Linux. I sidestep the whole GNU/Linux vs. Linux debate by just calling it Mandrake or Debian or Redhat, but that's just me.
So, in summary:
If *you* need SVG support (with creating it) now that your desktop supports it, I highly recommend the fine folks in #svg on the Freenode IRC network.
Yes, I do know it was a troll.
SVG replaces PDF (Acrobat format). SVG plus SMIL replaces SWF (Flash format), as replacing SWF for use in animated presentations such as this or this needs audio and animation.
SVG replaces PDF (Acrobat format). SVG plus SMIL replaces SWF..
That's a pretty fair summary, although SVG can be animated without SMIL, using the animation elements. If you add javascript and DOM into the mix you can get interactive applications, like FOAFNaut.
Slashdot looked deep within my soul and assigned
me a number based on the order in which I joined
It is only a natural evolution from character based displays to bitmaps to vector graphics. The main advantage of vector graphics is resolution independence. Imagine installing a very high resolution screen, and instead of everything getting smaller everything gets sharper. Want to display more information on the screen? Just seemlessly zoom in and out of your desktop. Currently, most windows systems are bitmap based, although there are some kludgy ways of adapting to different resolutions without changing the size of your text and windows and icons.
The big problem is that our current screens are just not good enough. Monitors rarely get over 150dpi, whereas even very old laser printers get 300dpi. On most screens, you can still see the individual dots. This is why zooming in and out like I described above wouldn't work on current hardware: too much detail is lost when the zoomed out desktop is rasterized to the screen. It would be only good for previewing the windows (like Apple's Expose), not for actually working with them. Note that in the area where these issues matters the most, text and font display, there has been a great amount of research and clever solutions to work around this. If (when?) display technology finally catches up, the entire windows system will be arbitrarily scaled with good quality, not just the fonts. Let's hope that when the hardware get's good enough, the software to utilize it will already be in place.
SVG - or more specifically, the Adobe Plugin for SVG, has some interesting features that makes the use of SVG even more interesting..
The Adobe SVG provides the user a getURL() (or similar named) method which allows the browser to read information from the server or any other arbitary url on the web without any form submits of page refreshes.
This is useful, for instance, to have a stock exchange ticker which continuosly reads data from a stock exchange server and renders a graph of the values on the screen - without requiring the browser to refresh.
Another interesting aspect of SVG is that it can be compressed using gzip and so a fairly complex svg image could still be in a very small file. The data that is passed into the SVG could also be compressed.
where could you get a modern vector display nowadays
A few posts have commented that vector-displays would be good to use with SVG-based desktops. They're probably all joking, because there is no such thing as a modern vector-graphics display, and if it did exist, it would be inapplicable.
Vector displays can only draw the actual vectors, which are just straight lines. Vector graphics consist of more than just vectors, and actually includes a full set of primitives whose positions are merely defined by vectors.
Even a simple filled triangle (surely one of the most common elements of existing SVG files) is beyond the capability of a vector display, unless it emulated a raster display to draw the shape as a series of scanlines.
I posted this on OSNews, but I'll post it again here...
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.
Of course, once you start using some of the more advanced features (like certain filters), the rendering time is likely to go up. It all depends on what features you use and how you use them.