FORMÆTRIX Publish Architecture
A publishing system that treats a manuscript as structured source, not a Word file — one canonical source compiled to print, EPUB, and web, so a correction made once reaches every edition.
The manuscript was not the product.
Problem
A novel needed to become a paperback and an EPUB. That should have been simple. It wasn't: the manuscript carried multilingual passages, unusual section structures, transcripts, ornamented breaks, metadata dependencies, and typographic rules that did not survive ordinary document conversion.
So it forked. manuscript-final.docx became manuscript-final-KDP.docx became manuscript-FINAL-final.docx. Corrections made during print formatting never reached the EPUB. The proof became a third manuscript. Eventually the book had several technically valid versions and no obvious answer to which one was actually the book.
None of these problems was individually hard. Together they built a system that ran on memory — and memory is exactly what fails across a year of revisions.
Approach
Content has one source; presentation has many outputs. The architecture separates content, structure, metadata, typography, and output instead of embedding all five in one application document. A paragraph is stored as a paragraph; its appearance belongs to the renderer.
- Canonical document model:prose is a tree of semantic nodes (chapter, scene break, epigraph, transcript, footnote, language span), never layout. Each renderer decides presentation, so the text stays identical across editions.
- Edition profiles:a base book is inherited by each edition — paperback, large print, web — which overrides only what changes (trim, type scale, measure, how a chapter number is displayed). A new trim size is a config change, not a manuscript reconstruction.
- Centralized metadata and script-aware fonts:ISBNs, subjects, and dates live once and flow into EPUB metadata, copyright pages, and web tags; fonts are mapped by script through the shared typography layer so multilingual passages render correctly rather than falling back silently.
- Validate before build, version like code:the publication is checked (chapters, unique IDs, resolved footnotes, font coverage) before generation, and because the source is text it lives in Git with history, branching, and tagged editions. A book becomes reproducible.
Demo
One canonical source, rendered live: the semantic node tree, a print interior whose edition profile changes trim and type, the EPUB semantic mapping, and the build validator with its receipt. Switch editions and the same nodes regenerate. (Print output targets a LuaLaTeX pipeline; the demo renders the model and validation in the browser.)
Technical Detail
The prose is stored as semantic nodes — a chapter is a chapter, a scene break is a scene break, a foreign-language span declares its language — with no layout instructions embedded. The renderer decides whether chapter seven reads as CHAPTER SEVEN, as VII, or as nothing at all; the content layer does not care.
Separate renderers interpret the one source: print through a LuaLaTeX pipeline for press-ready PDF, EPUB through accessible semantic HTML, web through an excerpt view. Metadata lives once and flows into every output; fonts are mapped by script (the Polytype layer underneath), so a Hebrew passage never silently drops to a fallback glyph.
Before anything builds, the publication is validated — chapters detected, IDs unique, footnote references resolved, font coverage complete. The pipeline can fail loudly instead of shipping a subtly broken book.
A book should not require its author to remember where all of its copies are lying.
Outcome
A publication pipeline that behaves like software compilation. A typo corrected once disappears everywhere; a new trim size is configuration, not reconstruction; a Hebrew passage keeps its font; a new edition inherits the same source and overrides only what differs. The book becomes reproducible — and the expensive, invisible divergences between editions stop happening.
- 1canonical source; print, EPUB, and web are outputs
- 0manuscripts to keep in sync — a correction made once reaches every edition
- 5layers kept apart: content, structure, metadata, typography, output
- Build validation fails loudly before generating a broken book
- Edition profiles inherit a base and override only what changes
- Text-based source → Git history, branching, tagged editions