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?
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.
-----