Die Kosten des nachträglichen Reparierens: Warum die EPUB-Nachbearbeitung wirtschaftlich unklug ist

Das Kernproblem: Nachbearbeitung Komplexer Code-Architektur

Wer regelmäßig reflowbare E-Books produziert, kennt die Problematik der Nachbearbeitung: Satzprogramme sind für die visuelle Gestaltung von Druckseiten hervorragend geeignet. Beim Export in ein fluides EPUB erzeugen sie jedoch eine unvollständige und technisch viel zu komplexe Code-Architektur.

Versucht man anschließend, diesen Quelltextmanuell aufzuräumen oder nachträglich barrierefrei zu machen, wird der Prozess schnell zum kalkulatorischen Risiko. In diesem Artikel erfährst du, warum und welche versteckten Kosten bei der nachträglichen E-Book-Reparatur entstehen und weshalb ein compiler-basierter Ansatz diese Kosten zukünftig langfristig minimiert.

Das Code-Gestrüpp: Herausforderungen bei der nachträglichen Korrektur

Wird das E-Book beim Print-Satz lediglich nebenbei produziert oder ohne Struktur konvertiert entsteht eine schwer zu bearbeitende Code-Basis. Wird es zweimal über ein Layout-Satzprogramm erzeugt, um das E-Book separat herzustellen, hat man dann zwei unterschiedliche Herstellungsprozesse, woraus die digitale Version trotzdem weder layoutstabil noch barrierefrei hervorgeht. Der Grund, warum Nacharbeit dann mehr Zeit benötigt liegt in den technischen Abhängigkeiten innerhalb des EPUB-Containers:

Inhaltliche Nachbesserungen

Das Ändern eines einzelnen Tags oder das Umstrukturieren eines Kapitels erfordert eine hohe Aufmerksamkeit für semantisches HTML und zusätzlich das Zerlegen von oft 1.000 bis 1.500 Zeilen CSS.

Kaskadierende Fehler

Wer Pfade, Dateinamen oder IDs anpasst, muss diese manuell an mindestens vier Stellen synchronisieren oder zumindest auf Vollständigkeit überprüfen: in der Steuerungsdatei (content.opf), im manifest, im spine sowie in den Navigationsdateien (nav.xhtml und toc.ncx). Nachträgliche Eingriffe sind in einem zu umfangreichen Code-Gerüst mit viel Zeitaufwand verbunden.

Barrierefreiheit unter Zeitdruck

Das nachträgliche Injizieren von ARIA-Attributen und semantischen Bedeutungen auf fehlerhaftem Grundcode erfordert tiefes technisches Architekturverständnis. Ein einziges falsch gesetztes Attribut führt beim EPUBCheck und in anderen Prüftools sofort zu Validierungsfehlern und verfehlt die Barrierefreiheit in der echten Praxis.

Der Mehraufwand in Zahlen:

In der Reparaturpraxis zeigt sich regelmäßig ein Vielfaches des ursprünglich kalkulierten Arbeitsaufwands. Bei einem konkreten Reparaturfall eines InDesign-Exports summierte sich das auf über 90 Arbeitsstunden, nur um die grundlegende XHTML-Tag-Struktur wiederherzustellen. Weitere 30 Stunden gingen nur dafür drauf, für einen einzigen Distributor Layoutstabilität wiederherzustellen. Ohne vollständige Tag-Struktur in diesem 500-Printseiten-Manuskript war das 5-fache an Arbeitszeit nötig.

Technische Ursachenanalyse: Wo die Zeit verloren geht

Satzprogramme sind weniger dafür gemacht, komplexe logische Strukturen in vollständigen und kaskadierenden und schlanken Web-Code zu übersetzen. Drei Bereiche erweisen sich in der Praxis als ziemlich zeitintensiv:

Fehlende oder falsche HTML5-Tags

Semantische Strukturelemente werden in manchen Fällen als neutrale div– oder p-Tags ausgegeben. Zuviele span-Tags für einzelne Formatierungen schaffen zusätzlich aufgeblähtes HTML, das man erstmal durchdringen muss.. Die Korrektur im fertigen EPUB ist Handarbeit, die dann mit RegEx nicht möglich ist.

Selbst das Sondieren nach Attributen oder Klassen erfordert mit dieser Praxis ein viel höheres Maß an Genauigkeit und sich ständig ändernde Suchparameter, um die gleichen Tags auseinanderzupflücken. Hier folgen ein paar konkrete Beispiele, die am häufigsten aufgefallen sind:

• Listen: Fehlen die korrekten Tags (ul, ol, li), muss jede Liste manuell nachqualifiziert werden. Bei einem 500-Seiten-Manuskript mit 14 unstrukturierten Listen bedeutet das hunderte händische Eingriffe.
• Tabellen: Für eine barrierefreie Ausgabe reichen visuelle Gitterlinien nicht aus. Es werden präzise th-Header, scope-Attribute (col/row), verknüpfte caption-Elemente und ein defensives CSS benötigt. Erst das Fehlen von ARIA-Rollen macht den div-Export für Screenreader unzugänglich, während native table-Elemente die einzig wartbare Basis bieten. Das Umwandeln dieser Container in eine Tabellenverschachtelung ist echte Sisyphusarbeit.
• Beschreibungslisten: Glossare benötigen eine strikte dl–dt–dd-Struktur. Da Satzprogramme diese Verschachtelung nicht immer nativ korrekt erzeugen, verstreicht viel Zeit mit der händischen Nachstrukturierung.

Semantische Anreicherung & Barrierefreiheit

Für ein barrierefreies EPUB 3 müssen Buchstrukturen über epub:type und ARIA-Rollen klar und nach aktuellen Standards deklariert werden:

• Buchbereiche: Die Zuordnung von frontmatter, bodymatter und backmatter sowie spezifischer Sektionen (chapter, colophon) erfordert ein hohes Maß an Aufmerksamkeit und eine zeitgleiche Prüfung der eingesetzten Attribute. Das parallele Aufbauen der Landmarks macht diese Elemente erst dezentral bedienbar und muss ebenfalls korrekt in der Navigationsdatei eingearbeitet werden.
• Fußnoten: Eine hybrid funktionierende Fußnote benötigt ein lineares Zusammenspiel aus barrierefreier bidirektionaler Verlinkung, korrekter Platzierung am Kapitelende im entsprechend getaggten <section>-Container und einem präzisen Backlink am Ende des Textes. Fehlerhaft platzierte aria-label-Attribute zerstören hier sofort den Sprachfluss von Screenreadern und benötigt ein genaueres überprüfen, damit der lineare Lesefluss und die Bedienbarkeit für jeden nachvollziehbar bleibt. Endnoten und Querverweise unterliegen je nach Bedeutung oder Art der Verwendung, wiederum anderen Herangehensweisen.
• Bildelemente: Neben reinen Alt-Texten müssen Bildtitel, Bildunterschriften und komplexe Beschreibungen semantisch korrekt ausgezeichnet und verschachtelt werden. Der Einsatz von Icons erfordert wiederum eine andere Attributisierung, als ein Foto oder eine Grafik. Auch hier ist Semantik entscheidend, wie diese Medien von assistiven Systemen erfasst werden, damit ihre Bedeutung und Verwendung verstanden wird.

Die Steuerzentrale des EPUBs

Fehler in den zentralen Steuerdateien führen dazu, dass Lesesysteme das E-Book falsch ausgeben, fehlende Einbettung und Obfuscation der Schriften ignorieren und im schlimmsten Fall überhaupt nicht öffnen können:

• Im spine wird die exakte Abrufreihenfolge aller Inhalte und Dateien gesteuert.
• Im manifest muss jede einzelne Ressource (Bilder, Schriften, Dateien, Style-Sheets) fehlerfrei registriert sein.
• Die nav.xhtml ist das Rückgrat der Menüführung. Die toc.ncx muss hier deckungsgleich vorliegen und ebenfalls im manifest angemeldet und im spine integriert sein. Fehlen hier Bezüge, liegen auf unterschiedlichen Geräten unvollständige oder nicht bedienbare Navigationselemente vor.

Sind diese Beziehungen oder Strukturen fehlerhaft oder nicht mitgedacht worden, wird diese Nacharbeit sehr schnell zur Prozess-Verstopfung. Ältere Backlists, die bisher noch liefen, müssen dann vielleicht ebenfalls nachgearbeitet werden. Ein gutes Beispiel sind sehr alte E-Reader, die robustere Fallbacks benötigen.

Die Folgen zusammengefasst:

All diese Punkte der Nachbearbeitung führen sehr schnell zu mehr Stunden als geplant, wenn der Code nicht vorher schon sauber exportiert wurde.

Fehlendes HTML-Tagging sorgt für zusätzlich erschwerte Arbeit, da die Unterstützung mit RegEx wegfällt, was bei Arbeiten in Code-Architekturen manuelle Fehler verhindern kann.

Die technische Architektur des E-Books muss von vornherein anders gedacht werden. Das erfordert entweder zwei Datei-Versionen oder die Grafikabteilung hängt während der Satzarbeit immer in Kompromissen fest, print und digital in einer Datei unter einen Hut zu bekommen. Auf ersten Blick spart man sich erstmal Zeit alles in einer Pipeline zu lassen. Langfristig sitzt die Backlist aber auf einem unsicheren Fundament. Und gerade das zeigt sich jetzt mit den gesetzlichen Vorgaben zu digitale Inhalte Barrierefrei anzubieten.

Das EPUB ist unter der Oberfläche ein technisches Format. Layoutexporte kommen so oder so selten ohne Korrekturen aus. Dieser Aufwand lässt durch einen spezialisierten und separaten Herstellungs-Workflow abfangen, der technisch für genau dieses Format optimiert ist. Umfangreiche Korrekturen werden so eingespart, die Ergebnisse lassen sich leichter nachbearbeiten und rechtssicher dokumentieren.

Kommen wir also im nächsten Abschnitt zur softwareunabhängigen Lösung und sehen uns an, welche Vorteile sich daraus ergeben.

Die Lösung: Quality by Design durch Compiler-Workflows

Anstatt zu Komplexe Ebook-Architekuren im Nachhinein zeitintensiv aufzuräumen oder zu reparieren, wird die EPUB-Erstellung durch einen Compiler-basierten Workflow von Grund auf solide und robust durch Teilautomation aufgebaut:

1. Markdown als semantisches Fundament: Autorinnen, Autoren, Lektorat oder gerne auch wir erfassen die Inhalte direkt in einer maschinenlesbaren Auszeichnungssprache. Markdown erfordert keine Einstellungsorgien. Es liefert reine Semantik, die für die technische Weiterverarbeitung die dafür geeignete Grundlage ist.
2. Kompilierung über Pandoc & Lua-Filter: Ein Compiler wandelt das Manuskript inklusive aller Ressourcen direkt in ein schlankes, weboptimiertes EPUB 3.3-Gerüst um. Individuelle Lua-Filter fügen komplexe HTML5-Strukturen, ARIA-Attribute und Buch-Sektionen automatisch während der Kompilierung ein. Genauer gesagt wird hier alles vollständig in die finale technische Architektur übersetzt und fehlerfrei integriert. Die Lua-Filter sind hier der Schlüssel der Teilautomatisierung. Zum Beispiel wissenschaftlich strukturierte Inhalte, unterschiedliche Bildelemente, Fussnoten uvm.
3. Gezielte Feinarbeit im sauberen Code: Die verbleibende manuelle Aufbereitung für die Finalisierung findet in einer übersichtlichen, flachen Code-Architektur statt. Änderungen am Text oder CSS lassen sich dank valider Strukturen verlässlich über RegEx-Muster durchführen. Das macht eine Backlist langfristig resistent und wartbar.

Der betriebswirtschaftliche Hebel

Der Wechsel zu einer Compiler-basierten Pipeline verlagert Ressourcen von der Fehlersuche hin zur Qualitätssicherung. Folgende Vorteile und Benefits ergeben sich daraus:

Zeitersparnis bei der Herstellung

Die gesparte Zeit kann nun in umfangreichere Praxistests fließen. Durch das Entschlacken des gesamten Herstellungsprozesses kann man sich auf die Überprüfung, die Funktionen und die Ausgabe auf unterschiedlichen Geräten konzentrieren. Ein Abgleich der visuellen und nutzer- sowie screenreaderfreundlichen Wiedergabe sorgt gleichzeitig für die Erfüllung der gesetzlich geforderten Barrierefreiheit. In unserem Prozess bei Bookcode Tech sind diese Qualitätsaudits bereits im Workflow integriert und werden für interne und externe Prüfstellen dokumentiert.

Zusätzlich bleibt die Version für den Druck von Kompromissen für technisches während der Satz-Arbeit unberührt und sorgt in beiden Welten für eine höhere Qualität des Leseerlebnisses.

Minimierung von Upload-Risiken

Ein unterschätztes Risiko kann im Publishing-Alltag zum Produktionsstopp führen. Ein Distributor entscheidet über die technische Korrektheit und Qualität des E-Book-Codes. Wer sich durch technische Expertise hier mit alternativen Workflows aufstellt, minimiert diese Risiken schon im Vorfeld und zukünftig.

Datenhoheit & Single Source of Truth

Digitale Souveränität ist nicht nur der Speicherort. Es bedeutet auch, die Hoheit über die Datenquelle zu behalten (Single Source of Truth). Ein optimal strukturiertes Ausgangsformat ermöglicht die mühelose Weiterverarbeitung. So gelingen zum Beispiel automatisierte Übersetzungen in andere Sprachen oder der Export in weitere E-Reader-Systeme ohne erneute E-Book-Satzkosten, da die inhaltliche Struktur unberührt bleibt.

Ein valider W3C-Standard schützt vor Inkompatibilitäten der eigenen Datenbasis, selbst wenn Lese-Apps ihre Rendering-Regeln anpassen. Verlage und Autor:innen behalten so die Kontrolle über die Werke und besitzen eine von einzelnen Distributoren unabhängige Datenquelle und eine hohe Datenqualität.

Proaktive Entwicklung und Förderung

Durch die Erleichterung wächst das Entwicklungspotenzial. Inhalte lassen sich so durch Code-Anreicherung und neue Ideen weiterdenken und für die jeweilige Verwendung vorbereiten.

Das EPUB bietet sehr viel mehr als nur das Lesen von Textinhalten. So arbeitet man langfristig an der Qualität des digitalen Lernens und Lesens global mit, visuell sowie auch verbal, und macht das Format EPUB zu dem, was es sein soll: größere Teilhabe an tollen Geschichten, Perspektiven verändern, Bildung verständlich weitergeben und weiterentwickeln.

Nutzerfreundlichkeit durch EPUB-spezifische Funktionen sind ein zusätzliches Plus, das allen Altersgruppen zugute kommt. Und es wird eine robuste Architektur geschaffen, die auch auf alten oder rudimentär gebauten E-Readern läuft. Zum Beispiel bauen sich viele Menschen inzwischen auch gerne mal eigene E-Reader mithilfe von Raspberry-Pi und E-Ink-Screens. Wo wir dann auch beim Thema Nachhaltigkeit, Digitale Souveränität und weniger Energieverbrauch angekommen sind.

So entsteht für sehr viel mehr Menschen überall auf der Welt ein angenehmes und reibungsfreies Leseerlebnis, was dem Zweck des geschriebenen Wortes entspricht: Bildung, Austausch und Weitergabe für jeden zugänglich.

Ein Fazit

Eine Nachbesserung bereits bestehender Backlists lohnt sich dann, wenn das erforderliche Grundgerüst von Anfang an mitgedacht wurde. Print lässt sich nicht einfach in eine technische Architektur konvertieren und ein optisch perfektes Ergebnis kann im Hintergrund trotzdem unvollständig sein. Das erschwert im Nachhinein auch die Nachbesserungen für für die geforderte Barrierefreiheit, was in der Natur der Sache liegt, wie du in diesem Artikel erfahren kannst.

Die Kosten sind nicht nur die Arbeitsstunden, die in die Reparatur selbst fließen. Eingesetzte Attribute und Codestrukturen müssen in vielen Fällen manuelle Tests durchlaufen. Die Fragen, die sich hierbei stellen, sind: wer muss es nutzen können, welche Barrieren verhindern das und welche Einzelakteure erfordern welche zugrundeliegenden Parameter, um Layoutstabilität und Barrierefreiheit zusammenzubringen? (hier nächsten Artikel 3 verlinken).

Die Anpassung der hauseigenen Workflows und das Nachbessern externer oder interner Kompetenzen ist hier ein wichtiger erster Anfang. Ein Compiler-basierter Workflow kann nicht alle Herausforderungen automatisch auffangen, aber so weit minimieren, um sich und seinem Team für andere nötige Arbeitsschritte mehr Luft zu verschaffen. Allen voran aber auch um Rechtssicherheit zu erhöhen und Haftungsrisiken zu minimieren.

Das macht zukünftige Herstellungsprozesse kalkulierbarer und sorgt für das digitale Leseerlebnis für die Leserschaft, um die es am Ende eigentlich geht.

Weiterführende Standards & Primärquellen

Thema	Relevanz für den Artikel	Offizielle Quelle
Code-Validierung & Syntaxfehler	Prüfmaßstab für die technische Fehlerfreiheit von EPUB-Dateien bei Distributoren.	W3C EPUBCheck auf GitHub
Semantische Web-Architektur	Technischer Standard für die Trennung von Struktur und Präsentation im Reflowable Format.	W3C EPUB 3.3 Specification
Barrierefreies E-Book	Official W3C Recommendation für die Umsetzung barrierefreier EPUB-Publikationen.	EPUB Accessibility 1.1