Every once in a while I get in a pure SVG evangelization moment. Today, I was reading through FlashMagazine's explanation of why they had to switch from SWF to HTML for publishing. They know SWF, and they know the limitations of the Flash platforms. So I put on my nice fella hat and wrote this email:
I've been checking out FlashMagazine every week or so to see what was going on in the Flash world outside of Macromedia. However, I am not part of the Flash community... I work within the W3C SVG (Scalable Vector Graphics) Working Group and am keen on evangelizing good usage of SVG.
The arguments you put forward for switching to HTML as a publishing format make a lot of sense to me. I think that is quite sad that Macromedia, although it has come up with very sexy new features (like video) in the latest Flash Player release, still does not handle some very much needed and simpler features like this HTML-kind of layout.
Although I don't imagine you will switch to delivering your content as SVG (that would be nice though), I thought you might well want to hear about how SVG could help your publishing problems.
Also, JPEG loading (or any other image format handled by your implementation) can be loaded dynamically, just like any other SVG content. You can either use the SVG tag the same way you would use your HTML tag to change an image's URL, or use a getURL() method through scripting to do some progressive loading.
As to generation, SVG is simply XML and therefore is very flexible as to how you will want to generate it on your server. You can build your document from scratch using standard APIs like the DOM (available on pretty much every single server platforms out there - Java,
.NET, mod_perl, PHP, you name it!), pre-built templates with modified fragments connected to your database (SVG is just text too!) or just basic kind of CGI like generation like in the good old HTML days. Being XML, SVG will work well with XML data on the backend, and that would enable any kind of alternate output formats you would want to consider (HTML, PDF, even SWF). Also, SVG is free to use. By "free", I mean patent-free and in the public domain, it does not belong to a single company and is a W3C-endorsed standard. You will never *have* to use any proprietary software to generate or view SVG content.
You would also gain a couple things by using SVG. Text in SVG is real text. Writing "Hello World!" in SVG looks something like <text>Hello World!</text> which allow for much accessibility as text selection, search and copy. Note that this would work for any kind of text, it could be on a curve, animated, flipped, with a filter applied to it, etc. Also, you can use fonts specified encoded as SVG (the so-called SVG fonts) to preserve your perfect text layout and look on any platform. There are a couple TrueType to SVG font converters out there.
Now, there are a few myths hanging around about SVG in the Flash community. SVG is bandwidth-friendly: using gzip compression (supported in all SVG client implementations) you get small file sizes, in exactly the same kind of weight that you would get from a comparable SWF file, if not smaller! SVG is pretty well deployed: Adobe have been shipping their SVG Viewer with Acrobat Reader 5 as well as in almost all their products. That way, there are more than 160,000,000 viewers deployed as of late May 2002. It may not be as many as Flash Players, but it is just about as much as PDF viewers out there and I don't see this as a major problem for a lot of people to deploy PDF content online (even Macromedia do on their website).
It would be nice to see some Flash community important people give some support to SVG. Macromedia is just about the only graphics company that keep on not supporting SVG in any way, which is very sad for the advances of dynamic 2D graphics on the Web (and elsewhere). After all, what is of most interest to you: using Flash itself or a whatever rich dynamic 2D solution that will fit your needs?
If you are also using SWF for publishing, take this into consideration.