One manuscript, from print PDF to braille
GLIO
Summary
I didn't hand typesetting to the AI. It judges structure only; deterministic code draws the page, where one changed character ruins the book. One manuscript produces print PDF, EPUB, an accessible PDF and braille.
- 1.76×
- 5 → 7
- 96
Overview
One manuscript goes in; print PDF, EPUB3, large print, an accessible PDF and braille come out. It is built in four parts.
- Engine – Python and FastAPI; HarfBuzz shaping, its own line breaking, Korean typesetting rules as data.
- Studio – a single-file web UI with no dependencies.
- macOS app – SwiftUI, calling the engine as a local process instead of over HTTP, so manuscripts and fonts stay on the machine.
- MCP server – exposes tools to AI clients for analysing artwork, creating specs, preflight, proof rendering, quotes and order requests. It never executes payment; it returns an approval link.
Nothing has shipped yet. Accessibility remediation goes out first; typesetting follows.
Problem
Making one book means print typesetting, EPUB, large print and braille each re-interpret the manuscript separately, and proofing repeats each time. Korean typesetting has no standard implementation like Japanese JIS X 4051. Accessible formats are now an obligation: the European Accessibility Act (June 2025) and Korea's Digital Inclusion Act (January 2026) are in force.
Key decisions
The AI decides; deterministic code typesets
In a book, one changed character makes it unusable.
The model outputs only decisions, as JSON; the engine draws the text. A test stops the engine from importing the LLM module.
Build the engine, export IDML
A commercial typesetting server costs heavily in licences and puts Korean typesetting on someone else's platform.
An engine of HarfBuzz, its own line breaker (Knuth–Plass) and Korean line-break rules kept as data – with IDML export so designers can carry on in InDesign.
The first product is accessibility remediation, not typesetting
Pass and fail are objective, the standards are documented, and a working prototype already existed.
Accessibility checks, auto-fix and alt-text approval ship first; typesetting follows.
Zero paid APIs; fonts never leave the machine
Commercial Korean fonts aren't licensed for use on a server.
AI runs in three tiers – rule engine, local model, the user's own subscription AI via MCP – and the macOS app processes manuscripts and fonts on the device.
Two more decisions
- People pick a role, not coordinates – per-paragraph overrides lead to the "one heading in forty looks different" accident. Users choose a block's role only; millimetres and positions are the engine's job.
- When unsure, body text – fail toward the less harmful – a wrongly structured manuscript makes every format wrong together. Import reads the author's Word styles first, then layout heuristics, and only then, optionally, an LLM. Anything uncertain stays body text.
Process
Tested against a real book – the MMCA Guide to Publication
The benchmark is a real book made by designers. The National Museum of Modern and Contemporary Art, Korea's Guide to Publication, 2nd edition (2020), exists both as its manuscript (docx) and as the printed book, so the same manuscript can be run through GLIO and set beside the real thing. Over 15–16 August, this one book produced 114 result files as the engine was fixed.
Opening the book…
- 125×220mm, matched
- 300 / 263
- 114
- Trim size matched – the first run came out at 161×256mm; iterations brought it to the real book's 125×220mm.
- Page count differs – 300 pages in the real book, 263 from GLIO. The same text set tighter; matching the book's leading and margins is the next step.
- Typefaces differ – the book uses commercial faces (Janson, AG Choijeongho, Akzidenz); GLIO uses OFL faces licensed for servers (EB Garamond, Noto Serif KR).
Testing archive
Five books whose manuscript and printed edition both survive went in, and each ran until the output came close to the printed thing. Between the evening of 14 August and midnight on the 16th, 483 result PDFs piled up. Every run produced three tracks at once: print, spread and reading path.
| Publication | Manuscript | Result files (output) | Printed (measured) | GLIO (measured) | First result → last (measured) |
|---|---|---|---|---|---|
| MMCA Guide to Publication, 1st ed. (2018) | docx | 144 | 300pp | 265pp | 220 → 265pp |
| MMCA Guide to Publication, 2nd ed. (2020) | docx | 114 | 300pp | 263pp | 219 → 263pp |
| MMCA Collection Description Guide (2023) | docx | 111 | 88pp | 61pp | 36 → 61pp |
| This is Hanseongbu (exhibition catalogue) | docx + plate list xlsx | 59 | 176pp | 288pp | 289 → 288pp |
| SeMA Collection Description Guide | docx + plate list xlsx | 55 | 52pp | 60pp | 47 → 60pp |
A page count that grew is not a failure. The first results were dropping footnotes and plate positions altogether. Across the runs, 87 footnotes, 207 plate markers and the glossary copy found their places, and the pages grew with them.

All five are pages taken straight out of the final PDFs GLIO produced. Nothing was edited or redrawn. In This is Hanseongbu, Korean, English and Japanese sit on one spread.
What broke
Every manuscript broke the engine somewhere. The order in which they were fixed is the record.
- Korean vanished silently from RTF – no error, just missing characters. The encoding path was rebuilt.
- A PDF manuscript sent it into an endless load – it now reads page by page, with a browser regression test attached.
- A whole HWP manuscript became headings – the outline paragraph style was unreadable, so body text was promoted to chapter titles.
- The first chapter title became the book title – in the MMCA manuscript, "Part 1: On Art Publishing" was printed on the cover, the half title and the colophon, and the author was Word's "Un-named". The manuscript head is now separated from the body, and what it says beats the file's properties.
- Adding plates killed the grid settings – full re-typesetting was replaced by partial updates.
- A slow preview broke the loop – it was made 11× faster (measured) and told to say when it is working.
Not run yet
Three art-magazine manuscripts and the Forbes material were left out. A magazine flows differently from a book: columns change within one page, and pictures wrap the text. The engine cannot place that yet.
Results
- 1.76×
- 659 → 508MB
- 0 of 57
On the accessibility checks, passes went from 5 of 9 PDF/UA items to 7, measured on the same file before and after auto-fix. The two that remain are alt text, which a person writes. Typesetting is 1.76× faster, with none of the same manuscript's 20,413 lines changed. Nothing has shipped. Everything so far was validated on manuscripts I chose myself, not on a customer's book.
Where a person steps in
- By itself – one manuscript becomes print PDF, EPUB3, large print, an accessible PDF and braille. Typesetting is checked by rules before any eye sees it.
- By hand – what rules cannot catch – a picture's description, the reading order of a table, how a name is written – an editor fixes. The tool carries the draft as far as it can and leaves the judgement.
Reflection
What held up
- The AI decides; code draws. After the rewrite that made typesetting 1.76× faster, 0 of the output's 20,413 lines had changed. The test that stops the engine from importing the LLM module is what kept that line.
- Licensing is design too. No AGPL or GPL libraries, OFL fonts only. A good tool you can't distribute is a tool you can't use.
- Choosing accessibility as the first product. Pass and fail are written down, so every run pointed at the next thing to fix. Typesetting quality is not judged that way.
What failed
- I assumed that matching trim size and structure would bring the page close to the real book. The trim size matched; the page count stayed 300 against 263. Density turned out to be a separate problem.
- I assumed one engine would cover plate-heavy catalogues too. This is Hanseongbu is 176 printed pages against GLIO's 288. A book where text flows and a book where plates hold positions follow different rules.
- I trusted the Word file's properties. The author came out as "Un-named" and a part title became the book title. Now what the manuscript says beats the file.
- I assumed reading a manuscript's formatting would reveal its structure. In an HWP manuscript, all the body text was promoted to chapter titles. The rule "when unsure, body text" comes from that run.
What I would test next
- Whether leading and margins can match the real book's density. The same manuscript still sets tighter.
- Plate-heavy catalogues, and magazine manuscripts – columns changing within a page, pictures wrapping text.
- How far a designer can actually carry the IDML export inside InDesign.
- A real customer's book. All five test books were ones I picked.