cmiles – blog

I recently needed to display ‘notes’ in a WPF application – the interesting detail was that the notes contained both text and mathematical equations. I did not find a tremendous amount of information about presenting mathematical equations in WPF – so I thought I would share my experiences.

The notes for the application were delivered by the client as a Microsoft Word document.

Because I do not have any experience with Adobe Illustrator or any of the Expression products none of the solutions I investigated involves those products.

jsMath – My first idea was to display the notes in a browser control with the hope of reusing them on the web. I quickly found jsMath which generates equations from TeX input (if formulas in TeX are not a familiar idea see Help:Displaying a Formula). Setup was quick and my test page looked nice in Firefox. However, the rendering in the WPF Browser control was unacceptable. It is completely possible that I did not have something configured correctly and/or that there were settings I needed to change, but I decided to move on…

MathML – As an alternative to having jsMath handle the equations I briefly looked into using MathML. Unfortunately this page failed to open correctly on my machine in IE8, Chrome, Safari and Opera. That was enough to steer me away from MathML. The page opened without problems in Firefox 3.5…

WPF Chromium WebBrowser control – I was not quite ready to give up on the idea of presenting the notes in a browser control with jsMath and thought the rendering in this control might be better. I did not get very far with this and did not try the control in my project – not because of problems with the control, but because the Awesomium project that this control uses is going closed source. I was unsure about the future of the WPF Chromium WebBrowser control without updated versions of Awesomium so I moved on to my next idea.

DocumentViewer -  I already had nicely formatted text and equations in the original Word document and thought that I might be able to leverage that. The WPF DocumentViewer control can display XPS documents – and Word documents can be saved as XPS. I saved the first note from the Word document as a .XPS file and – after figuring out that System.Windows.Xps.Packaging is in ReachFramework.dll – quickly put together a test. The file displayed quickly and easily (including equations) and for some applications this could be a great option!  However, I felt the DocumentViewer was too page and print focused for this application. I do not think – at least in it’s default configuration – that the DocumentViewer is a very good solution for displaying shorter items for easy on-screen reading (esp. in a smaller screen area). I am sure I could have tweaked options to improve the DocumentViewer for use in this application, but this seemed like the wrong approach.

Word/XPS converted to FlowDocument – I thought these articles were interesting, but was skeptical about the time/results, and did not try this approach – Converting FixedDocument (XPSDocument too) to FlowDocument and WordML to FlowDocument – how to convert docx files to WPF FlowDocument. I would be really curious to hear from anyone how the conversion of Word equations works with the ideas/code presented in these articles.

Flow Document  + Images – Images seem like an obvious/traditional choice for presenting the equations and the FlowDocument seemed like an interesting choice for presenting text and images for on-screen reading. One easy way to produce the images is Roger’s Online Equation Editor which transforms LaTeX equations into images. It is easy to work with images in WPF – but the problem I had was getting the images to look as sharp as the text in the FlowDocument when they were resized. If this was a document for printing, or had specific static layout requirements, I think that the images would have worked great. But as the images were resized (either because of dynamic layout changes or changes to the applications design) I was not able to keep them as sharp as the surrounding text. If I had more graphics expertise I may have been able to find a better image type/resolution/rescaling combination.

FlowDocument + Shapes – a good friend suggested that I look for ways to represent the equations as SVG. What I eventually found was Inkscape + textext. textext works as an add-in to Inkscape that allows you to render LaTeX. The install and troubleshooting steps near the bottom of the textext page are critical in finding the dependencies (MikTex, Pstoedit, Ghostscript) and dealing with errors (I had to add a directory to my path to get textext working). Once it is up and running textext worked great – it is very easy to create an equation and save it as an SVG file. The next problem is moving the equation from SVG into XAML.

SVG to XAML Canvas – All of the methods below can be used to convert an SVG file  into shapes in a XAML Canvas object. In the case of the equations I was producing all of the solutions below generally produced usable output. The Canvas output could be inserted directly into your application – or it could be placed in a resource file by stripping out the Name elements and adding a Key. In addition to using the Canvas directly it could also be used as a VisualBrush.

Xsl – I was able to use the xsl on this page to get canvas based output (and do a some xsl debugging in Visual Studio – a great feature and the first time I have used it).

Inkscape – Inkscape has save as XAML built-in. In the past, for simple images, this worked great for me. For the equations that I was producing in this project the canvas that Inkscape produced apparently lacked a RenderTransform that was crucial to correct display. The problem was fairly easy to fix, but mainly because I had the output from XamlTune as a comparison.

XamlTune – The command line executable in this project worked great – and could potentially be integrated into a build script which is a nice bonus. I had trouble with the gui portion of this project crashing.

The Canvas with shapes output is ok – but I want to reuse the same equation multiple times, use the same equations both as larger stand-alone figures and inline with the text and rescale the larger images as the application’s size changes. I assume that I could get the canvas based resources working for all of those requirements (although I not sure exactly how and imagine a bit of awkward code…). However, I know that having the equations as DrawingImages in a resource file would allow me to use the equations inside an Image tag, solving the problems above.

FlowDocument + DrawingImage – The only programs I found that produced DrawingImage output from SVG input were ViewerSvg Professional or Ab2d.ReaderSvg Professional (the ‘Basic’ versions are not listed as having ‘Export as Geometry’ support) from WPF Graphics (demo downloads available – note these will also convert from SVG to a Canvas). This software did nice conversions from SVG to DrawingImage with a good array of options. The Ab2d.ReaderSvg class library also includes a sample application that allows you to combine multiple SVGs into DrawingImages inside a ResourceDictionary, which is almost exactly what I wanted to do! For some situations these applications will not be appropriate since they are commercially licensed software with a cost of $169/$399.

Conclusion: The options above present several viable solutions for presenting mathematical equations in a WPF application. Every project will have different requirements that will dictate the best solution. With that said – in my opinion -  the combination of Inkscape and textext to create equations in SVG and Ab2d.ReaderSvg Professional to convert the SVG into DrawingImage resources is the best combination currently available for presenting mathematical  equations for on-screen reading in a WPF application.

Enjoy!

CM

Filed under: .net, equations, LaTeX, SVG, WPF, XAML