Yep, I think Sam’s summary is spot on: if we want emails / print view to show rendered math, we need server-side math rendering (or at least server-side “pre-rendering”), because email clients won’t run MathJax.
A realistic approach would be:
- During cooking (or in a background job after cooking), find the math spans (inline + display).
- Render each expression to SVG (or MathML as a fallback) using MathJax in a Node environment.
- Replace the math in the cooked HTML used for email/print with either:
- inline
<svg ...>(best fidelity, no external fetch), or <img src="data:image/svg+xml;base64,...">(more compatible for some clients, but can get large).
- inline
- Cache by a stable key (e.g.
sha256(latex + display_mode + macros + font_config)), so we only render once per unique formula.
The tricky bits (but manageable if scoped carefully):
- DOM simulation: MathJax’s “browser” output wants a DOM; so we’d likely need
mathjax-full+jsdom(or use the pure adaptor route). - Performance / timeouts: do it async in a job queue, and degrade gracefully (leave LaTeX as-is if render fails).
- Email client quirks: some clients strip SVG; so having a fallback plan matters (e.g. plaintext/LaTeX, or MathML where supported).
If someone wants a quick spike, the first experiment I’d do is:
- A tiny Node script using
mathjax-fullto render$begin:math:text$E\=mc\^2$end:math:text$to SVG, - See what assumptions it makes (DOM vs adaptor),
- Then decide whether MiniRacer is a dead-end and we should treat this as “needs Node available” (or a small service).
If that spike works, then we can talk about where it plugs in (email pipeline vs cooking vs print view), and what we cache/store.