SVG And The Free Desktop(s) 337
A user 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."
SGI (Score:4, Informative)
Mozilla's native svg support project (Score:3, Informative)
Re:SVG & Steganogrpahy? (Score:2, Informative)
Re:SVG & Steganogrpahy? (Score:2, Informative)
Re:SVG & Steganogrpahy? (Score:3, Informative)
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 [wikipedia.org].
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.
You're trolling, but I'll bite (Score:4, Informative)
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:
Need SVG help? (Score:5, Informative)
Re:WTF? (Score:5, Informative)
Yes, I do know it was a troll.
Re:if (SVG = Flash) .... (Score:5, Informative)
SVG replaces PDF (Acrobat format). SVG plus SMIL replaces SWF (Flash format), as replacing SWF for use in animated presentations such as this [rmitz.org] or this [badgerbadgerbadger.com] needs audio and animation.
Re:stupid acronyms (Score:1, Informative)
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.
Re:if (SVG = Flash) .... (Score:5, Informative)
That's a pretty fair summary, although SVG can be animated [w3.org] without SMIL, using the animation elements. If you add javascript and DOM into the mix you can get interactive applications, like FOAFNaut [foafnaut.org].
Re:SVG is the best thing ever! (Score:2, Informative)
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.
Re:You're trolling, but I'll bite (Score:0, Informative)
The whole package (as I read your post) would quite likely include various programs, that aren't GNU-programs.
Cairo (Score:4, Informative)
What makes SVG even cooler is that we have the perfect rendering technology for it: Cairo [cairographics.org]. 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.
Re:wave of the future (Score:3, Informative)
Re:You're trolling, but I'll bite (Score:5, Informative)
http://en.wikipedia.org/wiki/GNU/Linux
Re:You're trolling, but I'll bite (Score:4, Informative)
Re:no one wants it (Score:2, Informative)
Two points:
Why Vector Graphics matter (Score:5, Informative)
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.
Re:stupid acronyms (Score:3, Informative)
Re:no one wants it (Score:1, Informative)
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 - some obscure features (Score:4, Informative)
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.
Re:You're trolling, but I'll bite (Score:4, Informative)
> KDE or GNOME -> the desktop environment
There's no such thing as X Windows, it's either X, X11 or the X Window System. And although most implementations ship with a primitive UI (twm and some Xlib apps), nobody actually uses this as their UI. These days, an X implementation like XFree86 is mostly used as hardware driver and low level drawing engine for toolkit writers. The actual UI is a DE like KDE, Gnome, or a WM like blackbox, Windowmaker.
Re:Vector graphics on the dekstop (Score:2, Informative)
Re:Best viewed on a vector display (Score:5, Informative)
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.
Re:Here we go again! (Score:3, Informative)
FUD.
The flash format [openswf.org] has been documented and thus "open" since 1998.
S
Re:SVG & Steganogrpahy? (Score:3, Informative)
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.
SVG in Mozilla conflicts with desktop environments (Score:2, Informative)
Mozilla uses a hacked-up libsvg that interferes with other programs. So, SVG is turned off in Debian Mozilla packages, for instance [debian.org].
Re:wave of the future (Score:3, Informative)
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).
Re:stupid acronyms (Score:3, Informative)
For those of you unfamiliar with SVG, it is a file format for scalable vector graphics
Re:Yes! Finally. Let's create an SVG desktop... (Score:5, Informative)
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+SMIL = Flash; Mozilla Needs SMIL! (Score:3, Informative)
SVG is very useful on its own, but having an open alternative to Flash would be even better. SMIL [w3.org], 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 [mozilla.org] to leave full SMIL implementation to plugins. However, the W3C has designated a subset of the SMIL 2.0 modules [w3.org] 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 [mozilla.org] -- if you use Mozilla you owe it to the community to help direct the project.
Re:wave of the future (Score:3, Informative)
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).
Transcode Office to SVG (Score:2, Informative)
"Links to Bugzilla from Slashdot are disabled" (Score:3, Informative)
Does anybody know why Bugzilla does this?