TeX82: Donald Knuth Turns Beautiful Typesetting into an Algorithm

A justified paragraph can obey both margins and still look as though its words are avoiding one another. The geometry is correct. The reader is less impressed.

That gap bothered Donald Knuth. Mathematical publishing demands an additional sort of precision: a fraction must communicate its structure, an exponent must belong to the right expression, and spaces must help the eye follow an argument. A line that merely fits is an inadequate answer.

TeX82 made those visual decisions programmable. Its most interesting move was to give the software a larger problem to solve: compare arrangements across a paragraph, rather than declare each line finished as soon as it technically fits.

A publishing problem at Stanford

TeX began before 1982. While working on revisions to The Art of Computer Programming in the late 1970s, Knuth wanted better control over the typesetting. For books filled with mathematical notation, typography was part of communicating the argument, not merely decorating it. He began developing a system that would give him greater control over the result.¹

Donald Knuth in January 2011 at the Computer History Museum—not a photograph from the 1982 development period. Photo: Alex Handy, via Wikimedia Commons, CC BY-SA 2.0.

This was research software developed around Stanford University in California, rather than a commercial product launched by a PC company. It also had a broader cast than the familiar “Knuth wrote TeX” shorthand suggests.

Knuth’s preserved 1982 source credits Michael F. Plass and Frank M. Liang with an initial prototype in 1977. Knuth implemented an early full version in SAIL in 1977–78. Other implementations informed the redesign, including a 1979 Mesa version by Leonidas Guibas, Robert Sedgewick, and Douglas Wyatt at Xerox PARC.²

The program called TeX82 was written in late 1981 and early 1982. Its Pascal-based implementation used Knuth’s WEB system, combining code and explanatory documentation. The redesign emphasized portability and consistent output across computers. Knuth taught its internals in recorded Stanford lectures on July 28–30, 1982.²³

Calling it a 1982 invention would erase several years of work. The milestone was a substantial reimplementation of an existing idea.

The breakthrough: deciding across a paragraph

A straightforward line-breaking program can fill one line until the next word will not fit, then move on. That is a local decision: once the line is finished, its consequences for the following lines may receive little consideration.

TeX’s paragraph-breaking approach considers alternative sequences of breaks. An earlier break can make several later lines look better. In their 1981 paper, Breaking Paragraphs into Lines, Knuth and Plass described a model built from three primitives:⁴

Primitive	What it represents	Why it matters
Box	Material with a fixed width, such as a glyph or word	Supplies the occupied space
Glue	Space with a natural size and permitted stretch or shrink	Allows justified text to fit a line
Penalty	A cost or constraint associated with a possible break	Expresses preferences about breaking

The algorithm uses dynamic programming to retain the best partial solutions for relevant states, rather than exploring every complete arrangement independently. Its scoring can account for spacing and undesirable sequences of breaks.⁴

Think of planning a route with several possible stops. The nearest stop is not necessarily part of the best overall route. Similarly, the fullest first line is not necessarily part of the most balanced paragraph.

That analogy is an explanation, not TeX’s literal implementation. The important shift is the scope of the decision: judge a sequence instead of accepting each locally convenient choice.

Giving ugly spacing a number

TeX uses a measure called badness to evaluate stretching or shrinking ordinary interword spacing. For finite stretch, the underlying heuristic is approximately:

$$b \approx 100\left|r\right|^3, \qquad r = \frac{\text{required stretch}}{\text{available stretch}}.$$

The actual program uses a specified integer approximation and special handling for extreme cases. This simplified formula explains the behavior; it is not the complete paragraph score.⁵

Suppose a candidate line has a target width of 100 points. Its text and natural spacing occupy 95 points, and its spaces provide 10 points of total available stretch:

$$r = \frac{100-95}{10}=0.5, \qquad b \approx 100(0.5)^3=12.5.$$

Compare three hypothetical stretch ratios:

Stretch ratio	Approximate badness
0.5	12.5
1.0	100
1.5	337.5

These are illustrative values from the cubic heuristic, not exact outputs from TeX’s integer routine.

Doubling the ratio from 0.5 to 1.0 multiplies the cost by eight. Increasing it to 1.5 makes the cost twenty-seven times the original value. The curve therefore discourages one conspicuously loose line more strongly than a linear rule would.

This is a useful software lesson beyond typography: the shape of a scoring function expresses priorities. If extreme mistakes should be especially expensive, the cost must grow accordingly.

TeX’s full decisions also involve break penalties and relationships between neighboring lines. A paragraph is not optimized by adding the three illustrative numbers above, and the final line is normally allowed different spacing behavior.⁴

Mathematics becomes programmable input

Mathematical layout was another central reason for TeX’s existence. Authors could specify a formula through text commands rather than manually position every symbol.

Here is a small plain TeX example:

The quadratic formula is
$$
x = {-b \pm \sqrt{b^2-4ac} \over 2a}.
$$
\bye

The corresponding mathematical expression is:

$$x = \frac{-b \pm \sqrt{b^2-4ac}}{2a}.$$

The displayed equation here is rendered by your Markdown viewer; it is not an image captured from TeX82. The code illustrates plain TeX notation, while the display uses the familiar \frac command supported by many modern math renderers.

The author specifies a relationship: a numerator over a denominator, a square root, an exponent. The typesetting system applies layout rules to that structure.

That makes revision a different kind of activity. Change an expression in its source, and the layout can be regenerated. A writer does not need to move each neighboring symbol by hand.

New teaching diagram, created in 2026. The bars show the example’s stretch ratios and approximate cubic badness; they are not captured TeX82 output.

Portability reached beyond the source code

TeX’s traditional output format was DVI: device-independent output. It recorded placement instructions and references to fonts, with a separate driver responsible for producing output for a particular device. TeX used font metrics to calculate layout.⁵

That separation mattered. The engine could decide where material belonged without embedding every printer’s behavior into its paragraph-breaking machinery.

It also sets a limit on the portability claim. Consistent layout does not mean that a source file alone guarantees an identical document forever. Fonts, supporting files, software versions, and output tools still matter.

Today, that distinction should sound familiar to anyone who has moved a project between machines. A reproducible result depends on its environment as well as its main file. TeX made the boundary between those pieces unusually explicit.

A program written for people to read

TeX82’s implementation was remarkable for another reason: WEB.

Knuth’s approach, later explained in his 1984 paper on literate programming, encouraged programmers to organize an explanation of a program for human readers. Code and prose formed a connected account of how the system worked.⁶

For a typesetting engine, that was an especially appropriate experiment. Software about publishing was itself presented as a carefully explained document.

The broader implication is an interpretation: a program intended to last benefits from preserving its reasoning, not just its executable instructions. A future maintainer needs to understand why an algorithm takes a particular shape, which constraints it respects, and where its assumptions end.

Documentation cannot replace correct code. But code alone can be a poor record of the decisions that produced it.

TeX, LaTeX, and the limits of convenience

TeX and LaTeX are related, but they are not interchangeable names.

TeX supplies the underlying typesetting engine. LaTeX is a document-preparation system built on it, offering higher-level facilities for structured documents, including sections, references, and bibliographies.⁷ A modern LaTeX document is therefore not an accurate example of TeX82’s original user experience.

TeX’s power also carries a learning cost. Text commands, macros, font choices, and diagnostic messages demand skills that a visual editor can sometimes hide. A misplaced brace can become a practical obstacle long before a writer cares about line-breaking theory.

The achievement was not universal ease of use. It was unusually precise, programmable control over demanding documents.

A tiny route through possible paragraphs

Here is a second teaching model, with invented scores rather than TeX’s actual demerit calculation. Imagine two legal ways to break the first line. Route A gives that line a cost of 2, followed by lines costing 80 and 2. Route B starts with a cost of 12, followed by 12 and 12. A greedy decision likes A immediately. Comparing complete routes prefers B: 36 beats 84.

Nothing about the first line’s appearance alone reveals the later cost. That is why retaining alternatives matters. Dynamic programming makes a problem like this manageable by reusing the best partial results associated with relevant states. The exact states and penalties are part of the engineering; the general insight is that future consequences belong in the current decision.

A cost function also needs taste. If all excess space has a small, uniform cost, the optimizer may happily produce one conspicuously loose line. If its cost rises sharply, the program has reason to distribute the discomfort. The machine’s judgment is only as good as the preferences we have made measurable.

There are limits to this delegation. An algorithm can compare allowed breaks, but a writer may improve the whole paragraph by changing three words. No amount of numerical diligence obliges a bad sentence to become attractive. TeX can optimize the arrangement it receives; editing changes the available material.

Repeatable decisions, and the cost of getting them wrong

A macro is a reusable instruction expressed in TeX’s input language. This simple plain TeX example defines a notation once:

defloss#1{L_{#1}}
$$loss{train} + loss{test}$$
ye

Here #1 stands for an argument. Each use inserts that argument into the same subscript structure. This is an illustrative example, not code recovered from Knuth’s 1982 documents. The grouping braces delimit which material belongs to the argument and the resulting subscript.

The useful consequence is consistency. If an author decides to change the notation, there is one definition to inspect instead of many manually formatted instances. A macro can preserve an editorial decision. It can also propagate an editorial mistake with impressive discipline.

That balance is central to programmable publishing. Source text records intentions that can be reapplied. A typesetting engine implements those intentions across a document. The author remains responsible for choosing the intentions and checking the result.

TeX82’s combination of explicit source, paragraph-level judgment, and documented implementation makes an unusually complete example of that arrangement. It allows the page to look effortless by moving considerable effort into rules we can read.

A short timeline

Date	Development	Significance
1977	Initial TeX prototype involving Plass and Liang	Establishes that TeX predates the 1980s
1977–78	Knuth implements an early full version in SAIL	Develops the original system
November 1981	Knuth and Plass publish their paragraph-breaking paper	Explains the optimization approach
Late 1981–early 1982	TeX82 is written	Rebuilds the system with portability as a major concern
July 28–30, 1982	Knuth gives recorded TeX82 internals lectures at Stanford	Documents and teaches the implementation
1984	Knuth publishes “Literate Programming”	Explains the philosophy behind WEB

Sources and further reading

Footnotes

1. TeX FAQ, “What is TeX?”. Community documentation of the publishing motivation and distinction between the first system and its 1982 rewrite. ↩

2. Donald E. Knuth, preserved TeX82 WEB source, especially the introduction and development credits. Knuth’s programs page identifies this as version −0.25 from his July 1982 lectures. ↩ ↩²

3. Donald E. Knuth, “Musings”, entry for the TeX82 implementation lectures, July 28–30, 1982. ↩

4. Donald E. Knuth and Michael F. Plass, “Breaking paragraphs into lines”, Software: Practice and Experience, 11(11), November 1981, pp. 1119–1184. Full paper, mirrored PDF. ↩ ↩² ↩³

5. Donald E. Knuth, annotated TeX program, especially §108 on badness and the sections on DVI and font metrics. This is a later revised presentation of the program, dated March 2, 2026 in the consulted copy; it supports the mechanical explanation, rather than documenting an untouched 1982 release. ↩ ↩²

6. Donald E. Knuth, “Literate Programming” resource page; original paper in The Computer Journal, 27(2), 1984, pp. 97–111. ↩

7. The LaTeX Project, “An introduction to LaTeX”. Describes LaTeX’s document-preparation features and relationship to TeX. ↩