Well, it took a little longer than I thought, but I finally got the current version of SharpVectorGraphics converted to run on .Net 2.0 and the Longhorn SDK (PDC build), and added a print feature. Sometimes when you are experiencing some weird problems, it is best to drop back to the beginning and start all over. Once I did that, converting the code was easy. But I still get error messages when switching into design mode for a winform, but besides that, the conversion was pretty easy. SharpVectors uses NUnit and SharpZip, so I also pulled the code down for them and rebuilt them in .Net 2.0.
I created a new GDN Workspace for this version of the code, and called it Svg2Xaml. It is really just SharpVectors on Longhorn, but I think people will find it easier with that name. I put all the source into version control, and created two releases, one of just the binaries, and another a zip file with all the source. Any and all changes will be made to the SharpVectorGraphics codebase, and migrated to this project. SharpVectors is by no means complete, but will render most SVG. If you want to join the fun, the team is always looking for help.
Now onto the fun stuff. I used the standard tiger SVG example as a base SVG example (the URL can also be found in the SharpViewer’s combo box), and had the viewer render it (here’s a raster version for those with an SVG viewer). I then setup up my default printer to the Windows Client Printer Driver. I haven’t figured out how to change the printer properties thru code, so you are going to also have to go to the Advanced tab of the Printer Properties, click the Printing Defaults. On the General tab, change the Output Format to Windows Client Markup File and click OK. If you don’t do this, you will get the container version, which is used in the Digital Rights Management support (not the open XAML format). Then just click, File|Print and the Printing window will be displayed and then the SaveAs dialog box is displayed. The save as type should be set to xaml at this point. If it says container, then you didn’t set the Output format of the Print Driver to XAML. Save the file, and voila, you have XAML-GUI.
So the net process is conversion of SVG to a GDI Graphics object (via the SharpVectors GDI Rendering engine. The graphics object is sent to the printer, and the WCPD reverse engineers the graphics object to XAML. You are not going to get any reuse of graphic objects with this model. If a path is 20 different places, it will show up 20 different times in the XAML. You will have to convert the path to a component and reuse as needed, but at least you don’t have to convert all the paths yourself.
Here are the 3 files used in this example:
So, if you are a graphic artist, and want to start creating some stuff with XAML-GUI (aka Avalon Elements) you can use Adobe Illustrator (version 10 or CS) and save to the SVG format. Then you can convert the SVG to XAML-GUI using Svg2Xaml (aka SharpVectors on Longhorn). Not the way you will be doing it in the future, but it will work for now.
Update:
Pablo Fernicola suggested that maybe you could skip the SVG2XAML tool and print thru Illustrator to the WCPD. I haven't installed Illustrator on my Longhorn machine, but you know I'll do that as soon as I get back from work, and then let everyone know the results. SVG2XAML will still be good for those without Illustrator, and eventually it would be cool if we convert the SVG directly to XAML-GUI without going thru the WCPD. But then again, wouldn't it be cool if we also rendered XAML-GUI in SharpVectors (besides SVG). Anyone up for the challenge?
DonXML Demsak