Abstract
Einen (kostenlosen) E‑Book‑Output für eine digitale Edition zu erstellen ist technisch einfacher, aber konzeptionell herausfordernder, als zunächst gedacht.
Für die technische Umsetzung gibt es verschiedene Ansätze: Ich teste und diskutiere Softwarelösungen, das oXygen-interne TEI-P5-zu-EPUB-Transformationsszenario sowie eine eigene XSL-Transformation und vergleiche Möglichkeiten, E‑Books sowohl in den offenen EPUB- als auch den proprietären Amazon‑Formaten zu erstellen.
Konzeptionell stelle ich die Frage, ob sich interessierte Laien als neue Zielgruppe gewinnen lassen und ob diese überhaupt über die üblichen Plattformen erreicht werden können. Zudem untersuche ich, welche Teile wissenschaftlicher Editionen sich überhaupt für eine lineare Lesefassung eignen und wie stark ihre Inhalte dafür vereinfacht werden müssen.
Inhalt
- 1. Bedarf
- 2. Konzeption
- 3. Technische Umsetzung
- 4. (Exkurs) Laien als Zielgruppe – Zugänglichkeit neu denken
- 5. Fazit
Als jemand, der sehr gerne und sehr viel Literatur im E‑Book‑Format liest, stellte ich mir die Frage, ob man nicht die Inhalte der digitalen Editionen[1], an denen ich mitarbeite, als E‑Book zur Verfügung stellen könnte.
Aus dieser naiven Ausgangsfrage entwickelten sich schnell drei konkrete Folgefragen:
- Gibt es einen Bedarf?
- Wer ist die Zielgruppe und was bedeutet das für die Konzeption?
- Wie ist es technisch umsetzbar?
1. Bedarf
Zur Frage nach dem Bedarf war das ernüchternde Ergebnis einer ersten (nicht repräsentativen) Umfrage: kennt keiner, nutzt keiner, bietet keiner an. Auch eine Onlinesuche nach Editionsprojekten, die einen E‑Book‑Output anbieten, war nicht erfolgreich[2].
Aber bedeutet das, Editionen bieten keine E‑Books an, weil sie niemand lesen will? Oder liest niemand E‑Books, weil keine Edition sie anbietet?
Da kommerzielle Wissenschaftsverlage durchaus E‑Books vertreiben, unterstelle ich, dass es einen Markt gibt, das grundsätzliche Interesse also da ist. Im naturwissenschaftlichen Bereich sind digitale Publikationen ohnehin gang und gäbe und auch im geisteswissenschaftlichen Bereich werden viele Titel – selbst von textkritischen Editionen – zumindest auch als E‑Book neben einer Printversion angeboten. Einer Umfrage[3] aus dem Jahr 2024 nach lesen zumindest 40% der Befragten „hin und wieder” E‑Books (und 81% gedruckte Bücher), wobei die Akzeptanz bei jüngeren Leuten deutlich höher ist (50%) als bei älteren (ab 65 Jahre: 15%) Aber in Anbetracht der Tatsache, dass schon der Ausgangspunkt – die digitale Edition – stärker von einer jüngeren Zielgruppe genutzt wird, ist diese Diskrepanz für die weiteren Überlegungen nicht relevant.
Wenn ein Editionsprojekt seine Inhalte zusätzlich als E‑Book zur Verfügung stellt, scheint das somit zunächst eine kostengünstige Möglichkeit zum Hybrid-Selbstverlag zu sein. Die Herausforderungen beim Selbstverlag sind natürlich bekannt: Oft fehlt es in Projekten an Ressourcen und Know-how in Bereichen wie Layout, (Fein-)Typografie und Satz. Aber während im professionell gedruckten Buch hohe gestalterische Ansprüche gelten, die mit eigenem PDF‑Output nur selten erreicht werden, verschiebt sich der Fokus beim E‑Book auf andere Aspekte. Entscheidend ist nicht mehr eine perfekte visuelle Gestaltung, sondern im Gegenteil eine saubere technische Umsetzung, die flexible Ansichten ermöglicht und auf unterschiedlichen Geräten zuverlässig funktioniert. Ist das ein Vorteil für Editionsprojekte?
Zusammengefasst: Einen konkreten Bedarf kann ich zwar nicht nachweisen, aber um nicht an dieser Stelle bereits abbrechen zu müssen, unterstelle ich ein grundsätzliches Interesse, das dem allgemeinen Trend zur steigenden E‑Book-Nutzung folgt.
2. Konzeption
E‑Books sind digitale Bücher, die auf speziellen Geräten (E‑Readern) oder Apps gelesen werden. Sie unterscheiden sich von gedruckten Büchern (und statischen PDFs) dadurch, dass die LeserInnen die Darstellung nach ihren individuellen Wünschen anpassen können (etwa Schriftgröße und -art verändern) und von digitalen Textformaten wie HTML dadurch, dass sie nur sehr reduzierte Funktionalitäten bieten (etwa nur eine begrenzte Einbindung von Medien und kaum interaktive oder dynamische Zugangsmöglichkeiten).
Bevor es an die technische Umsetzung geht, muss zunächst das Ziel abgesteckt und konzeptionell durchdacht werden. Wie sich herausstellte, ist dieser Schritt deutlich komplexer, schwieriger und wichtiger, als anfangs gedacht und wirft einige sehr grundsätzliche editorische Fragen auf.
2.1 Allgemeine konzeptionelle Überlegungen
Zunächst die naiven, naheliegenden Überlegungen. Da es sich bei Editionen – insbesondere bei textkritischen und/oder synoptisch angelegten – um hochgradig strukturierte, heterogene Daten handelt und E‑Books lediglich eine stark reduzierte Ausgabe erlauben, ist es entscheidend festzulegen, welche Informationen wie abgebildet oder weggelassen werden.
Da E‑Books noch mehr als gedruckte Bücher linear gelesen werden (müssen), stellen insbesondere Inhalte, die auf eine starke interne Vernetzung setzen, ein Problem dar. Links sind in E‑Books zwar möglich, aber auf E‑Readern ist das Hin- und Herspringen oder Blättern über längere Abschnitte hinweg unkomfortabel. Das heißt, in einer idealen E‑Book-Welt lässt sich der Text ohne nennenswerten Informationsverlust linear von vorne bis hinten durchlesen, was allerdings der Realität und dem Anspruch vieler Editionen entgegensteht, die möglichst viele verschiedene, gerade nicht linear vorgegebene Zugänge zum Material bieten wollen.
Dynamisches Ein- und Ausblenden von Segmenten, z. B. Popups, oder ständiges Hin- und Herspringen zwischen Haupttext, Apparaten, Registern oder gar externen Webressourcen ist auf den meisten E‑Readern nicht möglich[4]. Das bedeutet, der Text muss auch ohne diese Ebenen in sich geschlossen und verständlich sein.
Auch dürfen weder das Textverständnis noch die Struktur von der visuellen Gestaltung abhängen. Da Layout und Satz im E‑Book nicht statisch sind, sondern sich je nach Gerät, Bildschirmgröße und Nutzereinstellungen verändern, müssen die Inhalte unabhängig von ihrer Präsentation erkennbar bleiben. Seitenumbrüche sind fluide und insbesondere ältere Geräte unterstützen keine Farben, sondern ausschließlich schwarz-weiße Darstellungen. Strukturen, die stark auf visuelle Unterscheidungen oder Positionierung setzen – etwa die Präsentation verschiedener Textzeugen oder Übersetzungen nebeneinander, farbliche Hervorhebungen, typografische Differenzierungen, Texteinrückungen oder Positionierung von Marginalien – lassen sich deshalb nur eingeschränkt oder gar nicht umsetzen.
Medien wie Bilder, Videos oder Audiodateien werden von nur von wenigen E‑Readern überhaupt dargestellt und führen zu einem enormen Anstieg der Dateigröße, was sich negativ auf die Ladezeiten und die allgemeine Performance auswirkt.
Typische Aspekte einer Edition, die aufgrund der genannten Eigenschaften gekürzt, vereinfacht oder ganz weggelassen werden müssen, sind z. B.:
- Zentrale Informationen
- Apparate (z. B. Sachanmerkungen, Textkritik, Varianten)
- Overlay-Informationen (z. B. Popups, Tooltips)
- Externe Vernetzung (z. B. Normdaten, Digitalisate)
- Ordnung/Hierarchisierung der Informationen
- Synoptische Darstellungen (z. B. Textzeugen, Übersetzungen)
- Hervorhebung (z. B. Farben, Schriftgröße, Positionierung)
- Alternative Zugänge zum Material
- Register (z. B. Personen, Orte, Werkzusammenhänge)
- Visualisierungen (z. B. Illustrationen, Graphen, Karten)
- Medien (z. B. Audio, Video)
- Suche/Filter (z. B. individuelle Korpuszusammenstellung, Ansichten-/Suchfilter)
Auch wenn die konkrete Zielgruppe eingangs nicht sicher umrissen werden konnte, muss ich doch wieder auf diese Frage zurückkommen. Denn um zu entscheiden, welches die wesentlichen Teile einer Edition sind und welche weggelassen werden können, müssen zwei Seiten zusammengebracht werden: 1. was die EditorInnen als das Wesentliche ihrer Arbeit ansehen und 2. was – in welchem Kontext – für die LeserInnen das Wesentliche ist.
Das Ergebnis einer – wieder nicht repräsentativen – Umfrage war, dass diese beiden Seiten mitunter deutlich auseinandergehen. Für LeserInnen steht beim E‑Book der unkomplizierte Zugang zum Inhalt im Vordergrund. Sie wünschen sich einen interessanten und flüssig lesbaren Text, ohne sich mit komplexen wissenschaftlichen Hintergrundinformationen auseinandersetzen zu müssen. Elemente wie textkritische Apparate, Variantenvergleiche oder vielschichtige Querverweise sind von nachgeordneter Bedeutung. Für EditorInnen hingegen steckt gerade in diesen wissenschaftlichen Ebenen ein zentraler Teil ihrer Arbeit. Werden sie weggelassen, bleibt ein wesentlicher Teil ihrer editorischen Leistung unsichtbar.
Dieses Spannungsverhältnis lässt sich leicht auflösen, wenn man das E‑Book nicht als den Output der Edition versteht, sondern lediglich als einen von mehreren, die alle auf unterschiedliche Zwecke hin gestaltet sind – beim E‑Book eine einfache Lesefassung. Genauso, wie auch eine gedruckte Fassung einen anderen Schwerpunkt setzt als beispielsweise die Darstellung in Form einer Graphdatenbank oder eine Parallelansicht von Text und Faksimile.
Eine – in welcher Form auch immer vorgenommene – Reduzierung auf einen einzigen Lesetext ohne Varianten oder vertiefende (sprach-)wissenschaftliche Erklärungen lässt sich vielleicht mit dem Ansatz von Reclam vergleichen: Das Ziel ist, „Bildung für alle zu ermöglichen”, indem „Leserinnen und Lesern jeden Alters Zugang zu Literatur – mit Klassikern der Weltliteratur” ermöglicht wird, durch die „verständliche […] und zeitgemäße […] Aufbereitung anspruchsvoller Inhalte”.[5] Reclam-Ausgaben sind eine niederschwellige, kostengünstige Möglichkeit, sich mit Texten verschiedenster Gattungen und Epochen auch außerhalb des eigenen Fachs zu befassen, einfach, weil sie einen interessieren. Wissenschaftliche (digitale) Editionen hingegen wirken oft unübersichtlich, abschreckend und zum einfachen Lesen zu kompliziert.
Ein Editor formulierte in diesem Zusammenhang einen sehr wichtigen Gedanken, der in wissenschaftlichen Editionsprojekten meines Erachtens oft untergeht: Warum nicht die edierten Texte auch für interessierte Laien zugänglich machen? Ein E‑Book‑Output kann meines Erachtens genau das leisten, indem es die Forschungsergebnisse auf niederschwellige Weise über den engen wissenschaftlichen Kreis hinaus einem breiteren Publikum näherbringt.
Aber dann wurde ich mit der berechtigten Frage konfrontiert, wie sich eine so radikal gekürzte E‑Book-Version rechtfertigen lässt, wenn doch auch eine PDF-Fassung erstellt werden kann, die auf der einen Seite viele der wissenschaftlichen Hintergrundschichten, z. B. Apparate, beibehält, es den LeserInnen aber auf der anderen Seite freistellt, diese bei Bedarf einfach zu überspringen. Warum also reicht eine PDF nicht aus?
Meiner Ansicht nach ist hier vor allem ein Argument ausschlaggebend: Barrierefreiheit. Nicht nur Menschen mit Behinderungen profitieren von barrierefreien Angeboten, sondern alle, da diese im Idealfall besonders durchdacht, klar strukturiert und intuitiv gestaltet sind. Weil bei PDFs das Layout starr ist, müssen sie auf kleineren Geräten oder Bildschirmen wie Handys, Tablets und E‑Readern umständlich gezoomt und gescrollt werden. Das macht die Nutzung schwierig und für Personen mit Einschränkungen mitunter gänzlich unmöglich. E‑Books hingegen sind deutlich inklusiver: Sie lassen sich mit Screenreadern nutzen, Schriftgröße und Kontrast können individuell angepasst werden, und der Text kann vorgelesen oder in Blindenschrift umgewandelt werden.
Zudem zwingt die Arbeit an E‑Books dazu – so meine Erfahrung der letzten Monate –, die edierten Inhalte unabhängig von ihrer visuellen Präsentation wieder mehr als Daten zu betrachten. Denn wenn „[v]isuelle Gewichtungen durch Farbe, Schriftgröße oder Positionierung […] bei der Nutzung von Screenreadern oder Braillezeilen verloren gehen”[6], müssen die wesentlichen Teile der Edition ohne diese visuellen Hilfsmittel identifiziert, strukturiert und hierarchisiert werden, was zu einer neuen Auseinandersetzung mit den eigenen Inhalten anregt.
2.2. Der konkrete Anwendungsfall – vier Projekte
Die Entscheidung, in welcher Form – und ob überhaupt – sich eine Edition für eine E‑Book-Fassung anbietet, kann natürlich nicht global, sondern nur für jedes Projekt einzeln getroffen werden. In meinem Fall kommen die folgenden vier Projekte in Frage, die sich hinsichtlich Fachbereich, Umfang und Inhalt stark unterscheiden.
Rhodomanologia: eine textkritische Edition spätmittelalterlicher altgriechisch-lateinischer Lyrik (Klassische Philologie)
Die Texte dieser Edition eignen sich sehr gut für einen E‑Book‑Output. Derzeit umfasst die Edition etwa 75 Gedichte des Dichters und Schullehrers Lorenz Rhodoman zu Themen wie Bibelkunde, Theologie, griechischer Mythologie und Schul- und Bildungsgeschichte sowie persönliche Briefgedichte und Grabinschriften. Obwohl das Projekt seinen Forschungsschwerpunkt auf literarische und metrische Analysen legt, sind die Inhalte durch ihr breites Themenspektrum auch für interessierte Laien zugänglich. Hinzu kommt, dass viele Gedichte zweisprachig in Griechisch und Latein überliefert (und vom Projekt auf Deutsch übersetzt) sind, was sie zusätzlich für Studierende der Altphilologie interessant macht.
Niklas-Luhmann-Archiv: eine textkritische Edition des wissenschaftlichen Nachlasses von Niklas Luhmann (Soziologie)
Der Nachlass des Soziologen Niklas Luhmann ist deutlich diverser und eignet sich nur zum Teil für einen E‑Book‑Output. Der Nachlass besteht aus zwei Hauptkomplexen: einem Zettelkasten mit etwa 90.000 Zetteln sowie etwa 3.900 Manuskripten, bzw. Typoskripten. Aber das Projekt lebt zusätzlich vor allem von seiner bibliographischen Datenbank, die aktuell etwa 2.700 Bücher und Aufsätze enthält, die von Luhmann selbst verfasst wurden, sowie weiteren 14.000 Titeln, die er in seiner privaten Arbeitsbibliothek stehen hatte und/oder nachweislich bei der Entwicklung seiner Theorien herangezogen und zitiert hat. Diese bibliographische Datenbank ist immens wichtig für die Forschung, aber kein Inhalt, der sich zum gemütlichen Lesen als E‑Book anbietet.
Auch die Zettel enthalten vor allem Stichworte, Gedanken, Argumente und Literaturhinweise, die erst durch ihre exzessive Vernetzung das Gesamtwerk ausmachen, aber für sich alleine genommen eher wenig unterhaltsam zu lesen sind.
Die Manuskripte wiederum sind entweder stichpunktartige Vortrags- und Vorlesungsskripte oder sorgfältig konzipierte Aufsätze oder Monographien, die zur Printpublikation vorgesehen waren. Allerdings liegen diese oft in verschiedenen Bearbeitungsfassungen vor und müssten erst editorisch zu einer finalen Fassung zusammengesetzt werden. Die Edition versucht zwar, die oft stark annotierten Fassungen so aufzubereiten, dass sich ein Lesetext konstituieren ließe, allerdings sind dafür trotzdem zu viele editorische Einzelfallentscheidungen notwendig, als dass sich ohne Mehraufwand eine gute E‑Book-Fassung automatisiert erzeugen ließe. Das wiederum ist aber eine Voraussetzung, um einen E‑Book‑Output sinnvoll und ressourcenschonend in den bestehenden Projektworkflow zu integrieren.
VedaWeb: eine linguistische Forschungsplattform für altindische Hymnen (Indologie)
Das VedaWeb-Projekt scheint auf den ersten Blick die Voraussetzungen für einen E‑Book-Export perfekt zu erfüllen. Es stellt auf einer Plattform insgesamt sechs in sich geschlossene, vedische (indogermanische Sprache, Vorgänger des Sanskrit) Texte mit Hymnen von ca. 1300–1000 v. Chr. zusammen, die von großer historischer und religiöser Bedeutung sind. Zwar liegt der Fokus des Projektes auf der linguistischen und philologischen Arbeit, aber eine Lesefassung ließe sich recht einfach extrahieren. Allerdings ist das Projekt nicht als Editionsprojekt angelegt, sondern als „kollaborative Forschungsumgebung”, auf der die zur Verfügung gestellten Texte „von den BenutzerInnen der Plattform mit verschiedenen Arten von Annotationen, verfügbaren Übersetzungen sowie mit Links zu Wörterbuch-Einträgen angereichert werden können”[7]. Das bedeutet, das Projekt erstellt keine eigene Edition der Texte, sondern trägt bestehende Editionen zusammen. Daraus eine E‑Book-Lesefassung zu generieren, wirft somit Urheberrechtsfragen auf, die erst sorgfältig geprüft werden müssten. Zudem sind die Texte so bekannt und wichtig, dass sie bereits als E‑Books in mehreren Sprachen verfügbar sind.
Astronautilia (in Vorbereitung): eine textkritische Edition eines neuzeitlichen, altgriechisch-tschechischen Sci-Fi-Romans (Klassische Philologie)
Der Text dieser Edition eignet sich vermutlich am besten für einen E‑Book‑Output. Das Projekt befindet sich zwar noch in Vorbereitung, aber gerade deshalb kann die E‑Book-Fassung besser als bei den anderen Projekten von Anfang an mit bedacht werden. Inhaltlich geht es um ein außergewöhnlich bizarres Werk: ein Science-Fiction-Epos in ca. 6.600 Versen aus den 1990ern, verfasst auf Altgriechisch und Tschechisch. Im Rahmen des Projektes wird eine deutsche (möglicherweise auch eine englische Übersetzung) erstellt, während der fachwissenschaftliche Fokus wie bei Rhodomanologia auf der literarischen und metrischen Analyse und der Kommentierung liegt. Der außergewöhnliche Inhalt des Textes macht eine Lesefassung für ein deutlich breitgefächerteres Laienpublikum interessant, als die bisher genannten Projekte. Und auch für Altgriechisch-Lernende würde es die Literaturauswahl angenehm und spielerisch erweitern.[8]
Ob sich eine Edition für einen E‑Book‑Output eignet, hängt also stark vom konkreten Projekt ab:
- Rhodomanologia und Astronautilia sind besonders geeignet, da sie literarisch interessant und auch für Laien zugänglich sind.
- Das Niklas-Luhmann-Archiv eignet sich nur eingeschränkt, da viele Inhalte aus nicht-literarischen Dokumenttypen wie Notizzetteln, bibliographischen Datensätzen und Druckvorstufen bestehen und erst durch komplexe Vernetzungen untereinander ein Gesamtwerk ergeben.
- VedaWeb ist wegen urheberrechtlicher Fragen und bereits vorhandener E‑Book-Ausgaben ungeeignet.
Fazit zur Konzeption
Obwohl – oder gerade weil – E‑Books nur einen stark reduzierten Ausschnitt einer digitalen Edition darstellen, ist ihre Konzeption in Bezug auf Zweck, Inhalt und Zielgruppe ein komplexer und wichtiger Schritt. Da E‑Books im Gegensatz zur digitalen Edition stark linear aufgebaut und technisch eingeschränkt sind, müssen viele Inhalte vereinfacht oder weggelassen werden. Sie müssen ohne Apparate, synoptische Darstellungen oder interaktive Elemente verständlich sein und dürfen nicht von der visuellen Gestaltung abhängen. Das zwingt dazu, Inhalte strukturell sauber aufzubereiten und fördert eine datenzentrierte Sicht auf editorische Arbeit. Ähnlich wie Reclam-Ausgaben sollen die E‑Book-Exporte komplexe Inhalte als einen leicht zugänglichen und flüssig lesbaren Text bereitstellen. Idealerweise kann ein E‑Book Forschungsergebnisse somit auch für ein breiteres (Laien-)Publikum öffnen. Ein wichtiges Argument für die Bereitstellung von E‑Books ist zudem die Barrierefreiheit. Anders als PDFs sind sie kompatibel mit Screenreadern, nach individuellen Wünschen oder Einschränkungen anpassbar und lassen sich in Blindenschrift umwandeln. Aber nicht jede Edition eignet sich für einen E‑Book‑Output.
Um den konzeptionellen und technischen Workflow einmal durchzuspielen, habe ich mich im Folgenden auf die Erstellung von E‑Books im Rhodoman-Projekt konzentriert.
3. Technische Umsetzung
Die erste Hürde beim Erstellen eigener E‑Books ist das Format. Es existieren verschiedene Formate nebeneinander und nicht jedes Format ist mit jedem E‑Reader kompatibel und umgekehrt.
Das wichtigste Format ist EPUB – ein offenes, nicht-proprietäres Format, entwickelt vom IDPF / W3C, das von einer Vielzahl von Geräten (z. B. Tolino, Kobo), Apps (z. B. Apple Books, Google Play Books) und Browsern gelesen werden kann. Aber Marktführer in Deutschland bei E‑Readern ist (neben dem Tolino von Thalia) der Kindle von Amazon[9] und dieser ist mit EPUB nicht kompatibel[10]. Stattdessen setzt Amazon auf eigene proprietäre Formate: MOBI (das älteste), AZW, AZW3 und KFX (die neuste Version). Diese werden wiederum von E‑Readern wie Tolino und Kobo nicht unterstützt. Um Inhalte für eine möglichst breite Zielgruppe zugänglich zu machen, müssen also sowohl die Amazon- als auch die Nicht-Amazon-Geräte bedient werden, das heißt mindestens die Formate EPUB und KFX bereitgestellt werden, sowie idealerweise auch Formate für die älteren Kindle-Geräte (MOBI, AZW, AZW3). Mithilfe externer Software lässt sich EPUB in die Amazon‑Formate überführen, sodass es für meine Versuche ausreicht, mich zunächst auf die Erstellung der EPUB zu konzentrieren und die Amazon‑Formate daraus abzuleiten.
Um eigene E‑Books zu erstellen, gibt es verschiedene Möglichkeiten, die ich im Folgenden vorstelle.
3.1. Selfpublishing Web-Angebote
Onlinedienste (beispielsweise Feiyr) übernehmen einen Teil der klassischen Verlagsaufgaben, unter anderem die technische Aufbereitung des E‑Books für verschiedene Endgeräte, die Bereitstellung in gängigen Online-Shops (wie Amazons Kindle Store, Apple Books oder Thalia) sowie die Abwicklung von Verkauf und Abrechnung. Der offensichtliche Vorteil liegt darin, dass die veröffentlichten E‑Books eine hohe Sichtbarkeit erreichen und in professionellen Vertriebskanälen erscheinen, ohne dass ein klassischer Verlag eingeschaltet werden muss. Der Nachteil ist, dass diese Dienstleistungen kostenpflichtig sind und an einen externen Anbieter abgegeben werden, was ja gerade beides vermieden werden soll. Deshalb habe ich diesen Ansatz nicht weiterverfolgt.
3.2. Software zur EPUB-Erstellung
Programme wie Calibre oder Sigil sind eine einfache Möglichkeit, lokal E‑Books zu erstellen, ohne sich mit technischen Details beschäftigen zu müssen. Nach der Eingabe der Inhalte und Metadaten kann die Datei mit wenigen Klicks automatisch generiert werden. Während Calibre nicht nur EPUB‑Dateien erzeugen, sondern diese bei Bedarf auch in die Amazon‑Formate konvertieren kann, bietet Sigil diese Option nicht. Der Vorteil dieser und ähnlicher Programme liegt in der einfachen Bedienung und in der hohen Wahrscheinlichkeit, dass die erzeugten E‑Books auf verschiedenen E‑Readern korrekt funktionieren. Der Nachteil ist, dass die Konfigurationsmöglichkeiten begrenzt sind und die internen Abläufe verborgen bleiben, was projektspezifische Anpassungen erschwert. Aus diesem Grund habe ich die Programme zwar nicht zur Erstellung der EPUB genutzt, Calibre aber sowohl für die Konvertierung in die Amazon‑Formate, als auch als E‑Book-Lese-App eingesetzt.
3.3. Im oXygen XML Editor integrierte „TEI P5 EPUB Transformation”
Eine auf den ersten Blick ideale Lösung: der – ohnehin in allen vier Projekten verwendete, allerdings proprietäre – oXygen XML Editor bietet eine bereits integrierte Transformationsmöglichkeit von TEI-XML – die Datenbasis in ebenfalls allen Projekten – zu EPUB. Die anfängliche Euphorie war allerdings nur von kurzer Dauer. Die Ergebnisse der ersten naiven Transformationen waren nicht zu gebrauchen – vergleiche die Darstellung in der digitalen Edition mit dem EPUB-Export (Abb. 1).
Abb. 1: Vergleichende Darstellung eines Gedichts in der digitalen Edition (links) und dem EPUB-Export (rechts).
Die Ausgangs-XML enthalten viel zu viele Daten, die eben nicht in den EPUB‑Output übernommen werden sollen, z. B. <pb/>-Elemente für Seitenumbrüche, extensive Metadaten im <teiHeader/>, Apparate, diplomatische Versfassungen und Marginalien. Auch die automatisierte Übersetzung der TEI-Elemente in die für EPUB benötigten XHTML-Strukturen spiegelt häufig nicht die vom Projekt intendierte Hierarchie wieder. Insbesondere die Struktur der Gedichtverse mit ihren jeweils zwei oder drei Sprachen wurde nicht adäquat erkannt. Zudem werden elementare Bestandteile wie die Verszahlen (kodiert im @n-Attribut in <l n=“…”/>) gar nicht übernommen, dafür aber Titel und Kapitel automatisiert aus den völlig falschen Elementen „generiert”. Die Ausgangs-XML müssten also zunächst durch eigene Arbeitsschritte vorprozessiert und in ein reduziertes Übergangs-TEI-XML gebracht werden, das von der Transformation dann in das finale XHTML‑Format übersetzt werden kann.
Auch das Styling der generierten Datei war unbrauchbar. Beispielsweise waren die Sprachen in den Gedichten nicht durch Zeilenumbrüche voneinander abgesetzt. Wenn es eine Möglichkeit zur Anpassung während der Erstellung gibt, beispielsweise durch das Einbinden eigener CSS-Stylesheets, konnte ich sie nicht finden. Auch die offizielle Dokumentation liefert dazu keine Hinweise, sondern bezieht sich nur auf das Post-Processing der erzeugten EPUB‑Dateien, was im Projektworkflow nicht praktikabel ist.
Da es sich um eine oXygen-interne Transformation handelt, kann diese auch nicht ohne weiteres aufgebohrt und manuell angepasst werden. Stattdessen muss in einer Kopie gearbeitet werden, was ich aber nach einigen erfolglosen Versuchen aufgegeben habe. Zum einen, weil die Transformation viel zu viel Ballast enthält (insb. extensive interne und externe Abhängigkeiten sowie Einzelschritte und -skripte) und zum anderen, weil der Vorprozessierungsschritt für ein reduziertes Input-TEI-XML dennoch weiterhin nötig bleibt.
Aus diesem Grund habe ich auch diesen Ansatz verworfen und stattdessen den „build from scratch”-Schritt gewagt.
3.4. Eigener Workflow zur EPUB-Erstellung mit XSL
Aus der Projektarbeit bin ich es gewohnt, Daten zwischen unterschiedlichen Formaten zu konvertieren. Die benötigten Transformationsskripte selbst zu schreiben, um jetzt ein EPUB‑Format zu erzeugen, lag somit nahe. Der offensichtliche Nachteil gegenüber den zuvor genannten Optionen sind eine höhere technische Einstiegshürde und größerer Arbeitsaufwand.[11]
Am Anfang steht die Analyse des Zielformats: Was genau ist EPUB und wie ist es aufgebaut? Das bedeutet: erst einmal die Spezifikation lesen. Erfreulicherweise ist EPUB im Kern XML-basiert und lässt sich somit wunderbar in unseren bestehenden Workflow integrieren. Konkret handelt es sich bei EPUB um ein ZIP-komprimiertes Archiv mit standardisierter Struktur. Es besteht im Wesentlichen[12] aus folgenden Bestandteilen:
- mimetype – Eine Textdatei mit dem Medientyp „application/epub+zip”. Sie muss unkomprimiert an erster Stelle stehen und ist kein
- xml – Eine technisch notwendige Datei, die dem Lesegerät mitteilt, wo sich der Einstiegspunkt (die OPF-Hauptdatei des E‑Books) befindet.
- opf – Eine XML‑Datei mit Metadaten (Titel, Autor, Identifier, Version, Datum usw.), einer Auflistung aller enthaltenen Dateien und der Lesereihenfolge.
- ncx (EPUB 2) bzw. toc.xhtml (EPUB 3) – (Optional) Ein Inhaltsverzeichnis im XML‑Format, aus dem das Lesegerät Sprungmarken und Navigation generiert.
- XHTML‑Dateien – Die eigentlichen Inhalte auf beliebig viele Dateien verteilt.
- CSS‑Dateien – (Optional) Für Layout und Formatierung.
- Ergänzende Ressourcen – (Optional) Bilder, Medien oder Schriftarten.
Mein Anspruch war es, die Transformation so aufzubauen, dass sie beliebig oft wiederholbar ist – ohne manuelle Eingriffe ins Endergebnis. Der E‑Book‑Output soll sich jederzeit aktualisieren lassen, falls sich die Ausgangs-XML‑Dateien ändern oder neue Inhalte hinzukommen. Abgesehen von der mimetype‑Datei, die grundsätzlich unverändert bleibt, und der CSS‑Datei, die einmal erstellt und nur bei Bedarf angepasst wird, müssen die Skripte somit automatisch:
- die XHTML-Inhaltsseiten aus den Ausgangs-XML generieren,
- die Metadaten- und Strukturdatei (package.opf) entsprechend aktualisieren,
- und die Inhaltsverzeichnisse (toc.ncx bzw. toc.xhtml) neu erzeugen.
Da es sich um eine XML-zu-XML-Transformationen handelt, bietet sich XSL als naheliegende Skriptsprache an. Lediglich den letzten Schritt – das Zippen der Einzeldateien zu einer Gesamt-EPUB‑Datei – konnte ich nicht über XSL steuern. Stattdessen habe ich dafür ein Pythonskript geschrieben.
Nachdem das Zielformat verstanden, das grundsätzliche Vorgehen mit XSL festgelegt und erste Tests erfolgreich waren, möchte ich im Folgenden auf einige unerwartete Herausforderungen und Fallstricke aus den Bereichen Technik, Design und Konzeption eingehen.
3.4.1. Technische Herausforderungen
Validierung: Damit die selbst erzeugten E‑Books auf den unterschiedlichen Lesegeräten und Apps korrekt dargestellt werden, müssen sie dem erwarteten Format entsprechen. Das bedeutet, sie müssen valide sein. Für diese Prüfung habe ich die freie Software EPUB-Checker verwendet. Das war sehr hilfreich, denn obwohl ich mich bemüht hatte, den Aufbau der EPUB möglichst genau an der Spezifikation auszurichten, machte mich die Validierung auf einige Punkte aufmerksam, die ich übersehen hatte. Beispielsweise war in den Metadaten das Datum zu kurz angegeben und entsprach nicht dem korrekten Format (s. Abb. 2).
Abb. 2: Fehlermeldung im Validierungstool EPUB-Checker zu falschem Datumsformat.
Überrascht und dankbar war ich auch für die Fehlermeldung „referenzierte Datei nicht gefunden”. Übergangsweise hatte ich eine spezielle Schriftart in der EPUB‑Datei eingebettet und die TTF‑Dateien in der OPF aufgelistet. Als das Einbetten des Fonts in einer späteren Fassung nicht mehr nötig war, habe ich zwar den Eintrag in der OPF gelöscht, aber vergessen, dass die Fonts auch in der CSS‑Datei über @font-face referenziert wurden, worauf mich erst die Validierung hinwies (s. Abb. 3).
Abb. 3: Fehlermeldung im Validierungstool EPUB-Checker zu einer Referenz im CSS auf eine nicht mehr vorhandene Datei.
Besonders, wenn der E‑Book‑Output immer wieder neu generiert wird, weil weitere Inhalte hinzukommen, ist es eine große Hilfe, wenn die Validierung auf Konsistenz achtet und sicherstellt, dass sämtliche Abhängigkeiten korrekt aufgelöst sind.
E‑Book-Identifier: Laut Spezifikation benötigt das E‑Book einen eindeutigen Identifier in der OPF: „The EPUB creator MUST provide an identifier that is unique to one and only one EPUB publication – its unique identifier – in an dc:identifier element”[13]. Dieser Identifier kann z. B. eine UUID, DOI oder ISBN sein. UUIDs lassen sich einfach selbst generieren, aber DOI und ISBN müssen von einer entsprechenden Organisation vergeben werden. Für eine zitierfähige Veröffentlichung des E‑Books wären letztere besser, aus einem Projekt heraus sind diese aber mitunter organisatorisch schwerer zu bekommen. Das Fehlen des Identifiers wurde auch bei der Validierung sofort korrekt gemeldet.
E‑Reader stürzt ab – Datei zu groß: Zum Testen der erzeugten E‑Books verwende ich auf dem PC die App Calibre und als Lesegerät einen Tolino Vision Color von Thalia. Eine erste E‑Book-Fassung enthielt alle Gedichte in allen drei Sprachen (Griechisch, Latein und Deutsch) jeweils untereinander pro Vers, wie in der digitalen Edition. Aber während Anzeige und Bedienung in Calibre problemlos waren, stürzte der Tolino beim Blättern regelmäßig ab. Da das Gerät mit Erscheinungsdatum 2024 und Kaufdatum 2025 noch sehr neu war und ich dieses Problem bei anderen – kommerziellen wie nicht-kommerziellen – E‑Books nicht hatte, lag die Ursache vermutlich in der Datei selbst. Und tatsächlich stellte sich als Grund die Dateigröße heraus, mit der der E‑Reader offenbar überfordert war. Die Datei enthielt sowohl ein Titelbild als auch einen eingebetteten griechischen Font. Letzterer war nötig, weil die Akzente im Griechischen zuvor nicht sicher korrekt angezeigt wurden (s. Abb. 4). Aber schon bei einer Testdatei mit lediglich drei Gedichten ergaben sich daraus folgende Dateigrößen:
| Dateigröße (in KB) | Titelbild | Fonts | |
| 1.928 | ✓ | ✓ | mit Titelbild + mit Fonts |
| 1.178 | ✓ | ✗ | mit Titelbild + ohne Fonts |
| 769 | ✗ | ✓ | ohne Titelbild + mit Fonts |
| 19 | ✗ | ✗ | ohne Titelbild + ohne Fonts |
Das Problem war somit eindeutig das zu große Titelbild. Zwar gibt es Möglichkeiten, die Dateigröße insbesondere von EPUB mit Bildern zu reduzieren, aber da ich persönlich das Titelbild als nicht so elementaren Teil sehe, habe ich diesen Weg vorerst nicht weiterverfolgt und das Bild in den nachfolgenden Fassungen schlicht weggelassen. Kurioserweise konnte ich das Problem mit der fehlerhaften Akzentdarstellung später selbst ohne eingebetteten Font nicht mehr reproduzieren und auch bei Testpersonen, die verschiedene andere Lesegeräte verwendeten, war die Darstellung stets fehlerfrei. Somit konnte ich glücklicherweise auf die eingebetteten Fonts verzichten – auch wenn ich bis heute keine Erklärung für diesen Bug gefunden habe.
Abb. 4: Fehlerhafte Akzentdarstellung im Griechischen.
Inhaltsverzeichnis nicht erkannt: Das Inhaltsverzeichnis eines E‑Books ist nicht bloß eine normale Textseite, sondern auch eine technische Navigationsfunktion. Die Lesegeräte erzeugen daraus ein eigenes Menü, das als Popup oder Seitenleiste erscheint und Sprungmarken zu den einzelnen Abschnitten anbietet. Es kann auf zwei Arten definiert werden: über die Datei toc.ncx (EPUB 2) oder über toc.xhtml (EPUB 3). Obwohl der von mir verwendete Tolino das Format EPUB 3 und damit toc.xhtml als Inhaltsverzeichnisdatei unterstützt und die Validierung keine Fehler in der Datei oder ihrer technischen Zuweisung über das @properties-Attribut meldete, wurde es auf dem E‑Reader dennoch nicht erkannt. Auch bei Tests auf anderen Geräten war das Navigationsmenü stets leer bzw. die Funktion nicht verfügbar. Lediglich Calibre setzte das Menü ohne Probleme um. Die toc.ncx hingegen funktionierte fehlerfrei. Eine Erklärung konnte ich bislang nicht finden. Glücklicherweise ist es möglich – und aus Gründen der Rückwärtskompatibilität ohnehin empfehlenswert –, stets beide Dateien anzubieten, damit sowohl neue als auch alte Lesegeräte ein Navigationsmenü generieren können, sodass dieses Problem zwar frustrierend unerklärlich aber zumindest leicht zu lösen war.
Lesegeräte-Simulatoren: Die Vielzahl an Lesegeräten und Apps ist vergleichbar mit dem Problem digitaler Editionen, auf allen möglichen Betriebssystemen, Browsern und Bildschirmgrößen funktionieren zu müssen. Während sich im Webbereich jedoch verschiedene Umgebungen simulieren lassen, um die Darstellung einer Edition gezielt zu prüfen, konnte ich für E‑Book-Lesegeräte kein vergleichbares Tool finden. Dabei wäre es sehr hilfreich, unterschiedliche Geräte vergleichen zu können, um ein Gefühl dafür zu bekommen, ob – und an welchen Stellen – sich die Darstellungen unter Umständen so signifikant unterscheiden, dass sie konzeptionell berücksichtigt werden müssen.
Apps wie Calibre oder Adobe Digital Editions erlauben zwar das Lesen von E‑Books auf dem PC oder Mac, simulieren aber keine konkreten Geräte. Der Kindle Previewer wiederum ist eigentlich genau dafür gedacht, die Darstellung der Amazon‑Formate auf verschiedenen Kindle-Geräten zu testen, jedoch konnte ich das Programm nicht wie gehofft nutzen, weil ich bei meinen Dateien die Fehlermeldung bekam: „Kindle Previewer unterstützt diese Datei nicht, da sie […] [mit] einer Drittanbieteranwendung erstellt wurde”. Somit war das Tool für meine Tests der mittels Calibre erzeugten Amazon E‑Book-Versionen leider unbrauchbar. Das Laden der EPUB‑Dateien hingegen funktionierte im Kindle Previewer unerwarteterweise gut, sodass ich dort zumindest grob die Anzeige auf Tablet, Smartphone und einem generischen Kindle-E‑Reader[14] vergleichen konnte. So wurden beispielsweise auf Tablet und Smartphone die Links im Inhaltsverzeichnis blau dargestellt, in der Kindle-Ansicht hingegen nicht, da die meisten E‑Reader keine Farben wiedergeben können. Auch die Anzahl der pro Seite angezeigten Zeilen variierte je nach Gerätegröße. Auf dem Smartphone brachen zudem die Zeilen aufgrund des schmaleren Displays früher um (s. Abb. 5).
Abb. 5: Simulierte E‑Book-Vorschau für Tablet, Smartphone und E‑Reader.
3.4.2. Design-Herausforderungen
Die meisten Design-Herausforderungen hingen damit zusammen, dass kaum vorhersehbar ist, wie – oder überhaupt ob – ein Lesegerät die mitgegebenen CSS-Anweisungen interpretiert und umsetzt. Wirklich zuverlässig funktionierten auf den getesteten Geräten und in den Apps nur sehr grundlegende Formatierungen wie Fett, Kursiv oder Unterstreichung. Auch Zentrierung wurde überraschend konsistent umgesetzt, obwohl sie bereits eine Form von Positionierung darstellt. Unsicherer waren dagegen zeichenbasierte Formatierungen wie Kapitälchen oder die Darstellung des Griechischen, weil sie jeweils von der auf dem Gerät verfügbaren Standardschriftart abhängen. Ebenso unvorhersehbar war, wie ein Gerät klassische XHTML-Strukturelemente – etwa Überschriften (<h1>) oder Absätze (<p>) – behandelt und ob es dabei den mitgegebenen CSS-Vorgaben folgt oder ein eigenes, im Gerät hinterlegtes Design verwendet.
Als besonders problematisch erwies sich der Seitenumbruch. Im Rhodoman-Projekt ist jede Einheit als eigene XHTML‑Datei angelegt, die wiederum mehrere Gedichte enthalten kann, verschachtelt in <div>-Elemente. Alle Reader setzen automatisch vor jeder neuen XHTML- Datei einen Seitenumbruch. Mein Wunsch war es aber, dass auch jedes darin enthaltene Gedicht auf einer neuen Seite beginnt, also ein page-break vor jeder <div>. Während Calibre diese Anweisung zuverlässig umsetzt, wurde sie von den getesteten Tolino-Geräten ignoriert – unabhängig davon, ob ich die ältere, theoretisch abwärtskompatible CSS-Variante page-break-before:always; oder die neuere break-before:page; verwendet habe. Der Kindle Previewer suggeriert zwar eine korrekte Umsetzung, letztlich hängt das Ergebnis aber auch dort wohl vom konkreten Gerät ab.
Schwierig war auch die Darstellung des Inhaltsverzeichnisses, genauer der toc.xhtml als Textseite (also nicht des aus der toc.ncx generierten Navigationsmenüs). Der Tolino scheint intern zwar die Anweisung zu haben, die <li>-Einträge einer <ol> automatisch zu nummerieren, liefert jedoch keine eigene CSS-Regel, die sicherstellt, dass für diese Zahlen ausreichend Platz vorhanden ist. Mehrstellige Zahlen wurden dadurch abgeschnitten (s. ab Eintrag 10 in Abb. 6). Die Lösung bestand darin, die Einrückungen über CSS mit margin und padding zu definieren. Aber ob die E‑Reader diese Vorgaben tatsächlich umsetzen, bleibt offen.
Abb. 6: Fehlender Platz im Navigationsmenü des Lesegeräts für automatisiert generierte Nummerierung.
Dieses Misstrauen ist nicht unbegründet, denn dass Einrückung per CSS problematisch sein kann, zeigte sich an den Verszahlen. Zunächst wollte ich diese, wie in der Printtradition üblich und auch in der digitalen Edition umgesetzt, in Fünferschritten ausrücken. Auf meinem Tolino (Erscheinungsjahr 2024) wurde dies problemlos dargestellt. Als mir jedoch ein Test-User die Anzeige auf seinem Tolino Epos 3 (Erscheinungsjahr 2022) zeigte, wurde deutlich, dass selbst zwischen zwei so eng verwandten Geräten die Unterschiede unvorhersehbar groß sein können (s. Abb. 7). Weil es zwar etwas weniger elegant, aber für die Darstellung robuster ist, habe ich mich deshalb entschieden, die Verszahlen nicht mehr auszurücken, sondern schlicht in eckigen Klammern in den Vers zu schreiben. Hier beeinflussen Einschränkungen im Design also direkt konzeptionelle Entscheidungen.
Abb. 7: Deutliche Abweichungen in der Darstellung desselben Textes auf zwei nah verwandten Lesegeräten.
3.4.3. Konzeptionelle Herausforderungen
Abb. 7 zeigt noch weitere Schwachstellen meiner initialen Konzeption.
Die Verse, insbesondere die deutsche Fassung, sind in der Regel zu lang für eine Zeile und brechen um. Bei stets mindestens zwei, oft drei Sprachen parallel führt das dazu, dass ein einziger Vers in der Anzeige vier oder mehr Zeilen umfasst. Um die einzelnen Verse optisch voneinander zu trennen, müssen die Abstände zwischen diesen Gruppen vergrößert werden, was den Text stark zerfasert. In Abb. 7 sind auf einer Seite nur sechseinhalb Verse zu sehen, verteilt auf 20 Zeilen – und das mit lediglich einer einzigen Verszahl zur Orientierung. Unter anderen Umständen könnten für sechs Verse sechs Zeilen ausreichen, auf der Seite wäre somit Platz für dreimal so viel Inhalt. Sollten sich LeserInnen nicht für alle drei Sprachen interessieren, sondern beispielsweise nur für die deutsche Übersetzung, muss somit bereits nach jedem sechsten Vers umgeblättert werden, was auf Dauer viel zu anstrengend ist. Aber selbst LeserInnen, die Originalsprache und Übersetzung parallel lesen möchten, müssen beim Lesen von Sprachzeile zu Sprachzeile springen. Ein lineares Lesen ist somit nicht möglich. Wäre die Darstellung wenigstens so regelmäßig, dass jede Sprache nur eine Zeile beansprucht, wäre das Layout ruhiger und geordneter. Dafür müsste der Reader aber entweder auf Querformat eingestellt oder die Schriftgröße verringert werden und beides ist keine robuste Lösung, da die NutzerInnen die Einstellungen ja selbst anpassen können.
Um den Anspruch der linearen Lesbarkeit in den Mittelpunkt zu stellen und diesem gerecht zu werden, habe ich deshalb entschieden, in einer zweiten Fassung die Sprachen zu trennen und jeweils ein eigenes EPUB für den deutschen, griechischen und lateinischen Text zu gestalten. Das Ergebnis wirkt sofort viel ruhiger, und der Text ist deutlich flüssiger lesbar (s. Abb. 8). Es bleibt jedoch das eingangs aufgeworfene Problem, dass ohne genauere Kenntnis der tatsächlichen NutzerInnengruppe nicht klar ist, ob überhaupt Bedarf an einer rein originalsprachigen Ausgabe im E‑Book‑Format besteht.
Abb. 8: Deutlich ruhigere Textdarstellung bei nach Sprachen getrennten E‑Book-Fassungen.
Diese zweite Fassung brachte zudem weitere konzeptionelle Probleme mit sich. So gibt es beispielsweise Einheiten, die aus einem ersten Gedicht auf Latein und einem eng verwandten zweiten Gedicht auf Griechisch bestehen, weshalb sie als eine Einheit zusammengefasst sind. Eine Einheit mit dem Kurztitel „Rhod. Coc.Ion. 1–2” signalisiert beispielsweise, dass sie zwei Gedichte enthält. In der lateinischen E‑Book-Fassung ist jedoch nur das erste Gedicht enthalten, in der griechischen wiederum nur das zweite. Die Einheit behält dann zwar weiterhin den Titel „1–2”, beginnt aber entweder irritierenderweise mit „Gedicht Nr. 2” oder endet nach „Gedicht Nr. 1”, wodurch der Eindruck entsteht, dass Inhalte fehlen würden. Und wenn doch mal eine Übersetzung für eine originalsprachliche Stelle benötigt würde, müsste ein komplett anderes E‑Book geöffnet werden – ausgesprochen unkomfortabel.
Da ich weder die Paralleldarstellung noch die Sprachtrennung zufriedenstellend finde, plane ich aktuell eine dritte Option, in der die gesamte Edition wieder in einem einzigen E‑Book zusammengefasst ist, aber jedes Gedicht in zwei aufeinanderfolgende Blöcke aufgeteilt wird: Zunächst die Originalsprachen Griechisch und/oder Latein pro Vers untereinander (Zeilenumbrüche sollten sich hierbei in Grenzen halten) und anschließend die deutsche Übersetzung als eigenständiger Block. Die Verszahlen dienen dabei als Link-Verbindung zwischen den Sprachblöcken, sodass LeserInnen entweder einen der beiden Blöcke linear durchlesen oder bei Bedarf über die Links zum entsprechenden Vers im anderen Block springen und wieder zurückkehren können.
Ich hoffe, dass dies ein Kompromiss ist, der sowohl die lineare Lesbarkeit als auch die parallele Darstellung der Sprachen berücksichtigt, ohne dass der Lesefluss oder die Übersichtlichkeit zu stark leiden.
Fazit zur technischen Umsetzung
Es gibt verschiedene Möglichkeiten, E‑Books aus einem Projekt heraus zu generieren. Selfpublishing Web-Angebote sind kostenpflichtig und gehen eher in Richtung Verlags-Kooperation. Spezielle Software zur EPUB-Erstellung funktioniert grundsätzlich gut, lässt sich aber schlecht individuell konfigurieren. Die im oXygen XML Editor integrierte „TEI P5 EPUB Transformation” will eine generisch für alle TEI‑Dateien funktionierende Transformation bieten, lässt sich aber ebenfalls nicht projektspezifisch anpassen und interpretiert Strukturen oft anders als gewünscht.
Ich habe mich deshalb für einen eigenen Workflow zur EPUB-Erstellung mit XSL entschieden. Da EPUB im Kern eine ZIP‑Datei ist, die (fast) ausschließlich XML-basierte Formate enthält, ließ sich es sich sehr gut in den bestehenden Projektworkflow integrieren. Technische Herausforderungen waren dabei unter anderem die Dateigröße (umfangreiche EPUBs mit Bildern und eingebetteten Fonts führten auf meinem Lesegerät zu Abstürzen) sowie das Inhaltsverzeichnis (das neuere Format toc.xhtml wurde, im Gegensatz zum älteren toc.ncx, nicht zuverlässig als Navigationsdatei erkannt). Um sicherzustellen, dass die EPUB‑Dateien dem von den Lesegeräten erwarteten Format entsprechen, bieten Validierungstools wie der EPUB-Checker eine unkomplizierte und praktische Hilfe. Generell fehlt es jedoch an Simulationsmöglichkeiten für verschiedene Lesegeräte. Programme wie Calibre oder der Kindle Previewer liefern zwar grobe Eindrücke, etwa beim Vergleich von Tablet, Smartphone und E‑Reader, simulieren aber keine konkreten Geräte. Meine Tests zeigen, dass selbst nah verwandte Geräte dieselbe Datei teils signifikant unterschiedlich darstellen. Insgesamt erwiesen sich die physischen Lesegeräte bei meinen Tests generell als weniger zuverlässig, komfortabel und robust in der Anzeige als E‑Book-Apps.
Wie – und ob überhaupt – eingebettete CSS-Anweisungen umgesetzt werden, ist von Gerät zu Gerät unterschiedlich und nicht vorhersehbar. An Beispielen wie der Ausrückung von Verszahlen, der Nummerierung im Inhaltsverzeichnis und dem Versuch, Seitenumbrüche vor <div>-Elementen vorzugeben, zeigte sich, dass diese Design-Instabilität mitunter direkten Einfluss auf die konzeptionelle Gestaltung hat.
Konzeptionell noch ungeklärt ist zudem der Umgang mit den verschiedenen Sprachen im Projekt: Alle drei Sprachen nebeneinander stört die Lesbarkeit, während drei nach Sprachen getrennte E‑Books die Gedichte inhaltlich auseinanderreißen und fälschlich Lücken suggerieren. Ein möglicher Kompromiss – Originaltext und deutsche Übersetzung in zwei separaten, aber miteinander verlinkten Blöcken innerhalb eines E‑Books – muss noch umgesetzt werden.
4. (Exkurs) Laien als Zielgruppe – Zugänglichkeit neu denken
Abschließend noch ein paar Gedanken zu der eingangs aufgeworfenen Frage, ob eine digitale Edition auch für eine Laien-Zielgruppe außerhalb der fachwissenschaftlichen Community zugänglich gemacht werden kann. Mein Eindruck ist, selbst wenn sich ein Projekt inhaltlich für eine breitere Öffentlichkeit eignet und einen E‑Book‑Output anbieten würde, ist fraglich, ob diese Zielgruppe tatsächlich erreicht würde – oder ob die Angebote nur weiter innerhalb des akademischen Umfelds zirkulieren. Ich vermute, dass dafür neben Suchmaschinen wie Google stärker auch Plattformen wie Amazon, Thalia oder Kobo als potenzielle Zugangs- und Sichtbarkeitskanäle in den Blick genommen werden müssten.
E‑Books in diesen Shops anzubieten wäre ein naheliegender Weg, um Sichtbarkeit zu schaffen, denn genau dort suchen Leute nach Lesestoff. Fraglich ist allerdings, ob kostenlos angebotene E‑Books die Zugänglichkeit tatsächlich erhöhen oder eher Zweifel an ihrer Relevanz und Wertigkeit wecken. Zudem kommen organisatorische und technische Aspekte hinzu, die ich noch nicht überblicken kann. So müsste sich das Projekt etwa um die Vergabe einer ISBN kümmern. Unter Umständen ist die Nutzung kommerzieller Plattformen wie Amazon auch mit Kosten verbunden, für die im Projekt keine Mittel bereitstehen. Und es stellt sich die Frage, wer sich nach Ende der Projektlaufzeit um Pflege, Aktualisierung und langfristige Verfügbarkeit kümmert.
Aber vielleicht muss die DH-Community auch darüber nachdenken, wie die Angebote innerhalb der digitalen Edition besser auffindbar gemacht werden können. Denn wissenschaftliche Editionen sind von Natur aus komplex. Es kostet Zeit und Mühe, sich in fremde Editionen einzuarbeiten, ihre Struktur zu verstehen, ihre Zielsetzung, welche Materialien sie bereitstellen, kurz, was die Edition ist und was sie nicht ist. Von interessierten Laien kann ich das nicht erwarten.
Wenn ich mich als Laie erst in die individuellen Untiefen einer Edition einarbeiten muss, weil sich die E‑Books unter abschreckenden Reitern wie „Technische Dokumentation und Downloads” befinden – wo sie bei meinen Projekten schändlicherweise zu Testzwecken momentan noch liegen – oder ganz am Ende in der Fußzeile zwischen Buttons mit hoch technischen Bezeichnungen wie „TEI-XML”, „JSON” und „TIFF”, werde ich sie sehr wahrscheinlich nicht finden.
Für mich bedeutet das ganz konkret: Wenn ich die E‑Books im Rhodoman-Projekt leicht zugänglich machen will, müssen sie raus aus dem Downloads-Untermenü und am besten bereits auf der Startseite sichtbar sein (weil potentielle LeserInnen beispielsweise nach einer Googlesuche dort landen). Das widerspricht allerdings meinem Anspruch, diese möglichst minimalistisch und aufgeräumt zu halten. Und welche Rechtfertigung gibt es, einen – im Gesamtkonzept des Projektes klar untergeordneten – E‑Book‑Output prominent auf der Startseite zu platzieren, während der „eigentliche” Inhalt der Edition verborgen bleibt? Das heißt, idealerweise zeigt bereits die Startseite der Edition beiden Zielgruppen – Laien und FachwissenschaftlerInnen –, welchen Weg sie innerhalb der Edition wählen müssen, um die für sie relevanten Inhalte und Outputs in den jeweils passenden Komplexitätsstufen zu finden. Aber eine konkrete Vorstellung, wie das für die Rhodoman-Edition aussehen könnte, habe ich noch nicht.
5. Fazit
Die technische Umsetzung eines E‑Book‑Outputs ist deutlich unkomplizierter, als ursprünglich befürchtet. Das EPUB‑Format ist gut dokumentiert, standardisiert und weit verbreitet. Unerwartet war lediglich die Notwendigkeit, neben EPUB auch die proprietären Amazon‑Formate bedienen zu müssen, um nicht einen großen Teil der potentiellen Leserschaft auszuschließen. Falls in einem Editionsprojekt keine Mittel für eine Kooperation mit einem Verlag vorgesehen sind, lässt sich mit soliden XSL-Kenntnissen recht einfach ein E‑Book‑Output realisieren. Unter Umständen reichen sogar Softwarelösungen wie Calibre oder Sigil aus. Projektspezifische Konfigurationsmöglichkeiten sind dabei jedoch begrenzt und sie lassen sich mitunter schwerer in automatisierte Projektworkflows integrieren, weil die Erzeugung per Hand geschehen muss.
Die eigentlichen Herausforderungen liegen meines Erachtens weniger auf der technischen, sondern auf der konzeptionellen Ebene – ein Aspekt, den ich unterschätzt habe. Die komplexen Inhalte wissenschaftlicher Editionen müssen für das Medium E‑Book stark vereinfacht und reduziert werden und nicht alle Projektinhalte eignen sich überhaupt für eine lineare Lesefassung. Zudem sind viele Gestaltungsmöglichkeiten und Funktionen, die im digitalen oder gedruckten Kontext gang und gäbe sind, im E‑Book nicht möglich, weil das Layout nicht starr und die Funktionalitäten der Lesegeräte eingeschränkt sind.
Ein großes Problem ist zudem, dass die Zielgruppe nicht klar bekannt ist. Durch die stark reduzierte Struktur und den Anspruch, eine niederschwellige Lesefassung zu sein, sind E‑Books zwar eine Chance die in den Digital Humanities manchmal zu wenig bedachte Zielgruppe der interessierten Laien zu erschließen, gleichzeitig ist aber fraglich, ob diese über den Weg einer digitalen Edition überhaupt erreicht werden. Zumindest für meinen Testfall Rhodomanologia muss ich die Website dahingehend noch einmal gründlich überdenken.
Überlegungen für einen E‑Book‑Output sind damit weniger ein technisches, sondern vielmehr ein konzeptionelles Experiment. Sie regen dazu an, sich mit der Edition als Ganzes auseinanderzusetzen. Wenn also Zeit und Ressourcen es erlauben, spricht nichts dagegen, es einfach zu versuchen.
Endnoten
[1] Ich verwende im Folgenden die Kurzform „Edition” für jede Art von nicht-kommerzieller, fachwissenschaftlicher Aufbereitung und Bereitstellung von Texten in digitaler Form ohne Verlagsbeteiligung, die über eine bloße Faksimiledarstellung hinausgeht, und bei der eine „klassische” Publikation als Print (oder E‑Book) nicht der primäre Output des Vorhabens ist.
[2] Was nicht bedeutet, dass keine Editionen E‑Books anbieten, sondern dass die Frage schwer in eine Onlinesuche umzusetzen ist.
[3] https://de.statista.com/statistik/daten/studie/277971/umfrage/nutzung-von-buechern-und-E‑Books-deutschland/
[4] Die meisten neueren Geräte können zwar ins W-Lan und haben teilweise auch eingebaute Browser, aber gerade die papierähnliche, augenfreundliche E-Ink-Technik, die E‑Reader ausmacht und sie von anderen Geräten wie Tablets unterscheidet, macht jede Änderung in der Anzeige wie scrollen oder Passwörter eintippen langsam und ruckelig.
[5] https://www.reclam.de/verlag/ueber-reclam
[6] https://www.boersenverein.de/beratung-service/barrierefreiheit/leitfaden-barrierefreie-epub3-E‑Books-seite-2/
[7] https://gepris.dfg.de/gepris/projekt/470926253?context=projekt&task=showDetail&id=470926253&
[8] Aus persönlicher Erfahrung kann ich sagen, dass interessante Texte, die in klassische Sprachen übersetzt werden, ein nicht zu unterschätzender Anreiz sind, sich intensiver mit diesen Sprachen zu beschäftigen. So habe ich beispielsweise Harry Potter auf Latein und Altgriechisch deutlich lieber gelesen als die klassischen antiken Werke zu Religion, Philosophie und Krieg.
[9] https://de.statista.com/themen/658/E‑Reader/
[10] Um EPUB auf Amazon-Geräten lesen zu können, müssen sie zunächst selbstständig in ein kompatibles Format konvertiert werden und das funktioniert – je nach Tool und EPUB – nicht immer zuverlässig.
[11] Es ist abzusehen, dass sich der Workflow und die Skripte nicht als Rundum-Sorglos-Lösung zur direkten Nachnutzung für andere Projekte eignen werden, weil sie speziell auf dieses eine Projekt zugeschnitten sind. Die oXygen-interne „TEI P5 EPUB Transformation” hingegen versucht gerade diese generische Lösung zu bieten. Für Projekte mit flacherer oder näher am klassischen Buchformat orientierter TEI-Struktur kann dieser Ansatz deshalb durchaus ausreichend sein.
[12] Minimalanforderung: Eine EPUB muss nur aus mimetype, HTML/XHTML‑Dateien, einer OPF‑Datei und der container.xml bestehen, damit sie technisch gelesen werden kann. Inhaltsverzeichnis, CSS und sonstige Dateien sind üblich aber optional.
[13] https://www.w3.org/TR/epub-33/#sec-opf-dcidentifier
[14] Die drei Ansichten (Tablet, Telefon, Kindle) im Kindle Previewer sind generische Simulationen und beziehen sich nicht auf konkrete Gerätemodelle. Vermutlich spiegelt die Kindle-Ansicht wider, wie Amazon intern EPUB‑Dateien bei der Konvertierung in eigene Formate interpretiert.






































