EPUB + Print PDF from One Source Manuscript: Single-File Workflow

Export EPUB and Print PDF from One Source: An Indie Author’s Single-File Workflow

Ebook versus print isn’t an either-or choice in the indie ecosystem anymore. In 2026, a common release strategy is to ship both simultaneously — ebook through KDP, Apple Books, Kobo Writing Life and others; print through KDP Print, IngramSpark, or a local press. Two forms cover different readers, different buying contexts, different price points; together they make up an indie author’s full distribution.

Scribe single-source EPUB and PDF export — Catalpas Atelier Scribe · One source, two outputs

But EPUB and print PDF follow very different layout logic. EPUB is reflowable — readers adjust font size, line spacing, and reading width, and the text reflows by device. Print PDF is fixed layout — every page’s character positions, line counts, chapter starts, and left/right relationships are predetermined. “New page per chapter” in EPUB has to become “new page per chapter, starting on a recto page” in print; an image that can be any proportion in EPUB has to account for bleed and color space in print.

This difference pushes many authors onto a “dual source” path: write a .docx in Word or Scrivener, export and convert to EPUB via Calibre, and simultaneously do the print version in Vellum, Atticus, or InDesign. Mid-project you may need to revise the manuscript and sync the changes across both versions. Short term it works; long term every revision has to be synced twice, and drift is only a matter of time.

A more sensible path is single source + template fork: one plain-text file (typically Markdown or .docx) is the authoritative source; ebook and print each have their own typesetting templates that render from it. Vellum and Atticus have promoted this model in the English-language indie scene (though their source formats differ); it’s less common in the Chinese-language publishing scene. The piece below covers four dimensions.

The cost of dual sources: drift is only a matter of time

Most authors don’t feel the cost during the first book — for the two or three months before publication, maintaining both files in parallel isn’t hard. The cost shows up after the book is out.

A reader flags a misprint in some section — you go back to revise, fix the .docx, but the Vellum project isn’t updated; the next reprint, you discover the fix didn’t make it. Or you want to do a second edition with a new foreword — the foreword goes into the print project, but the EPUB source isn’t synced, and ebook readers still see the old version. This “two versions out of sync” is a recurring trap for indie authors during multiple reprints or long-tail operations.

The subtler cost is psychological burden. Every time you consider a revision, your brain has to track “fix in two places,” and that friction quietly raises the threshold for “change one line.” Over time it suppresses ongoing polish of the manuscript.

Single source + template fork: keep the source unique

A more robust path is to compress the manuscript to a single authoritative source, with ebook and print versions each rendered via their templates. Markdown has structural advantages here:

It’s plain text, openable by any editor;
Its structure (chapters, emphasis, lists) is semantic, and templates can render different forms from the same semantics;
It’s small, easy to version-control and sync.

The workflow roughly looks like this:

Write in Markdown, one .md file per chapter, and put project metadata (title, author, ISBN, copyright page) in a YAML file.
Pick an ebook template — set fonts, line spacing, paragraph styles, chapter-open page styles — render EPUB 3.
Pick a print template — set trim size, margins, binding side, fonts (which can differ from the ebook), CMYK — render print PDF.
When revising, edit only the Markdown source — both outputs update on the next render.

The point isn’t “use Markdown” — it’s that the templates absorb the differentiated needs of EPUB and print, so the author doesn’t tweak the manuscript itself for each output.

Version management: pin every release

Another benefit of the single-source workflow is that it pairs naturally with version control. Put the Markdown project in a Git repo, commit at every meaningful change, and tag each release (v1.0, v1.1-typofix, v2.0-revised). With that:

You can switch back to any historical version at any time and re-render that version’s EPUB and print PDF;
You know exactly when each change was made and why (commit message);
You can branch for different language versions, regional editions, and special editions (hardcover, signed) without polluting the main manuscript.

For authors willing to spend a day or two learning Git, the stability this layer brings far exceeds the Word + date-suffixed filename approach. If Git isn’t for you, putting the Markdown project in Dropbox / iCloud / Google Drive gives you basic sync and history rollback — just at coarser granularity.

Catalpas Atelier Scribe: Single Source + Synced Preview

Catalpas Atelier Scribe is a desktop application designed around this workflow. Its core stance is “Markdown source + ebook and print templates in parallel + live preview.”

The source is Markdown in a folder One .md per chapter, plain text openable by any editor, Git-friendly, recognizable by any sync tool. Scribe doesn’t lock the manuscript inside a proprietary database.

Writing pane + live dual-output preview The left writing pane is Markdown; the right preview pane toggles between “ebook preview” and “print preview” — same source, two output forms, with millisecond-level layout updates per keystroke. This significantly shortens the feedback cycle compared to “export and check the PDF.”

From Plus: EPUB 3 + grayscale / RGB PDF Plus unlocks EPUB 3 (with full publishing metadata, ready for KDP / Apple Books / Kobo) and grayscale/RGB PDF. Dual-track release of most English novels and general nonfiction works fits inside Plus.

Pro: CMYK + ICC + custom print masters + ruby Projects with higher print requirements (hardcover, art books, CJK publishing, color interiors) need Pro: CMYK color space, ICC color management, custom print masters (facing pages + binding-side switch + bleed + gutter), custom font import, and ruby. Pro is $79.99/year early-bird, $129.99/year regular.

Native on three platforms Windows, macOS, and Linux all have native clients; files default to local storage, cloud sync optional.

A comparison with Vellum and Atticus

Vellum and Atticus both embody the “single source, ebook and print template fork” design philosophy, and both are battle-tested tools in the English-language indie scene. Vellum offers carefully designed preset themes and near-flawless English typesetting; Atticus is web-native, easy across devices, and one-time-purchase.

What keeps them off the candidate list on this path are different limits:

Vellum is macOS only and doesn’t support CJK vertical typesetting or ruby;
Atticus being web-native means the manuscript is hosted in the cloud, doesn’t support CMYK print color, and doesn’t cover CJK vertical;
Neither’s source is open Markdown — exporting out requires conversion.

Scribe makes different tradeoffs on these three points: native on three platforms, CJK vertical available by default, source is open Markdown. It won’t beat Vellum on the Mac English user experience axis — that isn’t its goal. It extends the single-source workflow into the scenarios Vellum and Atticus don’t cover.

Making your choice

Single source + template fork is a sustainable workflow long-term, but not every author needs to switch right away.

If you’re only publishing one book and Word + Vellum/Atticus already works, there’s no reason to force a migration “for a more elegant workflow.” Good tools don’t need to be replaced.

In the following cases, the single-source Markdown workflow may be the better fit:

You plan to publish multiple books and want maintenance cost to stay manageable;
You value long-term portability of the manuscript and don’t want to be locked into any tool’s proprietary format;
You already write in Markdown;
Your project involves CJK vertical or ruby, putting Vellum and Atticus out of the picture;
You want to use Git for precise version control and collaboration;
Your device mix spans Windows, macOS, and Linux.

The best workflow is “revise once, update both outputs.” Start from the Free tier, preview both ebook and print from the same Markdown source, and see whether it fits your rhythm.

Further reading:

Try the same workflow in Scribe — Free to start, Pro early-bird locked in →