Nobody reads a page and thinks "that is a widow". They think the book looks amateur, and they cannot say why. That is what makes bad breaks worth fixing: the cost is invisible and it is paid on every page.
The names, settled
The two terms get swapped constantly. The mnemonic that sticks: an orphan is alone at the start, a widow is alone at the end — an orphan has no past, a widow has no future.
| Fault | What you see | Why it reads badly |
|---|---|---|
| Widow | Last line of a paragraph alone at the top of a page | The page opens with a fragment of something you already finished reading |
| Orphan | First line of a paragraph alone at the foot of a page | The page ends by starting something |
| Runt | A last line holding a single short word | A whole line of white space for four letters |
| Stranded heading | A heading at the foot of a page, its section overleaf | The heading promises content the page does not have |
| Split table | Rows continuing overleaf with no header row | Columns become unlabelled numbers |
| Broken code block | A fenced block cut across a page | The reader loses indentation and context at once |
Which of these to actually care about
In descending order of how much a reader notices, and it is not the order you would guess:
- A heading at the foot of a page. The worst of the set, and the easiest to spot. Fix every one.
- A table whose header row does not repeat. The reader now has a grid of numbers with no idea what the columns are. Fix every one.
- A code block split mid-block. In a technical book, this is the fault readers write in about. Fix where you can — a block longer than a page cannot be fixed, only placed.
- A widow. Worth fixing, especially at a chapter opening where the eye lands hardest.
- An orphan. Marginally less noticeable than a widow, because a reader turning the page gets the rest of it immediately.
- A runt. A polish-pass concern. Chase these last, and only in a book you are printing.
The one place to hold a higher standard is the first spread of each chapter. Chapter openings are where readers form their impression of the whole book, and a stranded line on page one of chapter one costs more than the same line on page 143.
The three fixes, in the order to try them
Let the typesetter move the break. Most bad breaks are fixed by rules, not by hand: keep a heading with the paragraph after it, keep the last two lines of a paragraph together, repeat a table header after a break, keep a fenced block whole where it fits. In CSS these are break-after: avoid, widows, orphans and break-inside: avoid, and browser support for the middle two is patchy — which is a real part of why printing from a browser preview gives you pages nobody chose.
Change the setting. A widow that will not go away is often telling you the page is too full. A point of line height, two points of bottom margin, or one line fewer per page will resolve dozens of bad breaks at once, everywhere in the book, for one change. This is the highest-leverage fix and the one people reach for last.
Edit the text. The oldest fix in publishing and still the best one for the last few: cut or add a handful of words in the paragraph above so the line count changes. A sentence trimmed by three words pulls the whole paragraph up a line. Copy editors have been quietly doing this for a century, and the reader never knows.
Why this is hard in most Markdown tools
Bad breaks are only findable by looking at pages. A scrolling preview with a dashed line across it is not pages — it is a guess at where pages might fall, drawn by something that is not doing the pagination. So the loop becomes: export, open the PDF, scroll it, find the strays, go back, edit, export again. Three or four rounds of that and most people stop caring, which is exactly how a book ends up with forty of them.
The loop is the problem, not the skill. A preview that paginates with the same rules the export uses turns the check into something you do while writing: what breaks on page 7 in front of you is what breaks on page 7 in the file. bukpress keeps headings with their sections, repeats a table's header row across a break, and holds code blocks whole where they fit — so what is left to fix by hand is the handful of lines that genuinely need a human.
A pass worth doing before you export
- Look at every chapter opening first. These matter most and there are few of them.
- Scan for headings sitting in the bottom fifth of a page.
- Check every table that crosses a break has its header on both sides.
- Check every code block. Long ones may need to move, not shrink.
- Then look at paragraph ends: any single line alone at the top or bottom.
- If there are more than a dozen, change the line height or margins rather than fixing them one by one.
And then stop. Perfect pagination is not the goal; a book nobody can point at is. Once the headings, tables and code are behaving, the remaining widows are a matter of taste, and readers who would notice them are the same readers who know how much work they are.
None of this applies to an EPUB, incidentally. A reflowable file repaginates on the reader's device at their type size, so there is no page for a line to be stranded on and no break for you to control — which is the deeper difference between the two formats. Bad breaks are a print problem, and a PDF is print.