Writing a poetry collection in Markdown

Poets are told Markdown is for programmers. It is not — it is for anyone whose text should outlive the software it was written in — but the advice comes from somewhere real. The first thing standard Markdown does to a poem is destroy it.

The line-break problem, and why it is the whole problem

In CommonMark a single newline is a space. Two lines of verse become one line of prose. The three lines of a haiku become a sentence. This is not a bug; it was designed for paragraphs of web text, where a hard-wrapped source file should render as flowing prose. For a poem it is exactly wrong.

The workarounds all cost something. Two trailing spaces at the end of every line are invisible, get stripped by editors, and make every poem a trap. A backslash at the end of each line is visible and ugly and turns the manuscript into something you would not want to read in the editor. Raw <br> tags make it HTML.

The workable answer is a renderer that treats one Enter as one line break. bukpress does this — a single newline in the source is a real line break in the PDF and the EPUB — which means a poem is typed the way it is read, and nothing is added to the file to make it survive. If you are using a different tool, find out how it handles a single newline before you write a second poem.

## Harbour, February

The boats are in.
Nothing moves but the light on the water
and a gull, reconsidering.

Somewhere a door.
Somewhere the sound of a door.

Stanzas, titles and the outline

With line breaks solved, the conventions are simple and worth keeping to, because the ebook's navigation and the contents page are built from them.

• A blank line between stanzas. That is a paragraph break, and the stanza gap comes from the paragraph spacing in the typography settings — so every stanza gap in the book is the same size, without you measuring one.
• Every poem's title is a `##` heading. One level, used for every poem, so the outline is a flat list of titles: the contents page in one place and the Kindle's jump-to menu in the other.
• Sections of the collection, if it has them, are `##` too, each on its own page, with the poems that follow demoted to ###. Pick one scheme and hold to it; a collection with sections and one without should not be mixed.
• An untitled poem gets a heading anyway — its first line, or a number. A poem with no heading has no entry in the contents and no place in the ebook's navigation, and a reader cannot find it.

One poem to a page

Most collections put each poem on its own page, and a short poem sits in the upper part of the page with white space beneath. That white space is not waste. It is the frame. A renderer that flows the next poem straight in under the last one has produced a document, not a collection.

In Markdown the instruction is a page break after each poem. With bukpress that is three dashes on their own line — a hard page break rather than a horizontal rule — so the manuscript reads as poem, ---, poem, ---, and each heading starts at the top of a fresh page. Four dashes prints a small ornamental divider instead, which is what you want between the parts of a long poem that share a page.

Long lines and indentation

A line of verse that is longer than the measure wraps, and a wrapped line is a lie about the poem's shape. Two things control it. The measure itself — the text width the margins leave — and the type size. A collection with long lines wants a slightly smaller face or narrower margins than a novel would, and a landscape orientation is not available in a book, so the tradeoff has to be made on the page you have. Print a page with your longest line on it before you decide anything else.

Indented lines — the stepped lines of a Williams poem, a dropped half-line — are the hardest thing to do in any plain-text format, because leading spaces are what Markdown uses to mean *code*. Four spaces at the start of a line and the renderer sets it in monospace. The options are narrow: a few non-breaking spaces at the start of the line, which survive but are invisible in the file, or accepting that the collection is left-aligned and revising the poems that depend on the step. Concrete poetry, where the layout *is* the poem, is not a Markdown project; that is a layout application or a hand-set page.

PDF or EPUB for verse?

For verse the PDF is the edition of record. A poem is partly a shape, and only a fixed page keeps the shape. The EPUB is the edition that reaches a Kindle, and it is worth making, with the understanding that a long line will wrap on a small screen and there is nothing any tool can do about that — the reader chose the screen. Short-lined collections survive reflow well. Long-lined ones should be sold as PDF first and EPUB with a note. The general case is that you want both; for poetry the PDF is the one to proof.

Contents, page numbers, and the rest of the book

A poetry collection is more front matter than most books: a dedication, sometimes an epigraph, a contents page that lists every poem, acknowledgements naming the magazines that first published some of them. Each is a ## heading followed by a page break, in the order a printed collection puts them, so they sit in the outline with everything else.

Write the contents page by hand as a list of titles, and leave the page numbers out of it unless the book is final; a contents with numbers is a snapshot that the next edit makes wrong. Page numbers on the pages themselves are a footer setting — in bukpress a single switch — and a collection wants them, because "page 41" is how a poem is cited at a reading.

For the type, a serif with a real italic at 11pt, line height a little looser than prose, and margins wider than you think — the six decisions that hold for any book hold for this one, with the extra rule that the poem, not the page, sets the measure. Set it once, save it, and every collection after this one starts from the same page.