Convert SVG to XAML

For one of our current projects I needed to convert some hazard symbols from SVG to XAML to use them in a Silverlight GIS front-end.  After querying the web I found several tools that supposedly do so.  However none of them fitted my needs.

• A few of them where payable products; and they only offered severely crippled demo versions
• One of them was a plugin for Adobe Illustrator, and I do not have it :)
• Inkscape has an export to xaml function (Save As -> Microsoft XAML), but trying that on the hazard symbols mentioned above (you can download the SVG’s following that link) turned out to be no good.  While the xaml could be parsed correctly from a technical view point, it rendered images that where nothing like the original SVG’s

One of the search results mentioned the Microsoft XPS Document Writer printer driver.  And to my suprise, you can in fact use that one in the process of converting SVG’s to XAML :)

Here’s what I did:

This may seem a bit tedious, but in fact works quite well once you have done a few conversions :)

First, you need an SVG file.  For example: this one

Secondly, you need to open that SVG file in Inkscape (I have had no luck printing the SVG from my browser, probably because it uses some weird plugin to render the SVG).

Then print the SVG from within Inkscape to the Microsoft XPS Document Writer.  You have to specify a file name:

Then go to the location of the .xps file and rename its extension to .zip (yep, apparently it is also a zip file :))

Browse the zip file for \Documents\1\Pages\1.fpage and extract that file.

Optionally rename its .fpage extension to .xml to open it up in your favourite xml editor.  Alternatively leave the file as-is and open it in any text editor (notepad will do).

You should see something like:

<FixedPage Width="816" Height="1056" xmlns="http://schemas.microsoft.com/xps/2005/06" xml:lang="und">
	<Path Data="F0 M 4.32,528.8 L 528.8,528.8 528.8,4.32 4.32,4.32 4.32,528.8 z" Fill="#ffff7d00" />
... snip ...
</FixedPage>

If you copy-paste all the lines that are enclosed between the <FixedPage> tags inside a <Canvas> tag you have fully functional XAML ready to be used in your Silverlight or WPF application :)

Getting my hands dirty again

It’s been more than a year since I last actively participated as a developer in a development team.  Sure, I wrote some kick-ass T-SQL scripts and the occasional line of C#.  But, over the last year my tasks were more targeted to data modeling, functional design and project- and team coordination rather than to writing source code.

This was up until about 3 weeks ago, when I was given the chance to write some code again.  I wrote most of the functional design for the project and a team of 3 developers already implemented a great deal of it.

Now, during the time of my source code writing abstinence, my colleague Davy Brion had done serving his time in Enterprise Hell and was asked to strengthen our in-house software development team.  Davy introduced a lot of technologies and patterns that extended the way we previously developed our software projects.

He ditched our code generated data layer and introduced NHibernate instead.  Being a big fan of dependency injection he also threw Castle Windsor into the picture.  And to top it of, for our unit tests he showed us how to easily mock dependencies using Rhino.Mocks.

It only took me about a day or 2 to fully understand and start using the new architecture in a productive way.  So how did I manage to grasp these concepts so quickly?  Well, the answer is easy: they aren’t all that hard to understand!

NHibernate

While having had no experience in NHibernate at all, I already knew the general idea of ORM.  And as I joined the development in a stage of the project in which already alot of funtionalities were implemented, I had some real life examples of mapping files, entities and data repositories laid out in front of me.  Taking it from there was not that hard.  Although for the occasional question it is kinda handy to have an NHibernate developer in your team.

Castle Windsor

Again, I knew about dependency injection as a way to implement strategies and the likes but seeing CW in action really blew my mind.  You just register your components in code (or xml) and don’t care about them anymore.  The IoC will automatically inject the configured dependencies for you (as long as you provide the means to do so by adding the corresponding constructor parameters or public properties).

Rhino.Mocks

We already were writing unit tests for a few years (as is the core of our genesis development methodology) before Davy introduced Rhino.Mocks.  Some of the techniques a mocking framework solves were not new to me.  I already had stubbed some dependencies with manually written ‘test’ code.  Again, the simplicity of creating mocks, stubs and expectations with Rhino.Mocks really impressed me.  And the unit tests are _fast_!

So, All’s Well That Ends Well?

I did manage to screw one thing up though :)  I wrote a piece of code that created a new entity in memory and that did not initialize a non-nullable field.  Since the tests for that code, mocked the data repository that is responsible for persisting the entity, they ran just fine while in fact they covered faulty code.  Adding an extra test for every non-nullable field would solve this problem, but I don’t believe that is the best approach (a bit tedious don’t you think?).  We’re already thinking about an elegant solution for this… maybe one day you’ll read about that on Davy’s blog orso… :)