Follow Slashdot stories on Twitter

 


Forgot your password?
Close
typodupeerror
×
Graphics Software

Scalable Vector Graphics Format Candidate Released 132

Posted by timothy from the must-say-as-one-syllable dept.
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?
This discussion has been archived. No new comments can be posted.

Scalable Vector Graphics Format Candidate Released More

Scalable Vector Graphics Format Candidate Released

Comments Filter:

  • Re:Its Text, Not Binary (Score:1)

    by Anonymous Coward
    A lot of people have this issue with XML - its verbosity leads to larger file sizes. Bandwidth and disk space are still improving, I think it's worth the trade-off for data readability. Hopefully someone will come up with a standard method for compressing XML files for transmission - they should compress pretty good, because they are text-based and also because of the tag redundancy. A plaintext compression scheme would work just fine; an XML-optimized one would be even better.
  • E.g.,
    <line x1="0" y1="0" x2="300" y2="100" style="stroke-width:5" />

    <line x1=0 y1=0 x2=300 y2=100 style="stroke-width:5" />

    as alternatives. Of course, for this particular item, the [xy][12]= items are pretty useless too, unless you want to specify the numbers in some other order, or have interposed defaults.

    <rant>Some XML folks think it's a big deal to parse simple tokens without the quotes, not noticing that they already have the requisite parsing defined in their syntax for the tail end of the left side of the '=' sign. Feh. Use quotes to enclose white space, etc., ok, but x1="0" ?? Is that really necessary? No. There might be instances where you'd need to normalize the representation, e.g., to compare two XML chunks for functional equivalence. Ok, so normalize when/if you need to do that. Don't impose burdens on normal use to cater for the exceptional.</rant>

    IMHO XML is like PostScript Level one. They need a Level 2, for more efficient encoding. SVG has done some things in that direction (gzip compression and abbreviated operator names, etc.), probably because Adobe is on SVG.
    --
    My 2 cents' worth.

  • Re:Macromedia Flash already has the lead. (Score:1)

    by Anonymous Coward
    Flash isn't open at all. You need Marcomedia tools (for Win/Mac only) to create or even view it. The file format is proprietary, and you certainly can't embed it in your page source.
  • actually not NDA (its been awhile) but it is a very restrictive licence on what you can actually do with it. now i cant find it. use to be easy to find.

    my bitch with it being thier claim of being an open standard and that it forces web designers who want to use it (notice all the job descriptions wanting flash?) to use windows or macos. to make content thats only usable on a few platforms, defeating the purpose of the web.

  • eps is for print, static content and with much precise detail paid to color. its easy for eps files to get huge, for example when they have raster images. with svg, said rasters can be jpgs or pngs for example, thus much smaller size.


    not to mention extending for animation, interactivity, and noise is probably soon so we can ditch flash...

  • and i actually looked. NDA.

  • Yes, re-read my post. I said it doesn't make sense to label a graphics format "textual" versus "binary", cause that's just a difference of which basis you use: is it base 256, or base 2? It doesn't matter, right? It's only a difference of a fixed constant factor of space.

    The post I was originally responding to, in part, made the claim that SVG was silly because it used a "textual" representation. But, by the above argument, labeling something as textual doesn't really help matters. A vector graphics format can, in certain cases, represent considerably more information than even a highly JPEG-compressed bitmapped image. Consider the example of a black background with a white diagonal line going through it. That's two operations for a vector format.

    But, in other cases, bitmapped representations are better: imagine a vector representation of an Monet painting. This probably isn't the right domain for a vector representation, and the vector representation will probably be huge compared to a JPEG-compressed bitmapped representation (and maybe even an uncompressed bitmapped representation.
  • PostScript is a good counter-example here. Remember, PDF is gzipped postscript beaten with an ugly stick.

    Text will compress better, and after it has been converted into an internal format, the uncompressed text can be discarded too. Also, if a description language for vector graphics is used correctly, the files shouldn't be that much bigger anyhow.

    I'd trust it a lot more than a binary format, too; at least here I can tell if the source is clean, or clean it up myself if I have to. The flexibility text adds is not to be denied.

    Of course, there's nothing wrong with making a binary format *too*... That's why we have converters. What sorts of vector graphics formats are out there? Coreldraw, Flash, .wmf? I haven't been keeping up with it.
    ---
    pb Reply or e-mail; don't vaguely moderate [ncsu.edu].
  • I've been loosly following SVG for the past year or so. It does have great promise as an open solution to vector graphics. First of all, authoring programs all have SVG support NOW. So the chicken and egg problem is solved. Second, many of the other advantages have already been pointed out - open format, hand editable, XML and other stuff. Since its main competition is Flash, lets compare. XML is easily indexable by search engines, although some may have to make changes to do so. Flash doesn't, although some of the changes in Flash 5 seem to make it easier to integrate with HTML content. Flash has only just added decent scripting support with version 5, so I feel they are neck and neck in that category. Flash does have the advantage of being widely adopted. However, this isn't quite the advantage that one may think it is. I bet a good percentage of the Flash support is v3, with no support for any of the later versions. Furthermore, without an easy mechanism for upgrading these are going to stay that way, negating some of the advantages the newer Flash offers. Still, it is way ahead in this area. Someone from the print design field was looking forward to SVG because it afforded them the nearly seamless transition from the world they are in to the web. We'll all argue that the web is not a brochure, but there are always going to be those that see it that way. Fortunatley, instead of messy HTML we can look forward to SVG sites only, but at least Lynx could be able to get the textual content out of the page. Um, I could keep going, but others have covered some other pros and cons. SVG has some pretty good momentum behind it and it will be a useful addition to the web. You should check it out, if nothing else IBMs Developer Works has a java viewer that should work across most platforms, if you're running windows there are all kinds of programs (including free as in beer) that offer some kind of SVG support.


  • You said:

    "SVG is cooler in every way except it's not
    out and supported by browsers yet. Which,
    unfortunately, may be enough to kill it."

    Although I know what you say is true, you must NOT give up right now.

    After all, there is _still_ a "browser war" going on out there, albeit with a much more _quiter_ war-front. So, with Mozilla is still in its milestone 17 formation stage, and other milestones to come, we should put all our effort into "convincing" the mozilla development team that SVG is super-cool enough for them to support the format.

    And when mozilla picks it up, you bet others will follow.



  • You mentioned:

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

    In other words, is the SVG implementation flexible enough to allow other types of addons ?

  • It's not that open and not really textual, but it rocks for years now.
  • The latest automated build of this breaks Mozilla on my machine.

    (The plain old nightly build is not much better, but at least it runs...)
  • I have to agree. I was rummaging for a good, simple vector graphics format to integrate into my app and was drawn right to SVG. The problem is, SVG uses the HTML model of linking to numerous components, either locally or over the network. While it's a cool idea, how practical is it really?

    First, how many people are sick of seeing slow web browsers? Now images are going to be just as slow as complex tables, as each pattern
    and image element is downloaded separately. Heck, JPEG and PNG decompression is slow enough locally -- now add network latency and bandwidth slow downs!

    Second, what about browsing images offline? Offline HTML is already pretty painful, now you need some way to extract a whole page *and* all of the nested links inside the SVG images.

    Finally, can you say bloat? XML, DOM, CSS, network stack, etc, etc. -- that's alot of code just to display a random graphic. I guess the footprint of modern web browsers has numbed us to the fact that software is getting slower, not faster.

    I'm not saying SVG doesn't have it's place -- but I do agree, this is a classic example of design by committee.
  • Why don't you just download MAME [amame.net]?
  • There's zlib / gzip, they're patent-free, browsers seem to support unpacking them, so no problem at all.
    Well, they have to, gzip compression is part of the HTTP/1.0 Specification [http]. See the Content-encoding section.

    © 2000 Ilmari. All ritghts reserved, all wrongs reversed

  • Mozilla does MathML, and was actually pretty much totally independently developed out of netscape by voulunteers. It works great. I think they even want to make LaTex -> MathML programs etc. I think you can go look at sample pages if you get a nightly build. Very impressive.
  • This is all quite true; XML works well for SVG but the DOM is just plain awful for event-driven development. CSS Events are pathetic, and the DOM is a memory pig.

    I'm ambivalent at this point. You can't really afford to do without something like the XML DOM, but it leaves the programmer in the difficult position of having to do a lot of imaginative coding to balance functionality with standards-compliance.

    I wish the Core DOM could be redesigned, but it's too late at this point.

    MJP
  • The crux of the matter is that the XML parts are all useful and well-designed, whatever the cost. It's worth it to have full XML addressing in the SVG specification, without a doubt. Core XML libraries do most of the work, after all.

    The problem is that the SVG DOM is completely head-up-ass insane. It is a nightmare to implement; I've written proof-of-concept handlers in both C++ and Python, and they were both difficult (although the Python version was far easier: 10% code size and 10% time-to-implement by comparison to my C++ version, plus I get free GC).

    I suspect that SVG DOM support will be largely ignored by vendors for years to come, and even when it's available it will be wildly variant between implementations. It's a real bitch.

    MJP
  • Text works well for vector graphics (see Postscript, CGM, DXF). Text does *not* work well for rasterized graphics, except in limited use (see XPM).

    If you think that vector graphics should be stored in binary, then you might as well argue that HTML should have been a binary format. The same principles apply either way.

    MJP
  • No, that's not right. VML predates the SVG working group; it was available around 1998. They developed it as a vector format with the cooperation of HP, Autodesk, and others with the intention of creating a de facto standard, but submitted it as a primary input for the SVG standard when the SVG working group was formed.

    VML sucks, *really* sucks. But that isn't terribly important, since SVG *doesn't* suck. The other major input to the SVG working group was Adobe (et al)'s PGML standard.

    As far as I can tell, VML really isn't complete, at least not in terms of implementation. IE 5.5 claims to support VML but

    1) Anti-aliasing is not implemented, except for fonts
    2) The 1.0 specification is fraught with inconsistencies, errors, and ambiguity
    3) The documentation on Microsoft's Web site is dated 1998
    4) Microsoft's own VML generation tool supports tags that aren't listed in the 1.0 specification (like ).

    MJP
  • Actually, I beat you to the joke. :-)

    http://savage.sourceforge.net

    MJP
  • Amen to that. There should be a Slashdot area for developers.

    MJP

  • Finally, can you say bloat? XML, DOM, CSS, network stack, etc, etc. -- that's alot of code just to display a random graphic. I guess the footprint of modern web browsers has numbed us to the fact that software is getting slower, not faster.



    XML fights bloat by standardizing layers and re-using components. An SVG implementation need not include its own XML parser, network stack, Unicode components, or Core DOM libraries.



    Quit bashing SVG. As "design by committee" goes, SVG is a shining example of success. Educate yourself before you go off.



    MJP
  • Any idea what Postscript is? (Hint: a vector graphics format)

    MJP
  • Adobe's beta plugin for SVG display works on Windows with Navigator and IE 5.x. It's a good implementation for proof-of-concept and testing.

    http://www.adobe.com/SVG

    MJP
  • All right! I can finally print web pages on that 8-pen plotter that's been lying around the house.

    Now do you thing W3C will come up with an XML ASCII-art standard, so I can use up the rest of my daisy-wheel ribbons?

  • As many have pointed out, XML can be compressed just as Flash can, although the compression is left as an "transfer encoding" (on the HTTP level) rather than being an explicit part of the data format.

    Some suggests that compressed SVG would be bulkier than an equivalent compressed binary format file. Here some Information Theory is useful. It turns out that every type of "message" sent has a certain minimum average size. For example, to send an integer randomly selected from [1,256], you need to use at least 8 bits on average.

    An ideal compressor should shrink every file to its "best" size. In fact, this often almost happens. Reversible transformations applied to a file, such as binary->text or text->binary tend to merly change the resulting compressed size with some constant overhead.

    In the light of that, one could even argue that to create "efficient" binary formats is to confuse the different stages a message is transfered in. You are in effect applying an ad-hoc compression algorithm, when you could/should leave that to the later pass of an universal data compressor.

    But the point is, compressed SVGs will not turn out significantly larger than binary formats with compression, just because the original data was in a different for. It is the content (that is, the picture you are transmitting) that matters.

  • What's wrong with MNG [libpng.org]? I thought MNG was supposed to be the new web animation standard?

  • I have no idea, except that they're not me :)

    You mean mentos [mentos.com], right?

  • HTTP_ACCEPT_ENCODING=gzip,deflate,compress,identit y

    A browser that can do that, can download html,xml,txt,svg,etc,
    content in gzipped format and decode them approprietly, without the propierty kludges of macromedia.
  • PDF is the most ridiculously bloated text format around! I cringe every time I see it used.

    ---
    Despite rumors to the contrary, I am not a turnip.
  • I meant "text format" as in, format which is used for distributing text. I suppose I should have said "document format".

    It annoys the hell out of me to download a 3 MB PDF to read a dozen pages of text and see three pictures, 2 of which are the company logo and the third poorly illustrating a concept already described well by the text.

    I don't know whether it's inherently lousy or just widely misused, but I've never seen a PDF that wouldn't be better in another format.

    ---
    Despite rumors to the contrary, I am not a turnip.
  • PNG/MNG are for bitmapped (pixels) graphics. SVG is vector-based (lines, curves, shapes, etc.) graphics. They serve different purposes.
  • So which one is going to survive? SVG or VML? I know that VML is pushed by Microsoft [microsoft.com] but that isn't necessarily a reason to jump to something else. VML is here now (in IE5 of course) I haven't found a way to actually display SVG output yet (in my 10 minutes of trying).

    SuperID

  • In fact there's somewhere on the MS IE developper site an example of Dynamic HTML that lets you play Asteroid - all done with only HTML, CSS and Javascript ! Works only in IE 4 or better, but still impressive...
  • XML based allows easier xDOM scripting (SVG to HTML-page interactions)
  • ... you can download the SVG plug-in (2.4meg, Win32/Mac) ...

    Even taking shoddy engineering into consideration, that's pretty bloated -- compared to Flash plug-in (actually, ActiveX control) which is about 150KB.

  • Of course, general-purpose compression like gzip is excellent when applied to text.

    However, it will never reduce the animation file size down to Flash's extreme bit-tweaked precision (see the Flash format specification for all the tricks they use to reduce size; they sensibly apply dictionary compression techniques to avoid repetition in the data), which is the first reason why we would want an SVG-specific compression algorithm. I have written a conversion tool for turning Flash into XML and back, and there is no reason why a binary representation of [parts of] SVG could not exist.

    The talk so far of compression has ignored something extremely central to Flash, which is streaming. Streaming is what made Flash the popular format and product it is today.

    In order to compress SVG and still support streaming we would need a multi-part compression system and/or add another XML layer that can hold compressed SVG frame batches as CDATA elements.

    Finally, you don't cite your resolution and pixel depth, which affects the size of the PNG file you're comparing to, so your data point doesn't make much sense.

  • No, Adobe has SWF output with LiveMotion and Xara, a cool UK company, will have SWF output in their upcomming graphic product XaraX, which I heartily recommend.
  • I know this may sound a bit cynical, but I'd think that Microsoft would see this coming and create something similar, with more flexibility than Macromedia's technology, but it would be free and totally proprietary. Kind of like Quicktime, actually. The scenario I describe sounds very similar to the Netscape vs Microsoft thing. Netscape owns the market, Microsoft comes in, forces their browser on everyone, and Netscape withers. And when has Microsoft even followed standards, except those already widely accepted? If HTML wasn't standard before IE, IE would have a totally different markup language.

    My point is that Microsoft will always try to use their existing market advantages to draw more capital and gain more power. If Microsoft makes another windows-only "industry standard," even if it is a mangled version of this proposed standard, and makes everything needed to use/create with this technology, Macromedia will go away, standards will be ignored, and Microsoft will get another tentaclehold.

    This is why Microsoft is evil; not because of its shoddy software, but because its only motivation is greed, as is such for any corporate entity. Oh well.

    It's Time to Crack the Corporate I:
    http://adbusters.org/campaigns/corporate/ [adbusters.org]

  • Microsoft (Hewlett-Packard, Autodesk, and surprisingly Macromedia) submitted VML earlier to the W3C.

    Meanwhile, Adobe (and a few other companies) submitted their version, SVG (an earlier implementation).

    The W3C then put together a group to combine the best of both proposals (along with other entries like DrawML and PGML) that is, apparently, supported by all of the companies mentioned (as well as Mozilla).

    Read Microsoft's take on it here [microsoft.com].
    -----

  • That's what Sun want to do with StarOffice and their openoffice.org

  • Speaking as someone who works alongside 30-40 graphic designers, the reason Flash will win is simply that the content-creators want as much control as possible over the final output.

    They don't like HTML - it looks different on PC's and Macs. They don't like Javascript - people can turn it off. And then next version of a flash player will not render their work obsolete (open standards are all well and good, but unfortunately implementations of them vary hugely - contrast Flash Player which will render everything faithfully (and is already installed in >80% of browsers).

    By and large, Flash content is produced by people who formerly (or still) produced Director content for CD-ROMs. Not programmers, and not OSS advocates.

  • I took the time to read through the Gill site, and most of the points that Raph raises seem to stem from the fact that he's trying to cart the dom around in memory to deal with dynamic updates to the document.

    While this has its up points, and is rather elegant in the abstract, it's not really how I prefer to do things. Add to that the fact that Gill is implemented in C, and you're just begging for a nightmare.

    I've gone a little further afield than I wanted to from my main point: the problems from Gill stem from the W3C DOM API recommendations, not XML. XML by itself really is easy to work with... The dom just isn't capable of being a general purpose document in the MVC paradigm. (Actually, I don't think it's possible to come up with a truly generic way of doing that.)

  • How long till Microsoft change it?
  • Nobody would read something that long "just for curiosity". You might read something like that if you were intending to implement the spec.
  • Granted you need to have some open standards, but SVG won't be implemented because it isn't economical. Why would America Online and Microsoft work to push SVG when the SWF standard is already widely supported -plus- Macromedia has sophisticated the format and is making lots of money off of it? While things like SVG are great for the little guy, large corporations are not helped particularly by it.
  • You mention blueprints, but could this be used with online maps???

    Wiwi
    "I trust in my abilities,
  • with the smil standard, svg, and/or you can achive even better effects cross-platform
  • Very true, but you can do a LOT with lines, text, and area fills. And the files they make are SMALL. Look at Flash--if you're careful, you can make a complete website or fairly complex web app costing about 60k max. (example here [washington.edu], ~68K for a LOT of drawn stuff) It sure as heck will be nice to have scalable vector graphics without having to rely on a plugin.

    On an off-topic note, this having been in the works for a while, I can understand Macromedia's moving towards increased interactability with Flash 5 [macromedia.com].

    -s

    http://students.washington.edu/steve0/ [washington.edu]
  • This trolls been floating about for a while now.

    If I compile a version of gcc, I can charge you as much as I want for it, the thing is you dont have to pay me but I sure as heck can charge you,


    If you think education is expensive, try ignornace
  • I think it's about time people wrote a spec for a text-based vector graphics format.

    This is great because now you'll actually be able to diff your images and have GOOD concurrent versioning of your graphics collection.

  • Flash, you've only got 14 minutes to save the Earth.

    Flash is binary, nasty and costly to develop, it must die.

    I went to a talk on converting flash to SVG a few months ago, the program to do it is available online via some cgi

    Flash to SVG converter [nott.ac.uk]
  • SVG is cooler in every way except it's not out and supported by browsers yet. Which, unfortunately, may be enough to kill it.

    Agreed, although they really need to sort the font problems [levien.com] 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.

  • 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
  • Has anyone actually tried compressing XML?

    Gnumeric uses gzipped XML as their file format. It compresses very well, IIRC.

  • 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
  • http://www.adobe.com/svg [adobe.com] - go there and find out how unavailable it is.
  • Duh.
    MNG = pixelized animation
    SVG = vector graphics animation

    Sorry, just realized my mistake.

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

  • mathML (Score:2)

    by asa ( 33102 )
    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
  • 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?
  • 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.
  • http://www.adobe.com/svg/main.html

    http://www.mozilla.org/projects/svg/

    http://www.webdeveloper.com/design/design_svg_in tro.html

    http://www.xml.com/pub/Guide/SVG_(Scalable_Vecto r_Graphics)
  • FYI, AbiWord [abiword.org] 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.


    --

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

    http://www.mozilla.org/projects/svg/
    http://msdn.microsoft.com/xml/general/overview.a sp

    -----

  • 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.
  • Biological term.

    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

  • Q.What do you get if you cross a mosquito with a mountaineer?

    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.
  • Yeah, I guess that would make it an implementation of the Xtreme Markup Language? :)
  • 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.

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

    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?

    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.

    Text can be compressed, and will usually compress better than binaries. Why? Well, think of the XML text as source code - compilation into binary is a form of compression, so binaries are already compressed (therefore they won't compress well themselves). A text file is likely to be inherently more compressable. Has anyone actually tried compressing XML?

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

  • Not cynical at all, because it happened. Microsoft has something called VML [microsoft.com]. I think they pulled a Netscape-style submit-it-to-the-W3C-after-we've-already-shipped-i t type thing.
  • FLASH IS OPN

    http://www.macromedia.com/software/flash/open/co ntents.html

    . 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
  • PNG/MNG store rasterized bitmaps. This new format stores vector images. The difference is that vector images are pixel-independant; they are scalable to any size, aspect ratio, or dpi setting you like.

    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.

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

    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:

  • SVG specifications have been evolving for quite some time, and Adobe [adobe.com] is one of the companies in the forefront of SVG acceptance. At Adobe's SVG website [adobe.com] you can download the SVG plug-in [adobe.com] (2.4meg, Win32/Mac) and then see demos [adobe.com] 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 [macromedia.com], 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 [perl.com], php [php.net], cold fusion [allaire.com], asp) can generate SVG code just as easily.
  • 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 [w3.org]? I thought that this had promise, but in the last year, no browser has supported it, besides Amaya [w3.org]

    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.


    --

  • Re:bad logic; text for graphics is insane (Score:3)

    by Nick Mitchell ( 1011 ) on Saturday August 05, 2000 @01:34PM (#877492) Homepage
    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).

  • Re:What about PNG? (Score:3)

    by frantzdb ( 22281 ) on Saturday August 05, 2000 @12:04PM (#877493) Homepage
    Neither PNG nor MNG are vector graphics. If you make 'em bigger they pixelize. With vector graphics a circle is a circle, a line is a line rather than a collection of pixels.

    --Ben

  • they aren't as different as you think (Score:3)

    by TheDullBlade ( 28998 ) on Saturday August 05, 2000 @03:29PM (#877494)
    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.

  • bad logic; text for graphics is insane (Score:3)

    by TheDullBlade ( 28998 ) on Saturday August 05, 2000 @01:06PM (#877495)
    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.

  • Re:Not quite (Score:3)

    by psicE ( 126646 ) on Saturday August 05, 2000 @01:49PM (#877496) Homepage
    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.

  • XMill (Score:4)

    by harmonica ( 29841 ) on Saturday August 05, 2000 @01:43PM (#877497)
    Try it here [att.com]. 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.

  • Can We Call It SaVaGe? (Score:4)

    by GeekLife.com ( 84577 ) on Saturday August 05, 2000 @12:23PM (#877498) Homepage
    It'd fit in real well with the whole "extreme" thing we've got going on these days.
    -----

  • Not quite (Score:4)

    by The Pim ( 140414 ) on Saturday August 05, 2000 @12:08PM (#877499)
    Because this is an XML-based format, it should be easy to implement

    You misspelled "a royal pain in the *ss". As the author of Gill [levien.com] makes painfully clear [levien.com], 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.

  • My job hits here (Score:5)

    by British ( 51765 ) <british1500@gmail.com> on Saturday August 05, 2000 @01:34PM (#877500) Homepage Journal
    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.

  • Re:Macromedia Flash already has the lead. (Score:5)

    by GeekLife.com ( 84577 ) on Saturday August 05, 2000 @12:26PM (#877501) Homepage
    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.
    -----

Slashdot Top Deals

After an instrument has been assembled, extra components will be found on the bench.

Close