From TeX to Angular: Rendering Mathematical Formulas with MathJax

Mathematical formulas are one of those things that look simple until you try to present them properly in a web application.

For simple expressions, plain text may be sufficient. Once fractions, exponents, sums, matrices or more complex models appear, readability deteriorates quickly.

A formula could be exported as PNG or SVG, but from the perspective of a content platform that is not particularly elegant. A formula is structured content, not merely an image.

Interestingly, a better solution takes us back to technology whose roots are almost fifty years old: TeX.

TeX: A Problem from the 1970s

Donald Knuth began developing TeX in 1977. One motivation was his dissatisfaction with the quality of computer typesetting for his books, particularly mathematical material.

The goal was a system capable of producing high-quality scientific and mathematical typesetting.

From a modern software-engineering perspective, the underlying idea remains remarkably familiar: separate the description of the content from its final presentation.

From TeX to LaTeX

TeX is extremely powerful, but it operates at a relatively low level. Leslie Lamport developed LaTeX on top of TeX during the 1980s, providing a higher-level document preparation system.

Authors can focus more on document structure and meaning instead of controlling every typographic detail.

For software engineers, this is a familiar concept: abstraction and separation of concerns.

My First Encounter with TeX and LaTeX

I first encountered TeX and LaTeX at university many years ago. At the time, I associated them mainly with academic publishing, mathematics, physics, engineering and computer science.

Some university departments also had very specific expectations about how technical documents should be prepared.

I certainly did not expect to encounter the same family of ideas decades later while building a modern web platform with Angular, server-side rendering and a headless CMS.

The Concrete Problem: Formulas in Financial Research

RedneckWorks combines software-engineering content with quantitative financial research. That naturally introduces mathematical notation.

For example, compound annual growth rate:

An inflation-adjusted value:

Or drawdown:

with the running high:

and maximum drawdown:

As plain text these expressions quickly become difficult to read.

Contentful Remains Responsible for Content

The articles are managed in Contentful. I do not want the CMS to know how a mathematical expression will ultimately be displayed.

Instead, the application uses a simple convention: mathematical source is enclosed in dedicated math markers. The exact marker syntax is shown in the code example below.

[math]
\mathrm{CAGR} =
\left(\frac{V_T}{V_0}\right)^{\frac{1}{T}} - 1
[/math]

The markers are an application convention, not part of TeX or MathJax. They simply tell the application that this part of the content contains mathematical notation.

Contentful stores the content. The frontend identifies mathematical notation. MathJax performs the typesetting.

MathJax Brings TeX-Style Mathematics to the Web

MathJax is a JavaScript display engine for mathematical notation in web browsers. Its TeX input processor understands TeX-style mathematical syntax and converts it into a representation that MathJax can render for the browser.

An important distinction is that MathJax is not a complete LaTeX document processor. It supports the TeX/LaTeX commands and extensions relevant to mathematical typesetting.

The source expression therefore remains text while the browser presents properly typeset mathematics.

This is especially useful for a content-driven system because the mathematical source can remain editable, searchable and reusable.

Why Not Generate PNG or SVG Files?

Server-side rendering of every formula into PNG or SVG is technically possible.

But then the formula becomes an asset. Changing a variable requires regenerating the asset, the CMS has to manage additional files, and the mathematical source becomes less convenient for automated processing.

For a platform where content may later be translated, analyzed or reused for automated video production, retaining the source notation as text is much more flexible.

Angular Makes the Problem More Interesting

With a static HTML document, MathJax integration can be relatively straightforward.

Angular introduces an application lifecycle. Structured content is received, components are created and the DOM changes over time.

This creates an important question: when should MathJax typeset the mathematics?

If MathJax runs before Angular has inserted the relevant content, there is nothing to process. If Angular changes the content later, typesetting may need to run again.

Server-Side Rendering Makes Timing Even More Important

RedneckWorks also uses Angular server-side rendering.

The initial HTML is generated on the server and subsequently hydrated in the browser. Libraries that manipulate the DOM therefore need to be coordinated carefully with Angular's rendering and hydration lifecycle.

The important architectural rule is simple: we need to know not only what should be typeset, but also when it is safe and useful to do so.

A Possible Angular Architecture

I prefer not to put MathJax-specific responsibilities directly into the article component.

A dedicated service gives the integration a clear boundary.

@Injectable({ providedIn: 'root' })
export class MathJaxService {
  async typeset(element: HTMLElement): Promise<void> {
    // Initialize or reuse MathJax and typeset only this element.
  }
}

After client rendering, the relevant article region can then be processed explicitly.

afterNextRender(() => {
  if (this.containsMath()) {
    void this.mathJaxService.typeset(
      this.articleContent().nativeElement
    );
  }
});

This is deliberately an architectural example rather than a claim that there is only one correct MathJax integration. The final implementation should match the MathJax version and the actual Angular component lifecycle.

Do Not Typeset the Entire Application Repeatedly

Performance matters as well.

If an article contains no mathematics, there is no reason to invoke mathematical typesetting for it. And if only one region contains formulas, processing can be scoped to that region.

A simplified detection step might look like this:

const containsMath =
  content.includes('[math]') &&
  content.includes('[/math]');

Production parsing should be more robust, but the principle remains useful: no mathematical content means no MathJax processing.

Security: CMS Content Is Not Automatically Trusted

Content coming from a CMS should not automatically be treated as unrestricted trusted HTML.

MathJax solves mathematical typesetting. It does not replace Angular's security model.

Rich text, mathematical expressions, permitted structural elements and genuinely trusted HTML should remain distinct concerns. A MathJax integration should not become a reason to bypass sanitization for an entire article.

Content and Presentation Stay Separate

This brings us back to the idea that made TeX so interesting in the first place.

The expression

describes mathematical content.

Font size, responsive layout, browser rendering and visual integration are presentation concerns.

That separation is clean, reusable and surprisingly well suited to a modern content architecture.

From Contentful to Angular and the Browser

Conceptually, the complete path is:

Contentful → Spring Boot API → Angular SSR → MathJax → Browser

Each component has a clearly defined responsibility. Contentful manages content. The backend delivers structured data. Angular controls application rendering. MathJax handles mathematical typesetting. The browser presents the result.

An Almost 50-Year-Old Idea in a Modern Architecture

TeX originated in the late 1970s. LaTeX followed in the 1980s.

The modern web did not exist. Neither did TypeScript, Angular, headless CMS platforms, hydration or today's JavaScript SSR architectures.

Yet the basic idea remains highly useful: describe the meaning and structure of the content and let a specialized system handle its presentation.

Technologies change. Good abstractions can survive for a remarkably long time.

Conclusion

The original requirement was small: a financial research article needed properly rendered mathematical formulas.

That requirement created a connection across several generations of software technology:

TeX → LaTeX → MathJax → Contentful → Angular → SSR

It is also a good example of why real software projects are often more interesting than isolated tutorial examples. A seemingly small domain requirement can expose questions about content modeling, rendering lifecycles, SSR, hydration, security, performance and architecture.

Sometimes the solution to a modern problem leads back to an idea from the 1970s.

A Question for Today's Students

I first encountered TeX and LaTeX at university many years ago.

What does it look like today?

Are there still professors or university departments that require seminar papers, theses or other technical documents to be prepared using TeX or LaTeX?

Let me know in the comments.