How plain text becomes a book that holds up — page breaks, embedded type, the formats each store wants, and the decisions that separate a designed page from a printed document. Written for people who would rather be writing.
Front matter is everything before chapter one: half title, title page, copyright page, dedication, epigraph, contents, and sometimes a foreword or preface — in that order. Back matter is everything after the last chapter: appendices, notes, glossary, acknowledgements, an about-the-author page, and whatever you want the reader to do next. Neither is decoration; both are conventions readers use without noticing.
A widow is the last line of a paragraph stranded alone at the top of a page. An orphan is the first line of a paragraph left alone at the bottom. Both are bad breaks, and so are a heading at the foot of a page, a split table and a broken code block. Every one of them is fixed the same way: give the typesetter permission to move the break, or edit the text until the break lands somewhere harmless.
Most published chapters run between 1,500 and 5,000 words, with 2,500 to 3,500 the commonest band across fiction and nonfiction alike. But the number is downstream of the decision that matters: a chapter is one complete movement of the book, and it ends when that movement does. Length is what you measure afterwards to check the pacing, not what you aim at while writing.
VS Code is a genuinely good place to write a book, because a manuscript is plain text and VS Code is very good at plain text — Git history, search across chapters, no proprietary format, no cloud dependency. What it will not do is produce the book: its Markdown preview is a web page, and printing a web page gives you a document, not a typeset volume.
Use a single `#` for the book's title, `##` for every chapter and `###` for the sections inside them, and never skip a level. Those three marks are the only structure a Markdown file has, and everything downstream — the running hierarchy on the page, the printed contents, the EPUB's navigation — is read straight off them.
Choose one serif with a generous x-height for the body text, set it at 10.5 to 12 point with about 1.4 line height, and pair it with a single contrasting face for titles. Two families is the ceiling. Check the licence allows embedding before you fall in love with anything.
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.
Use fenced blocks, keep every line under about 80 characters, and let the typesetter hold each block on one page. Monospace type is wider than body type at the same size, so a listing fits fewer characters on a line than prose does — the fix is shorter lines in the source, not smaller type in the PDF.
Use LaTeX if the book has serious mathematics, numbered cross-references or a layout you need to control to the point. Use Markdown for everything else — which is most books — because it reaches a well-set page in a fraction of the time and the file stays readable. Pandoc lets you write in Markdown and borrow LaTeX only where you need it.
For a PDF that will be read on screens and printed at home, A4 is the right default: it is what most of the world's printers hold, and on a screen the page size barely matters. A trim size like 6×9 inches only becomes necessary when the book goes to a print-on-demand service as a bound paperback — and Amazon KDP accepts A4 as a trim size too.
A dark or coloured page is a screen decision, not a print one. It works for a PDF that will be read on a laptop or tablet — a lead magnet, a guide, a portfolio — and it fails on paper, where it costs ink, hides in the gutter and prints as a grey nobody chose. If the book will be printed, keep the page white or a light cream.
Markdown works for poetry only if the renderer keeps a single line break as a line break, because verse is made of lines and standard Markdown joins them. Get that one behaviour, then the rest is convention: a blank line between stanzas, a heading for each title, a page break after each poem, and a PDF rather than an EPUB where the shape of the poem on the page is part of the poem.
A recipe is a heading, a short headnote, a table of ingredients with quantities in their own column, a numbered method and, if you have one, a photo — and a page break after it so the next recipe starts fresh. Markdown has a block for each of those, and a cookbook is just that pattern repeated with the discipline to never vary it.
Keep the handbook as a folder of Markdown files, one per section, under version control, and publish it as a numbered, dated PDF each time it changes — with an EPUB for phones. The wiki can stay for day-to-day reading; the exported book is the thing HR can say a given person received on a given date.
There are five practical routes from a Markdown file to a PDF: printing from a browser or editor preview, a VS Code extension, an online converter, Pandoc with a LaTeX engine, or a hosted typesetting tool. They differ almost entirely in how much control you get over the page — and the page is the whole problem.
Markdown has no page break because it describes structure, not pages — so every method is really an instruction to whatever renders it. The three that work are a raw HTML div with a CSS page-break rule, a LaTeX \newpage command through Pandoc, or a renderer that assigns a meaning to a plain-text marker.
Because original Markdown treats a single newline as a space and only breaks a paragraph on a blank line — a deliberate choice for wrapped plain-text email in 2004. The workarounds are two trailing spaces, a backslash, an HTML break tag, or a renderer that treats one Enter as a real break.
A table that crosses a page loses its header because most Markdown-to-PDF pipelines emit a plain HTML table with no thead, and repeating a header row requires the renderer to know which row is the header. Fix the markup first, then the renderer.
Because the font was referenced rather than embedded. A PDF can either carry a copy of the typeface inside the file or just name it and hope the reader's machine has it — and when it does not, the reader silently substitutes something else, which changes the line breaks and the page count along with the look.
Use PDF when the page is fixed and matters — print, handouts, workbooks, anything with a layout the reader must see as you set it. Use EPUB when the text should adapt to the reader's screen and type size, which is every e-reader and almost every ebook store.
Page numbers are not Markdown — they are a property of the page the file is rendered onto. The working method is to turn them on in the renderer, in the footer, and to suppress them on the cover and any other full-bleed page. Anything that tries to type "12" into the manuscript itself will be in the wrong place the moment the text reflows.
A printed table of contents is a page you write: a list of chapter titles, in order, with a page break before the first chapter. An EPUB does not need that page — its table of contents is generated from the heading structure and lives in the reader's navigation. Get the headings right and both fall out of the same manuscript.
Treat the cover as a separate full-bleed image, sized to the page, placed as page one of the PDF and — for an ebook — as the file's native cover. Do not fake it with a large heading and a JPEG dropped into the first paragraph; that produces a title page with a picture on it, which is a different object and reads as one.
Export the Markdown as a reflowable EPUB with your typefaces packaged in it, add a 1,600 by 2,560 pixel cover, and upload that EPUB to KDP. Amazon converts it to the format the Kindle actually reads. You do not need Calibre, a .mobi file, or Amazon's old .kpf toolchain unless something in the preview is specifically broken.
No, not for most books. You need InDesign — or an equivalent layout application — when the page is a designed object: overlapping elements, wrap-around images, a magazine-style spread. You do not need it to produce a typeset novel, a guide, a workbook or a technical book whose content is the point. Those are a manuscript plus page rules, and a layout canvas is the slow way to apply them.
Use Canva for the cover, for a one-page lead sheet, and for any document that is really a designed poster with a few sisters. Do not use it to typeset a book. Past a couple of dozen pages you are doing frame-by-frame layout with no manuscript underneath, and every edit becomes a layout job.
Write the prose and the listings in the same Markdown file, in fenced code blocks, and typeset them as two different things: body text at a readable measure, code in a real monospace face that is embedded in the PDF, at a size that does not wrap a 72-character line into noise. The structure is chapters as `##`, listings kept short enough to fit on one page, and a command the reader can run without guessing at the elided bits.
You need an ISBN to sell a printed book through most retailers and libraries. You do not need one to sell a PDF from your own website, and you do not need one for a Kindle ebook on Amazon KDP. If you use a free ISBN a platform assigns, that number is tied to that platform — it cannot come with you if you also publish the same edition somewhere else.
Keep chapters as separate files while you write, named so they sort in book order, then concatenate them into one manuscript with a page-break marker between each file. Do this as a last step, not as a working habit — the combined file is what you typeset; the per-chapter files stay the thing you edit.
A series looks like a series when the interior type, sizes, colours, margins and page-numbering, and the cover's layout architecture, are the same file of decisions applied to every book. Save that combination once — as a kit, a template, or a written spec — and start book two by applying it, not by opening book one and approximating.
Most of the gap between an amateur page and a professional one comes down to six things: line length, type size, line spacing, margins, how many typefaces you use, and whether the heading sizes form a clear hierarchy. None of them require taste to get right — they have known good ranges.
Pandoc is the best tool available for documents with citations, cross-references or mathematics, and for any book whose production is automated by a build. It stops being the pragmatic choice when your requirements are visual rather than structural, because every visual change is made by writing LaTeX or a template.
Keep it under about fifteen pages, make the first page deliver something useful on its own, structure it so it can be skimmed in ninety seconds, and produce it properly — a document that looks like a word-processor export undermines the expertise it is meant to demonstrate.
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.
Treat each exercise as a self-contained unit that fits on one page or spread, leave real physical space for answers rather than a thin line, and keep the source in plain text so the workbook can be regenerated whenever the course changes instead of being re-laid-out by hand.
Obsidian's Export to PDF prints the note the way your current theme draws it on screen, which is why the result looks like a screenshot of an app rather than a book. To get a real book you have to decide first whether you are exporting one note or assembling a manuscript — they are different problems with different fixes.
As a working figure, a typical trade paperback runs about 250 to 300 words a page, and a typeset A4 page at 11pt with generous margins runs about 450 to 500. Anything more precise than that requires knowing your type size, line spacing and margins, because those three settings can move the same manuscript by 40 percent.
A screen shows about 96 pixels per inch and print wants 300, so an image needs roughly three times the pixels you see on screen to print sharply. Size images by the width they will occupy on the page — a full-column image on A4 needs about 1,900 pixels across — and choose the format by what the picture is rather than by habit.
KDP is two products behind one dashboard. The Kindle ebook wants a reflowable file — EPUB is the format to give it — plus a cover image around 1,600 by 2,560 pixels. The paperback wants a print-ready PDF built at a specific trim size with margins that widen as the book gets longer, and a separate one-piece cover including the spine.
Export as Markdown & CSV rather than PDF: the PDF export prints Notion's screen styling, while the Markdown export gives you the text in a portable form. Then expect a cleanup pass — hashed filenames, URL-encoded image paths, callouts flattened to blockquotes and databases split off as CSV — before you have a manuscript.
A print-ready PDF has pages at the finished size, every font embedded, images at 300ppi, nothing important within a few millimetres of the trim, and bleed on anything meant to run off the edge. Half of that list also matters for a PDF nobody will ever print, and the other half only exists because paper gets cut.
Make one cover at 1,600 by 2,560 pixels — a 1:1.6 ratio, RGB, saved as a high-quality JPEG under about 5MB — and it will satisfy every major ebook store. A print cover is a separate job entirely, because it is one spread covering back, spine and front at the physical size of the book.
Run EPUBCheck before uploading anywhere: it is the same validator the stores run, and it names the file and line for every problem. Errors block ingestion and must be fixed; most warnings are advisory, with the exception of remote resources and missing accessibility metadata, which some stores treat as fatal.
Write in Google Docs if other people need to comment on the draft while you write it, in Word if an editor or publisher will hand you tracked changes, and in Markdown if the same manuscript has to become several finished formats without being reformatted each time. Most people who finish books use two of the three, in sequence.
A blog archive is raw material, not a manuscript. Choose the third of it that serves one argument, put it in an order a reader can follow rather than the order you wrote it, rewrite every reference to time and place, and add enough new connective material that it reads as a book instead of a folder of posts.