Den Ben’s Blog

March 17, 2009

Convert SVG to XAML

Filed under: Silverlight, WPF — Tags: , , , , , — benpittoors @ 20:00

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:

xps_filedialog

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 :)

Advertisements

December 2, 2008

Software Factories and Frameworks. How to maintain infrastructure code?

Filed under: Software Development — Tags: , — benpittoors @ 20:53

In a reaction to Davy Brion‘s post about how to deal with common infrastructure code for multiple projects I’d like to share my take on said topic.  I already placed a brief comment on Davy’s blog but maybe I need to go in a bit more detail to make my point fully clear.

Davy lists these 3 options, each with its pro’s and con’s:

  1. Infrastructure code as a separate project.  Binary dependency per client project.
  2. Infrastructure code as a separate project.  Copy source code into client project repository.
  3. No separate infrastructure project.  Each project contains its own infrastructure code.

If you place these options into following table, you get ‘more consistency over different projects’ on the left hand side and ‘more flexibility’ on the right hand side:

Option 1 Option 2 Option 3
  • Highest level of consistency
  • Requires a lot of discipline in versioning and maintaining
  • Has to provide many extensibility points for clients to implement their custom behavior
  • Least flexible
  • Inconsistencies possible between client projects
  • Still requires a certain level of discipline for maintaining different versions
  • Also requires extensibility points for custom implementations
  • A bit more flexible
  • Inconsistencies between client projects are as good as certain
  • No need to maintain different versions
  • No extensibility points required
  • Very flexible

The question is:  What option would you take?

Easy question, not so easy answer!  My take would be not to pick a single option, but depending on a specific part of the ‘framework’, categorize that part into one of the 3 options.  So, in the following part of my post I’ll address these 3 options as category 1, category 2 and category 3 respectively.

Category 1 code should be (just my first thoughts, some of these points may be hard to implement):

  • Ui paradigm independent.  Code in this category should not need to know whether the client project is an asp.net-, a winforms-, a wpf- or even a silverlight application.
  • I’m thinking mostly interfaces and abstract classes here… Extensibility is key.
  • Very generic code.
  • Probably a relatively small code base.

Category 2 code should be:

  • More concrete, but still reusable over different projects.
  • I’m thinking default implementations here (e.g. an ActiveDirectoryAuthentication component, an EventViewLogger, an ASP.Net BasePage, etc.)
  • If proven to be very stable (both in behaviour as in requirements) can possibly be moved to category 1.
  • And vice versa: if proven to be unstable (i.e. changes quite often), move to category 3.

Category 3 code should be:

  • Very specific for the client project.
  • Ideally some components start their life cycle in this category, but are moved/refactored to category 2 if their reuse becomes apparent by taking on specifications of new client projects.

Now, how to organize these categories in assemblies, source control, etc. is not part of this post.  I just wanted to share my theorethical view on this.  Turning this into something practical is the next step…

Create a free website or blog at WordPress.com.