While going thru the process of learning to convert SVG to XAML, I always had in the back of my mind that I would eventually write a tool that do this conversion automatically. I had assumed that it would be a bit of a chore to do, and that I would use the SharpVectors project as a starting point, since it already has a SVGDOM and parsing engine, and all I would have to do is navigate the DOM and produce the XAML.
But late yesterday all that change when I read a couple posts on the Windows Client Print Driver. Take the concept of Adobe Distiller, but make it XAML instead of PDF, and you have the WCPD. It reverse engineers the GDI objects into XAML. So the idea came to me that maybe I could use the Adobe SVG Viewer (which is an ActiveX control) and WCPD to convert SVG to XAML. Well when I got back to my Longhorn machine last night (after the local user group meeting) I tried it out. Unfortunately, since the ASV is hosted in IE, it must not render directly to GDI, because the WCPD does render all XAML, the SVG is actually a rastered image. So I figure the ActiveX control must raster the image instead of writing directly to GDI (would make sense since the core of ASV is cross platform, or it could be an ActiveX or IE thing).
But I’m not defeated, yet. What I’m going to do this weekend is to try plan b. Plan b is modified version of my original idea of using SharpVectors. Instead of walking the SVG DOM to create the XAML, I’ll take the Graphics object that we create (via GDI+) and print that (which I’ve done for another project and is easy to do) to the WCPD. That should (in theory) produce all XAML and no rastered images (except if the SVG had embedded raster images). The hardest part is porting SharpVectors to the Whidbey/Longhorn build, and that all depends on how much the System.Drawing namespaces changed. Hopefully, by the end of the weekend we will have a really good tool to convert SVG to XAML. I know the resulting XAML will still need to be refactored to eliminate all the repeated graphics, but this is easier than trying to covert all the paths by hand.
Once I get it up and running, I’ll create a new GDN Workspace (since it is a Longhorn only version of SharpVectors), and put all the code up there.
But wait, I’ve still got other ideas that I want to try to get done. There has been a bunch of complaints that XAML will only run on Longhorn, and I was thinking that it shouldn't be that big of a jump to update SharpVectors to render XAML. It wouldn’t have all the performance of Longhorn (well at least the performance Longhorn will have in the final product), but it would enable people to play with XAML on macines that has .Net 1.0/1.1. Right now SharpVectors renders to GDI+, but we have had plans to build a DirectX 9.0 rendering engine in addition to the GDI+ engine, and have the viewer switch between engines depending on the system and/or an attribute in the SVG. IMHO, this is something that the Mono team should be seriously investigating. I emailed Miguel a while ago about using the SharpVectors engine in Mono in addtion to stuff like GTK#, but at the time he didn’t seem to get it, but now that he has seen XAML, I’d hope he is rethinking that decision.
DonXML