---
title: Can Book Typesetting Be One Click? — Put in a manuscript and photos, press one button, and get an EPUB and a print PDF: a book bound from “A Lucky Day”
url: https://oosioo.com/en/p/%EC%B1%85-%EC%A1%B0%ED%8C%90%EB%8F%84-%EB%94%B8%EA%B9%8D%EC%9D%B4-%EB%90%A0%EA%B9%8C
date: 2026-10-21T09:11:33+00:00
author: SYSOP
summary: Writing with AI is now normal, but typesetting that writing into a book still means learning InDesign or LaTeX. I built “Bind a Book”, a typesetting tool that runs in the browser: put in a manuscript and photos, press one button, and it divides the pages, places the pictures, builds the contents and index, and exports an EPUB and a print PDF. I bound Hyun Jin-geon's “A Lucky Day” (1924) with six photos of 1910s–20s Seoul into a 26-page sinkukpan book, and the EPUB passed the official checker EPUBCheck with 0 errors. I also added a story bible to catch continuity breaks in characters and settings, and it found where two AI-written sequels departed from the original.
---
# Can Book Typesetting Be One Click? — Put in a manuscript and photos, press one button, and get an EPUB and a print PDF: a book bound from “A Lucky Day”

![The “Bind a Book” screen. Across the top are the “Bind the book”, “Download EPUB” and “Print PDF” buttons, and on the right it reads “28 pages · 6 pictures · 64 ms · 0 to fix / 1 to check”. The spread shows pages 8–9 of 28. On the left page (8), a black-and-white photo of a gentleman seated in a rickshaw with the rickshaw puller runs all the way to the trim edge. On the right page (9), a 1928 view of Keijo (Seoul) from Namsan takes the page on its own](/uploads/f21128b0ca41e943.webp)

These days we don't write alone. Some people write an essay in conversation with an AI. Others write down a novel's characters and settings ahead of time and hand that to an AI so the story doesn't contradict itself. Writing has clearly become easier.

But **turning that writing into a book** hasn't changed. You set the text on pages, decide where a photo goes when it lands at the bottom of a page, make chapters start on a right-hand page, and fill in page numbers in the table of contents. Publishers call this **typesetting**, and it's done by people who know InDesign. Academics learn LaTeX or Overleaf. Novelists organize their manuscripts in Scrivener and then move them into yet another program. Books with lots of photos are harder still. Put one photo in the wrong place and the next few dozen pages all shift.

So this time I built a tool that does it in one click. You put in a manuscript and photos, press a button, and a book comes out. It also exports that book straight away as an e-book (EPUB) and as a PDF you can send to a printer.

## What I set out to do

1. Briefly trace how book-making tools have changed: typesetting programs, e-book standards, and the setting-storage features of AI writing tools.
2. Work out why typesetting is hard, and which parts of it can be handed to a program.
3. Build “Bind a Book”, a typesetting tool that runs in a single browser tab. No server, no install.
4. Take one Korean short story whose copyright has expired, mix in photos, and actually bind a book. The story I picked is Hyun Jin-geon's “A Lucky Day” (Unsu joeun nal).
5. Run the resulting EPUB through the official checker, and see whether the PDF meets print-on-demand (POD) specs.
6. Test whether a story bible really works as a “safety net”, using sequels written by AI.

I left the research to AI agents. They could cite only official documents, papers, laws and company announcements, and any year they couldn't confirm stayed marked as unconfirmed.

## 46 years of book-making tools

![Timeline of 46 years of book-making tools. Typesetting programs (gray): 1978 TeX (Knuth), 1981 Knuth–Plass line-breaking paper, 1985 LaTeX 2.09 and PageMaker, 1989 Hangul (HWP) 1.0, 1999 InDesign 1.0. Writing tools and web typesetting (blue): 2006 Pandoc, 2007 Scrivener 1.0 and EPUB 2, 2013 Vellum, 2014 Overleaf beta, 2018 Paged.js. E-book standards (green): 2011 EPUB 3.0, 2023 Typst and EPUB 3.3 W3C Recommendation. AI setting features (orange): 2021 NovelAI service (Lorebook), 2024 Sudowrite Story Bible 2](/uploads/e89de03be8cea9c6.webp)

**Typesetting software was born from disappointment with page proofs.** In 1977 Donald Knuth got the proofs for the second edition of his own *The Art of Computer Programming*. He was disappointed with the quality and decided to write a typesetting program himself. That became TeX in 1978. The 1981 line-breaking paper by Knuth and Plass doesn't fill a paragraph one line at a time. It **looks at the whole paragraph at once** and finds the most even set of line breaks. It is still treated as the benchmark for good typesetting. In 1985 Lamport built LaTeX 2.09 on top of TeX, and it became the standard for people writing papers.

The same year, PageMaker came out and the term “desktop publishing” was born. InDesign followed in 1999. In Korea, Hangul (HWP) arrived in 1989 and became many people's first tool for laying out documents.

**After 2000, the tools for writing and the tools for typesetting split apart.** In 2006 Pandoc converted a single Markdown manuscript into many formats. In 2007 Scrivener became the writer's tool for drafting a long work in pieces and putting it back together. The e-book standard EPUB 2 appeared the same year. With EPUB 3.0 in 2011 and EPUB 3.3 becoming a W3C Recommendation in 2023, an e-book became, in effect, “web pages bound in the shape of a book”. After that came novelist-oriented typesetting apps like Vellum (2013), web LaTeX like Overleaf (beta in 2014), Paged.js (2018), which lays out print pages with browser CSS, and a new typesetting language, Typst (2023).

**AI writing tools are converging on “setting storage”.** NovelAI's Lorebook quietly passes a character's settings to the AI whenever a key such as that character's name shows up in the text. Novelcrafter's Codex registers aliases for each character, tracks where they appear in the manuscript, and lets you decide whether each entry goes to the AI “always / only when mentioned / never”. In 2024 Sudowrite's Story Bible 2 lifted the limit on the number of characters and added a feature that passes along only the relevant settings (per the company). All three share the same idea. **Keep the settings outside the manuscript, and slip the AI only what the current scene needs.** It is a device against “continuity breaks” in long works, where a character suddenly ages or a house changes shape.

But this story bible usually stops at the **writing stage**. I found it hard to find a tool that checks the whole manuscript against the bible once more at the binding stage. So I gave that job to this tool as well.

## Where typesetting gets hard

Setting text on pages involves more decisions than you'd think.

- **Where to cut a paragraph at the bottom of a page.** Cut anywhere and you may leave a single line at the bottom of a page (an orphan), or push a single line to the top of the next page. Books avoid both.
- **Where to send a photo that doesn't fit.** If a photo is larger than the space left on a page, it gets pushed to the top of the next page, and the gap is filled with the text that comes after the photo. LaTeX calls this a “float”. Doing it by hand means every photo you add shifts all the pages after it.
- **Where Korean breaks lines.** The W3C's Requirements for Hangul Text Layout and Typography (klreq) describe two ways to break Korean lines: by character and by word. Books usually break by word and justify both edges. There are also line-breaking rules that keep an opening bracket off the end of a line and a period or closing bracket off the start of one.
- **Printers want a specific shape.** The trim size (the book's dimensions), 3 mm of bleed on every side when a photo runs to the edge of the paper, and a spine width that depends on page count.
- **A book has pages besides the body.** Half title, title page, copyright page, table of contents, index. You only know the page numbers for the contents and the index after all the pages have been divided.

The first four of these can be written as rules. The only thing a person chooses is “what kind of book should this look like”. So the tool comes with **three presets** (Classic, Photo essay, Paper/textbook), and picking one changes the trim size, typeface, margins, leading and picture sizes all at once.

## What I built: “Bind a Book”

![What “Bind a Book” does. The top row is the four things a person puts in. ① Manuscript (one line is one paragraph, # chapter, ## subheading, *** scene break, a picture line), ② Pictures (drag them in and they link to the manuscript by name; "page" takes a whole page, "full" runs past the trim line), ③ Story bible (@person name | aka | age | not: words that must not be used), ④ Preset (Classic, Photo essay, Paper/textbook). The bottom row is ⑤ Paging (cutting paragraphs, deferring pictures, front and back matter) and ⑥ Preflight → export (picture resolution, mixed punctuation, checking against the story bible, spine width → EPUB 3 and print PDF). At the very bottom: “Edit the manuscript or bible and press again. Nothing leaves for a server; only the fonts come from a CDN”](/uploads/061b649c14d65274.webp)

It's a single HTML file. Open it in a browser and it runs. The manuscript and photos never leave the browser. Only the fonts (Noto Serif KR, Nanum Myeongjo, Gowun Batang, Noto Sans KR) are fetched from a public CDN.

**The manuscript is a trimmed-down Markdown.** One line is one paragraph, `#` is a chapter, `##` is a subheading, `***` is a scene break, and `![caption]` followed by a file name in parentheses is a picture. Add `"page"` after a picture and it takes a whole page. Add `"bleed"` and it fills the page out past the trim line. (The Korean edition of the tool uses the Korean words `"쪽"` and `"전면"`.)

**Paging is done by having the browser actually draw the text.** The tool builds a text box in millimeters for a sinkukpan page (152×225 mm, the most common Korean trade size) and drops paragraphs in one at a time. If one overflows, it does a binary search over that paragraph's words to find how many fit on this page. If only one line fits, the whole paragraph moves to the next page. If only one line would carry over to the next page, it carries one more line over with it. The last line of the first part of a split paragraph is justified, and the first line of the second part isn't indented.

**Pictures get deferred.** If there's no room on a page, a picture goes to the top of the next page, and the text after the picture fills the space in between. Order is kept. If two pictures are waiting, the second comes after the first. A “page” picture takes the next empty page whole.

**Front and back matter are computed twice.** The half title, title page, copyright page and contents are set first. Then the body is paged, and the page where each chapter starts is filled into the contents. Chapters start on a right-hand (odd) page, and if the previous part ends on an odd page, a blank page is inserted. Entries in the story bible become the index at the back of the book, with the pages where each entry appears added automatically. Finally, the total page count is padded to a multiple of 2, 4 or 16 pages, whichever you choose.

**The EPUB is built separately from the same manuscript.** A printed book has fixed pages, but an e-book reflows to fit the screen. So the EPUB holds the manuscript as it was before paging, as one XHTML file per chapter, with a table of contents (nav), cover, copyright page and index, all packaged as EPUB 3. I added one more thing. At every spot where the printed book turns a page, I planted a marker that says “page 12 starts here” (`epub:type="pagebreak"`). If the page turns mid-paragraph, the marker goes in at that exact character. This lets someone teaching from the printed book and someone holding the e-book open to the same page. Accessibility metadata calls this `printPageNumbers`.

**The print PDF comes from the browser's print function.** The pages drawn on screen are printed as they are, at the `@page` size. Choose “3 mm bleed” and every page grows 3 mm on each side, with full-bleed photos spreading past the edge. Choose “crop marks” too, and the four corners show where to cut.

## Example: “A Lucky Day”

The sample manuscript is Hyun Jin-geon's “A Lucky Day”. It was published in June 1924 in issue 48 of *Gaebyeok*. Hyun Jin-geon died in 1943, and under the copyright law of the time (enacted in 1957, life plus 30 years) protection ended in the 1970s. The 1987 revision lengthened the term but did not revive rights that had already expired, so the story is now in the public domain. I used the modern-spelling text on Wikisource as is, with two changes. I replaced the wiki text's scene-break markers with `***`, and I changed the `<…>` that enclose Kim Cheomji's inner speech to `〈…〉` so they wouldn't be read as HTML tags. For the English edition of the book, an AI agent translated this text into English line by line.

To test a photo-heavy book, I added six photos of Seoul from the 1910s and 1920s. All of them are in the public domain on Wikimedia Commons. A gentleman seated in a rickshaw with the rickshaw puller (US Library of Congress), a 1928 view of Keijo (Seoul) from Namsan (Seoul History Archive), a postcard of Namdaemun and the streetcar tracks (New York Public Library), a streetcar and a shoe market in Seoul (Library of Congress), and Geumcheonggyo Bridge in the 1920s (from *Keijo-fu shi*, the history of Keijo). None of them shows a scene from the story. I never found a public-domain photo of a rainy 1920s Keijo street. So the copyright page says these are records of the city's streets from around that time.

**The Korean edition came to 26 pages in sinkukpan** (the English edition, on a US trade 6×9 in trim, to 28). After the half title, title page, copyright page and contents, the story starts on page 7. On page 8 the rickshaw photo runs to the trim line, and on page 9 the Namsan photo takes a full page. The story ends on page 21. Page 22 is left blank so the next chapter starts on a right-hand page, the afterword comes on page 23, the index on page 25, and one blank page is added at the end to pad to a multiple of 2. Paging took **94 ms** in a laptop browser.

![The Preflight tab of “Bind a Book” and the page 12–13 spread. The preflight list on the left shows “Check: rickshaw.jpg — 246 dpi at 158 mm wide”, “OK” for the other five photos at 300–340 dpi, “OK: Checked against 8 bible entries”, “OK: 28 pages (1 blank added)” and “OK: Spine ≈ 3.0 mm”. On the right, page 12 is text only, and at the top of page 13 sits the postcard of Namdaemun and the streetcar tracks, with the text continuing below it](/uploads/231b4d9370290868.webp)

Page 12 shows picture deferral at work. In the manuscript, the Namdaemun photo came after a paragraph near the end of page 11. But the space left on page 11 was smaller than the photo, so it was pushed to the top of page 12, and the text that followed the photo filled the gap on page 11. (In the English edition the same thing happens one page later, with the photo at the top of page 13.)

Here is the same manuscript bound again with only the preset changed.

![The same spread from the same manuscript and photos, bound with three presets. Left, “Classic · 6×9 in · 28 pp”: serif body text with generous leading. Center, “Photo essay · 8×8 in · 24 pp”: a square page with a wide text block. Right, “Paper/textbook · B5 · 22 pp”: unindented body text with numbered figures such as “Figure 4”](/uploads/495ce342264d3e3a.webp)

One button turns the 26-page classic into a 22-page photo book, and then into an 18-page textbook (in the Korean edition; the English edition runs 28, 24 and 22 pages). Page numbers, contents and index are recomputed every time.

## What preflight caught

Typesetting software usually lays out whatever it's given. This tool adds a preflight check that questions the manuscript once before export. In the Korean “A Lucky Day” it flagged three things.

- **Photo resolution.** Print calls for 300 dpi or more at the size the photo will actually be printed. The rickshaw photo is 1,536 pixels wide in the original, and spread to 158 mm wide including bleed, it comes to only 247 dpi. It looks fine on screen, so it's an easy problem for a person to miss. Set at the text width (97 mm), the same photo is over 400 dpi.
- **Two kinds of ellipsis.** “...” (three periods) in 3 places and “…” (the single ellipsis character) in 9.
- **Two kinds of dash.** “ - ” (a hyphen) in 1 place and “—” (a dash) in 8.

The last two are traces of the Wikisource transcription. They aren't errors in the original. They crept in when the text was typed up digitally. I left them in on purpose to see whether the checker would catch them. Making symbols consistent is the thing most often missed in proofreading a printed book.

## Can a story bible be a safety net?

A story bible is written like this.

```
@person Kim Cheomji | job: rickshaw puller | lives: inside Dongsomun
@person Gaettong | age: three | relation: Kim Cheomji's son
@person Chisam | relation: Kim Cheomji's friend
@place Kim Cheomji's home | aka: servants’ quarters | looks: one rented room off the gateway, with a main gate | not: brushwood gate, thatched
```

The checker compares the manuscript against this bible. It looks for spellings not in the bible (a name that differs only in spacing, like “김첨지” for “김 첨지”), ages that differ from the bible (“four years old” near “Gaettong”), and words the bible has ruled out (anything listed under “not:”). The bible can also be copied out as a “settings pack to hand to the AI”.

To see whether this is actually useful, I ran an experiment. I had two freshly started AI agents each write a scene of 1,200 to 1,600 Korean characters: the morning after “A Lucky Day”, when Kim Cheomji goes out with his rickshaw again. **A** got only the story's title and the scene. **B** also got the first seven lines of the story bible (the home entry didn't exist yet) and was told to list separately any settings it invented that weren't in the bible.

Both scenes were well written. Gaettong stayed three years old, Chisam appeared as a friend, and the cold seolleongtang (ox-bone soup) showed up too. But **both gave Kim Cheomji's home a “brushwood gate (saripmun)”.** In the original, the home is a single rented servants' quarters room, and Kim Cheomji steps in through the “main gate”. A brushwood gate is the gate of a thatched country cottage, woven from scrub branches. It doesn't fit a rented house inside Dongsomun.

| | A (no bible) | B (with 7 bible lines) |
|---|---|---|
| Character names, ages, relations | Match the original | Match the original |
| Gate of Kim Cheomji's home | **Brushwood gate** | **Brushwood gate** |
| New settings the AI disclosed | None (not asked) | 9. One of them: “Kim Cheomji's home has a brushwood gate” |
| Checker (bible without home entry) | Missed | Missed |
| Checker (home entry + “not: brushwood gate” added) | **1 issue: “brushwood gate”** | **1 issue: “brushwood gate”** |

Three takeaways. First, even with a story bible, **the AI makes up whatever isn't in the bible.** Both invented the very same word, which suggests the common image of “poor house = brushwood gate” beat the original's context. Second, **the one given the bible wrote down what it had invented.** A person reading that nine-line list can catch the brushwood gate. Third, a rule-based checker catches **only as much as the bible says**. Once the home was described in the bible with “not: brushwood gate”, it was caught at once in both manuscripts.

So in this tool the story bible works in two directions. Before writing, it's the pack you hand the AI. Before binding, it's the checklist you hold the manuscript against. And whatever the AI lists as “new settings” that you want to keep goes back into the bible.

## Are the output files actually usable?

**EPUB.** I ran it through EPUBCheck 5.4.0 (September 2026), the official conformance checker maintained by the W3C. Both the Korean and English editions came out with **0 errors and 0 warnings**. The Korean EPUB is 939 KB and contains two chapter XHTML files, six photos, a cover, a copyright page, an index, a table of contents and a list of print page numbers (page-list). The W3C notes that most bookstores won't accept files that fail EPUBCheck.

**Print PDF.** 152.0×225.0 mm, 26 pages, 1.4 MB. Both the serif body font and the sans-serif caption font are embedded in the PDF (as subsets holding only the characters used). That is the first thing POD services check.

**What's left before self-publishing** is matching a service's specs. Here is what the book-creation screen of BOOKK, one of Korea's POD services, shows.

- **Trim sizes** are four: 46-pan 127×188, A5 148×210, B5 182×257 and A4 210×297 mm. The sinkukpan used in this example isn't on the list. Change only the trim size to A5 in the tool and bind again.
- **Bleed**: if an image or background reaches the edge of the page, make it 3 mm larger on each side, and keep important content 10–15 mm inside the trim line. In this book the rickshaw photo reaches the edge, so it has to be printed with “3 mm bleed”.
- **Page count** goes up to 977. The calculator counts anything under 50 pages as 50.
- **Spine width** has no published formula. Fitting the calculator's output, it comes close to “pages × 0.055 mm + 1.6 mm” for 100 g cream wood-free paper (our estimate). I put this approximation into the tool's paper list. At 26 pages, counted as 50, that's about 4.4 mm.
- **ISBN**: the system is that whoever holds a publisher number from the National Library of Korea applies, so individuals usually register as a publisher or get one under the POD platform's name. Print books (form code 3) and e-books (5) get different numbers.
- **Legal deposit**: under Article 21 of the Library Act, a book must be deposited with the National Library of Korea within 30 days of publication. BOOKK and Kyobo Baro Publishing POD handle this on your behalf.

## Try it yourself

Here is the tool. Edit the text in the Manuscript tab or change the preset in the Trim & type tab, then press “Bind the book” and it binds again. The Preflight tab shows what to fix and what to check.

```map /embed/book-forge-2026-en.html 4:5
“Bind a Book”. Add a manuscript, story bible and pictures, then press “Bind the book” to page it. Downloads are disabled inside the embedded frame.
```

To download the EPUB and PDF, **[open it in a new window](/embed/book-forge-2026-en.html)**. To use your own manuscript, clear the Manuscript tab, paste yours in, and drag your photos into the Pictures tab. Your manuscript and photos never leave the browser.

## Where it went wrong

- **Every scene break turned a page.** I had scene-break markers placed “only when there's room for two lines below”, so they wouldn't be left alone at the bottom of a page. But I measured the remaining space with `scrollHeight`, and when the content is shorter than the box, that value just returns the box's height. The remaining space always came out as 0, so every scene break turned the page, and page 11 was left with only four lines on it. I only noticed when I looked over the thumbnails at a glance. I changed it to measure from the bottom edge of the last element.
- **The wiki text's scene-break markers were printed in the body.** The source separates scenes with `<center>🙝🙟</center>`, and the rule that swaps the inner-speech brackets turned this into the literal text “〈center〉”. I saw it printed in the middle of page 10 and changed it to a scene break.
- **It flagged 4 straight quotation marks by mistake.** The checker counted directives on picture lines, like `"전면"` (bleed) and `"쪽"` (page), as body text and reported “mixed quotation marks”. I excluded picture lines from the check. Then the picture resolution check disappeared too. I put the picture check back to scan the whole manuscript.
- **Only half the print page markers made it into the EPUB.** At first I only looked for spots where a page turned mid-paragraph. Pages that began with a new paragraph got no marker. I changed it so the paging step tags each paragraph with its position in the manuscript.
- **Loose lines remain.** When a long run of characters written without spaces in the original, like 「일어나기는새로」, gets pushed to the next line, the words on the line above spread visibly apart. The browser fills one line at a time, so it doesn't look at the whole paragraph and break it evenly the way Knuth and Plass do. I didn't fix this.
- **Some pages have a few empty lines at the bottom.** When the orphan and scene-break rules push a paragraph to the next page, two or three lines are left empty at the foot of the previous page. A professional typesetter would nudge the leading or tighten a paragraph on the previous page by a line to even out the bottom, but this tool doesn't.

## Why it can be one click

Most of the work people spend a long time on in typesetting is **work with fixed rules**. Avoiding orphans, deferring pictures, starting chapters on the right, filling in contents page numbers, checking photo resolution. The program keeps the rules, and a person only has to pick one preset: “what kind of book should this look like”.

As AI has made writing easier, the chance that a manuscript drifts from its settings has grown too. In this experiment, both AIs made up the same brushwood gate. What caught it wasn't an AI. It was one line written in the bible, and a simple check that scans the whole manuscript with that line. The AI creates, and the checker doubts.

## If you want to try this

- **Write your manuscript with structure from the start.** Mark chapters, subheadings and picture spots, and it will be easy to move to any typesetting tool. Markdown is enough.
- **Judge photo resolution at the size it will actually print.** A photo that looks sharp on screen may fall below 300 dpi at the width of the page. Compute “pixel width ÷ (print width in mm ÷ 25.4)”.
- **Write “not” in your story bible.** “What doesn't exist in this world” matters as much as names and ages. AI fills blanks with the common picture.
- **Have the AI list the settings it invented.** You can't stop it from making things up, but you can find what it made up.
- **Check the EPUB with EPUBCheck and the PDF against your service's specs.** Bookstores won't accept files that fail the check. Trim sizes and bleed differ by service, so bind again with the values of the one you'll use.

## What it can't do

- **It doesn't make covers.** It only calculates the spine width and the size of the cover spread. The front and back cover design has to be done separately.
- **It doesn't export EPUB 2.** According to BOOKK's guide, Aladin doesn't accept EPUB 3.0, and Yes24 recommends EPUB 2.0 or PDF (this is what BOOKK reports; I couldn't confirm the two stores' own documents). This tool exports EPUB 3 only.
- **No footnotes, tables or equations.** The Paper/textbook preset goes as far as “numbered figures”. For math-heavy manuscripts, LaTeX or Typst is still the better choice.
- **No print color management.** The PDF is screen RGB. To print a color photo book on an offset press, you need a separate CMYK conversion and color proofing. Black-and-white POD is fine.
- **It doesn't replace human eyes.** Lines with spread-out words, pages with an empty foot, and photos that don't fit the scene still have to be found by opening the book and fixed by hand.
- **I haven't printed a physical copy yet.** I got as far as the PDF, but haven't actually uploaded it to a POD service and received a book.

Writing keeps getting easier. Now binding that writing into a book can move behind a single button too. What's left is deciding “what kind of book do I want”, and writing down in the bible “what doesn't exist in this world”.

### If you enjoyed this, please leave a comment.

## Sources

- TeX and LaTeX: D. E. Knuth & M. F. Plass, Breaking Paragraphs into Lines, *Software: Practice and Experience* 11(11) (1981), [LaTeX Project history papers](https://latex-project.org/news/2019/04/23/history-papers/), [TeX](https://en.wikipedia.org/wiki/TeX) (secondary)
- Desktop publishing: [Aldus PageMaker](https://en.wikipedia.org/wiki/Aldus_PageMaker) and [Adobe InDesign](https://en.wikipedia.org/wiki/Adobe_InDesign) (secondary), Hangul (HWP) 1.0 [YTN 2015-01-21](https://www.ytn.co.kr/_ln/0103_201501212056279963)
- Writing and web typesetting tools: [Twenty Years of Pandoc](https://pandoc.org/twenty-years-of-pandoc.html), [Scrivener press notes](https://www.literatureandlatte.com/wp-content/uploads/2024/10/Scrivener-Press-Notes.pdf), Vellum [TechCrunch 2013-12-11](https://techcrunch.com/2013/12/11/pixar-veterans-launch-vellum-an-app-to-help-authors-craft-pixel-perfect-ebooks), [Overleaf founders look back](https://overleaf.com/blog/looking-back-on-10-years-with-overleaf-founders), [Paged.js](https://pagedjs.org/about), [Typst](https://en.wikipedia.org/wiki/Typst) (secondary)
- E-book standards: [EPUB 2.0 OPS](https://idpf.org/epub/20/spec/OPS_2.0_latest.htm), [EPUB 3.0 approval](https://idpf.org/node/418), [EPUB 3.3 W3C Recommendation](https://www.w3.org/press-releases/2023/epub33-rec), [EPUBCheck](https://www.w3.org/publishing/epubcheck/)
- Korean typesetting: W3C [Requirements for Hangul Text Layout and Typography (klreq)](https://www.w3.org/TR/klreq/), [CSS Text Level 3 word-break](https://www.w3.org/TR/css-text-3/#word-break-property)
- AI setting features: [NovelAI Lorebook](https://docs.novelai.net/en/text/lorebook), [Novelcrafter Codex](https://www.novelcrafter.com/help/docs/codex/the-codex), [Sudowrite Story Bible 2](https://feedback.sudowrite.com/changelog/worldbuilding-unlimited-characters-and-more) (company announcement)
- Self-publishing: BOOKK [book creation](https://bookk.co.kr/author/make/paperBook), [bleed FAQ](https://bookk.co.kr/community/faq/all?id=69785dfa7405c60981e2d73c) and [EPUB FAQ](https://bookk.co.kr/community/faq/all?id=6a100b42ca6a52a018a6f222) (checked 2026-10-21; the spine approximation is our estimate from the calculator's output), [Kyobo Baro Publishing POD](https://store.kyobobook.co.kr/pod/), National Library of Korea [who gets an ISBN](https://nl.go.kr/seoji/contents/S20101050000.do) and [legal deposit guide](https://www.nl.go.kr/seoji/contents/S20102010000.do), [International ISBN Agency FAQ](https://www.isbn-international.org/node/26)
- Text: Wikisource [운수 좋은 날 (A Lucky Day)](https://ko.wikisource.org/wiki/운수_좋은_날) (PD-old-50), original publication [Literature Translation Institute of Korea](https://library.ltikorea.or.kr/originalworks/102153), copyright term [Copyright Act No. 432](https://ko.wikisource.org/wiki/저작권법_(대한민국,_제432호)) and [No. 3916](https://ko.wikisource.org/wiki/저작권법_(대한민국,_제3916호)) Addendum Article 2, [PD-South Korea](https://commons.wikimedia.org/wiki/Template:PD-South_Korea)
- Photos (all from Wikimedia Commons, public domain): [gentleman in a rickshaw](https://commons.wikimedia.org/wiki/File:Native_aristocrat_of_the_old_school_in_his_rickshaw_after_the_fall_of_the_government,_Korea_LCCN2001705594.jpg) (Burton Holmes, US Library of Congress), [Keijo from Namsan, 1928](https://commons.wikimedia.org/wiki/File:View_of_Downtown_Keij%C5%8D_from_Nanzan_mountain_in_1928.jpg) (Seoul History Archive), [Namdaemun postcard](https://commons.wikimedia.org/wiki/File:The_Nandaimon_Gate,_Keijo_(NYPL_Hades-2359557-4044321).jpg) (New York Public Library), [streetcar in Seoul](https://commons.wikimedia.org/wiki/File:Streetcar,_Seoul,_Korea_LCCN2001705632.jpg) and [shoe market](https://commons.wikimedia.org/wiki/File:Shoe_market,_Seoul,_Korea_LCCN2001705633.jpg) (Carpenter Collection, US Library of Congress), [Geumcheonggyo Bridge, 1920s](https://commons.wikimedia.org/wiki/File:Geumcheonggyo_Bridge_1920s.png) (*Keijo-fu shi*)
- The typesetting tool, EPUB, PDF, preflight results and the AI sequel experiment were all made for this post. The English translation was done by an AI agent