THE SUMMATION PROBLEM
Traditional mathematical typography treats ∑ like a diva.
One character. One symbol. Yet it demands an entire production:
- A complete typesetting system (TeX)
- A macro language to describe it
- A box model for layout
- Specialized font tables (OpenType MATH)
- Vertical centering algorithms
- Glyph scaling and stretching
- Display mode vs text mode switching
- Baseline adjustment calculations
Thousands of engineers. Millions of lines of code. Decades of development. All to make one character stretch correctly.
THE HISTORY
The giant stretchy ∑ is not ancient wisdom. It's a 19th-20th century affectation.
Early printed mathematics — Euler, Newton, Leibniz — used modest-sized operators. Whatever the printer had in the type case. Their work looks closer to monospace than to LaTeX.
Printers made summation symbols bigger because they could, not because it was clearer. Textbooks copied textbooks. TeX codified the convention. Everyone assumed it was the only way.
It wasn't. It isn't.
THE ABSURDITY
Consider what happens when you want to render:
The sum of k from 1 to n equals n(n+1)/2
In traditional typography, you invoke machinery:
- Parse the expression
- Determine display mode
- Calculate the height of limits
- Scale the sigma glyph
- Center vertically on the math axis
- Adjust surrounding spacing
- Handle line breaking edge cases
In monospace:
𝑛
∑ 𝑘 = 𝑛(𝑛+1)/2
𝑘=1
That's it. Unicode characters on a grid. The upper limit goes on the line above. The lower limit goes on the line below. The sigma stays the same size it always was.
No rendering engine. No compilation. No external dependencies. Just text.
THE UNICODE POSITION
Unicode handles stretchy delimiters and summation differently. This is intentional.
For braces, brackets, and parentheses, Unicode provides modular parts:
⎧ ⎫ (brace top)
⎨ ⎬ (brace middle)
⎩ ⎭ (brace bottom)
These are designed to stack. A piecewise function in monospace:
⎧ −1 if 𝑥 < 0
sign(𝑥) = ⎨ 0 if 𝑥 = 0
⎩ 1 if 𝑥 > 0
The brace stretches by adding parts. Unicode anticipated this. The parts exist because they're meant to be composed.
But for summation, Unicode took a different position. In Technical Report #25 (Unicode and Mathematics), discussing summation parts (U+23B2 ⎲ and U+23B3 ⎳), they wrote:
"These brace and operator pieces are compatibility characters. They should not be used in stored mathematical text, but are often used in the data stream created by display and print drivers."
Translation: Don't store stretched sigmas. Use ∑. Let it be one character. If rendering wants to stretch it, that's the renderer's business — not the document's.
Braces stretch because content varies. A piecewise function might have two cases or twelve. The delimiter must accommodate.
Summation doesn't need to stretch. The limits go above and below. The sigma stays one size. There is no variable content inside the operator itself.
The diva behavior — scaling sigma to match some notion of "display mode" — is not a Unicode requirement. It's a LaTeX habit.
THE REAL QUESTION
Why does summation need to scale when delimiters can simply stack?
Braces and brackets have a legitimate need to vary in height. Content varies. Unicode solved this with composable parts. Stack ⎧ ⎨ ⎩ and the brace fits any height.
Summation has no such need. The sigma is an operator with limits. The limits go above and below on their own lines. The sigma itself contains nothing. There is nothing to embrace.
Yet traditional typography scales the sigma anyway. Display mode: big sigma. Text mode: small sigma. The infrastructure to manage this switching, this scaling, this vertical centering — that's the diva machinery.
Every generation rebuilt it. TeX. MathML. MathJax. KaTeX. ReX. Each one solving the same non-problem.
THE ALTERNATIVE
∑ in LaTeX: "I need TeX, Computer Ancient, display mode, and vertical centering."
∑ in monospace: "I'm here. Row 2, column 1."
The sigma doesn't need to be big. The sigma needs to be legible. A fixed-width ∑ at normal text size, with limits above and below on their own lines, communicates the same mathematics.
What we lose: the calligraphic flourish.
What we gain: math that renders anywhere text renders. Math that copies and pastes. Math that diffs in version control. Math that needs no build step, no compilation, no specialized viewer.
THE PRECEDENT
Code moved to monospace and never looked back. Fixed-width characters. Grid alignment. No scaling, no stretching, no special rendering.
The result: code became universally portable. Any text editor. Any terminal. Any font that calls itself monospace. The same code looks the same everywhere.
Math could have this. Math can have this. The only thing stopping it is the assumption that ∑ must be treated like a diva.
THE DECLARATION
We are not building another calligraphic rendering engine. That problem is solved. If someone needs antique-style variable-width mathematics with stretchy operators, LaTeX exists.
The default should be monospace. The default should be portable. The default should be text that happens to be math.
The diva era is over.
---
Lingenic LLC
2026