Slashdot Mirror
Scalable Vector Graphics Format Candidate Released
gwernol writes: "The Worldwide Web Consortium (W3C) has released the specification for the Scalable Vector Graphics (SVG) format as a 'candidate release.' Because this is an XML-based format, it should be easy to implement, and could see wide adoption as a standard for animated and vector graphics on the web. Cool." And wouldn't it be neat to have a freely available, widely used free-both-ways vector animation format?
http://www.sun.com/xml/
download page
Agreed, although they really need to sort the font problems out. Given the MS monopoly on the desktop, the font issues are unlikely to kill SVG, just as they haven't killed web pages in general. It just becomes really annoying when people assume that because it looks fine on their platform, it'll look fine for everyone.
"The invisible and the non-existent look very much alike." -- Delos B. McKown
Here are my thoughts on why SVG is going to kick Flash (if only people realize it!)
* Programmable using any language supporting the w3c DOM.
Rather than use Flash4's pissweak internal scripting language, or flash5's JavaScript-syntax-similar scripting, you can use anything - ECMAScript,Java,PerlScript, whatever.
Think about this: when browsers support SVG properly, each vendor can provide a custom/standard backend (to handle keyframing, sound, whatever) matched to its authoring tool, if they want (java classes that read some definition file, javascript files etc) -- there is no tie to a proprietary viewer, like flash. The whole functionality of flash can be easily replicated, Java could provide sound support.
It already has some SMIL compatibility built in.
* XML namespaces
Mix'n'match HTML and SVG (and any other XML namespace). Eliminate the need for any bitmaps on a webpage -- just inline or instantiate some SVG -- you can't do it in Flash, and never will (can't do it yet with SVG either, because no browsers support it yet)
* Flash is becoming bloated.
* XML
The enterprise Flash Generator costs some obscene amount of cash.
SVG is just XML -- produce it or read it using any XML tools (eg Apache XML tools, perl's XML::* etc etc).
Create it from some other XML using XSLT.
The whole basis is simply several orders of magnitude more flexible than flash. Off the shelf XML tools can be used with no modification. (Drawing it might be harder, but creating it programmatically/manipulating it is easy)
"Its ascii & too big" -- gzip it, there's a heap of redundancy to be exploited (adobe's svg viewer supports gzipped svg)
I think that one of the biggest obstacles is that heaps of www developers have specialized in flash -- it owns a heap of mindshare.
Adobe sees SVG as its way to beat Macromedia/Flash, and are putting their full force behind it (SVG viewer, SVG support in Illustrator)
Hope I've been coherent enough to get my point across: SVG is so much better than flash, especially for the programmer.
Lach
/* NO COMMENT */
Gnumeric uses gzipped XML as their file format. It compresses very well, IIRC.
Any sufficiently advanced technology is indistinguishable from a rigged demo
--Andy Finkel (J. Klass?)
I think the problem with PDFs is really a larger problem of documentation and the process that produces it. By and large many businesses' documentation sections are dominated by people with print experience -- writers, designers, and desktop publishing people.
The tools they use to generate documentation are the tools of the printing industry, and largely their "product" is designed to be printed on paper. They like PDFs because it doesn't sacrifice the quality of their work and they get to keep doing what they know even when the result is just a PDF file; management likes PDFs because they can stick them on CDs or web pages and make the not entirely untrue claim that they're producing "documentation for the internet" without actually having to do the documentation twice; once for the printed manuals and re-doing it for the web.
What would be nice would be quality "compiler" that would allow postscript or some other application-neutral page composition output to render to web pages.
Netscape, at least on the Unix platforms, has long had this feature where, if feeded a gzipped text file, it would decompress it on-the-fly and display it.
If you apply this to the SVG data-stream, and your stream immediately gets a size comparable to what it'd be if it was some obscure binary format.
SVG is designed for integration with SMIL, which allows for all manner of multimedia. It's a powerful combination.
MJP
Don't try that "protecting the children" shit you people use to keep the tits and bad words off my TV. --Seanbaby
http://www.adobe.com/svg - go there and find out how unavailable it is.
Open Source. Closed Minds. We are Slashdot.
MNG = pixelized animation
SVG = vector graphics animation
Sorry, just realized my mistake.
GNU/Linux. The Freshmaker.
Since this is in XML, one can surely expect file sizes to be huge compared to binary formats. What sort of sumb idea is this?
You will be able to save a lot of space compared to a GIF or PNG that represents a bitmapped version of the same image (which had to be used until now). And you cannot even scale that bitmap a lot without seeing its pixel nature.
My guess is that, if anybody uses this, they'll compress the files as a matter of course. But with LZW, so this will end up with patent issues in practice.
Why should anyone pick LZW?! There's zlib / gzip, they're patent-free, browsers seem to support unpacking them, so no problem at all.
mozilla has it, along with SVG support
Hardly! The .swf as created by Macromedia also includes abilities to throw in sound, TONS of interactivity, a sweet library of network functions, the list goes on.
So what? You can get interactivity from JavaScript, and web browsers can already do sound without Flash. Remember, SVG isn't in its own little world like Flash is. SVG is, ideally, an XML-born, native part of the web browser. This means it can interact with ever other aspect of the page.
Flash is nice, but it has several issues. Not the least of which is the standard is defined by Macromedia. Flash Generator (for dynamic content) is expensive and only runs on NT and Solaris. And since Flash is a plugin, it robs the browser of navigation and boomarking -- just like frames all over again. This really confuses people.
Flash also conveniently sidesteps all the progress that has been made in web standards -- CSS, XML, etc. Anybody can sit down in a few minutes and create a stylesheet. It's remarkably easy to do. The Flash application (or even Adobe's LiveMotion), however, requires some time to learn.
PHP does seem to have some functions for creating SWF files, but I haven't played with it yet.
- Scott
------
Scott Stevenson
Scott Stevenson
Tree House Ideas
Yes, I've seen it done before. You can turn landmarks on/off and zoom in/out to your heart's content. You could make mapquest go really fast! heh
I haven't have the time to digest all the SVG docs yet, so, please permit me to ask this question :
>Is it possible that SOUND is added as an add-on - sort of like a plugin or tag-on thing - for SVG ?
That I do not know for sure. I know with javascript you can stick in sounds(I think, I forgot the gory details).
>In other words, is the SVG implementation flexible enough to allow other types of addons ?
IIRC, you can stick in foreign namespaces, such as HTML into svg documents, so i don't see why not.
If SVG takes off and made hardware for SVG, I would recommend they focus on speeding up the filter effects. Everything I've seen for editing/viewing of SVG graphics WITH filter effects slows down, a LOT. Of course you can do all sorts of neat things with the filter effects, but it is complicated(i once made a rather complicated flowchart form one of the w3c's examples).
Imagine someday counterstrike/quake 3 like graphics made on the fly from a server in SVG. It would be mind boggling. Wait, would that be VRML then?
Oh well, still good for quick and dirty vector graphics. You can make your insignia in a few lines and still have the XML be human-readable. It's the path statements that get a bit complicated to read, and that's best left to software to do that.
You know what would be really cool? A graphics chip that accelerated rendering of something like this. Currently, vector graphics aren't really that feasible for use all over the system because of their performance problems. Even MacOS X still uses bitmaps for most elements. Plus, as anyone who has tried software transparency knows, it is really slow for large images. However, graphics accelerators these days have a nearly limitless number of transistors (from the chip designer's point of view) and it shouldn't be too difficult to design chips that would accelerate something like SVG. Additionally, a lot of 3D these days is very similar to what a 2D vector API would need (the rasterization of curves and lines, compositing using blends, etc) and with some more hardware, it should be feasible to put it on a chip. What that would really enable is the large scale use of vector graphics all over the environment. People who have used MacOS X already know how nifty it can look, and a more large-scale implementation is sure to offer many new possibilities. (One of which could be the ability to keep resolution and image size independant so each one can be customized to suit one's tastes.) Any hardware designers out there? How hard exactly WOULD this be?
A deep unwavering belief is a sure sign you're missing something...
The big problem with SVG is that it is text and not binary. This means that a graphic will be bigger in SVG than Flash. Also flash can be compressed, and SVG cannot making the difference bigger. Think those 100k flash animations are annoying to wait for loading? I can only image how big the SVG equivelents will be.
I can't spell or type, but that doesn't mean I'm unusually stupid.
http://www.adobe.com/svg/main.html
n tro.html
o r_Graphics)
http://www.mozilla.org/projects/svg/
http://www.webdeveloper.com/design/design_svg_i
http://www.xml.com/pub/Guide/SVG_(Scalable_Vect
FYI, AbiWord uses an XML-based format for its documents. It also exports rtf, html, utf, and LaTeX. It's also free software and GTK. It's not feature-complete yet (no bullets or lists for one thing) but it is very lean and fast. It's also evolving fast, so anything that isn't supported yet should be RSN.
--
Friends don't let friends misuse the subjunctive.
Here's a small data point. I have fifteen figures in SVG format, of varying complexity,
which I rendered as PNG and also gzipped.
Total SVG size: 107944 bytes
Total PNG size: 66739 bytes
Total gzipped SVG size: 13510 bytes
> So how long until someone combines the two into
> one format, with the best of both worlds.
Take a close look at Paragraph 5.7 of the SVG
spec. It's already done.
On another note, the figures for the forthcoming ISO/IEC Standard for PNG were done in SVG, and will be converted to PNG for use on the Web.
As is Microsoft. Unfortunately, developers already know how to do Flash and have to learn SVG. Adobe LiveMotion plans on exporting to either SWF or SVG in the future. Macromedia might even do the same someday, what with them being involved in the writing of SVG. If both those things happen, and quickly, SVG might have a chance.
a sp
http://www.mozilla.org/projects/svg/
http://msdn.microsoft.com/xml/general/overview.
-----
An XML-based format may be easy to parse (because free parsers exist) or "reverse engineer" (though the specs are available...) but I see no reason why being XML makes anything easier to implement, unless all you're looking to do is export or validate the files.
vector n 1 Maths a variable quantity, such as force, that has magnitude and direction. 2 Pathol an animal, usually an insect, that carries a disease-producing microorganism from person to person. [Latin: carrier]
Rich
A.Nothing. Everyone knows you can't cross a vector with a scalar.
Rich
one of the benefits of using xml is that javascript built into the browser already has the capabilities to script the animation. Recently though Macromedia has added a scripting language to Flash in ver 5. I know I'll be called upon to script flash in my web design job but I hope SVG wins out. I'll be pushing for it.
.oO0Oo.
There are places where the networks are not touching,and there are places where they are-Boeing's Lori Gunter
Yeah, I guess that would make it an implementation of the Xtreme Markup Language? :)
N4st0r, trixx0r h0bb1tz0rz! Th3y st0l3 0ur pr3c10uzz!
Try iCab for the mac, its only a prerelease 2.0 last I heard, and it won't be ported, and its not open source, but its faster, and better than netscape and ie combined, and it doesn't have full javascript and no css yet, go figure. It also has a preference for rendering, to see if the code is proper or not, and there are a lot of sites that don't use good html. It also has some good validators for html. Soon it may support all the new stuff for the web, hopfully.
As the author of Gill makes painfully clear, vector graphics is hard, standards compliance makes it harder, and XML (with all the baggage it entails) makes it a monster. Care to share why you thought XML would make it easy?
I certainly would care to share. I've been involved in efforts to implement both an XML interpreter and a Macromedia Flash interpreter. I know which one was easier, and it wasn't the Flash interpreter.
Sailing over the event horizon
Not cynical at all, because it happened. Microsoft has something called VML. I think they pulled a Netscape-style submit-it-to-the-W3C-after-we've-already-shipped-i t type thing.
When I hear the word 'innovation', I reach for my pistol.
FLASH IS OPN
o ntents.html
http://www.macromedia.com/software/flash/open/c
. To further Flash as a Web standard, Macromedia has undertaken many initiatives, including opening the Flash file format, releasing the Flash Player code for licensing, and allowing redistribution of the Flash Player
Not a lot of people know that.
SVG has will have it tough, Flash has a serious lead and despite its annoying habit of ignoring your browser it is out there and proven.
(Go on, moderate me up +1)
--
"may you live in interesting times"
Chinese curse
The downside to vector images is that you are limited to the drawing commands provided in the format. While you can apply all sorts of Photoshop filters to a bitmap and save it as PNG, you can only use lines, text, and area fills in a vector format.
SVG is fine for vector graphics alone, yes, but it is not a step up from SWF at all. And the spec for SWF is open and there is a ton of interesting stuff being done with SWF and open source projects.
Personally, I can live with the text in my animation not being indexed by web spiders. I think that's a tiny loss, compared to all you get with SWF.
sig:
sig:
See the "..for smart people" banners Wired runs here? Look elsewhere guys.
SVG specifications have been evolving for quite some time, and Adobe is one of the companies in the forefront of SVG acceptance. At Adobe's SVG website you can download the SVG plug-in (2.4meg, Win32/Mac) and then see demos of what SVG is capable of. One of the coolest things SVG can do over Flash is client-side image filters, such as marbled textures, flaming text, and embossing, without the user having to download a large raster image.
The biggest problem facing SVG going forward is the strong alliance between Microsoft and Macromedia, the makers of Flash. This alliance lead to the tight integration of Flash in Internet Explorer 5.5. Fortunately Adobe has worked out a deal with Microsoft to automatically download the SVG viewer on-demand in future releases, much like Internet Explorer automatically installs the Flash viewer now.
Personally I think the biggest strength of SVG lies in its text/xml format, because any current HTML generating tool (perl, php, cold fusion, asp) can generate SVG code just as easily.
my blog
We can only hope that this catches on. It would drastically increase the flexibility of the web developer. Unfortunately, the only way that I can see it catching on is if M$ implements it; because other browsers would have to follow suit.
W3C's recommendations seem to be increasingly ignored by the major browsers. This is partially because their recommendations seem more complex, but still, old browsers were usually 100% HTML4/3.2 etc. compliant. Now we see all of the major browsers having around 50% compliance for difference specifications.
also, whatever happened to MathML? I thought that this had promise, but in the last year, no browser has supported it, besides Amaya
We seem doomed to be following the wishes of the IE development team instead of those of the W3C.
However, I do believe that this particular technology will catch the eyes of those in M$, and will be implemented. It should be interesting to see how long this takes.
--
I'm sorry. The number you have reached is imaginary. Please rotate your phone 90 degrees and try again.
You can't be seriously comparing bitmapped to vector graphics? A "textual" representation of a bitmap just makes no sense. A bitmap is just that: a map of bits (the 19th entry is a 1), in the same sense that this post is a map of ASCII characters (the 19th entry is an "s"). Observe that ASCII encodings are going to be shorter than bitwise encodings, but only by some fixed constant factor (log256/log2). Also observe that both a raw bitmap and this post are compressible (they probably contain contain lots lots of redundancies :P).
Now, a vector representation of graphics is an entirely different beast. Instead of using 0s and 1s or As and Bs, you use high-level parameterized operations, like DRAWLINE(3x5,5x9). It would be akin to me encoding this document with things like: STANDARDREPLY(sillypost,verbose=9).
In other words, by using high-level primitives, rather than raw data, the size of a vector representation is simply not comparable to a raw representation. It is algorithmic encoding, using domain-specific knowledge (that you are drawing vectors).
--Ben
Now, a vector representation of graphics is an entirely different beast. Instead of using 0s and 1s or As and Bs, you use high-level parameterized operations, like DRAWLINE(3x5,5x9).
Complex vector graphics are composed mostly of coordinates, just as large bitmapped graphics are composed mostly of pixels.
You don't think you can build up bitmapped graphics from smaller components? I guess you've never works with sprite and tile sets.
What about slightly more complex bitmapped graphic languages, that support tiles:
light_green = #00FF00
dark_green = #00A000
light_grey = #A0A0A0
dark_grey = #404040
Grass start
light_green dark_green light_green
light_green dark_green light_green
light_green light_green light_green
end
stone start
light_green light_grey dark_grey
light_green dark_grey dark_grey
light_green light_green light_green
end
field start
grass grass grass grass grass
grass grass grass stone grass
grass stone grass grass grass
grass grass grass grass grass
grass grass grass grass grass
end
or perhaps:
field = tiled(grass,5x5)
changetile(field,4x2,stone)
changetile(field,2x3,stone)
Sometimes, I do stuff somewhat like this when I want a quick hacked-up solution that I can easily manipulate with Perl, but I'd never think of using it as a network standard, and I'd never expect a sufficient number of people to want to edit pictures with vi. Even at my laziest, I always have a binary end-use format.
The advantages are similar, but clearly insufficient. You get a tiny advantage in readability which means maybe a few hours of programmer time saved, and you get a huge increase in file size and a big performance hit in decoding.
The human mind just can't make a picture out of hundreds of DRAWLINE commands any more than it can make a picture out of a grid of hundreds of thousands of #A08EFF style pixels. Unlike something like HTML, it isn't significantly human-readable. Using text just doesn't help much; the proper way to work with these files is in a graphical editor, with the actual format of the data completely hidden from the user.
If they were talking about compiling these specs into an efficient binary format, I'd be cheering them on, but it's just nuts to distribute bloated XML text (compressed or not).
---
Despite rumors to the contrary, I am not a turnip.
The fact that is is a text-based (actually XML-based) format is a strength as well as a weakness. Yes, it tends to be bigger than Flash binaries, but its open and extendible whereas Flash is a closed, proprietary binary format controlled by Macromedia. Its a bit like comparing HTML with the page description languages used internally by desktop publishing apps. Which one was better suited for creating the Web? Which one would you rather work with?
These are all advantages of having an open, well-documented format, not of having a text format.
The only advantage of having a text format is being able to read it and make some small amount of sense out of it with an ordinary ASCII text editor, and it adds a lot of overhead. Similarly, the only advantage of XML over making up a format specially suited to the data is the ability to make some educated guesses about the format from the data, and it adds even more overhead (XML is a lot of things, but it's not terse).
HTML works as text because there's relatively little formatting information and it's almost all text already; a human being can reasonably sit down and manually write HTML to produce anything it is capable of, so it's a good tradeoff. The best you might do by switching to a binary format is cut the average HTML file in half, whereas when you start using a markup language for graphics, you'll probably see a size increase of tenfold or more. People aren't going to be writing a lot of vector graphics in text; this is a huge expense to all the users for a small gain in the convenience of a relatively tiny number programmers.
It's not worth it, not by a long shot.
Text can be compressed, and will usually compress better than binaries.
That doesn't mean that it'll be smaller than the binaries. Quite the contrary, the overhead of storing the necessary data to regenerate the text makes it inherently larger. Not to mention the overhead of decompressing to a file 10X as big, and having to keep that in temporary store and processing it.
Any arguments for and against readable text vector graphics formats apply to bitmapped graphics formats, and we all know how popular readable text bitmapped graphics formats are.
---
Despite rumors to the contrary, I am not a turnip.
You misspelled "a royal pain in the *ss". As the author of Gill makes painfully clear, vector graphics is hard, standards compliance makes it harder, and XML (with all the baggage it entails) makes it a monster. Care to share why you thought XML would make it easy?
:)
Except that with XML, you have two unusual but possible benefits:
1) The graphics could be embedded in page instead of in separate file (useful for line graphics or cases where you can only have one file)
2) Graphics could be itemized by complexity, so that browsers could automatically chop off harder-to-render parts on slower computers or at the user's discretion, or even objectionable parts (have a layer called obscene
Both of these might have been possible before, but now we have both.
Try it here. It takes into consideration the structure of XML for its compression model.
BTW, the exact redundancy depends on the kind of data you're compressing. But because you cannot use certain characters directly in XML (you have to escape certain things like the ampersand etc.), you will always be able to reduce XML files a bit.
It'd fit in real well with the whole "extreme" thing we've got going on these days.
-----
You misspelled "a royal pain in the *ss". As the author of Gill makes painfully clear, vector graphics is hard, standards compliance makes it harder, and XML (with all the baggage it entails) makes it a monster. Care to share why you thought XML would make it easy?
And wouldn't it be neat to have a freely available, widely used free-both-ways vector animation format?
And wouldn't it be neat if everyone was happy, shared their music, and ran Linux on Alpha? Maybe, but it'll be a long road before we get there.
The evaluation of an action as 'practical' . . . depends on what it is that one wishes to practice.
heh, I can now surf to here and not slack off at work. The company I work for is working on SVG, and i must say you can really impress the programmers when you can do/edit SVG by hand just to get things right.
In response to asteroids, yes, someone did make an SVG/ECMAscript asteroids game. I couldn't make more than 1 function in ECMA script until IE conked out on me with bizarre error messages(I was doing functions for moving the SVG-rendered ship around).
I would like to see this format take off though. Even though there is no sound support like Flash, it makes up for it in many other ways. I can't wait until I can scroll through blueprints on a web browser with all sorts of attention to detail.
And that's the *only* advantage with Flash. Navigation disables browser controls, text within it isn't indexed by search engines or searchable with Find, you can't view the source, etc. SVG is cooler in every way except it's not out and supported by browsers yet. Which, unfortunately, may be enough to kill it.
-----