SVG for all… with Flash?

Translate This Post

For several years, we’ve supported uploading SVG vector images to Wikimedia sites… with the limitation that they would be rendered to static PNG raster images when actually used inline.
This gives our editors great flexibility in editing, customizing, and translating maps and diagrams using cross-platform free tools like Inkscape, but we’re missing out on some of the big potential in SVG — high-quality scaling for zoomed displays and printing, and animation and scripted interactivity.
In large part we can blame Internet Explorer — the most widely used browser has never supported SVG graphics natively, and Adobe isn’t even maintaining their plug-in anymore! With the majority of users cut out, we’ve had little incentive to move forward with new capabilities that would be closed to most visitors.
But that may be changing, thanks to… Flash??
svgweb implements a highly capable SVG renderer in JavaScript and Flash, bringing high-quality, scriptable SVG support to the ~95% of web users who have either Flash or a naitvely SVG-capable browser.
I love to see Flash’s near-ubiquity used for good — implementing support for modern, open web standards on older and less capable browsers.
One of the chief drivers of the project is Google open standards evangelist Brad Neuberg; we had a great talk today along with Trevor on our Usability team and Michael of Metavid/Kaltura/video awesomeness, and we’re all very excited at the possibilities.
We’re going to see if we can whip together some basic integration in time to show at the SVG Open conference in October, starting with a basic zoom-and-pan view for SVG images which can make use of native or emulated SVG support.
Future ideas that have us really excited include:

  • Live previewing of parameterized images at insert time (localized text, highlighted map segments, charts, etc)
  • On-web basic vector image editing? Sometimes you just need to make an adjustment and installing Inkscape is kind of heavyweight.

Pure SVG + Javascript should be able to provide for selecting, moving, adding, and altering objects, which we could then save back to a new version of the file… svgweb’s powerful scripting support should be able to extend this to Internet Explorer users too!
Use of SVG originals inline in article pages is more dependent on file size issues. We have a lot of files that are just plain huge, especially detailed maps, and the SVG version ends up being a lot slower to download and display.
A project which can help with that is Scour, a tool to optimize SVG source by stripping out unneeded verbosity and rearranging style bits to keep size down.
With further work to strip out detail that will never be visible, a filter like this could let us produce output files that are more suitable for on-screen viewing while still scaling up nicely on zoomed displays and printed output.
Brion Vibber, Lead Software Architect

Archive notice: This is an archived post from blog.wikimedia.org, which operated under different editorial and content guidelines than Diff.

Can you help us translate this article?

In order for this article to reach as many people as possible we would like your help. Can you translate this article to get the message out?

7 Comments
Inline Feedbacks
View all comments

It’s not just about the svg size.
You can easily freeze a browser by making it render lots of very basic svgs.

Platonides :

It’s not just about the svg size.
You can easily freeze a browser by making it render lots of very basic svgs.

Yep… by all means help file bugs with Mozilla etc and make them fix this. 🙂 A slowly rendering SVG shouldn’t interfere with the responsivity of the rest of the system any more than a slowly-loading JPEG does.

This is great news! I can’t wait until this is implemented

“I love to see Flash’s near-ubiquity used for good — implementing support for modern, open web standards on older and less capable browsers.”
Me, I’m glad that, ten years later, “Hey, you can render your preferred SVG instructions in Flash y’know” is finally getting through… in the early years it was amazing how this was simply not heard, a forbidden thought.
Me, I’m more concerned about humans communicating, than I am in the genesis of a file format.
jd/adobe

brion : Platonides : It’s not just about the svg size. You can easily freeze a browser by making it render lots of very basic svgs. Yep… by all means help file bugs with Mozilla etc and make them fix this. 🙂 A slowly rendering SVG shouldn’t interfere with the responsivity of the rest of the system any more than a slowly-loading JPEG does. In this case, Platonides was talking about having multiple instances of Flash on the page, which is an issue with the Flash Player, not the host browser. A single SWF loaded on a page itself can… Read more »

Epoch, I have tests with up to 20 swfs on the page through SVG Web and haven’t seen crashes. What environments and browsers have you seen the issue you describe?