A cookbook in Markdown: ingredients, steps and one recipe per page

A cookbook is read with one hand, standing up, with the other hand in a bowl. That is the design constraint, and it is stricter than a novel's: the reader has to find the recipe, see the whole ingredient list at once, and follow the method without losing their place. Every decision below comes from it.

The recipe as a repeating pattern

Fix the shape of one recipe and use it for all of them. Readers learn the pattern on the first page and then stop reading the layout, which is what you want. A cookbook where some recipes list ingredients before the method and some after is one the reader has to re-learn every few pages.

## Braised leeks with mustard

A side that behaves like a main. Serves 4, takes 40 minutes, most of it unattended.

| Ingredient | Quantity |
| --- | --- |
| Leeks, trimmed | 6 medium |
| Butter | 40 g |
| Dijon mustard | 1 tbsp |
| Stock | 200 ml |

1. Halve the leeks lengthways and rinse the grit out.
2. Melt the butter in a wide pan, lay the leeks cut side down, and colour them.
3. Add the stock and mustard, cover, and cook until soft — about 25 minutes.

---

Heading, headnote, table, list, page break. Five blocks, always in that order.

Ingredients in a table

The instinct is a bulleted list — - 40 g butter — and it works until the reader is scanning for whether they have enough butter. A table puts the quantities in a column of their own, aligned, so the eye runs down the numbers without reading the names. Put the ingredient first and the amount second; that is the order a shopping list is written in.

• One unit system, everywhere. Grams or cups, not both, unless the book is explicitly dual and every row carries both. A third column for the second system is the honest way to do it.
• Order the rows by use, not alphabetically. The first thing in the pan is the first row.
• Preparation goes with the ingredient, in the same cell: "Onion, finely sliced". The method then says "add the onion" and nothing more.
• A long list splits into sub-tables with a ### between them — *For the dough*, *For the filling*. Two short tables are easier to shop from than one long one.

A table with twenty rows can cross a page. When it does, the header row has to repeat on the second page or the reader is looking at a column of numbers with no label. That is a property of the renderer, not something you can write in Markdown; bukpress repeats the header automatically, and it is worth checking that whatever you use does the same before the book has a recipe for cassoulet in it.

The method as a numbered list

A numbered list, one step per item, each step one action. The number is what the reader comes back to after looking away — "I was on four" — so a step that contains three actions has cost them the place three times. If a step is a paragraph, it is two steps.

Times and cues go in the step they belong to, and the cue matters more than the time: "until the edges brown, about 8 minutes" is a step a reader can follow on a different hob. Temperatures go at the point the oven is needed, not in a preamble that was two pages ago when the dough was resting.

One recipe, one page, one photo

Every recipe starts at the top of a fresh page. In Markdown that is a page break after each one — in bukpress a line of three dashes — and it is the single change that turns a document into a cookbook. A recipe that begins two-thirds of the way down a page, after the end of the last one, cannot be found by flipping.

The photo, if there is one, belongs to its recipe and nowhere else. Place the image line directly under the heading or directly after the method, and use the same position for every recipe. The renderer has to hold the image on the page with the text it belongs to rather than floating it to wherever there was room; a photo of the soup on the page after the soup is the fault every self-published cookbook has at least once.

Whichever row you pick, pick it once. And size the images before they go in: a 6 MB photograph per recipe makes a 200-recipe PDF nobody can email. Around 1500 pixels on the long side is sharp on A4 and small enough to send.

Headnotes, scaling and the small print

The headnote is the paragraph between the heading and the table: what the dish is, why it is here, one thing the reader should know before starting. Two or three sentences. It is the most-read prose in any cookbook and the place the author's voice lives, and it is also the first thing to cut when a recipe will not fit on its page.

State the yield in the headnote — *serves 4*, *makes one loaf* — and state it every time, because a reader scaling a recipe needs the number and will not go looking for it. If the book is meant to be scaled, quantities in grams make that possible and cups make it approximate; that is an argument for metric, or for the third column.

The book around the recipes

Chapters are ## headings that are not recipes — *Soups*, *Bread*, *Things for a Tuesday* — each on its own page, with the recipes under them promoted to the same level or demoted to ###; the heading levels are what the ebook's navigation is built from, so a reader on a phone can jump to a chapter and then to a recipe. Write the contents page as a list by chapter, and put the recipe index — every recipe, alphabetically — at the back as a plain list. Page numbers in the footer are what make the index useful; leave them on.

For the page itself: a serif body at 11pt, a sans-serif for headings so a recipe title is visible across a kitchen, and one of the warmer paper textures if the book will be read on a screen. Set that once as a Brand Kit and the second volume matches the first. The EPUB is worth exporting too — a cookbook on a phone in a supermarket is a cookbook that gets used — with the understanding that the one-recipe-per-page rule becomes a suggestion the moment the device decides what a page is.