# Scrivener to PDF: getting a book out of Compile

> What Compile does well, where its PDF stops short of a finished book, and how to hand the manuscript to something that typesets it properly.

Canonical: https://buk.press/blog/scrivener-to-pdf

8 September 2026 · 6 min read

Compile to PDF directly when the book is plain prose and the default layouts are close enough; set the page size and margins in the Page Settings pane before anything else. When you need control over page breaks, running heads or an image-heavy interior, compile to Markdown or DOCX instead and typeset from there: Scrivener is a superb drafting environment and a blunt typesetter.

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.

Duplicate a built-in Format before editing it. Scrivener's own Formats cannot be edited in place, and the copy is what you will spend the next hour tuning.

## 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.

1. **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](https://buk.press/blog/a4-vs-letter-vs-trim-size) covers the choice.
2. **Set mirrored margins** so the inside edge is wider than the outside. The gutter is where the binding eats the page.
3. **Turn on facing pages** if the book will be printed, so chapters can be made to start on a right-hand page.
4. **Set the running heads and page numbers** in the Header and Footer fields; `<$p>` is the page number token, `<$sectiontitle>` the current chapter.
5. **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](https://buk.press/blog/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](https://buk.press/blog/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.

```
<code># 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.</code>
```

- **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](https://buk.press/blog/markdown-images-pdf) 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. It is the same argument as [Word to Markdown](https://buk.press/blog/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.

This is also the answer to the question Scrivener users ask eventually: what happens to the book if the project file breaks. A Markdown compile is a plain-text backup of the entire manuscript that any editor on any machine can open.

## 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](https://buk.press/blog/markdown-to-kindle) |
| 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

1. **Assign Section Types in the binder:** Chapter for folders, Scene for the documents inside them. Ten minutes, once.
2. **Duplicate a Format** and edit the copy, so you can always get back to a working baseline.
3. **Keep two compile presets:** one to PDF for reading drafts, one to Markdown for the finished book.
4. **Compile the whole book weekly,** not at the end. A compile that has not been run in three months has always broken.
5. **Do the final typesetting outside Scrivener** unless the book is plain prose. 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, and the whole route is laid out in [from Markdown draft to published book](https://buk.press/blog/self-publish-from-markdown).

**About this article.** Written by the team that builds bukpress, which turns Markdown into print-ready PDF and EPUB books. Spotted something wrong or out of date? Write to [support@buk.press](mailto:support@buk.press).

## Read next

Tools 4 September 2026 · 4 min read

## [Word to Markdown: converting a manuscript cleanly](https://buk.press/blog/word-to-markdown)

Pandoc converts a .docx to Markdown in one command and gets the structure right about 90 percent of the time. The remaining 10 percent is the part that matters: direct formatting that was never a real heading, smart quotes, tracked changes, embedded images and Word's own list numbering. Budget an hour of cleanup, once, and you never do it again.

[Read it](https://buk.press/blog/word-to-markdown)

Guides 30 August 2026 · 5 min read

## [From Markdown draft to published book: the whole pipeline](https://buk.press/blog/self-publish-from-markdown)

Six stages: mark up the manuscript by structure, add the front and back matter readers expect, design it once, export the formats each channel needs, check the output against a proof list, then upload. The writing is the long part; the pipeline itself is roughly a day.

[Read it](https://buk.press/blog/self-publish-from-markdown)

Design 2 September 2026 · 6 min read

## [Page margins and line length: the numbers that make it read](https://buk.press/blog/page-margins-and-line-length)

Set margins so that a line of body text holds 55 to 75 characters including spaces. On A4 at 11pt that means margins of roughly 60 to 80 points a side, not the 20 to 40 a word processor defaults to. Line height then follows from the measure: the longer the line, the more space it needs beneath it.

[Read it](https://buk.press/blog/page-margins-and-line-length)

## Write it in Markdown. Ship a book.

bukpress turns the file you are already writing into a typeset PDF and EPUB: your type, your covers, no watermark, ever.

[Get Lifetime, $27 once](https://app.buk.press/signup)