Category Archives: .net

Some Experiences in the Display of Mathematical Equations in WPF

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.




A beginner’s view – Textual DSL with OSLO

For just over a month I have been working on a project at work that lets users select inventory items from a database using a textual DSL. This is the first DSL I have ever produced! I thought that it was interesting that with no significant experience in building DSLs I was able to produce a useful application in a relatively short period of time. Below are the best resources I found and a few remarks:


Overview/Perspective: The Herding Code interview with Markus Völter (who you might know from Software Engineering Radio) is interesting – while not strictly focused on textual DSLs he gives a great overview/critique of Microsoft’s OSLO effort and interesting information on the Eclipse tools in this space (some recent news related to topics in the interview from Douglas Purdy and a short post by Markus). If you want to see some of the Eclipse tools he mentions the second link will take you to a nice presentation.

Useful MGrammar/OSLO focused podcast: This podcast features Shawn Wildermuth and has some great discussion around DSLs with a focus on OSLO:

Bits and samples: The Oslo Developer Center – official downloads and samples (I thought the MGrammar samples were good study material):

Focused start: This three part series by Shawn Wildermuth was incredibly valuable because the focus of the articles matched what I was trying to accomplish quite well:

Digging deeper: There is a good chance that you will need to dig into some of the details of MGraph and MGrammar – I found the following references useful:

Skeptical? The application I developed is currently being tested by a handful of users, so far these are the points I would make in support of the DSL:

  • Less dev time than you might guess: this is a small business app with a tight focus, it was coded by one dev working part-time on the app in about 4 weeks. There are always more features to implement, but the app is useful now with a fairly low investment.
  • Powerful/Flexible Searching: For advanced users the DSL exposes many more search fields/categories/options than I know how to expose via a reasonable list/wizard/combo box/text box style query build screen, and it is not nearly as tedious! The textual interface allows advanced users to be more efficient and creative and gives them access to more options than they had in the past.
  • Conventional UI feeds the DSL: I found the ‘conventional’ query build screen to be fast and pleasant to develop because it simply constructs the text to be parsed! This means that anything I build for the conventional interface needs to be supported by the DSL – this forces all features to remain ‘exposed’ in the textual interface for more advanced users.

Pain points:

  • I was surprised by the amount of work that I had to to to turn the AST produced by parsing the user’s input into usable objects/actions. There are some samples/posts/ideas out that can help build objects automatically – but this seems like an obvious area for Microsoft to enhance since we are talking about an all MS tool chain. I imagine that most scenarios are going to involve walking the tree to build/modify objects? Is there an approach or scenario that really does not do that?
  • The lack of a text editor component to put in your application in conjunction with your DSL is disappointing. There is an obvious need to deliver an editor for your DSL embedded in your app with syntax highlighting and keyword completion, if that is currently available I am not aware of it… While inputting text into a vanilla textbox may be a good test of the simplicity and logic of your DSL I doubt it is really the user experience you want. If a commercial product is an option then Actipro’s WPF SyntaxEditor might be interesting – they have MGrammar support which sounds encouraging, but I have not made time to test it out.

While the jury is still out if the application mentioned in this post will be successful I think that it was the right choice to build and try a DSL – hopefully if you are interested in trying out a textual DSL in .NET the links and information above will be interesting!


Edward Tufte in Phoenix

Last week I went to Phoenix with my friend AJ to see a presentation by Edward Tufte – if you have not seen Edward Tufte’s work it is without a doubt worth a trip to his website. The price of the course includes four of his books and about six hours of presentation.

I really enjoyed the presentation! I have read various topics on his web site (‘ask E.T. forum’) and read part of Envisioning Information – with that background the best part was getting a broader overview of his ideas (which – in retrospect – I really missed in my previous reading) and a good framework for understanding the examples in his books. I also appreciated that E.T. was careful to give a number of interesting suggestions about ways to bring his ideas into the ‘everyday’ working world – useful information that was very much appreciated. Highly recommended!