Why Plain Markdown Prints Better: The Page Break Is the Whole Argument

Print quality is decided at the page boundary, not in the font menu. Knuth and Plass measured it in 1981: a typesetter that reads the whole paragraph before committing to any line produced seven badly spaced lines where the best line-at-a-time method produced twenty-four ¹. It only runs on a file that has not frozen its layout.

The paper is Breaking paragraphs into lines, published in Software: Practice and Experience, volume 11, issue 11, in November 1981 ². It is the paper behind TeX's line-breaker, and its argument is not about taste. It is an optimization claim, stated in the summary: "Instead of simply making decisions one line at a time, the method considers the paragraph as a whole, so that the final appearance of a given line might be influenced by the text on succeeding lines" ³.

Read that sentence as a requirement rather than a description and the whole print question changes shape. A method that lets later text influence an earlier line needs the later text still to be in play. It needs a paragraph, a target width, and permission to decide. A file that arrives with its font, its point size, and its column width already baked has answered all three questions before the typesetter is asked. There is nothing left to optimize.

So the honest version of "plain Markdown prints better" is narrow and mechanical: a file that declares nothing about presentation is the only kind a global typesetter can work on. Whether the result looks better is your call, and this post will not pretend otherwise.

The 1981 paper measured three methods, not two

Knuth and Plass named three line-breakers ⁴, and the distinction between them carries the entire argument. First-fit fills each line as full as it can. Best-fit picks each break to minimize that line's badness. Optimum-fit treats the paragraph as one problem and solves it with dynamic programming ³. Only the third looks ahead.

The trap is that first-fit and best-fit are both local. The paper is explicit about what best-fit does not do: "Once again each line has been broken without looking ahead to the end of the paragraph and without going back to reconsider previous choices, but this time each break was chosen so as to minimize the 'badness plus penalty' of that line" ⁴.

Two greedy methods. One global one.

That matters because the paper reports two separate head-to-head experiments, and they are easy to confuse. One compares the two greedy methods against each other. The other compares the best greedy method against the global one. Only the second is evidence for the claim in this post's title, and it is the one worth reading closely.

What happened when the algorithm could see the whole paragraph

Knuth and Plass set Section 3.5 of Seminumerical Algorithms at 25 picas, without human intervention, and compared optimum-fit against best-fit across roughly 800 line breaks each ¹. The global method produced better-behaved spacing on every measure they reported — and, unusually, used fewer hyphens while doing it.

The numbers are specific. The standard deviation of spacing "was 0.53 (optimum-fit) versus 0.65 (best-fit)" ⁵. On the extremes: "24 of the lines typeset by best-fit had spaces exceeding 12 units, while only 7 such bad lines were produced by the optimum-fit method" ¹.

Seven versus twenty-four, on the same text.

The authors describe the shape of the difference plainly: best-fit "produced considerably more lines that were extremely spaced out" ⁶. Their figure caption calls the comparison what it is — "the best line-at-a-time method" set against the paragraph-at-a-time one ⁷.

The hyphen result is the one that surprises. A method with more freedom might be expected to hyphenate more. It did the opposite: best-fit "also tended to end substantially more lines with hyphens: 119 by comparison with 80" ⁸. Roughly a third fewer hyphens, from the method that was allowed to reconsider.

They chose that section deliberately, because it "most closely resembles typical mathematics papers containing theorems, proofs, lemmas, etc." ⁹ — the hard case, not the flattering one.

The greedy-versus-greedy table, and what it does not show

The paper's other experiment is the famous one, and it is routinely misread as evidence for global typesetting. It is not. It compares first-fit against best-fit — two local methods — across 300 runs, "with line widths ranging from 350 to 649 in unit steps" ¹⁰. Its table is worth printing in full, because one column cuts against the argument.

Source: Knuth and Plass, p.1128 ¹¹. Each column sums to 100%.

The headline reading is real: "in 69% of the cases, the minimum adjustment ratio r_j in the lines typeset by first-fit was less than the corresponding value obtained by best-fit" ¹², and the maximum ratio was lower "about 35% of the time" ¹³.

In the authors' summary, first-fit "usually typesets at least one line that is tighter than the tightest line set by best-fit, and it also usually produces a line that is as loose or looser than the loosest line of best-fit" ¹⁴.

Now the third column. Hyphen counts are identical 77% of the time, and the authors say so directly: the "number of hyphens is about the same for both methods, although best-fit would produce fewer if the penalty for hyphenation were increased" ¹⁵. Between two greedy methods, hyphenation is a wash. It only improved when the global method got involved.

That is what an honest table looks like. It answers one question and declines another.

One finding here does transfer, and it is the one that should worry anyone printing to a narrow column: "the superiority of best-fit is especially pronounced in the cases where the lines are rather narrow" ¹⁶. Tight measures punish local decisions hardest.

Hyphenation was the other half, and it was solved in 1983

Good justified text needs somewhere to break a word, and that engine is older and smaller than most people assume. Franklin Mark Liang's 1983 Stanford thesis produced the hyphenation patterns still shipping inside the TeX toolchain: "The resulting hyphenation algorithm uses about 4500 patterns that compile into a packed trie occupying 25K bytes of storage" ¹⁷.

Twenty-five kilobytes. The whole of English hyphenation.

Its accuracy is the point: "These patterns find 89% of the hyphens in a pocket dictionary word list, with essentially no error" ¹⁸. The method it replaced, inside TeX itself, managed far less — "about 40% of the allowable hyphen points are found, with 1% error (relative to the total number of hyphen points)" ¹⁹.

Forty per cent to eighty-nine, on identical words. Nothing about the text changed. The algorithm did.

This is the pattern that keeps repeating at the page boundary: the input is fixed, and the quality is a function of what the software is allowed to compute. Which is exactly what an export takes away.

Widows and orphans: the default nobody sets is two

A page break can strand a single line at the bottom or top of a page, and the web has had a name and a knob for this since CSS 2.1 became a Recommendation in 2011. The spec is positional and unambiguous, and the default is smaller than most people would choose: two lines ²⁰.

The definitions are worth quoting exactly, because the words are counterintuitive. "The 'orphans' property specifies the minimum number of lines in a block container that must be left at the bottom of a page." And: "The 'widows' property specifies the minimum number of lines in a block container that must be left at the top of a page" ²¹.

Both properties take an integer, both are inherited, both apply to block container elements, and both carry an initial value of 2 ²⁰. So unless something says otherwise, your page is permitted to leave exactly two lines behind.

Two lines. That is the floor you inherit by saying nothing.

None of that is exotic. It is a stylesheet property that has been ratified for fifteen years and applies to paged media by definition — the CSS Paged Media module opens by saying it "defines a page model that specifies how a document is formatted within a rectangular area, called the page box, that has finite width and height" ²².

A page box with finite height is where all of this becomes real. Line-breaking decides the texture of a paragraph. Pagination decides whether your heading ends up alone at the bottom of page three.

Why a rich-text export cannot run any of this

An export hands the printer a document that has already made the decisions. The typesetter's job — choose a measure, break the paragraph globally, hyphenate, then decide where the page ends — is pre-empted by a file carrying its own fonts, sizes, and geometry. The optimizer arrives to find the problem already answered.

This is not a new observation, and it is not this post's to re-argue. That a formatted file smuggles its own inline styling is the subject of why pasting without formatting is a note discipline. That the note file has no width — the renderer does — is established in the 66-character line for notes. Take both as read.

The lineage is old enough to be documented in the standards. HTML 4.01 deprecated presentational font markup in 1999 with a one-line rationale that reads like the thesis of this post: "FONT and BASEFONT are deprecated," because "It is possible to achieve a much richer variety of font effects using style sheets" ²³. Richer, because the decision moved to something that could see the whole document and the target medium.

Markdown inherits that separation by having nothing to say about fonts at all. This is the same reason an LLM reads your Markdown better than an export — the printer and the language model want the same thing, for the same reason. Neither wants your font stack. Both want the text and the freedom to lay it out.

The sibling question — which typeface you read in — belongs to the screen, and monospace or proportional for your notes answers it there.

How to print a Markdown file

Five moves, in order of leverage. The toolchain is Pandoc, which is explicit about what it reaches for: "By default, pandoc will use LaTeX to create the PDF, which requires that a LaTeX engine be installed" ²⁴. That engine is where the 1981 line-breaker and the 1983 hyphenation patterns actually live.

1. Send the Markdown, not the export. Everything below depends on the file not having decided already.
2. Let LaTeX set the paragraph. Pandoc's default PDF path routes through it ²⁴, which is how you get paragraph-at-a-time breaking rather than line-at-a-time.
3. Widen the measure if the copy is hard. Narrow columns are where local methods fail worst ¹⁶, and the 1981 experiment needed roughly triple the second passes at 25 picas versus 29 ⁹.
4. Set widows and orphans deliberately if you print via CSS. The initial value is 2 ²⁰; decide whether that is what you want rather than inheriting it.
5. Re-read a printed proof, not the screen. Pagination bugs only exist where the page ends.

Everything else is downstream of step 1.

If you already have a formatted export and no original, the repair path is a separate job — cleaning up a vendor export into plain Markdown covers it.

The caveats: "better" is a judgment, not a measurement

This post's title contains a subjective claim, and the evidence underneath it is narrower than the claim. Nothing cited here shows that anyone reads a globally typeset paragraph faster, remembers more of it, or enjoys it more. The measurements are of spacing distributions and hyphen counts, not of readers.

So the honest scope, stated plainly:

• Preference is not performance. No study here measures reading speed or comprehension. Nothing on this page is a claim about eye strain, and none of it is medical advice.
• The 1981 evidence is one text, one engine. Knuth and Plass set mathematical copy at 25 picas — "About 800 line breaks were involved in each case" ²⁵, across 273 paragraphs ⁹. It is a real measurement and a small one.
• The greedy-versus-greedy table proves less than it is usually asked to prove. Hyphen counts tie 77% of the time ¹¹, and first-fit beats best-fit on the loosest line 15% of the time. Both facts are in the table above.
• A 1981 paper is not a description of every printer. TeX's line-breaker and Liang's patterns still ship in the toolchain shown here ²⁴. That is not the same as "everything uses this."
• Markdown cannot do page layout at all. True, and it is the thesis rather than an objection. The file declares nothing; the stylesheet decides ²².

A reader who prefers the look of their export is not wrong. They are exercising exactly the judgment this post says the file should leave open.

Frequently asked questions

Why does my exported PDF look worse than my printed Markdown? Because the export decided the layout before the typesetter saw it. A global line-breaker needs an unbroken paragraph, a target measure, and permission to choose breaks. A file carrying its own fonts and geometry has answered those questions already, so the optimizer has nothing left to solve.

How do I stop a heading being stranded at the bottom of a page? Set the orphans and widows properties if you print through CSS. Both specify a minimum number of lines that must be left at the bottom or top of a page, both are inherited, and both default to an initial value of just 2 in CSS 2.1 — a low bar you can raise.

What is a widow and an orphan in typography? The citable definition is positional. In CSS 2.1, orphans sets the minimum number of lines left at the bottom of a page, and widows sets the minimum left at the top. Popular usage often reverses them or adds meanings about single words; the specification's version is the one machines follow.

How do I print a Markdown file nicely? Pass the Markdown itself to a typesetting toolchain rather than exporting to a formatted file first. Pandoc's default PDF route uses LaTeX, which requires a LaTeX engine be installed — and that engine carries the paragraph-at-a-time line-breaker and the hyphenation patterns described above.

Why does LaTeX-typeset text look different from a word processor's output? Partly because of how the paragraph is broken. Knuth and Plass measured a global, paragraph-at-a-time method against the best line-at-a-time method on the same text: 7 badly spaced lines versus 24, a spacing standard deviation of 0.53 versus 0.65, and 80 hyphens versus 119. Whether you prefer the result is a separate question.

Does Markdown support fonts and colours? No, and that is the entire point. The file declares nothing about presentation, so the renderer or the print stylesheet decides — the same separation HTML 4.01 formalized in 1999 when it deprecated FONT in favour of style sheets. One file can go to a screen or to a typesetter without being rewritten.

A file that stays quiet about its own presentation is not an unfinished document. It is a document that has kept its options open, and the page boundary is where that turns out to have been worth something.

The page break is the one decision your file should never make for you.

Your notes stay open Markdown you control, so the printer can still do its job — mnmnote.com.