The Wolfram Box Typesetting Reference

Why this reference exists	Part 6 - Semantic and wrapper boxes
Part 1 - What a box is, and how to see one	Part 7 - Gotchas and recipes
Part 2 - Structural boxes	Part 8 - The full *Box catalogue
Part 3 - Math layout boxes	Part 9 - Controlling the front end's rendering: the levers
Part 4 - Styling, sizing, and adjustment	References
Part 5 - Spacing: the front end's model

Why this reference exists

LaTeXMathParse

turns TeX source into a tree of boxes - the low-level expressions the Wolfram notebook front end (FE) typesets into two-dimensional math. There is no single official "box typesetting manual": the knowledge is spread across the Low-Level Notebook Structure guide, the individual

*Box

symbol pages, and the textual box-syntax tutorial. This note consolidates what a box producer - a parser, a code generator, a

MakeBoxes

overload - actually needs: the construct set, their argument shapes and options, how the front end renders and spaces them, and the non-obvious behaviours that only surface when you generate boxes programmatically and rasterize the result.

Everything here is grounded in kernel introspection (

Options

::usage

) and in rendering experiments; the rough edges in the last section are the ones the parser actually hit.

Part 1 - What a box is, and how to see one

A box is an inert expression the front end knows how to lay out. Boxes nest: a

FractionBox

whose numerator is a

RowBox

whose third element is a

SuperscriptBox

, and so on, down to leaf boxes which are ordinary strings (

"x"

"+"

"α"

). Leaves carry the characters; the wrapping boxes carry the geometry.

Three round-trips connect expressions, boxes, and rendered output:

Direction	Function	Example
expression → boxes	ToBoxes[expr] , MakeBoxes[expr,form]	ToBoxes[x^2] → SuperscriptBox["x","2"]
boxes → rendered	DisplayForm[box] , RawBoxes[box]	DisplayForm[FractionBox["a","b"]] shows a fraction
boxes → expression	ToExpression[box] , MakeExpression[box,form]	parses the box back to a value

In[1]:=

ToBoxes[Sqrt[x]/2](*FractionBox[SqrtBox["x"],"2"]*)DisplayForm@RowBox[{"a","+",SuperscriptBox["b","2"]}](*renders:a+b^2*)

Out[1@1]=

FractionBox[SqrtBox[x],2]

Out[1@2]=

DisplayForm

is the workhorse when you have a box tree in hand and want to see it (it wraps the box so the FE typesets it instead of showing the raw

FractionBox[...]

RawBoxes[box]

is the same idea as a building block you can nest inside other expressions. In a live notebook,

Ctrl+Shift+E

toggles any cell between rendered and box form, and the literal

$box$

syntax lets you type boxes directly.

Tip for parser work: to verify what

LaTeXMathParse

produced, rasterize it -

Rasterize[Style[DisplayForm[box],FontSize->24]]

- rather than trusting the box tree by eye. A structurally plausible tree can still render wrong (a stacked limit that should be a side script, a fraction bar that collapsed). What you see is what the engine actually did.

Part 2 - Structural boxes

These carry no glyphs of their own; they arrange their children.

RowBox

RowBox[{box1, box2, ...}]

A horizontal run of boxes with baselines aligned. This is the spine of almost every formula - operators, operands, and delimiters are just successive string leaves and sub-boxes in one

RowBox

. It takes no options; spacing between its children comes from the front end's math-spacing model (Part 5), not from

RowBox

itself.

A single-element row should usually be unwrapped (

RowBox[{x}]

→

); the FE tolerates it, but it clutters the tree and can confuse downstream box rewrites.

GridBox

GridBox[{{box11, box12, ...}, {box21, box22, ...}, ...}]

A two-dimensional grid - the substrate for matrices,

cases

, aligned equations,

\substack

, and

\binom

. Rows must be rectangular (pad short rows with

). Its option set is by far the largest of the typesetting boxes:

Option	Controls	Notes
ColumnAlignments	per-column horizontal alignment	Left / Center / Right / "." (decimal point), or a list that cycles across columns - e.g. {Right,Left} gives R L R L …
RowAlignments	per-row vertical alignment	Baseline / Center / Top / Bottom / Axis
ColumnSpacings , RowSpacings	gaps between columns / rows	in units of the current font's em-ish width; a number or per-gap list
ColumnLines , RowLines	rules between columns / rows	True / False or list; the \hline /`
GridBoxDividers	fine-grained rules	{"Columns"->{...},"Rows"->{...}}
GridBoxAlignment	master alignment spec	{"Columns"->{...},"Rows"->{...}}
GridBoxItemSize , ColumnWidths , RowHeights	cell sizing
BaselinePosition	which row sits on the surrounding baseline	important when a grid is one factor in a larger row
GridBoxBackground , ColumnBackgrounds , RowBackgrounds	cell fills

The cycling-list behaviour of

ColumnAlignments

is the key one for math: TeX's

align

aligned

split

alternate right-aligned and left-aligned columns so the relation signs line up. Build the spec with

PadRight[{},width,{Right,Left}]

to get exactly

width

entries and avoid relying on the FE's cycling.

In[2]:=

DisplayForm@GridBox[{{"a","=","1"},{"bb","=","2"}},ColumnAlignments{Right,Left,Left}](*thetwo"="lineupinacolumn*)

Out[2]=

a	=	1
bb	=	2

Part 3 - Math layout boxes

These are the genuinely two-dimensional constructs. All take their arguments as boxes (strings or nested boxes), never as raw expressions.

Fractions and radicals

Box	Shape	Renders	Key options
FractionBox[x,y]	x over y with a rule	x⁄y	FractionLine (bar thickness; 0 = no bar, which is \atop )
SqrtBox[x]	square root	√x	MinSize (minimum radical height)
RadicalBox[x,n]	n-th root	ⁿ√x	MinSize

In[3]:=

DisplayForm@FractionBox["a","b"](*a/bwithbar*)DisplayForm@FractionBox["a","b",FractionLine0](*aoverb,nobar*)DisplayForm@RadicalBox["x","3"](*cuberootofx*)

Out[3@1]=

Out[3@2]=

Out[3@3]=

Note

FractionLine->0

is the textbook way to get an

\atop

\binom

stack with the fraction machinery (centred, scaled numerator/denominator). The parser instead uses a barless

GridBox

for those, because it wants the binomial-coefficient delimiters around the stack and finer control of the spacing - either is valid.

Scripts: side vs. stacked

This is the distinction that trips up every math renderer.

Box	Shape	Used for
SubscriptBox[x,y]	x with y low-right	x_i
SuperscriptBox[x,y]	x with y high-right	x^2
SubsuperscriptBox[x,y,z]	x with y low-right and z high-right	x_i^2
UnderscriptBox[x,y]	y centred below x	\lim_{...} , accents below
OverscriptBox[x,y]	y centred above x	\hat , \overline , \overbrace
UnderoverscriptBox[x,y,z]	y below and z above x	display-style \sum_a^b

The same TeX source (

\sum_a^b

) maps to either

SubsuperscriptBox

(bounds to the side) or

UnderoverscriptBox

(bounds stacked above/below) depending on the operator and the math style:

◼

Limits-stacking operators -

\sum\prod\coprod\bigcup\bigcap\bigvee\bigwedge\bigoplus\bigotimes\bigsqcup

- stack their bounds in display style. The parser keeps a set (

$bigOpChars

) and rewrites

SubsuperscriptBox[op,lo,hi]

→

UnderoverscriptBox[op,lo,hi]

for them.

◼

Integrals -

\int\oint\iint...

- keep their bounds to the side even in display style (TeX

\nolimits

). They must not be in that set.

Under

Over

UnderoverscriptBox

carry one option,

LimitsPositioning

: when

True

(the default for these boxes in some styles) the bounds drop to the side in inline/script size and stack in display size, mirroring

\displaystyle

behaviour. Generators usually pick the box explicitly (as above) rather than relying on

LimitsPositioning

In[4]:=

DisplayForm@SubsuperscriptBox"∫","a","b"(*sidebounds*)DisplayForm@UnderoverscriptBox["∑","a","b"](*stacked*)

Out[4@1]=

∫

Out[4@2]=

∑

Part 4 - Styling, sizing, and adjustment

StyleBox

StyleBox[boxes, options...] StyleBox[boxes, "NamedStyle", options...]

Wraps boxes with display directives. It accepts essentially any front-end style option; the ones that matter for math:

	Option	Effect
	FontSlant	"Italic" / "Plain" - math variables are italic, operator names ( sin ) upright
	FontWeight	"Bold" / "Plain"
	FontFamily	"Times" , "Courier" (typewriter), "Helvetica" (sans), "Latin Modern Math" …
	FontColor	any colour directive ( RGBColor[...] , Red , …)
	FontSize	absolute points, or Scaled[r] (see the gotcha below)
	Magnification	uniform scale of the wrapped box relative to its surroundings
	AutoSpacing	False suppresses the FE's automatic math spacing inside this box
	ShowStringCharacters	False hides the quotes around string leaves

The named-style form,

StyleBox[boxes,"TI"]

, pulls the option settings for a stylesheet style instead of spelling out directives. From the default stylesheet (

Core.nb

), the math letterform styles are literally Times faces:

In[5]:=

StyleData["TR"]→FontFamily"Times",FontWeight"Plain",FontSlant"Plain"StyleData["TI"inherits"TR"]→FontSlant"Italic"(*TimesItalic*)StyleData["TB"]/"TBI"→+Bold/+Bold+ItalicStyleData["MR"/"MO"/...]→CodeFont(monospace)Roman/variantsStyleData["SR"/...]→sans(\textsf)Roman/variants

AdjustmentBox - manual kerning

AdjustmentBox[box, BoxMargins -> {{left, right}, {bottom, top}}, BoxBaselineShift -> n]

FrameBox and friends

Part 5 - Spacing: the front end's model

This is the single biggest source of visual divergence from TeX/KaTeX, and the one you have the least direct control over.

You can influence it two ways:

Part 6 - Semantic and wrapper boxes

These display as their first argument but carry extra meaning for input, copy/paste, or evaluation. A renderer that only cares about display can mostly ignore them, but they matter the moment output must round-trip back to an expression.

Part 7 - Gotchas and recipes

Hard-won, mostly absent from the official pages:

Part 9 - Controlling the front end's rendering: the levers

Everything above is what the boxes are. This part is how to make the FE render them the way you want - the options and characters that tune fonts, spacing, and kerning. The findings below are cross-checked against the official references, the kernel's own usage strings, and community/blog sources (MaTeX's author, Wolfram Community, comp.soft-sys.math.mathematica); see References.

Settable INLINE - what a box producer controls directly

So a pure box emitter cannot retune script sizes or delimiter-growth bounds per-expression - those belong in the consuming notebook's cell options or a shipped stylesheet.