Slides for my talk at SVG Open available for download as PDF or Keynote source. (I can make my test corpus available as well — let me know if interested!)

– brion

I’m hanging out down in Mountain View for the SVG Open conference this weekend, to speak a bit on how we use and plan to use SVG at Wikimedia and to get up to date on the state of the art. I’ll post my full talk slides on Sunday after my talk…

One of the most exciting new developments in the SVG world right now is svgweb, a very cool tool which brings high-quality SVG rendering support — including full support for the SVG DOM and interactivity — to any browser that supports Flash. This essentially fills the “SVG gap” for most Internet Explorer users, which opens up a huge world of possibilities for both interactive content and tools for building, editing, and localizing SVG-based diagrams, charts, maps, etc right in the browser.

Google web standards evangelist Brad Neuberg gave a great talk about the background of how something like svgweb was needed and showed some great demos, including a quick preview of an inline SVG pan-and-zoom tool for Wikipedia / Wikimedia Commons; we’ll have some even funner demos based on that Sunday!

Also saw a good talk from Sam Ruby on some of the gotchas in the current state of HTML vs XHTML vs HTML5 and how SVG is (or isn’t) supported in various profiles and various browsers. Most interesting was his proposal to rethink how we deal with markup validators in the webdev world — right now most validators give you a lot of errors about things that don’t really make a difference (font vs style?), but freely ignore problematic but “legitimate” structures (say, unclosed list items).

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.