The Development of Radical Pie
Eric Lengyel • November 1, 2025
Between the late summer of 2024 and now, I have spent almost all of my time developing a professional GUI-based equation editor called Radical Pie. Making an equation editor is something I’ve wanted to do for a long time, and on October 28, 2025, the finished product shipped with all of the features I had ever dreamt of including. This blog post talks about why I made Radical Pie, how I made it, and what lies ahead.
Motivation
As a math major at Virginia Tech way back in the early 1990s, I became acquainted with LaTeX, and among other things, I used it to write my master’s thesis. I still use LaTeX today on my various wikis (for example, PGA) and in this blog itself to display equations on the web. LaTeX is powerful and produces nice output, but it is essentially an extremely complex markdown language developed for the computers that existed in the 1980s. For those who may not be familiar with TeX, the way it works is that you write code for your technical document by using a large set of control sequences and braced subexpressions to typeset your mathematical equations. You don’t see the results until you run the code through a compiler of sorts, and that’s when you find out that you made a syntax error or that some equation doesn’t look the way you had intended. Using TeX is a tedious cycle of fixing errors, tweaking layout, hunting for a package containing some symbol you want to use, and recompiling over, and over, and over. There are applications that wrap all of this in a GUI these days, but it’s still using a LaTeX compiler under the hood, and serious problems often arise during any real work.
Somewhere around the year 2000, I began using MathType. MathType was the souped-up professional version of the equation editor that shipped with Microsoft Word at the time. It could do everything I needed inside a graphical user interface, it produced instant results, and it didn’t rely on a LaTeX compiler to perform equation layout. MathType integrated with Word through OLE, so the equations remained live and weren’t just little pictures pasted into the text. I became so adept at using Word and MathType to produce professional results that all of my books beginning with the second edition of Mathematics for 3D Game Programming & Computer Graphics in 2003 up through Projective Geometric Algebra Illuminated in 2024 were not only written that way, but the books were actually printed directly from the output generated by Microsoft Word. The results were good enough that I sometimes took jobs as a professional typesetter to lay out other books such as Algorithms and Data Structures and GPU Zen 2, among others. MathType worked great, and I found that I was considerably more productive by using Word and MathType together than I could ever be if I were using LaTeX.
Around 2010 or so, it seems that MathType lost its momentum and was no longer in active development. It still worked, but over the next decade, it became increasingly difficult for me to use. To do things I wanted to do, I had to come up with a growing list of hacks. MathType could only handle Unicode in the basic multilingual plane (BMP), so I couldn’t access symbols outside that range. Instead, I ended up cobbling together a special font that contained all those symbols at different codepoints inside the BMP. MathType didn’t have good support for boxing equations, and that’s something I used a lot in FGED1, FGED2, and PGA Illuminated. I ended up adding the boxes inside Word, but I had to make a special style to adjust the vertical position of equation numbers to compensate for the shift in the baseline. Also, there’s a bug that causes the box color to change if the equation is edited. MathType doesn’t separate the font size from the rest of the typesetting preferences, and it doesn’t know what the font size in Word is where a new equation is inserted. This meant that I had to have two sets of preferences ready to go, and each equation appearing in a 10pt caption had to be manually changed from the 11pt main text size it would get by default. Finally, if I wanted to add highlights, lines, or annotations to an equation, there was no way to do it in MathType. I had to copy and paste the equation into Adobe Illustrator, manually draw these items, save as an SVG, and then import into Word. This causes another problem because Word thinks all SVGs are 96 DPI, but Illustrator uses 72 DPI, so I had to manually scale by 133%. And at this point, the highlighted equation is just a picture, so I can’t make any edits without going through the whole process again.
I needed an equation editor that was the spiritual successor to MathType, fixed all of the above problems, produced even higher-quality output, and provided a powerful set of drawing and annotation tools. It didn’t exist. The only way I’d get it is to write it myself. Fortunately, this kind of software application is right up my alley. My background has deep mathematical roots, I possess all the necessary expertise in software engineering, and I had just spent the last several years working in a closely related field, font rendering. There was only one unknown. This software needed to work with OLE in order to embed live equations in Microsoft Word, but I had no experience with that, and I didn’t know if it would be feasible to embed equations and get the baseline properly aligned with the surrounding text. So on September 4, 2024, I started working on a prototype to find out.
Development Process
The usual reaction I get when I mention OLE is something like “Hey, the nineties called, and they want their technology back! Haha.” The reality is that Microsoft Office and many parts of the Windows operating system are still heavily based on COM, and the best way to embed an editable object in a Word document is still to use OLE. The first step was to get this working in my own application, so I dove into the OLE documentation and started building my own COM class.
I was going to need an OLE server for experimentation and testing, so I created a basic Win32 application from scratch that just displays a window and receives input events. I added a D3D12 swap chain and graphics context to render the contents of the window because I had already planned to use the Slug Library to draw everything in the equation editor’s viewport. (I later decided that D3D12 was overkill for this kind of application and replaced it with D3D11.) Slug was also going to be essential for reading font files and giving me the Bézier curves I needed for font-free output. At this point in time, I was considering using Win32 for dialog boxes, but that turned out to be nonviable, and I ended up using Slug to draw everything in the user interface as well. Months later, I created a set of UI widgets with code based on the widgets I had designed for the C4 Engine many years ago. Now, every dialog box in Radical Pie has its own swap chain into which everything is rendered by Slug.
Once I figured out how to properly register an OLE server in the system, the first tests involved getting the Bézier curves for a few letters from Slug and writing them to the EMF format so they could be passed to Word through the OLE channels. This took many long hours of debugging and writing lots of information to log files that would show me how all the COM interfaces were being utilized (because the documentation doesn’t suffice). Along the way, I learned that I could access a huge amount of functionality in Word directly from my C++ application by using its COM interfaces. This was important for getting the font size of the text surrounding an equation and adjusting the baseline shift of an equation so its vertical alignment is correct. By the end of September, I had it sorted out enough that I knew Radical Pie would work, but I had important speaking engagements coming up in October and November, so I had to hit the pause button.
With the question of OLE viability answered, the serious work on a production-quality application began in the middle of November. All of my
work uses a restricted subset of C++, and I never use the standard library. My background in cross-platform game engine development taught me
that external dependencies can lead to very costly problems that can show up at the most inopportune times. Instead, Radical Pie incorporates the
extensively battle-tested Terathon Container Library and
Terathon Math Library, both of which have served me well for over two decades.
(These are freely available on GitHub.) These take care of all the generic data structures that I would need to organize the data making up a
complex equation, including any drawing objects attached to its components. A mathematical expression naturally possesses a tree structure, making
the Tree container a perfect fit. Drawing objects can be attached to multiple anchor points anywhere inside an equation, an annotation,
and/or other drawing objects, and this means they collectively form a directed acyclic graph (DAG) structure. The container library also has a
Graph class that provides everything I need to make that work. An “equation” in Radical Pie would be a collection of nodes
that each simultaneously belong to both a tree structure and a DAG structure.
There would need to be a method for serializing and deserializing an equation, and this would be used not only for saving to a native format but also for storing snapshots of an equation’s state in the undo-redo buffer. I wanted to serialize to a text format so native equation data could be directly embedded in other text formats like SVG without going through a base64 encoding or something similar. Once again, my past work provided the perfect solution. In 2013, I developed the Open Data Description Language (OpenDDL) syntax as part of the Open Game Engine Exchange (OpenGEX) format, and it was something that I also used as the basis for an intermediate vector graphics format in the Slug tools. OpenDDL was a good choice because its hierarchical organization matches the tree structure of an equation, and its referencing mechanism provides a fitting means for capturing the DAG structure of the drawing objects and annotations. It also makes validation easy by enforcing strict syntax at a low level and by enforcing data relationships at a higher level.
Over the approximately 11 months between November 2024 and September 2025, except for a few weeks when I got distracted by the urge to work out the transwedge product, I implemented all of the guts of Radical Pie. I went back and forth between implementing mathematical structures like fractions and radicals and implementing user input like keyboard navigation and mouse selection. The tools at the top of the editor window, the color buttons, and all the symbol palettes came a little later. After all the mathematical structures had been finished, I added anchors and started working on the drawing tools. The final pieces of the product to be implemented were the design dialogs that let the user customize the 335 parameters that determine how Radical Pie lays everything out. Throughout the development process, I also created a special mathematical font. It started as a minor fix for a few missing or broken glyphs in other fonts but ultimately ballooned to over 750 mathematical symbols designed to have a consistent style.
In April 2025, after most of the mathematical structures had been implemented, I began testing Radical Pie in some real-world scenarios. I converted my old master’s thesis to a Word document and used Radical Pie to remake every single equation. This was an extremely informative exercise that exposed a few usability issues and led to a large number of adjustments to the spacing rules. Later, after Radical Pie had been developed further, I converted over 5500 equations in FGED1 and FGED2 to Radical Pie. Many of these equations were boxed, and I was able to handle that inside Radical Pie now, so it was possible to remove the hack that I had previously been using inside Word. Some of these equations contained lines or annotations that I originally added in Illustrator, so they were just static pictures inside Word, but now I could remake them as live, editable equations.
When Radical Pie was completed, I had written just over 98,000 lines of new C++ code spread across 36 source files. This doesn’t count the code belonging to Slug, OpenDDL, or the Terathon libraries. If I didn’t already have those technologies to build upon, especially Slug, then I think it would have taken at least two extra years at the beginning to lay the necessary foundation. It probably would have been difficult to maintain enthusiasm for the product over that time without being able to show much in the way of equation editing functionality. Having those technologies finished and available right from the get-go provided a huge boost.
The Future
I am about to release new versions of FGED1, FGED2, and PGA Illuminated that have been remastered with Radical Pie, and I am currently using Radical Pie to write FGED3 and FGED4. Each of these books exists as a single Word file containing thousands of embedded Radical Pie equation objects, and what you see in the final printed books is exactly what gets written to a PDF by the Acrobat add-on. I have found Word to be surprisingly capable once you turn off all the “smart” features, but there are still a few annoyances here and there. Sometime in the future, I would really like to build an entire word processor for editing large technical documents, which would of course have native support for Radical Pie equations. But that project is going to have to get in line behind FGED3 and FGED4 as well as the game I’ve been working on for half of my life, The 31st.
In January 2026, I will be demonstrating Radical Pie to the mathematics community as an exhibitor at the Joint Mathematics Meetings in Washington, D.C. I’ll be at booth #505.