Scrivener is the best-organised place to write a long book that anyone has shipped. The binder, the corkboard, snapshots, split-screen research, per-document metadata — for a 90,000-word manuscript with a structure that keeps changing, nothing else comes close. Then you press Compile and you are in a different application: one dialog box, forty settings, and a PDF that is either exactly right or subtly wrong in ways that are hard to name.
What Compile actually is
Compile assembles the documents in your binder into one file, applies a Format (the layout rules) and a set of Separators (what goes between documents), and hands the result to an output engine. The Format is the part that matters, and it is where most of the confusion lives.
| Concept | What it controls |
|---|---|
| Format | Section layouts, fonts, spacing — the whole visual design |
| Section Type | What a binder document *is*: chapter, scene, part |
| Section Layout | How that type is rendered — title style, page break, prefix |
| Separators | Blank lines, # marks or page breaks between documents |
| Compile For | PDF, DOCX, EPUB, Markdown, plain text |
The step everyone skips is assigning Section Types in the binder. Do it once, per folder, and every layout decision afterwards applies to a category rather than to individual files. Skip it, and you will be fixing chapter headings one at a time forever.
Setting up a PDF that is the right shape
Compile's page size does not come from the Format. It comes from Page Settings inside the Compile dialog, and it defaults to your printer's paper — which is why so many first exports are US Letter with one-inch margins, a shape no published book has ever been.
- Pick the trim size first. 6 × 9 in for most non-fiction, 5.5 × 8.5 in for a novel. A4, Letter or a trim size covers the choice.
- Set mirrored margins so the inside edge is wider than the outside — the gutter is where the binding eats the page.
- Turn on facing pages if the book will be printed, so chapters can be made to start on a right-hand page.
- Set the running heads and page numbers in the Header and Footer fields;
<$p>is the page number token,<$sectiontitle>the current chapter. - Compile a 20-page sample and print it. Every margin error is obvious on paper and invisible on a screen.
Margins are the setting that decides whether the export reads as a book or as a manuscript. The numbers that work, and why, are in page margins and line length.
Where Compile stops
Scrivener's PDF engine lays out a page. It does not typeset one. The distinction only becomes visible in a finished book, which is why it catches people at the last step rather than the first.
| Wanted | In Compile |
|---|---|
| Chapters starting on a right-hand page | Possible, via layout page-break settings |
| Widow and orphan control | Not exposed — you get what the engine does |
| Keeping a heading with its next paragraph | No direct control |
| Hyphenation and justification quality | Basic; noticeably looser than a real typesetter |
| Tables | Passed through from the editor, and fragile |
| Images at a controlled size and position | Awkward; sized in the editor, not the layout |
| Footnotes at the foot of the correct page | Yes, and it does this well |
| Embedded, subset fonts | Yes |
For a novel — one column of prose, no images, no tables — those gaps mostly do not matter, and a compiled PDF is a legitimate finished book. For anything with figures, tables, code or sidebars, you will spend longer fighting Compile than you would spend typesetting the book somewhere else. Widows and orphans is the specific thing readers notice without knowing its name.
Compiling to Markdown instead
The alternative that keeps everything Scrivener is good at and removes the part it is not: draft in Scrivener, compile to MultiMarkdown, and typeset from the Markdown. Compile For → MultiMarkdown (.md) gives you one clean file with your structure intact.
# Chapter One
The compiled Markdown is plain and predictable — headings from your
section layouts, emphasis preserved, footnotes as [^1] references.
[^1]: Which is exactly what you want handed to a typesetter.- Prefix titles with hash marks in the Section Layouts so your binder hierarchy compiles to heading levels rather than styled text.
- Turn on the rich-text-to-MultiMarkdown conversion so italics and bold survive as Markdown emphasis instead of being flattened to plain text.
- Compile images as references and keep them in one folder next to the Markdown; you will want to control their size at typesetting time anyway.
- Check the footnotes. Scrivener's inline annotations and its real footnotes compile differently, and only one of them survives.
What you get back is a manuscript in a format that outlives the app that wrote it — the same argument as Word to Markdown, arrived at from the other direction. From there the typesetting is a separate, repeatable step: change a font, re-export, and nothing about the draft has moved.
Compiling to DOCX, and why it is usually worse
DOCX is the obvious route to an editor or a proofreader, and the right one for that job. As a route to a PDF it adds a second application's opinions to the first's: Word will re-flow the text, substitute anything it cannot find, and hyphenate to its own taste. Two layout engines in sequence is one more than a book needs.
| Target | Best route out of Scrivener |
|---|---|
| A proofreader with tracked changes | Compile to DOCX |
| A print-ready interior | Compile to Markdown, typeset separately |
| A Kindle upload | Compile to Markdown, then to EPUB |
| A quick draft to read on a tablet | Compile straight to PDF |
| An agent or publisher submission | Compile to DOCX, standard manuscript format |
A working setup
- Assign Section Types in the binder — Chapter for folders, Scene for the documents inside them. Ten minutes, once.
- Duplicate a Format and edit the copy, so you can always get back to a working baseline.
- Keep two compile presets: one to PDF for reading drafts, one to Markdown for the finished book.
- Compile the whole book weekly, not at the end. A compile that has not been run in three months has always broken.
- Do the final typesetting outside Scrivener unless the book is plain prose — and if it is plain prose, compile straight to PDF and stop reading.
Scrivener earns its place at the drafting end, where structure changes daily and nothing is final. The typesetting end wants the opposite: a stable source file and a layout you can regenerate on demand. Splitting the two at the Markdown compile is what lets each tool do the part it is actually good at — the whole route is laid out in from Markdown draft to published book.