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."
I remember SGI's 4DWM having completely vector based graphics back in 1992 (and probably before that). Has anyone else done it in the interim?
If you're not part of the solution, you're part of the precipitate.
The article mentions several ongoing SVG projects. Worth mentioning is Mozilla's efforts in this arena.
You are receiving this message because your browser supports Slashdot Sigs and you have Slashdot Sigs enabled.
This is not really how it is supposed to work. The cool thing about steganography is, that you might not even know, that a picture has a message encrypted in it, because the data is there any way. since XML is clear text, one could easily see any encrypted text in it, as it is NOT clear text... of course, you could put tags with encrypted text in it that wouldnt get displayed, and as probably only few people would bother reading the source of a svg file, only few people would find out. but if you want to, you can have the pure ciphertext and run cryptographic attacks on it. So it is not really anything like steganography, you could as well hide your encrypted text in the comments of a pdf file or whatever...
I think the author is refering to the embeding of other types of XML in a SVG image. You can for example use HTML and MathML inside an SVG file, or even your own XML based data format.
Yes, you could embed any data (including scripts), and with a ECMAScript capable renderer, even use it to generate the image (for graphs etc).
That's not what steganography is, though. I suggest you review what steganography is.
A big blob of <[CDATA[ would stick out like a sore thumb in an SVG. It's best to stick with embedding int Tiffs and Wavs.
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.
No kidding. I do machine learning, and EVERY TIME this comes up, I immediately think Support Vector Machine... No. Support Vector ... Graphics? OK, that makes sense, but wait. What is a support to an image designer? And why are graphics so important for (this field of) AI?
Wait, oh, I know! This is an algorithm for synthesizing new images based on user response to previous images!
Oops. Wishful thinking. It's just vector graphics. Really, how many formats for this HAVE there been already? I'm glad W3 wasn't around before - we'd still be trying to develop ASCII.
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
This is a decent comparison, except that it leaves out a very important fact. Most sounds are not generated through a midi-type process. On the other hand many images are produced by drawing vectors.
MIDI cannot rival the quality of sampled sound unless the sound being sampled was produced by a MIDI-like process.
SVG is good for many image applications because the sampled forms are produced through an SVG-like process.
What makes SVG even cooler is that we have the perfect rendering technology for it: Cairo. Cairo renders perfectly stroked and antialiased SVG for a variety of backends including bitmaps, PostScript, and X11.
Hopefully the SVG projects will either adopt the existing Cairo SVG code or use the Cairo rendering code as a backend for their SVG libraries.
But XML can be compressed using some amazingly efficient text compression algorithms. In fact, XML generally compresses better than regular text because it has so many predictable features. An SVG file compressed using standard ZIP format yeilds impressive results. It's highly likely most SVG files will be distributed this way.
Two points:
-1, Too Many Layers Of Abstraction
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.
I would have. This is proper technique when writing an article - identify the acronym the first time you use it. Not everyone who reads an article is intimately familiar with the subject. Some of us, in fact, read articles so that we can learn about a topic we're not familiar with.
no one wants it
Not quite true.
Vodafone will start putting SVGT 1.2
on 3 out of 4 tiers of their data enabled live! handsets
(on all except the very low end tier)
in October 2004.
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.
The nice thing about the start menu is that it is always on top (at least for me). I don't think I've seen my desktop in years. A better start menu would be awesome, but making me go to the desktop would be an archeology project.
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.
No, but is Flash actually a standard? Erm... no. It's propietary.
FUD.
The flash format has been documented and thus "open" since 1998.
S
Data that's encrypted for transport through a text-only environment (e.g., email), and to be decrypted by a piece of software supporting multiple ciphers, looks like that -- a header describing what kind of encryption you're using, followed by the encrypted data, which is encoded using the base64 algorithm.
But the encrypted data itself, after stripping the header and de-base64ing it, just looks like random binary noise.
If your recipient knew what encryption algorithm you were going to use to encrypt, you could just leave the header off, and if you're hiding the encrypted data in an image format that allows binary data (SVG, being XML, doesn't, but most image formats, such as JPEG, GIF, PNG, are binary), you wouldn't even need to base64 it.
Liberty in your lifetime
So, one bummer about SVG is that you can't have it enabled in Mozilla and, say, Gnome at the same time.
Mozilla uses a hacked-up libsvg that interferes with other programs. So, SVG is turned off in Debian Mozilla packages, for instance.
Evan Prodromou | evan@prodromou.name | http://evan.prodromou.name/
That isn't really true -- the binary format does save you some parsing work, but that's about it.
Traversing down into the tree is still going to be logarithmic time, at best -- in most real applications you will have to visit the parent nodes to get relevent context information. Unless you've got an index of each node's children in there, you'll still have to resort to some linear scanning...
That's assuming you work directly with the data in serialized form, though, which is not generally a realistic assumption.
Any application using XML data interactively is going to parse the file _once_, into an AST, and use that instead of parsing/writing text over and over. As a result, the application's performance will be dominated by the performance characteristics of the AST representation, not the deserialization costs of the original data.
Binary formats make more sense for e.g. streaming situations, since there you're spending the majority of your time serializing/deserializing data rather than doing transformations on it (i.e. constructing an AST in those cases would be a waste of effort).
DNA just wants to be free...
3rd paragraph: ...
For those of you unfamiliar with SVG, it is a file format for scalable vector graphics
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.
SVG is very useful on its own, but having an open alternative to Flash would be even better. SMIL, a W3C Recommended standard for adding timing and animation to things like SVG and XHTML, is that alternative.
The Mozilla team has (wrongly, IMO) decided to leave full SMIL implementation to plugins. However, the W3C has designated a subset of the SMIL 2.0 modules as being suitable for integration with XHTML, which is obviously functionality that belongs in the browser and is already available in IE6.
To keep Mozilla competitive, allow SVG to reach its full potential, and help kill Flash, I'd like to encourage everyone to vote for two Bugzilla bugs:
If you don't already have a Bugzilla account, you can get one painlessly -- if you use Mozilla you owe it to the community to help direct the project.
In addition you could use ebxml, which is xml in a binary form. This is currently mostly used in wap2.0 and soap. But there's no reason to not use it elsewhere.
The human readable part of xml is a myth. It is just structured data. The most common way to represent this data happens to be very verbose unicode formatted text. Ebxml can be seen as a binary equivalent representation of this data. Instead of the verbose tags and the tedious brackets, whitespace, comments, etc a few bits are used as symbols for tags and attributenames so it is just textual data decorated with binary symbols. Ebxml can be parsed very efficiently (after all xml is nothing but a simple tree representation) and in case of automated generation/consumption, you don't have to worry so much about well formedness (of course you can validate if you want), assuming the generator puts the bits in the right order.
IMHO it is ideal for situations where one program dumps xml to a stream that is read by another program, for example XHTML generated from a contentmanagement system and consumed by a browser. Or embedded svg objects in a openoffice document. Or XML fragments stored in a database.
Currently lots of bandwidth and computer resources are wasted on the human readable part (just, for a second, consider how many bytes of totally pointless commented xml/html fragments are transmitted on the average site, how many brackets, quotes and verbose tagnames the average webpage contains).
But most XML is never touched by a human editor. There is no technical reason for storing XML as very verbose text other than that this is easier to read, debug and generate from scripts. If you construct xml using an api rather than output text to some stream (which in the long term will save you from some headaches), ebxml makes no difference at all.
Ebxml, in combination with gzip compression, would be hard to beat for equivalent datastreams (with the same information). You get very compact data that is easy to parse back into a dom datastructure without giving up the advantage of being able to approach the data using the standard apis (including being able to dump regular unicode xml if needed).
Jilles
SVGmaker transcodes Office documents to SVG. Some sample documents at the site.
Teach me not to test my links! The bugs mentioned in the parent are #231729 and #216462.
Does anybody know why Bugzilla does this?