What software do publishers use for books? Three chains

Book publishers run three separate toolchains, not one program: a manuscript chain built on a word processor with tracked changes, a production chain built on page-layout or markup-based typesetting that emits print-ready PDF and EPUB, and a metadata chain built on a title-management system that emits ONIX records to distributors and retailers. The applications people usually mean when they ask "what software do publishers use for books?" — InDesign, Vellum, Atticus, Scrivener, Affinity Publisher, Scribus — all live inside the second chain.

That is why the answers you find contradict each other. Someone describing a production workflow and someone describing a drafting workflow are answering different questions, and neither one mentions the chain that decides whether your book shows up correctly in a retailer's catalogue.

The narrower question is the useful one: which artifact are you responsible for producing, and who touches the file immediately before and after you? Answer that and the shortlist drops to two or three candidates.

The three chains and the artifact each one owes

A one-person press collapses all three into a single folder, and that holds up fine for a first title. It stops holding when a correction arrives after the ebook has already gone live, because now the same fix has to be applied in two places by the same tired person on the same evening.

The manuscript chain: the file always leaves the tool it was written in

Drafting tools compete on how pleasant they are to write in. Interchange formats compete on nothing at all, which is why DOCX with tracked changes ends up carrying manuscripts between authors, editors, and typesetters: the change history survives the trip. Scrivener, Ulysses, Dabble, Google Docs, and plain Markdown are all reasonable places to write. None of them is where the book gets set.

The constraint sits on the export, not on the draft. If your tool cannot emit a file where every chapter opener carries a named paragraph style rather than manual bold-and-centre, someone downstream pays for it.

That cost is measurable in a way most tool round-ups skip. A typesetter importing a manuscript with 40 styled headings maps them in a single pass, because the style name is the instruction. The same manuscript with 40 hand-formatted headings has to be found by eye, page by page, and the ones that were centred but not bolded get missed. Style discipline in the manuscript chain is not tidiness — it is the interface contract with production.

If you are negotiating a workflow with an editor or a freelance typesetter, ask one question before comparing anything else: which file formats do your tracked changes survive in? That answer decides the manuscript tool faster than any feature list.

The production chain: pick by your hardest output, not the longest feature list

Three shapes of book pull toward three different categories of software.

Linear prose with few images and many rebuilds — novels, memoir, most business and self-help titles. Style-driven book formatters (Vellum, Atticus) fit here. You accept their templates and their typographic decisions; in exchange, a text change and a fresh PDF plus EPUB are minutes apart.

Fixed grid where image placement is part of the product — illustrated non-fiction, children's books, cookbooks, textbooks, art titles. Page-layout applications fit here: Adobe InDesign, Affinity Publisher, Scribus. The design is the thing being sold, so the tool has to let a designer place every element deliberately.

Equation-heavy, template-driven, or reused across editions — academic, scientific, technical, and reference publishing. Markup-first workflows fit here: LaTeX, or XML in DocBook, JATS, or BITS, rendered to PDF and EPUB by a build script. Setup is slower and the rebuild is a command.

The tell is how often the book gets rebuilt. A novel that is typeset once and reprinted unchanged rewards the tool that is fastest the first time. A textbook on a two-year revision cycle rewards the tool where a rebuild is a command rather than an afternoon.

Before committing a title, check three things in the vendor's current documentation rather than in a review: which operating systems the current release supports, which interchange formats it imports and exports, and whether the EPUB it produces validates cleanly. All three change between versions, and a round-up written eighteen months ago will not tell you.

The exit test: can you get the book back out?

Five checks, all answerable in an afternoon with a trial file:

1. Is the source a format you can open in something else — DOCX, IDML or ICML, `.tex`, XML — or only an opaque project bundle?
2. Does the exported EPUB pass EPUBCheck with zero errors, not just "no warnings that look serious"?
3. Does the PDF match the PDF/X variant your printer actually asked for?
4. Do your font licences permit embedding for every output you produce?
5. Can you reproduce last year's build after the application updates itself?

A tool that exports finished artifacts but never its own source is a rental. For a single title that is a fair trade. For a backlist you intend to keep selling, it is the decision you will regret in year three, when the thing you need is a corrected reprint of a book whose source only opens in a version you no longer have.

Count conversions, not tools

The number that predicts where your errata will come from is not how many applications you own. It is how many times the text crosses a format boundary, and how many finished outputs are generated from the same copy of the text.

Watch the third column. Every output generated from a different copy of the text is an edition that can quietly disagree with the others. A late change on page 212 — a name spelling, a permissions deletion, a corrected figure — has to be applied once per divergent copy. The ebook is the copy that gets re-proofed least, because it has no print deadline forcing a final read-through.

The operating rule: every conversion boundary needs one named owner and one check that runs immediately after it. If you cannot say who owns a boundary, that boundary is where your next correction slip comes from.

The chain the tool round-ups leave out: ONIX, ISBN, subject codes

Publishers describe books to the trade in ONIX for Books, an XML message standard maintained by EDItEUR. A title record carries the ISBN-13, contributor details, subject codes (BISAC in North America, Thema for international use), format and extent, prices per market, on-sale and availability dates, and marketing copy. Retailers and wholesalers ingest that record; almost everything a shopper sees on a product page came from it.

This is software work, and it is the reason "publishing software" inside a house often means a title-management system rather than a layout application. Systems in this category include Klopotek, Firebrand Title Management, and Virtusales Biblio. Evaluate them against what your distributor requires, not against a feature grid — ask which ONIX version and which subject scheme they accept before you choose anything, because receivers differ and the answer determines whether a simpler setup is viable at all.

A spreadsheet is a legitimate title-management system right up until one of these becomes true:

• The same field — subtitle, price, on-sale date — is maintained in two places.
• You publish into more than one territory with different prices or dates.
• More than one person edits the same record in the same week.

Any one of the three and you have a synchronisation problem rather than a formatting problem. No layout tool solves it, and the symptom arrives as a customer email asking why the description on your site promises a chapter the book does not contain.

A per-title time model to fill in with your own numbers

The figures below are placeholders for structuring an estimate, not measurements. Replace every cell with your own timings from your last three titles. Assume a 320-page prose title and four rebuilds: first pages, revised pages, ARC, and one post-publication correction.

The first build is the number people compare. The rebuild is the number that determines the year.

That gives a decision rule you can apply without any vendor comparison: if your realistic rebuild count is one per title, the first-build row decides and the fastest setup wins. At four or more rebuilds per title, the rebuild row dominates, and a tool that is slower to configure but scripted to regenerate everything is the one that pays. Count the rebuilds you actually performed on your last three books, not the number you planned.

Free and open source: where the free route stops

The free chain exists end to end. LibreOffice Writer for manuscript, Scribus for layout, Sigil for direct EPUB editing, Calibre for library and conversion work, Pandoc for moving between formats, EPUBCheck for validation.

It stops in three predictable places. Tracked-change fidelity degrades when a DOCX moves between different word processors, so a copyeditor on a different application may hand back a file where some revisions have flattened. Advanced OpenType features — true small caps, old-style figures, optical margin alignment — are uneven, which matters for a designed book and not at all for a paperback novel. And retailer-specific EPUB quirks tend to surface as rejected uploads rather than as documentation.

None of those is a reason to avoid the free route. They are the three things to test with a real file before you commit a title to it.

Ten checks before you commit a title to any tool

1. Can you export a file where every heading carries a named style?
2. Does the EPUB validate with zero EPUBCheck errors?
3. Does the PDF match the PDF/X variant your printer specifies?
4. Can two people work on the file without emailing versions back and forth?
5. Do tracked changes survive the exact round trip your copyeditor uses?
6. Can you rebuild both PDF and EPUB from one source after a one-word change?
7. Do your font licences permit embedding for the outputs you ship?
8. Does the metadata record come from the same place as the cover and the website copy?
9. Can you reproduce last year's build after the application updates?
10. If the vendor stopped operating tomorrow, what do you still own?

Items 2, 6, and 10 are disqualifiers. A tool can fail four of the others and still suit a small list; fail any of those three and you have bought a problem that arrives around month nine, usually in the form of a correction you cannot cleanly apply.

The same split, one industry over

Book production and web publishing hit an identical structural problem from opposite directions: the tool that renders the artifact is not the tool that decides the artifact is ready. In book production the split is obvious, because nothing about a layout application tells you whether permissions cleared for chapter nine. On the web it hides, because the CMS both stores the post and publishes it, so the decision to publish becomes a side effect of pressing a button.

Making that separation explicit is the same design move in both places — see publishing control plane software for how the state machine and gates work when the rendering layer is a website rather than a printer. The evaluation habit transfers too: judge the system by where the work actually stops rather than by the feature list, and treat approvals and handoffs as a named stage, which is the argument in editorial workflow software.

Questions that come up

What software do most authors use to write books?

There is no census worth quoting, and drafting is the least consequential choice in the chain. Whatever you write in has to leave as a styled file that survives editing, so judge your drafting tool on its export rather than on its writing mode.

Does it matter which software a well-known novelist uses?

Not for your decision. A novelist's drafting tool solves the problem of getting words onto a page, which has nothing to do with your production constraints — page count, image density, rebuild frequency, or what your printer will accept. Interviews are the only reliable source for that trivia, and the answer would not transfer.

Do I need a page-layout application for a novel?

Only if the design is doing work. Linear prose with a handful of images sets well in a style-driven formatter, and the trade-off you accept is template constraints. Move to a layout application when you need control the templates do not offer, and expect the rebuild time to go up in exchange.

What is ONIX, and do I need one?

If your book sells through a distributor or retailer, an ONIX record exists for it — the question is who produces it. Ask your distributor whether they generate it from data you supply or expect a feed from you. That single answer determines whether the metadata chain is your software problem or theirs.

Where this framework does not fit

Design-led books break it. When the layout *is* the product — art, photography, heavily illustrated children's titles — portability is secondary and the tool choice belongs to the designer. Ask them what they can hand your printer and build backwards from that file.

One-off projects break it too. If you do not expect to rebuild the title, the rebuild arithmetic is irrelevant and the fastest route to one clean PDF is the correct route, template constraints included.

And audio is a different chain entirely: recording, editing, mastering, and a separate metadata spec. None of the three chains above describes it, which is worth knowing before someone offers you a "complete publishing platform" that quietly means print and ebook only.