EPUB + Druck-PDF aus einem Quellmanuskript: Single-File-Workflow

EPUB und Druck-PDF aus einer Quelle exportieren: Ein Single-File-Workflow für unabhängige Autoren

E-Book versus Druck ist im Indie-Ökosystem keine Entweder-oder-Entscheidung mehr. Im Jahr 2026 ist eine übliche Veröffentlichungsstrategie, beide gleichzeitig auszuliefern – E-Book über KDP, Apple Books, Kobo Writing Life und andere; Druck über KDP Print, IngramSpark oder eine lokale Druckerei. Zwei Formen decken unterschiedliche Leser, unterschiedliche Kaufkontexte, unterschiedliche Preispunkte ab; zusammen ergeben sie die vollständige Distribution eines unabhängigen Autors.

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

Aber EPUB und Druck-PDF folgen einer sehr unterschiedlichen Layout-Logik. EPUB ist umfließbar – Leser passen Schriftgröße, Zeilenabstand und Lesebreite an, und der Text fließt je nach Gerät um. Druck-PDF ist festes Layout – jede Seitenposition der Zeichen, Zeilenanzahlen, Kapitelanfänge und Links/Rechts-Beziehungen sind vorherbestimmt. »Neue Seite pro Kapitel« in EPUB muss zu »neue Seite pro Kapitel, beginnend auf einer Recto-Seite« im Druck werden; ein Bild, das in EPUB jedes beliebige Verhältnis haben kann, muss im Druck Beschnitt und Farbraum berücksichtigen.

Dieser Unterschied drängt viele Autoren auf einen »Zwei-Quellen«-Weg: Schreiben Sie ein .docx in Word oder Scrivener, exportieren und konvertieren Sie über Calibre zu EPUB, und machen Sie gleichzeitig die Druckversion in Vellum, Atticus oder InDesign. Mitten im Projekt müssen Sie vielleicht das Manuskript überarbeiten und die Änderungen in beiden Versionen abgleichen. Kurzfristig funktioniert es; langfristig muss jede Überarbeitung zweimal synchronisiert werden, und Abweichungen sind nur eine Frage der Zeit.

Ein sinnvollerer Weg ist Einzelquelle + Vorlagengabelung: Eine Klartextdatei (typischerweise Markdown oder .docx) ist die maßgebliche Quelle; E-Book und Druck haben jeweils ihre eigenen Satzvorlagen, die daraus rendern. Vellum und Atticus haben dieses Modell in der englischsprachigen Indie-Szene gefördert (obwohl sich ihre Quellformate unterscheiden); es ist in der chinesischsprachigen Verlagsszene weniger verbreitet. Der folgende Artikel behandelt vier Dimensionen.

Die Kosten von zwei Quellen: Abweichungen sind nur eine Frage der Zeit

Die meisten Autoren spüren die Kosten beim ersten Buch nicht – für die zwei oder drei Monate vor der Veröffentlichung ist es nicht schwer, beide Dateien parallel zu halten. Die Kosten zeigen sich, nachdem das Buch veröffentlicht ist.

Ein Leser meldet einen Druckfehler in einem Abschnitt – Sie gehen zurück, überarbeiten, korrigieren das .docx, aber das Vellum-Projekt wird nicht aktualisiert; beim nächsten Nachdruck stellen Sie fest, dass die Korrektur nicht eingeflossen ist. Oder Sie möchten eine zweite Ausgabe mit einem neuen Vorwort machen – das Vorwort wird in das Druckprojekt eingefügt, aber die EPUB-Quelle ist nicht synchronisiert, und E-Book-Leser sehen immer noch die alte Version. Dieses »zwei Versionen nicht synchron« ist eine wiederkehrende Falle für unabhängige Autoren bei mehreren Nachdrucken oder langfristigen Verkaufsoperationen.

Die subtilere Kosten sind psychologische Belastung. Jedes Mal, wenn Sie eine Überarbeitung in Betracht ziehen, muss Ihr Gehirn verfolgen: »in zwei Stellen korrigieren«, und diese Reibung erhöht leise die Schwelle für »eine Zeile ändern«. Mit der Zeit unterdrückt sie die fortlaufende Politur des Manuskripts.

Einzelquelle + Vorlagengabelung: Die Quelle einzigartig halten

Ein robusterer Weg ist, das Manuskript auf eine einzige maßgebliche Quelle zu komprimieren, wobei E-Book- und Druckversionen jeweils über ihre Vorlagen gerendert werden. Markdown hat hier strukturelle Vorteile:

Es ist Klartext, von jedem Editor öffnbar;
Seine Struktur (Kapitel, Betonung, Listen) ist semantisch, und Vorlagen können aus derselben Semantik verschiedene Formen rendern;
Es ist klein, einfach zu versionieren und zu synchronisieren.

Der Workflow sieht grob so aus:

Schreiben Sie in Markdown, eine .md-Datei pro Kapitel, und legen Sie Projektmetadaten (Titel, Autor, ISBN, Impressum) in eine YAML-Datei.
Wählen Sie eine E-Book-Vorlage – legen Sie Schriftarten, Zeilenabstand, Absatzstile, Kapitelanfangsseiten-Stile fest – rendern Sie EPUB 3.
Wählen Sie eine Druckvorlage – legen Sie Endformat, Ränder, Bindungsseite, Schriftarten (die sich vom E-Book unterscheiden können), CMYK fest – rendern Sie Druck-PDF.
Wenn Sie überarbeiten, bearbeiten Sie nur die Markdown-Quelle – beide Ausgaben aktualisieren sich beim nächsten Rendern.

Der Punkt ist nicht »Markdown verwenden« – es ist, dass die Vorlagen die differenzierten Anforderungen von EPUB und Druck absorbieren, sodass der Autor das Manuskript selbst nicht für jede Ausgabe anpassen muss.

Versionsverwaltung: Jede Veröffentlichung festschreiben

Ein weiterer Vorteil des Single-File-Workflows ist, dass er sich natürlich mit der Versionskontrolle verbindet. Legen Sie das Markdown-Projekt in ein Git-Repo, committen Sie bei jeder sinnvollen Änderung und taggen Sie jede Veröffentlichung (v1.0, v1.1-typofix, v2.0-revised). Damit:

Sie können jederzeit zu jeder historischen Version zurückwechseln und das EPUB und Druck-PDF dieser Version neu rendern;
Sie wissen genau, wann jede Änderung vorgenommen wurde und warum (Commit-Nachricht);
Sie können für verschiedene Sprachversionen, regionale Editionen und Sonderausgaben (Hardcover, signiert) abzweigen, ohne das Hauptmanuskript zu verschmutzen.

Für Autoren, die bereit sind, ein oder zwei Tage in das Lernen von Git zu investieren, übersteigt die Stabilität, die diese Schicht bringt, bei weitem den Ansatz von Word + datumsversehenem Dateinamen. Wenn Git nichts für Sie ist, geben Sie das Markdown-Projekt in Dropbox / iCloud / Google Drive – das bietet grundlegende Synchronisation und Verlaufsrücksetzung, wenn auch mit gröberer Granularität.

Catalpas Atelier Scribe: Einzelquelle + synchronisierte Vorschau

Catalpas Atelier Scribe ist eine Desktop-Anwendung, die um diesen Workflow herum entwickelt wurde. Seine Kernposition ist »Markdown-Quelle + E-Book- und Druckvorlagen parallel + Live-Vorschau«.

Die Quelle ist Markdown in einem Ordner Eine .md pro Kapitel, Klartext, von jedem Editor öffnbar, Git-freundlich, von jedem Synchronisationswerkzeug erkennbar. Scribe sperrt das Manuskript nicht in einer proprietären Datenbank ein.

Schreibbereich + Live-Dual-Output-Vorschau Der linke Schreibbereich ist Markdown; der rechte Vorschaubereich wechselt zwischen »E-Book-Vorschau« und »Druckvorschau« – gleiche Quelle, zwei Ausgabeformen, mit millisekundengenauen Layout-Updates pro Tastendruck. Dies verkürzt den Feedback-Zyklus erheblich im Vergleich zu »exportieren und das PDF prüfen«.

Ab Plus: EPUB 3 + Graustufen-/RGB-PDF Plus schaltet EPUB 3 (mit vollständigen Verlagsmetadaten, bereit für KDP / Apple Books / Kobo) und Graustufen-/RGB-PDF frei. Der Dual-Track-Release der meisten englischen Romane und allgemeinen Sachbücher passt in Plus.

Pro: CMYK + ICC + benutzerdefinierte Druckvorlagen + Ruby Projekte mit höheren Druckanforderungen (Hardcover, Kunstbücher, CJK-Publishing, Farbinnenteile) benötigen Pro: CMYK-Farbraum, ICC-Farbmanagement, benutzerdefinierte Druckvorlagen (Doppelseiten + Bindungsseitenwechsel + Beschnitt + Bundsteg), benutzerdefinierten Schriftimport und Ruby. Pro kostet 79,99 $/Jahr Einführungspreis, 129,99 $/Jahr regulär.

Nativ auf drei Plattformen Windows, macOS und Linux haben alle native Clients; Dateien werden standardmäßig lokal gespeichert, Cloud-Synchronisation optional.

Ein Vergleich mit Vellum und Atticus

Vellum und Atticus verkörpern beide die Designphilosophie »Einzelquelle, E-Book- und Druckvorlagengabelung« und sind beide kampferprobte Werkzeuge in der englischsprachigen Indie-Szene. Vellum bietet sorgfältig gestaltete voreingestellte Themen und nahezu fehlerfreien englischen Satz; Atticus ist web-nativ, einfach über Geräte hinweg und als einmaliger Kauf erhältlich.

Was sie auf diesem Weg von der Kandidatenliste ausschließt, sind unterschiedliche Grenzen:

Vellum ist nur für macOS und unterstützt keinen vertikalen CJK-Satz oder Ruby;
Atticus ist web-nativ, was bedeutet, dass das Manuskript in der Cloud gehostet wird, keinen CMYK-Druckfarbraum und keinen vertikalen CJK-Satz unterstützt;
Keines der beiden hat offenen Markdown-Quelltext – der Export erfordert eine Konvertierung.

Scribe trifft andere Abwägungen bei diesen drei Punkten: nativ auf drei Plattformen, vertikaler CJK standardmäßig verfügbar, Quelltext ist offenes Markdown. Es wird Vellum auf der Mac-englischen Benutzererfahrungsachse nicht schlagen – das ist nicht sein Ziel. Es erweitert den Single-File-Workflow auf die Szenarien, die Vellum und Atticus nicht abdecken.

Ihre Wahl treffen

Einzelquelle + Vorlagengabelung ist langfristig ein nachhaltiger Workflow, aber nicht jeder Autor muss sofort wechseln.

Wenn Sie nur ein Buch veröffentlichen und Word + Vellum/Atticus bereits funktioniert, gibt es keinen Grund, eine Migration für einen »eleganteren Workflow« zu erzwingen. Gute Werkzeuge müssen nicht ersetzt werden.

In den folgenden Fällen kann der Single-File-Markdown-Workflow die bessere Wahl sein:

Sie planen, mehrere Bücher zu veröffentlichen, und möchten, dass die Wartungskosten beherrschbar bleiben;
Sie legen Wert auf langfristige Portabilität des Manuskripts und möchten nicht an ein proprietäres Format eines Werkzeugs gebunden sein;
Sie schreiben bereits in Markdown;
Ihr Projekt betrifft vertikalen CJK oder Ruby, was Vellum und Atticus ausschließt;
Sie möchten Git für präzise Versionskontrolle und Zusammenarbeit nutzen;
Ihre Gerätemischung erstreckt sich über Windows, macOS und Linux.

Der beste Workflow ist »einmal überarbeiten, beide Ausgaben aktualisieren«. Beginnen Sie mit der kostenlosen Stufe, sehen Sie sich sowohl E-Book als auch Druck aus derselben Markdown-Quelle in der Vorschau an und sehen Sie, ob es zu Ihrem Rhythmus passt.

Weiterführende Literatur:

Probieren Sie denselben Workflow in Scribe – Kostenloser Start, Pro-Einführungspreis gesichert →