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

About these ads

19 Comments »

  1. - In Firefox (3.1 but 3.0 should do also, even 2.0 i think), i can open the SVG without any problems and print to XPS, thanks to Firefox’ built-in SVG capabilities. No need to use another program. must.. resist… saying… USE A REAL BROWSER… pfew, glad i could resist :)
    – Why does MS always has to come up with their own ‘standards’. SVG works, why not just support that in WPF/Silverlight :s ?
    – I found this page, http://weblogs.asp.net/jgalloway/archive/2007/06/05/silverlight-and-xaml-have-you-guys-met-old-man-svg.aspx, which seems to have code that can load an SVG on the fly in WPF. Also it links to a javascript converter for SVG to XAML.

    Comment by TeRanEX — March 18, 2009 @ 08:31

  2. Haven’t tested Firefox for this (used Chrome). And maybe you got me wrong: I was able to print to XPS, but the result was not usable in xaml although it looked OK in the XPS viewer (my guess is it rendered a bitmap version to print it out).

    No need to discuss the whole SVG vs XAML thing; XAML is a superset and contains way more functionality then SVG (google for it if you wish)

    I also came across that page you mention in my initial search. The javascript did not produce the correct result for the example SVG that I refer to in my post. I think the problem with all the ‘free’ SVG to XAML converters is that most of them are based on the same ‘engine’ (I think it originated from someone who wrote a SVG2XML.xsl); and that one is still not capable to convert hazard_E.svg to any usable xaml code.

    Comment by benpittoors — March 18, 2009 @ 09:44

  3. hmm so does this mean that, while chrome can show the SVG file correctly, it sends the output differently to XPS then Inkscape does? Then indeed i didn’t understand you correctly. Does Chrome also use a plugin to show SVG, no native support? (because you mentioned a plugin, i thought you used IE). FF has native SVG support, maybe it sends the SVG correctly to XPS?

    I didn’t mean to say xaml is a bad thing or something like that. i just think it is a bit sad MS didn’t add SVG support into it, as it is very similar, it can’t be that hard for them i guess.

    Comment by teranex — March 18, 2009 @ 09:59

  4. Yep, it sends the output differently to XPS.

    Must admit that I don’t know whether the SVG rendering is native in Chrome or that it is through a plugin :) Although it was my understanding that the whole Chrome architecture is based on plugins… (don’t shoot me if I’m wrong here)

    You can always try it using FF if you want (let me know in a comment what your findings are if you do so).

    Comment by benpittoors — March 18, 2009 @ 10:27

  5. I think depending on the image your mileage may vary.

    I have svg document, but when I printed it to XPS using Inkscape, the XAML used an ‘ImageBrush’ to render a png of the original image.

    However, when I used chrome to print to XPS, the XAML came out using ‘paths’ as desired.

    Comment by Andy — July 9, 2009 @ 04:37

  6. Thank you very much for this idea. It has helped me convert mathematical drawings from PDFs (produced with Metapost and pdflatex) to XAML, so that I can load that XAML code into my app (which is a shared whiteboard that I use for online math tutoring).
    However, there is a problem with fonts. I can avoid that problem by running the PDF through pdfcrop (a PDF cropping utility) first: that somehow forces Adobe Reader to write only paths to the XPS Document Writer so that the resulting XAML contains no Glyphs elements. However, if I do that the generated XAML code tends to get very large if there is plenty of text in the PDF. The route from Inkscape to XAML too may produce XAML with or without Glyphs. For example: if you first let Inkscape export the drawing as PDF and then have Adobe Reader write that PDF to the XPS Document Writer, I find that no Glyphs elements are generated: only paths. Whereas if I let Inkscape write directly to the XPS Document writer, I find that Glyphs are generated (if the drawing contains text).
    If I don’t use the trick to produce only paths, XPS Document Writer produces Glyphs elements that refer to obfuscated font files. If I then supply the original font files instead of the obfuscated ones when loading the XAML into my app, I get into trouble: the glyph indices are wrong! Even though it does not look like the glyph indices are deliberately obfuscated, they are definitely jumbled – and it is quite troublesome to figure out how, exactly, they have been jumbled – i.e. how to undo the jumbling. Do you know how and why those glyph indices are jumbled the way they are (by XPS Document Writer, I suppose)?

    Comment by Christian Stapfer — November 27, 2009 @ 13:11

  7. Don’t know what causes the ‘jumbling’. Have you tried converting the text to paths using Inkscape instead of using pdfcrop? Maybe that will produce better (smaller) results…

    Comment by benpittoors — November 27, 2009 @ 13:21

  8. Thank you for your reply!
    Just to make an example: In the XAML generated by the Xps Writer the Glyph for captial A is 37, whereas in the ttf file of that specific font it is actually 57. How come? I have to shift all the capital letters by an amount of 20 in this case. Small letters are a different story again. It’s quite confusing.
    As things stand at the moment, I have to come up with a mapping of Xps Writer generated glyph indices to ttf indices, for each and every font that gets embedded in the xps document (in an obfuscated form, that is): which is way too much boring busywork for my taste.
    Also: I do know how to force the generation of paths only, as I wrote. And that’s ok for relatively small drawings, small in the sense of not containing much TEXT, if any. However, if there are just a few lines of text, the generation of paths gives clearly much larger XAML files. I have examples (of math exercise statements with accompanying diagrams and example solutions) where the difference between “paths only” and “glyphs, not paths” for text gives me about a factor 10 larger files in the case of “paths only”. And they get larger very quickly with my adding text.

    Comment by Christian Stapfer — November 28, 2009 @ 15:00

  9. Come to think of it, I should have answered your question: “Have you tried converting the text to paths using Inkscape instead of using pdfcrop? Maybe that will produce better (smaller) results…”
    I am coming from PDFs since I am using tools of the LaTeX family to produce my graphics and math typesetting (pdflatex, Metapost, TikZ). So I am lacking a good converter from PDF to SVG (do you happen to know one, I mean something other than Adobe Illustrator?). Also: I have tried to let Inkscape print an SVG drawing that includes text on the Xps Document Writer, but the result was pretty ugly: there were Glyphs and ImageBrushes in the XAML that was generated that way. Ugh! If I want “paths only” XAML, it is much better to save an SVG drawing from Inksape as PDF and then have Adobe Reader print that PDF on the Xps Document Writer. Or, since I am really coming from PDFs: see to it that somehow Adobe Reader does not send the fonts of that PDF to Xps Document Writer but only paths (pdfcrop, a tool of the LaTeX family, does that).
    Regards,
    Christian

    Comment by Christian Stapfer — November 28, 2009 @ 16:41

  10. Why don’t you try my converter here:

    http://www.graphspe.com/Svg2Xaml.aspx

    or here (if you have Silverlight):

    http://www.graphspe.com/Main.aspx#/Solution/svg-to-xaml-converter

    Regards,
    Ceyhun

    Comment by Ceyhun Ciper — January 2, 2010 @ 14:55

  11. Hi Ceyhun,
    thank you for your tip! – Actually, I have already seen your site and, of course, tried your SVG to XAML converter.
    However, my first test with an SVG that I got from a Computer Algebra System (a simple graph of y=x^2) did not show any text (axis labels: the graph itself and the axis and coordinate grid lines are ok). Because of this I concluded that this SVG to XAML conversion was still a bit problematic. Your reply to this thread prompted me to have a second look (with the same SVG file). The text labels still don’t show, but when examining the XAML I don’t see any obvious problem. The text labels seem to be there, but are not displayed by my whiteboard (which is based on Microsoft’s InkCanvas component). The XAML gets essentially added as an (indirect) child of that InkCanvas.
    This brings me to a second problem with the XAML that I got from your SVG to XAML conversion with this exact same SVG file: the size of the canvas was wrong, I think by a factor of about 1.3333 (seen that factor before?)
    Also: My main source of vector graphics are not SVG but PDF files. To be more precise: PDF files generated by tools of the TeX family of tools. Since my conversion path from PDF to XAML for such files works reasonably well (although it still includes one single, very simple manual step), I have not taken the time to figured out the exact reasons why the XAML generated by your conversion does not display correctly in my InkCanvas. (Also: I’m not such an expert on XAML; I am just trying to muddle through to get XAML graphics from PDFs that work in my shared whiteboard…)
    Regards,
    Christian

    Comment by Christian Stapfer — January 2, 2010 @ 19:56

  12. Hi,

    I found a way to convert your file to xaml without having to use the Microsoft XPS Document Writer. I exported your file to a png. Then I opened it using Inkscape, when I opened it I chose the embed option. Then, I selected the image. Then choose the Path –> Trace Bitmap menu to vectorize your image. Select color in the Inkscape’s Trace Bitmap dialog box. Click Ok.
    clicking the OK button on Inkscape’s Trace Bitmap dialog box, Potrace is invoked and a vector image is created on top of the bitmap background. You can now remove the original bitmap image, for example, using the Edit –> Invert Selection menu (since the vector image would be selected after creation) followed by Edit –> Cut. Then save the vector image, for example as a XAML file, from the File –> Save As menu, enter a new filename and select XAML for the file type.

    I opened the xaml file and I could see the image rendered correctly. If you’re interested in more, check out this link, I found it useful: http://blog.tiaan.com/link/2009/02/21/vectorize-bitmaps-to-xaml-using-potrace-inkscape

    I hope this helps.
    Sou

    Comment by Sou — October 28, 2010 @ 21:16

  13. This is strange: I have repeatedly tried to have InkScape produce valid XAML (i.e. XAML that can be loaded by a .NET 3.0 application as Canvas) but every time it failed. I get various error messages when my application tries to load it.
    Fortunately, this is no longer much of a problem for me because I have now written a PDF to XAML converter (based on PDFRenderer) that works great for me (for a short description of it, see my blog http://www.mathcoach.ch/blog
    Since InkScape can also generate PDFs (through export via Cairo), I can convert the same formats to XAML (however: this time it is XAML that my application can load).
    One downside of using bitmap tracing to get a vector drawing is that the resulting XAML can get very large. This is especially a problem for my particular application, which is a shared whiteboard that I use for online math-tutoring: I have PDFs, generated by TeX and friends, that may contain large amounts of text and formulas. Already bitmap tracing would be a problem, because it would not produce very sharp text and formulas, but the worst problem that the XAML resulting from one A4 page can easily be several megabytes that my shared whiteboard would have to transmit over the internet….
    Now, with my own PDF to XAML converter, I can convert PDFs that I produce with LaTeX (containing text, formulas, and drawings) to valid and rather compact XAML on the commandline.

    Comment by Christian Stapfer — October 29, 2010 @ 05:09

  14. I’m not sure if the xps printer mechanism has changed since you posted this, but I am trying this and it seems to be converting the svg to a png and then using the png as the ImageBrush source (not actually converting the svg to xaml):

    Comment by Greg Sansom — February 12, 2011 @ 01:57

  15. Did you use Inkscape to print the SVG to the XPS printer? It’s not the XPS mechanism that chooses the output type. If you send it vector data it will convert it into xaml, if you send it bitmap data it will convert it the way you describe. (at least it did at the time of writing this blog post)

    Also, try to convert every object in the SVG to path data (no fonts, no embedded bitmaps, no nothing… just plain path data)

    Comment by benpittoors — February 12, 2011 @ 09:00

  16. Sure did, and I just tried it again with the same results. Closer inspection shows that the SVG file contains an embedded bitmap – this will be the cause.

    Thanks for the article :)

    Comment by Greg Sansom — February 12, 2011 @ 09:43

  17. [...] Convert SVG to XAML via InkScape: http://benpittoors.wordpress.com/2009/03/17/convert-svg-to-xaml/ [...]

    Pingback by Win8 (Metro style) app development – getting started « RaSor's Tech Blog — September 22, 2012 @ 17:20

  18. [...] via InkScape and XPS writer: http://benpittoors.wordpress.com/2009/03/17/convert-svg-to-xaml/ and [...]

    Pingback by List of Utilities | RaSor's Tech Blog — May 4, 2013 @ 22:53

  19. Hi.. I tried converting an svg file to xaml using this technique. Though I got the xaml but the xaml has references to some relative resource. I don’t want to use any other resource file with the xaml. the xaml itself should be able to render the image. I have pasted these paths here. is there a way I can avoid this? Basically I will use this xaml to load at runtime to show images in an wpf application.

    Comment by singh — June 20, 2014 @ 17:14


RSS feed for comments on this post. TrackBack URI

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

The Shocking Blue Green Theme. Blog at WordPress.com.

Follow

Get every new post delivered to your Inbox.

%d bloggers like this: