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.
Would it have killed you to say Scalable Vector Graphics once in the article?
I think that's a bit unfair. I for one would be happy if SVG was better supported as a web technology. The advantages to it becoming a standard is that useful, zoomable, interactive charting could be done easily on the client side. Just a little XML on the server side and then let the client deal with it. Right now I use Batik to render the SVG XML to PNG images before sending them to the client. Of course, the client can't zoom in on interesting areas like they can with pure SVG.
Javascript + Nintendo DSi = DSiCade
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.
Just another article that doesn't explain the acronym.
Maybe it's just me, but I'm wondering when SVG will become Flash. Or am I comparing apples and oranges here?
-What have you contributed lately?
They're great for displaying technical drawings. I'd like to see more architectual diagrams on the web, both software architecture and the physical type. With bitmapped graphics, web designers are pretty much limited to small low resolution images, dumbing down detail to a marketroid white sheet level. Vector graphics scale very well for diagrams and cad drawings.
Steganography? Are you going for a keyword karma whoring? Because your post is just silly. Who would try to embed some secret information in an XML file when the whole purpose of XML is so the files can easily be edited in an arbitrary text editor? It doesn't make any practical sense... Even if you encode the text somehow, its presence would still stick out like a much larger sore thumb than, say, a message hidden in a JPG file.
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.
I hear Osama is hiding in a specifically crafted xml document.
I recently dabbled in SVG for a website. I learned with that and a dash of javascript I could completely replace a java applet with a few kilobytes of code.
SVG is finding its way into everything, browsers, icons, etc. I forsee a world where SVG is dominant and regular pixel based images are seen as WAV files as in comparison to MIDI.
As a matter of fact that is a good analogy: MIDI vs WAV. One is intrections on how to draw the other is the final outcome.
Imagine how many songs you could fit on a CD if it were midi, with human voice parameters. Ignoring the vocals, you'd get thousands of songs on a CD.
SVG also fixes the pixelation issue, whenyou try to stretch and compress the image. As a matter of fact, do that once with a regualr image and you're working with crap. You can shrink SVG blow it up, and rotate without any kind of distortion.
It is kind of suprising it took us this long to get a cross-platform standard on how to specify how to draw shapes! But it is a good thing.
I don't think computers will ever be the same once SVG takes off.
Slashdot's rate-of-post filter: Preventing you from posting too many great ideas at once.
This could make for some really interesting desktops, if this is what I think it is. Make some interesting graphical effects within icons or as the desktop without dragging the system down. I can see a new type of desktop where the start menu is replaced by an interactive desktop background. Personally, I hate the damn start menu (including the Linux implementations) as an incredibly ineffieicient way to organize menus. But, that's just my opinion- obviously someone has to like it.
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:
I work at the Center for Teaching, Learning Technology at the university I am enrolled at. I am currently putting together a web-based document management system that is built around XML, and after seeing how much more powerful these open standards can be (especially, when you start looking at all the wonderful concepts that augment XML -- XSL, XPATH, XSL:FO, and the like).
We used to put together all of our documentation for workshops and whatnot using MS Word, and then later switched to InDesign for the sake of having more control over the layout. The new web-based system means we lost some control over the layout of these documents, but the amount of time we've saved and the flexibility we've gained from using it is worth more than its weight in gold (all 2mb worth -- if that, even)
What's frightening, however, is to see these products like MS Word and others potentially offering the option to export to a more open format, like XML. Ever tried reading through MS Word generated HTML? It's almost a fun task, and I hate to think of the possibilty of having to read through MS Word generated XML... eep!
huzzah
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.
Famous Last Web Development Words
Get thee glass eyes, and, like a scurvy politician, seem to see things thou dost not.--King Lear
I'd like to see SVG used more frequently for all sorts of things. I'm not a big fan of XML, but it seems like it'd be quite appropriate in many situations where bitmap formats are ordinarily used. Not only would such images be scalable, but it seems like they would be much easier to manipulate (how about typing or tweaking your images with a text editor?). Drawing languages are more interesting than bitmap formats, since you can actually do things with objects instead of pixels. I would be more interested in using SVG if a more 'flattened' wrapper format could be used to contain equivalent data ("rect 0 0 50 50 blue 5") making it easier to type by hand, and avoiding bloated XML data.
Around 1994 or so I had an updated version of this working. It was a major revision, so it was called SVGA.
I want to drag this out as long as possible. Bring me my protractor.
The best way to do this is with vector based graphics, which is what SVG is.
"Even if you encode the text somehow, its presence would still stick out like a much larger sore thumb than, say, a message hidden in a JPG file."
But XML does give you plenty of potential hiding places for data (e.g. white-space)
Now, SVG would make a lot of sense on a
vector display. However, where could you
get a modern vector display nowadays?
They used to sell arcade machines (battlezone)
and game consoles (vectrix) with these
displays.
Bram Stolk http://stolk.org/tlctc/
... so I can finally use my 8 way Opteron with 16GB to its fullest potential!!
Well duh, the whole point steganography is that you can't prove the data is even there.
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.
OH THE SHAME I fell off the wagon and use sigs again!
Some of you have remarked that MIDI has lost. Well, ear interpretations are not analogous to visual interpretations.
I was more referring about the costs to a computer of using them.
However if you do compare SVG icons to Bit-map icons, visually, the SVG icon will not only be simpler, and usually just as apealing.
Look at the SVG icon sets referenced and the background of Slax (Slackware's LiveCD) The #1 comment is "aww he's so cute". Clearly, the visual accptance is much higher to the human eye than MIDI's acceptance to the human ear.
MIDI could be re-invented to include wavelets which are a base representation of a voice (instrument or human) then define the mathmatical operations. You'd get a 99% facimilie that would probably pass as good as a low-quality MP3 at 1/0th the size.
Example (as SVG):
Now human voices are harder, but once downloaded you could just download the contents of the tree.
You could also hear brittney sing "Opps.." in her original voice or her aged voice, which would be interesting. Or even make Christina Agulera sing Spear's songs.
If you're seeing the potential of re-defining MIDI like that, surely you can see hwo awesome SVG is...
Slashdot's rate-of-post filter: Preventing you from posting too many great ideas at once.
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.
Indeed. Longhorn's vector graphics break the SVG standard, "because SVG did not integrate well with Avalon"--even though SVG is XML, like Avalon. You'd think with 400 developers working on Avalon, they would find a way to integrate it...
I'm sure they'll go out of their way to make it difficult to convert between their screwy system and the W3 standard. Hopefully someone will hack out a converter. And this IS important, for companies that don't want to rewrite all their vector graphics to port something to Linux. Reusing icons on different platforms used to be the easiest part.
Death and danger are my various breads and various butters.
Slashdot's rate-of-post filter: Preventing you from posting too many great ideas at once.
Anyone remember vector monitors? Those things would be great to resurrect, supposing that SVG really kicks in on the desktop, and also supposing that we get some svg version of asteroids shipping with those new o/s installs... nice!
stuff |
Yeah yeah yeah "Flash sucks, blah blah blah."
/. community would update their knowledge accordingly.
Dude, the web is full of badly designed websites written in HTML. Is HTML a bad standard?
Flash is capable of creating compact little applications, parsing XML from a data source, playing video, and doing a million other things that are made possible by the ubiquitous Flash player. We've moved on from the days of 'skip intro.' I wish the
Sheesh!
Drill baby drill - on Mars
With the vectrex video game system
I wonder... could those games be made to run under SVG... with frame buffering....
Two points:
-1, Too Many Layers Of Abstraction
So the fact that I use say fluxbox or windowmaker
as a windowmanager and no additional "desktop"
bloat means that I don't have a desktop
or a full GNU/Linux installation?
That is retarded.
I would suggest that GNU/Linux is (generally)
everything in your list up and including to Xwindows and some windowmanager. The desktop
stuff like KDE and GNOME are just further enhancements on top of the windowmanager.
But they should "never" be considered an
essential part of a GNU/Linux system.
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.
It's time for pixels to go away. With displays running from cellphones to graphic arts workstations, the concept just isn't useful any more above the renering level. I look forward to replacing as many as possible of the old pixel-based graphics format with something I can see at more than one display resolution.
Now if we can just get the Xwindows folks on board! When I say "12-point type", I mean a height of 6 lines per inch, not 12 pixels (enormous on the cellphone; invisible on the workstation).
Welcome to the Turing Tarpit, where everything is possible but nothing interesting is easy.
Hell, Y-Windows is thinking of using SVG for describing all their widgets. They plan a 1.0 release within the year.
SVG is being used almost everywhere I look. Icons are just the beginning.
Who would try to embed some secret information in an XML file Didn't MS get a patent on XML file formats that have data encrypted inside them?
Post: Sigged, for your pleasure.
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.
It's true that SVG (and XML in general) compresses well using normal Lempel-Ziv techniques.
But that only solves part of the problem, and isn't enough to make XML efficient for an integral part of interactive computer systems (where speed is crucial).
Normal XML is already slower than a binary format, because you must parse through the whole thing to reach the middle (linear time) versus jumping to an offset in the file (constant time). Adding compression to the mix makes that even worse, as now you've got to do the whole unpacking before the data can be read.
So although ZIP mostly solves the XML storage-size problem, it worsens the already bad XML access-time issue.
It's truely unfortunate that the XML standard didn't include some recommended/authoritative way to transform an XML file into a platform-dependent binary. Or even a defined mapping from XML into an XDR-like layout would be useful.
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...
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.
Well... for Inkscape I know that it's high up on the lists for some of the developers, and several of them are actually investigating various factors now.
Animation and scripting support are two things that may go in hand-in-hand, but definitely are being worked on. Of course, since it's open source, there's no hard timeline for supporting it, but I would not be supprised to see it in the CVS versions in the next quarter. The internals are being reworked now in a way that will facilitate that better.
...and of course, XDR is primarily used for situations where serialization/deserialization costs dominate (i.e. RPC).
You'll notice it's the RPC folks who are most interested in a binary XML representation.
DNA just wants to be free...
ls /bin
There are places where the networks are not touching,and there are places where they are-Boeing's Lori Gunter
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?
SVG is a perfect format for interactive visualizations of dynamic data.
For example, here is an interactive genealogical data visualization that was produced using XSLT transformations and published as a RESTful service via a Java servlet. The sourceforge project has more information on how the visualization was produced.
Use SVG as a medium to visually repurpose data to create your own interpretation of the world!
both these apps work on more than just linux. in fact from the SF stats the majority of users are win32 folks.