XAML-Math, a LaTeX-style formula renderer for WPF and Avalonia
A collection of .NET libraries for rendering mathematical formulae using the LaTeX typesetting style, for the WPF and Avalonia XAML-based frameworks
At a glance
- What is it?
- XAML-Math is a .NET library that turns LaTeX-style source into typeset mathematics inside WPF and Avalonia applications, with a control you can drop into XAML and a parser API you can call from code. It descends from a Java library, which is where both its maturity and its licensing story come from.
- Who is it for?
- Adopt XAML-Math when your WPF or Avalonia product has to show real mathematics and you want the output to look typeset rather than like a plain string, and skip it when you only need a handful of symbols, when you need LaTeX features the parser does not implement, or when you are on a platform outside the two XAML frameworks it supports.
- Can I use it commercially?
- Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 9 days ago.
- What is it written in?
- Mainly C#, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on October 23, 2026, and from our analysis. They are not legal advice.
Editorial analysis
A formula is a control with a LaTeX string attached
The quickest way to use XAML-Math is to put a formula in a XAML file. For WPF the namespace points at WpfMath.Controls and the element is a FormulaControl; for Avalonia the namespace is AvaloniaMath.Controls and the element is a FormulaBlock. The content of the Formula attribute is LaTeX source, and the library parses and lays it out for you:
<!-- WPF -->
<Window … xmlns:controls="clr-namespace:WpfMath.Controls;assembly=WpfMath">
<controls:FormulaControl Formula="\left(x^2 + 2 \cdot x + 2\right) = 0" />
</Window>The Avalonia form is the same shape with a different namespace and element name:
<!-- Avalonia -->
<Window … xmlns:controls="clr-namespace:AvaloniaMath.Controls;assembly=AvaloniaMath">
<controls:FormulaBlock Formula="\left(x^2 + 2 \cdot x + 2\right) = 0" />
</Window>Because the formula is a string in a markup attribute, it can come from a resource, a view model property or a converter, and the project points at an example under src/WpfMath.Example that demonstrates data binding and what it calls advanced concepts.
Parsing to a formula object and rendering it to a PNG
Behind the control there is a parser API that you can use directly, and the documented example renders a formula to a PNG file. The parser is obtained from a singleton instance, the source string is parsed, and the result is handed to an extension method that returns the image bytes:
const string latex = @"\frac{2+2}{2}";
const string fileName = @"T:\Temp\formula.png";
try
{
var parser = WpfTeXFormulaParser.Instance;
var formula = parser.Parse(latex);
var pngBytes = formula.RenderToPng(20.0, 0.0, 0.0, "Arial");
File.WriteAllBytes(fileName, pngBytes);
}The three numbers after the formula are the font size and the horizontal and vertical offsets, and the last argument names the font family used for ordinary text. Parsing is where errors surface, and the documentation is explicit that a call to Parse may throw a TexException when it cannot make sense of the source, so error handling around a parse is not optional in a long-running application. That exception type lives in the XamlMath.Exceptions namespace, which is what allows a UI-independent part of the library to be referenced from code that never touches a window.
Reaching past PNG with a TeX environment and a bitmap encoder
When you need control over the output format rather than a PNG blob, the documentation points at the extension methods in the WpfTeXFormulaExtensions class. The difference in approach is that instead of passing a font size directly, you build a TeX environment with a style and a size, then render to a bitmap:
var parser = WpfTeXFormulaParser.Instance;
var formula = parser.Parse(latex);
var environment = WpfTeXEnvironment.Create(TexStyle.Display, 20.0, "Arial");
var bitmapSource = formula.RenderToBitmap(environment);
Console.WriteLine($"Image width: {bitmapSource.Width}");
Console.WriteLine($"Image height: {bitmapSource.Height}");The environment carries the rendering style, so TexStyle.Display is a different mode from the inline style used inside a running sentence. Once you have a bitmap source you can hand it to any WPF encoder, for instance a PngBitmapEncoder with a frame added and saved to a FileStream. The escape hatch for other output is documented too: you can supply your own IElementRenderer implementation to the RenderTo method if you need to support an alternate rendering engine, which is the seam a project would use to add a different back end without forking the parser.
Three NuGet packages with different target frameworks
Packaging is split three ways, and the split matters when you choose a package. WPF-Math and Avalonia-Math are the UI framework packages, and a part of the library that is independent of the UI frameworks is published separately as XAML-Math Shared Code. The framework targets differ between them. WPF-Math supports .NET Framework 4.6.2 or later and .NET 8 or later. Avalonia-Math supports .NET Framework 4.6.2 or later, .NET Standard 2.0 or later and .NET 8 or later. That is the practical catch: a library that targets .NET Standard 2.0 or later can be consumed by WPF on .NET Framework 4.6.2, but the WPF package itself does not list .NET Standard, so a shared-code consumer on .NET Standard has to reference the framework-independent package rather than the WPF one. The fonts ship as a resource in the package, and the README documents a separate procedure for preparing DefaultTexFont.xml from a font file when you want to use a different typeface.
Building the solution, running the tests, approving the results
Building requires the .NET SDK 8.0 or later, and the build and test script is short:
$ dotnet build XamlMath.All.sln --configuration Release
$ dotnet test XamlMath.All.slnThe test results are compared against existing approved output, which is the usual arrangement for a renderer whose correctness is judged by how the pixels look. When the results differ and the new output is correct, the documentation says to run the scripts/approve-all.ps1 script with PowerShell or PowerShell Core to approve them. Packaging uses the same solution file:
$ dotnet pack XamlMath.All.sln --configuration ReleaseThe repository root carries a Directory.Build.props and a Directory.Packages.props, which is the pattern for keeping shared compilation settings and package versions in one place across the solution, and a renovate.json that points at automated dependency updates. A NuGet.Config sits alongside them. The presence of an approval workflow tells you something about how the maintainers treat rendering output as part of the test contract.
A port of JMathTeX, and the licensing that follows from it
The history section is short and it explains the licence. The library was originally ported from the JMathTex project, copyright 2004-2007 Universiteit Gent. The port was first named WPF-TeX, was maintained by Alex Regueiro, was later available as WPF-Math on Launchpad, and was unmaintained from 2011 until 2017 when it was revived in its current form. In 2023, after Avalonia support was added, the project was renamed to XAML-Math. The licensing has two layers. The project code and resources are distributed under the MIT licence, and the fonts cmex10.ttf, cmmi10.ttf, cmr10.ttf, cmsy10.ttf and cmtt10.ttf are under the Knuth License. One more font, jlm_msam10.ttf, taken from the JLaTeXMath project, is under the Open Font License. Because JMathTeX itself is distributed under GNU GPL v2, XAML-Math as a derived work carries a permission from the JMathTeX authors to be redistributed under the MIT licence, and the project links a licensing history document with the details.
Where XAML-Math is the wrong tool
The obvious limit is platform. This is a XAML library for WPF and Avalonia, so a console application, a web front end or a mobile app gets nothing from it, and even within the .NET world a WinForms or GTK-based desktop tool would need the renderer API rather than the control, which means hand-rolling the presentation. The second limit is scope of the maths. The parser implements a subset of LaTeX, and the documentation itself points at separate pages for environments with \begin and \end, for matrices and matrix-like constructs, and for colour support, which is a way of saying the feature set has edges that you have to check. A formula with a construct the parser does not implement will not degrade gracefully, it will throw a TexException. The third is rendering quality on the host: there is a documentation page on improving blurred formulas, which is an admission that small text rendered this way can look soft depending on the display scale and the font you supply. The fourth is that the newest published release is v2.1.0 from 2023-07-15, so an Avalonia or .NET version introduced after that date is not covered by a tested package.
Editorial conclusion
Adopt XAML-Math when your WPF or Avalonia product has to show real mathematics and you want the output to look typeset rather than like a plain string, and skip it when you only need a handful of symbols, when you need LaTeX features the parser does not implement, or when you are on a platform outside the two XAML frameworks it supports. Check first that your target runtime is covered, since WPF-Math and Avalonia-Math list different framework and .NET Standard combinations, and read the colors, matrices and environments documents to see whether the constructs you need exist. The code is MIT licensed and the last push was on 2026-10-14, but the newest published release is still v2.1.0 from 2023-07-15, so you should pin the package version you test against.
Frequently asked questions
How do I render a formula in a XAML file with XAML-Math?
Add a namespace reference to WpfMath.Controls for WPF or AvaloniaMath.Controls for Avalonia, then set the Formula attribute to LaTeX source, for example \left(x^2 + 2 \cdot x + 2\right) = 0. The WPF element is FormulaControl and the Avalonia element is FormulaBlock.
Which .NET versions does XAML-Math support?
WPF-Math supports .NET Framework 4.6.2 or later and .NET 8 or later. Avalonia-Math supports .NET Framework 4.6.2 or later, .NET Standard 2.0 or later and .NET 8 or later.
What happens when XAML-Math cannot parse a formula?
The documentation states that XamlMath.TexFormulaParser::Parse may throw a XamlMath.Exceptions.TexException if it was unable to parse a formula, so the call should be wrapped in error handling.
Can I render a formula to an image outside of a XAML control?
Yes. The TexFormula API exposes extension methods such as RenderToPng, and WpfTeXFormulaExtensions gives more control through a TeX environment and RenderToBitmap. You can also pass your own IElementRenderer implementation to the RenderTo method for an alternate rendering engine.
What licence applies to XAML-Math and its fonts?
The project code and resources are under the MIT licence. The fonts cmex10.ttf, cmmi10.ttf, cmr10.ttf, cmsy10.ttf and cmtt10.ttf are under the Knuth License, and jlm_msam10.ttf is under the Open Font License.
Official sources
Add this badge to your README
If you maintain this project, the badge below links readers to this analysis and shows its maintenance status from the daily GitHub snapshot. Paste the markdown into your README; add ?metric=license or ?metric=stars to the image URL for a different field.
[](https://hysenlabs.com/projects/fornever-xaml-math)Was this useful?