Digitale Bücher, E-Books im Format EPUB selbst erstellen

Erstellt: 2013-05-18/06-20 2013-08-11 2013-08-22 2013-09-18 2013-10-21 2013-10-24 2013-12-14 2014-03-24 2014-08-28 2014-10-16 2014-12-03/04 2015-03-27 2015-04-08 2015-04-23 2015-06-18/21 2015-07-01/02 2016-01-18 2016-01-23/24 2016-12-06 2017-01-20

Autor: Dr. O. Hoffmann (Weitere Projekte des Autors, Kontakt)

Projektmenü; Generator (EPUB 2); Tests von Darstellungsprogrammen (EPUB 2); Erläuterungen zu EPUB 3; Generator (EPUB 3); Rückmeldung, Diskussion, Hilfe

Eigentlich lernen wir nur von den Büchern, die wir nicht beurteilen können. Der Autor eines Buches, das wir beurteilen könnten, müßte von uns lernen.
Johann Wolfgang von Goethe

Kurzzusammenfassung

Digitale Bücher oder elektronische Bücher (EBOOK, E-Book) im Format EPUB zu erstellen, ist eine einfache Angelegenheit, die jeder Autor selbst bewältigen kann und wofür keine speziellen Hilfsmittel notwendig sind.
Diese Anleitung bietet einen einfachen Einstieg. Praktisch wird neben einem Texteditor nur ein Programm benötigt, mit welchem ein Archiv im Format ZIP erstellt werden kann.

Bei Bedarf kann auch ein Generator aus diesem Artikel verwendet werden, um einen kompletten Buchrohling für ein digitales Buch, ein elektronisches Buch oder die immer ähnlichen Strukturdateien zu erzeugen.
Ferner werden Tests und Testergebnisse angeboten, damit Autoren selbst beurteilen können, wie gut oder schlecht aktuelle Darstellungsprogramme für EPUB 2 dieses Format interpretieren.

Inhalt

Einleitung: Motiviert aber ahnungslos?

Als ich im letzten Jahrhundert meine ersten Texte geschrieben habe, habe ich diese zunächst mit Papier und Stift verfaßt und dann mit einer mechanischen Schreibmaschine eingetippt. Dann habe ich die Schreibmaschine zu Beginn meines Studiums durch einen Atari-Rechner ersetzt, bin dann später zunächst auf Unix und dann auf Linux umgestiegen. Ebenfalls noch gegen Ende des letzten Jahrhunderts habe ich dann Textauszeichnung mit (X)HTML gelernt und habe damit Zugang zur semantischen Textauszeichnung bekommen, die zudem einen barrierefreien Zugang zum Inhalt auch für behinderte Menschen drastisch erleichtern kann, es aber auch für Autoren stark vereinfacht, selbständig und ohne Verlag zu veröffentlichen. Somit habe ich von da an ausschließlich digitale Werke im Netz veröffentlicht, also die komplette Abkehr vom Papierveröffentlichungen und der dafür vorgesehenen Formate und der tradierten Kanäle der Veröffentlichung über Verlage.

Nun sind die Formate vom Atari auf heutigen Rechnern natürlich nicht mehr lesbar und es hat einige Mühe gekostet, die früheren Werke in diesen proprietären, binären Formaten in den letzten Jahren auf dem noch immer funktionierenden Atari in einfachen Text zu konvertieren, mit gerade noch so funktionierenden Disketten auf einen technisch aktuellen Rechner zu übertragen und dann auf dem Linux-Rechner umzukodieren und mit semantischer Textauszeichnung zu versehen. Dies führe ich hier als Warnung an für jene, die auch heute noch proprietäre, binäre Formate verwenden und ihre Texte etwa nur als PDF oder Microsoft Word aufbewahren. Es ist relativ schwierig, solche primär für den Druck geeigneten Formate nach EPUB zu konvertieren. Unwahrscheinlich für diese Formate, aber nicht ausgeschlossen: Geben die verantwortlichen Firmen die Formate auf oder gehen pleite, kann es in ein paar Jahrzehnten mit aktuellen Rechnern schwierig werden, die Dokumente noch zu dekodieren.

Was also tun als motivierter, ahnungsloser Autor?
Keine Panik, wenn ich das alles lernen konnte, können andere das sicher auch, zumal es für andere nun ja auch reichlich zielführende Hilfe gibt.

Nun ist es nicht besonders schwierig, ein Textformat wie XHTML zu erlernen, und damit in der Lage zu sein, qualitativ brauchbar ausgezeichnete Bücher zu verfassen. Was auf diesen Seiten notiert ist, wie man digitale Bücher selbst erstellt, sieht dabei umfangreicher und schwieriger aus, als es wirklich ist. Das liegt auch daran, daß EPUB deutlich mehr Möglichkeiten bietet, als man als Einsteiger für das erste einfache Buch wirklich braucht, man muß also längst nicht alles über EPUB verstanden haben, muß längst nicht alle Möglichkeiten verwenden, um ein qualitativ gutes Buch zu erstellen.

Allein, sofern man gar nichts davon versteht, ist es nicht besonders sinnvoll, zwei Dinge auf einmal zu tun, ein Buch zu schreiben und ein Format zur Textauszeichnung zu erlernen. Wenn man also eine dringende und gute Idee für einen Text hat, kann es sinnvoll sein, diesen erst einmal in Klartext zu notieren, entweder wie gehabt mit Papier und Stift oder auch einem einfachen Texteditor ohne jegliche Textauszeichnung.
Wer gar nicht Rechner-affin ist, für den kann es allemal sinnvoll sein, sich erst einmal nicht mit dem Rechner zu beschäftigen, sondern einfach erst einmal den Inhalt mit Papier und Stift zu entwickeln.
Andere mögen ohnehin so vertraut mit Rechnern sein, daß es inzwischen ganz selbstverständlich ist, den Text gleich auf dem Rechner mit einem simplen Texteditor zu erstellen.
Wie man die Urversion des Textes erstellt, ist also erst einmal eine recht persönliche Angelegenheit, bei der man keine pauschalen Empfehlungen geben kann.

Ist es hingegen nicht so dringend, die eigenen Ideen zu notieren, lohnt es sich, wenigstens ein paar Tage zu investieren, um wenigstens die Grundlagen der Textauszeichnung zu lernen, also wenigstens das dünnste Brett zu bohren, damit dann etwa für jedes Kapitel ein einfaches XHTML-Dokument anzulegen und sich anschließend etwa mit dieser Seite darum zu kümmern, wie man dann noch ein paar Kleinigkeiten ergänzt, um ein Buch im Format EPUB daraus zu machen. Die allermeiste Arbeit steckt so oder so im Schreiben des Inhaltes, nicht in der Erstellung des EPUB-Archivs, welches ohnehin hauptsächlich aus den dann bereits erstellten XHTML-Dokumenten bestehen sollte.
Und wenn man bereits Monate damit zugebracht hat, ein eigenes Buch zu einem Thema zu schreiben, welches einen wirklich interessiert, ist es dann nicht auch angemessen, ein paar Stunden oder Tage zu investieren, um daraus ein qualitativ hochwertiges digitales Buch zu machen, statt sich mit automatisch erzeugter Markierungssuppe zufrieden zu geben?

Selbst wenn man das Buch später doch noch drucken will, ist diese Strategie immer noch sehr gut, weil es einfacher ist, strukturierte, semantisch ausgezeichnete Dokumente in Druckvorlagen zu konvertieren als umgekehrt. Neben halbwegs automatischen Konversionen und Transformationen ist dann natürlich für den Druck noch Einiges zu ergänzen, was für digitale Bücher unnötig und gar überflüssig ist. Bei der Erstellung des eigentlichen Inhaltes wird man so gar nicht durch die Belanglosigkeiten abgelenkt, die massiv auftreten, wenn man Text in Druckvorlagen auf Einzelseiten unterbringen muß, die gar nichts mit der Struktur des Inhaltes zu tun haben, aber massiv davon ablenken, guten Text zu formulieren.

Hat man etwa einen Verlag gefunden, der bereit ist, die Druckkosten zu übernehmen, wird dieser zweifellos auch bereit sein, die Druckvorlage aus einem qualitativ hochwertigen EPUB zu erstellen, jedenfalls wenn der Verlage kompetente Mitarbeiter hat, welche die Grundlagen ihres Handwerks verstehen, was zugegebenermaßen jedenfalls im traditionellen Verlagswesen immer noch weit weg vom Verständnis semantischer Textauszeichnung ist, nicht aber von der Transformation eines Dokumentes aus einem XML-Format in eine Druckvorlage.

Nun bieten einige Verlage oder Vertreiber von digitalen Büchern auch Konversionswerkzeuge an, mit welchen sich automatisch aus PDF oder Microsoft Word Bücher im Format EPUB erstellen lassen. Selbst bei oberflächlicher Betrachtung stellt sich heraus, daß, wie nicht anders zu erwarten, die Ergebnisse technisch mangelhafte Markierungssuppe sind, weil diese Konversionsprogramme natürlich den Inhalt nicht verstehen und ansonsten nicht mehr konvertieren können, als im Ausgangsdokument steckt, was eben primär Anweisungen zum Druck auf Papier sind und keine semantische Textauszeichnung mit sinnvoller Strukturierung mit Kapiteln, Überschriften, Absätzen etc. Um aus solchen mangelhaften Ausgangsdaten qualitativ gute Bücher zu erstellen, ist zwangsläufig eine Menge manuelle Arbeit notwendig - etwa den Textinhalt herauskopieren und dann mit der semantischen Textauszeichnung versehen. Die Konversion ist also entweder aufwendig und teuer oder aber mangelhaft und technisch unsinnig und schlecht gemacht, wird dem Inhalt nicht gerecht, obwohl das Erscheinungsbild auf dem Bildschirm vielleicht sogar recht passabel aussehen mag, aber als Markierungssuppe nicht barrierefrei und zugänglich ist, wie es für digitale Bücher angemessen ist und einfach umzusetzen ist.

Folglich lohnt es sich also, entweder die Grundlagen zu lernen, oder aber schlicht jemanden zu beauftragen, der ein oder zwei Wochen Arbeit in ein Buch steckt, um daraus ein qualitativ hochwertiges EPUB zu machen. Hat man bereits akzeptables Ausgangsmaterial, etwa im Format XHTML, so kann sich der Arbeitsaufwand natürlich auf wenige Stunden oder ein oder zwei Tage reduzieren. Anders als beim Lektorat oder Korrekturlesen kann diese Aufbereitung des Inhaltes übrigens am besten und effektivsten durch den kundigen Autor erfolgen, weil dieser ja wissen sollte, was sein Inhalt bedeutet und wie er gemeint ist.

Diese Seiten erläutern die Grundlagen, die einen in die Lage versetzen, qualitativ hochwertige Bücher im Format EPUB zu verfassen, dies können dann auch Bücher mit komplizierterer Struktur sein, mit Bildern und sonstigen Anreicherungen, welche in digitalen Büchern möglich sind. Alternativ gibt es zwei Generatoren, mit denen inhaltlich einfach strukturierte Bücher mit guter Textauszeichnung erstellt werden können.
Selbst kann ich natürlich ebenfalls gute Bücher erstellen, bislang sind das dann aber eigene Inhalte und Bildergeschichten von Wilhelm Busch, die ich kostenlos anbiete.

Dreieinigkeit und zwei Versionen

EPUB (Elektronische Publikation, englisch: electronic publication) [EPUB] ist das Standardformat für digitale Bücher, oft auch elektronische Bücher genannt (kurz und englisch auch oft E-Book oder EBOOK). Das Format basiert im Wesentlichen auf einfachen Textdateien, die mit einem einfachen Texteditor erstellt werden können und welche dann zu einem Archiv zusammengefaßt werden. Neben wenig Klartext sind dies vor allem XML-Formate, die bereits anderweitig standardisiert und empfohlen sind, von daher hat EPUB eigentlich nur wenige eigene Strukturen, die nicht bereits stark verbreitet wären. Die Empfehlungen sind zudem frei verfügbar, es gibt also keine Geheimnisse bei der Erstellung von Dokumenten wie bei proprietären Formaten.

Von EPUB gibt es mehrere Versionen. Bei Buchhändlern noch weit verbreitet, aber mittlerweile längst veraltet ist Version 2. Aktuell ist sowohl für einfachere als auch für technisch aufwendigere und hochwertige Bücher die aktuelle Version 3 zu empfehlen.

Das in diesem ersten Teil betrachtete EPUB 2 selbst besteht aus drei Teilen oder Empfehlungen, eine für das Archivformat (OPF), das Containerformat (OCF) und die Empfehlung für den eigentlichen Inhalt (OPS), welche wiederum hauptsächlich auf Standardformate wie XHTML 1.1, SVG und DAISY (DTB) [DTB] zurückgreift.
EPUB 3 ist ähnlich strukturiert und wird getrennt behandelt: Erläuterungen zu EPUB 3. Die Erläuterungen zu Version 3 setzen mehr oder weniger einige Grundkenntnisse voraus, die für Version 2 mit vermittelt werden. Alternativ reicht allerdings auch ein routinierter Umgang mit Dokumenten in XML-Formaten, während die Anleitung zur Version 2 etwas weiter ausholt, damit auch jene Leser mithalten können, die wenig oder keine Erfahrung mit XML-Formaten haben.

Ist es nun sinnvoll, Version 2 oder Version 3 zu verwenden?
Beide haben Vor- und Nachteile.
Version 3 hat an wenigen Stellen ein paar Rückwärtsinkompatibilitäten, die Syntax für die Notation von einigen verfeinernden Metainformationen wurde unnötig geändert, die Basisinformationen und die Grundfunktionen bleiben allerdings erhalten und mit wenigen für Version 3 ohnehin empfohlenen Ergänzungen können Bücher der Version 3 auch mit Programmen gelesen werden, die nur Version 2 verstehen.
Das Konzept von Version 2 ist etwas allgemeiner gehalten als das von Version 3, theoretisch könnte man damit sogar mehr inhaltlich relevante Dinge realisieren als mit Version 3. Leider hat sich allerdings herausgestellt, daß die Darstellungsprogramme, die eigentlich für Version 2 entwickelt wurden, gerade das nicht interpretieren, was Version 2 wirklich zu einem sehr flexiblen Format gemacht hätte. Deswegen hat man einige sehr gute Ideen der Version 2 wegen fehlender Implementierungen in der Version 3 gestrichen.
In Version 3 hat man zudem einige Strukturen dem 'Zeitgeist' angepaßt, was teilweise eine Verbesserung bedeutet, zum großen Teil aber auf genannte Implementierungsmängel zurückzuführen ist. Version 3 erlaubt allerdings auch ein paar neue Dinge, die sich erst nach dem Erscheinen von Version 2 etabliert haben. Vieles, was an Behauptungen im Umlauf ist, daß man dies mit Version 3 erstmals realisieren könne, basiert offenbar auf mangelnder Kenntnis der Spezifikationen. Allerdings muß man auch betonen, daß es bei Version 3 durch Ignorieren von Anforderungen der Spezifikation an Autoren, Bücher zugänglich und barrierefrei zu erstellen, einfacher ist, blödsinnige und sinnfreie Werke zu veröffentlichen, zum Beispiel wenn man das für diese Version erlaube Java-Script einsetzt, aber vergißt, durch strikte Trennung von Inhalt und Dekoration den Zugang zum Inhalt auch ohne Skriptinterpretation zu ermöglichen. So können Autoren also leicht ihre eigenen Werke komplett korrumpieren. Allein, wenn man diese optionalen Merkmale gar nicht verwendet oder wie von der Spezifikation empfohlen, ergeben sich daraus keine Probleme für Autoren und Leser.
Insgesamt kann man wohl sagen, daß Version 3 auch oder insbesondere für recht einfach strukturierte Bücher, die nur aus Text und Bildern bestehen, etwas einfacher von Autoren und auch von Programmen zu handhaben ist als Version 2. Auch von daher ist es irreführend bis paradox, daß einige Verlage und Vertreiber digitaler Bücher immer noch auf Version 2 bestehen, wenn dessen Möglichkeiten allerdings wirklich vom Autor genutzt werden, die Bücher abgelehnt werden. Etwas widersinnig ist das Bestehen auf Version 2 dann natürlich auch, wenn man bedenkt, daß aufgrund der zahlreichen Mängel der Darstellungsprogramme für Version 2 die Interpretation von Büchern, die nach Version 3 abgefaßt sind, keinesfalls schlechter sein muß, teilweise sogar besser, je nachdem, welche Möglichkeiten man von der Version 2 nutzt, die in Version 3 bereits gestrichen wurden, weil sie nicht oder kaum implementiert wurden.
So oder so müssen Autoren und Leser immer noch mit schlechten Darstellungsprogrammen leben. Autoren sollten allzu exotische, aber formal erlaubte Merkmale eher meiden. Leser sollten darauf gefaßt sein, daß ihr Darstellungsprogramm längst nicht jedes Buch korrekt darstellen kann, gleich ob dies gemäß Version 2 oder 3 erstellt wurde. Einige Merkmale und Informationen im Buch werden faktisch immer erst zugänglich werden, wenn man direkt in das Bucharchiv und in den Quelltext der darin befindlichen Textdateien guckt, weil Darstellungsprogramme besonders im Buch vorhandene Metainformationen teilweise oder komplett ignorieren.
Persönlich habe ich zunächst mit Version 2 begonnen, bin dann aber schnell zu Version 3 gewechselt, weil diese Version hinsichtlich der semantischen Textauszeichnung letztlich flexiblere Möglichkeiten bietet, die es zudem nicht wie in Version 2 notwendig machen, den gleichen Inhalt mehrmals in verschiedenen Alternativen anzubieten, einmal inhaltlich sinnvoll ausgezeichnet und einmal einfach für schlecht programmierte Darstellungsprogramme. Version 3 ist so strukturiert, daß derselbe Inhalt sowohl semantisch reichhaltig sein kann, als auch in seiner Grundstruktur von eher schlichten Programmen präsentiert werden kann.

Einmal abgesehen von Standardformaten wie XHTML und SVG werden in dieser Kurzanleitung für die notwendigen weiteren Dokumente praktisch verwendbare Beispiele und ein Generator angeboten. Dies reicht aus, um einfache Bücher selbst zusammenzustellen.
Diese einfachen Strukturen sollten die allermeisten Strukturen konventioneller Bücher hinreichend abbilden können. Für experimentellere oder stark ambitionierte Projekte wird es sich hingegen nicht umgehen lassen, in diesem Artikel in die Details zu gucken und vielleicht einmal selbst in die Empfehlungen zu schauen. Nicht auszuschließen ist auch, daß weder Version 2 noch 3 für ambitioniertere Buchprojekte ausreichen. Bei den proprietären Formaten ist die Wahrscheinlichkeit allerdings deutlich größer, daß deren Möglichkeiten für ambitioniertere Buchprojekte nicht ausreichen, da EPUB im Schnitt einen deutlich größeren Bereich von Möglichkeiten abdeckt, was nicht heißen muß, daß diese Möglichkeiten auch alle durchgehend von den üblichen Darstellungsprogrammen oder Lesegeräten korrekt interpretiert werden können (siehe dazu auch die hier ebenfalls verfügbaren Tests).

Um Bücher im Format EPUB mit einem Texteditor zu erstellen, ist es sehr hilfreich, wenigstens Grundkenntnisse in XML zu haben. Grundkenntnisse in speziellen XML-Formaten wie XHTML oder SVG reichen dafür auch. HTML hat hingegen eine etwas davon abweichende Syntax. Grundkenntnisse darin sind zwar auch hilfreich, reichen jedoch nicht komplett aus, um auftretende Probleme zielführend zu bearbeiten.
Anders als für HTML gibt es für XML zahlreiche Programme, die solche Dokumente verarbeiten können, weil die Struktur einfacher ist als bei HTML, ohne die möglichen Inhalte damit einzuschränken.

Sofern keine Grundkenntnisse in XML vorhanden sind, gibt es hier eine Kurzeinführung in XML, soweit das für die weiteren Erläuterungen relevant ist.

Grundstruktur

Bücher im Format EPUB sind immer mit UTF-8 oder, sofern erforderlich, auch in UTF-16 kodiert. Der zur Erstellung der Bücher verwendete Texteditor ist also auf diese Kodierung einzustellen, was heute in der Praxis entweder bereits automatisch der Fall ist oder einfach einzustellen ist. Bei der Wahl von Verzeichnis- und Dateinamen gilt im Grunde das Gleiche. Besser aber man verwendet für diese nur die darstellbaren Zeichen aus dem ASCII-Zeichensatz.
Zusätzlich gilt, daß bei Verzeichnis- und Dateinamen Groß- und Kleinschreibung einerseits signifikant ist. Um Kompatibilitätsprobleme mit alten Dateisystemen beim Entpacken zu vermeiden, dürfen andererseits im selben Verzeichnis aber nicht zwei Dateien stehen, die sich nur durch Groß- und Kleinschreibung unterscheiden. Explizit ausgeschlossen für Datei- und Verzeichnisnamen sind folgende Zeichen:

In der EPUB-Empfehlung nicht erwähnt, aber garantiert auch als Problemfälle einzustufen und daher keinesfalls zu verwenden:

Die Namen dürfen nicht größer als 255 Byte sein.
Pfadnamen zu Dateien dürfen nicht größer als 65535 Byte sein.

Um sich Ärger zu ersparen, empfiehlt es sich also in der Praxis, nur Buchstaben und Ziffern, Minuszeichen und Unterstriche zu verwenden, also keine Leerzeichen, Umlaute, Ligaturen, Satzzeichen (einmal abgesehen vom Punkt zur Abtrennung von Dateiendungen) und ähnliche Komplikationen. Zudem sollte bei der Länge von Datei- und Verzeichnisnamen nicht übertrieben werden und es sollte auf eine flache Verzeichnis-Hierarchie geachtet werden, also nicht zu viele Verzeichnisebenen erstellen.

Davon ausgehend, daß es mittel- bis langfristig nicht bei einem Buch bleibt, bietet es sich an, die Grundstruktur pauschal als ein Verzeichnis als Vorlage zu erstellen und dieses dann als Anfang eines jeden Buchprojektes einfach zu kopieren.

Im Folgenden wird anhand eines solchen Prototyps erläutert, wie man ein Buch erstellen kann. Das fertige Buch oder Archiv kann ebenfalls direkt angesehen werden: Buch-Prototyp. Die einzelnen Bestandteile werden aber auch im weiteren Text vorgestellt.

Um die hier diskutierte Vorlage zu erstellen, wird als erster Schritt ein Verzeichnis mit dem Namen 'Buch' erstellt. Später wird dieses Verzeichnis dann rekursiv samt Inhalt auf den Namen des jeweils neu zu erstellenden Buches kopiert und dort werden dann die individuellen Anpassungen vorgenommen.

In das Verzeichnis wird eine Datei kopiert mit dem Namen 'mimetype' mit dem Inhalt "application/epub+zip". Dies gibt einfach den Inhaltstyp für das spätere Archiv an. Ein Programm kann an der Datei und dem Inhalt erkennen, welches Format in dem Archiv verwendet wird und welche Struktur das Archiv hat.

Ferner wird im Verzeichnis 'Buch' ein weiteres Verzeichnis erstellt, dies trägt den Namen 'META-INF'. In diesem Verzeichnis wird eine Datei namens 'container.xml' angelegt. Diese hat für einfache Bücher typisch folgenden Inhalt:

<?xml version="1.0"?>
<container version="1.0"
  xmlns="urn:oasis:names:tc:opendocument:xmlns:container">
   <rootfiles>
      <rootfile
        full-path="Inhalt/index.opf"
        media-type="application/oebps-package+xml"/>
   </rootfiles>
</container>

Das ist also ein XML-Dokument, welches so einfach kopiert werden kann, ohne es verstehen zu müssen. Im Wesentlichen wird damit einfach angegeben, wo der eigentliche Inhalt steht, beziehungsweise das Verzeichnis mit allen Dateien des Buches. Als Wert des Attributes full-path des Elementes rootfile wird dazu ausgehend vom Verzeichnis 'Buch' angegeben, wie die Datei heißt, in welcher das Verzeichnis mit allen Dateien des Buches steht. Die Datei ist ebenfalls ein spezielles XML-Dokument im Format OPF mit der Dateiendung '.opf'. Hier wurde 'Inhalt/index.opf' gewählt, wovon im weiteren Text ausgegangen wird. Man kann auch irgendwas anderes angeben, solange man sich dann im Weiteren daran hält. Ansonsten ist hier noch zu lernen, daß das Trennzeichen hinter Verzeichnisnamen für Pfadangaben '/' ist, aber das entspricht ohnehin der üblichen Konvention.
Leider kann man hier bei mehrsprachigen Werken keine Fallunterscheidung einbauen, um den Leser nach seinen Spracheinstellungen gleich automatisch auf den richtigen Inhalt umzuleiten.

Details zum Verzeichnis 'META-INF'.

Entsprechend den vorherigen Angaben wird als nächster Schritt im Verzeichnis 'Buch' das Verzeichnis 'Inhalt' erstellt. Und darin ist dann die Datei 'index.opf' anzulegen. Diese hier ist ein Prototyp, der an das eigene Buch angepaßt werden muß, wie im nächsten Abschnitt erläutert wird.

Diese Datei 'index.opf' enthält ein komplettes Verzeichnis aller Dateien, die für das Buch relevant sind. Ein für den Leser nutzbares Inhaltsverzeichnis wird hingegen mit einer weiteren Datei zur Verfügung gestellt, welche 'toc.ncx' heißt und auch in 'Inhalt' steht. In dieser müssen leider einige Informationen aus 'index.opf' wiederholt werden. Der Inhalt wird jedenfalls im einem der folgenden Abschnitte erläutert.

Die minimalen Prototypen in 'Inhalt' für 'index.opf' und 'toc.ncx' sind zum einen ein Beispiel, zum anderen enthalten sie Kommentare vor den Elementen, deren Inhalte oder Attributwerte für das eigene Buch anzupassen sind. Dort, wo in solch einem Kommentar etwas zwischen zwei Gruppen von drei Fragezeichen wie '???Buchtitel???' steht, ist im folgenden, nicht auskommentierten Element der Inhalt gegen Zutreffendes zu tauschen.

Die im Folgenden erklärten Strukturdateien sollten wenigstens grob verstanden sein. Allerdings wird hier auch ein Generator bereitgestellt, um diese Dokumente erzeugen zu lassen. Statt mit dem Texteditor Dokumente zu erstellen, ist es dann erforderlich, ein Formular auszufüllen: Generator.

Verzeichnis aller Dateien und Reihenfolge der Inhalte

Die Datei 'index.opf' enthält drei (oder vier) Informationsblöcke.
Im ersten Block stehen Metainformationen über das Buch, also Informationen über das Buch, die nicht nur für Bibliothekare und Archivare interessant sind. All diese Informationen sind so mit standardisierten Elementen strukturiert oder ausgezeichnet, daß diese Informationen einfach mit Computern automatisch auswertbar sind. Neben dem Titel, einer Kurzbeschreibung, Angaben zum Autor, Entstehungs- und Veröffentlichungsdatum können auch Lizenzrechte angegeben werden, Quellenangaben, wo das Buch oder eine Alternative dazu verfügbar ist oder auch Angaben zum Genre und über das für geeignet gehaltene Publikum.

Der zweite Block beinhaltet das Verzeichnis aller Dateien des Buches, also alle XHTML-Dateien, das Inhaltsverzeichnis für den Leser, Dateien für Stilvorlagen und Bilder. Dateien, die hier nicht gelistet sind, braucht das Darstellungsprogramm bei der Präsentation auch nicht zu berücksichtigen.

Der dritte Block gibt die Reihenfolge an, in welcher die Inhalte automatisch präsentiert werden sollen, also grob wie beim Papierbuch die Reihenfolge der Seiten. Bilder oder Stilvorlagen sind hier also nicht anzugeben, nur die XHTML-Dateien, welche nacheinander beim Durchblättern dargestellt werden sollen. Solche Dateien, die nicht automatisch erreichbar sein sollen, sondern etwa nur per direkter Auswahl durch den Leser, sind ebenfalls anzugeben, aber mit einem besonderen Attribut.

Der vierte Block kann dazu dienen, eine Führung durch das Buch oder wesentliche Bestandteile davon zusammenzustellen, um dem Leser einen schnellen Überblick zu geben.

So sieht also der Prototyp dieser Datei aus:

<?xml version='1.0' encoding='UTF-8'?>
<package xmlns="http://www.idpf.org/2007/opf"
         version="2.0"
	 unique-identifier="id">
  <metadata
   xmlns:opf="http://www.idpf.org/2007/opf"
   xmlns:dc="http://purl.org/dc/elements/1.1/">
    <!--dc:title xml:lang="de">???Buchtitel???</dc:title-->
    <dc:title xml:lang="de">Der Irrtum als System</dc:title>
    <!--dc:identifier
        id="id"
        opf:scheme="??????">???Eindeutige Buchidentifikation ???</dc:identifier-->
    <dc:identifier
        id="id"
        opf:scheme="uuid">5aa280ce-47cd-4779-8524-21abcb0df47e</dc:identifier>
    <dc:language>de</dc:language>
    <!--dc:description xml:lang="de">???Beschreibung des Buches???</dc:description-->
    <dc:description xml:lang="de">Kurzgeschichten für Irrende und Besserwisser</dc:description>
    <!--dc:creator
        opf:file-as="???Nachname des Erzeugers, Vorname???"
        opf:role="aut"
        xml:lang="de">???Name des Erzeugers???</dc:creator-->
    <dc:creator
        opf:file-as="Dr. Hoffmann, Olaf"
        opf:role="aut"
        xml:lang="de">Dr. Olaf Hoffmann</dc:creator>
    <!--dc:date
        opf:event="creation">???Erstellungszeitpunkt
	    wie 2003-07-21 ???</dc:date-->
    <dc:date
        opf:event="creation">2013-05-25</dc:date>
    <!--dc:date
        opf:event="publication">???Veröffentlichungszeitpunkt
	    wie 2003-08-06 ???</dc:date-->
    <dc:date
        opf:event="publication">2013-05-26</dc:date>
    <!--dc:publisher>???Verlag, Verleger,      
      Anbieterkennzeichnung
      ???
      </dc:publisher -->
    <dc:publisher
        xml:lang="de">Dr. Olaf Hoffmann 
      [
      Anbieterkennzeichnung siehe:
      http://hoffmann.bplaced.net/ich.php?in=kontakt
      ]
      </dc:publisher>
  </metadata>
  <manifest>
    <item href="toc.ncx"
          id="ncx"
          media-type="application/x-dtbncx+xml"/>


    <item href="titelseite.xhtml"
          id="titelseite"
          media-type="application/xhtml+xml"/>
    <item href="kapitel1.xhtml"
          id="k1"
          media-type="application/xhtml+xml"/>
    <item href="kapitel2.xhtml"
          id="k2"
          media-type="application/xhtml+xml"/>
    <item href="keineZauberei.dtb"
          id="keZa"
          media-type="application/x-dtbook+xml"/>

    <item href="stil.css"
          id="css"
          media-type="text/css"/>
    <item href="altstil.css"
          id="altcss"
          media-type="text/css"/>
    <item href="no.css"
          id="nocss"
          media-type="text/css"/>
    <item href="dtb.css"
          id="dtbcss"
          media-type="text/css"/>


    <item href="titel.svg"
          id="TitelbildSVG"
          media-type="image/svg+xml"/>
    <item href="titel.png"
          id="TitelbildPNG"
          media-type="image/png"/>
    <item href="titel.jpg"
          id="TitelbildJPEG"
          media-type="image/jpeg"/>

  </manifest>
  <spine toc="ncx">
    <itemref idref="titelseite"/>
    <itemref idref="k1"/>
    <itemref idref="k2"/>
    <itemref idref="keZa"/>


  </spine>
  <guide>
    <reference href="titelseite.xhtml"
               type="cover"
               title="Titelseite"/>
  </guide>
</package>

Metainformationen über das Buch

Oben gibt es erstmal einige formale Angaben, die nicht geändert werden müssen. Die Metaangaben sind alle im Element metadata notiert. Die Angaben folgen dem Standard Dublin Core [DC], daher auch das Präfix 'dc:'. Es können alle bei Dublin Core definierten Elemente verwendet werden und diese in beliebiger Anzahl und Reihenfolge. Erforderlich ist die Angabe der Elemente title, identifier und language, die im Folgenden auch erläutert werden und im Prototyp vorhanden sind. Die anderen Elemente sind optional.

Der erste wirklich spannende und erforderliche Eintrag im Prototyp ist der Buchtitel mit dem Element title - zwischen der Anfangs- und der Endmarkierung des Elementes ist einfach der Buchtitel einzutragen. Siehe dazu im Prototypen den Kommentar mit der Zeichenkette '???Buchtitel???'. Im darauf folgenden Element ist dann an entsprechender Stelle der vorhandene Text durch den eigenen Buchtitel zu ersetzen.
Der Buchtitel ist normaler Text.
Hier wird ferner davon ausgegangen, daß das Buch in deutsch ist, andernfalls ist der Attributwert von xml:lang von 'de' auf das entsprechende Sprachkürzel [rfc5646] zu ändern, für englisch etwa auf 'en'. Entsprechend geht das mit der Sprachangabe bei den anderen Elementen. Gemäß EPUB aber leider nicht bei allen, also erstmal nur da ändern, wo das Attribut im Prototyp bereits angegeben ist.

Ebenfalls erforderlich ist die Angabe einer eindeutigen Buchidentifikation mit dem Element identifier. Eindeutig ist in diesem Zusammenhang so zu verstehen, daß jedes neue Buch und jede veränderte Neuveröffentlichung eines Buches eine neue Identifikation benötigt. Der Wert des Attributes id muß derselbe sein wie der Wert des Attributes unique-identifier im Element package ganz oben am Dokumentanfang. Es gelten die üblichen Einschränkungen für Fragmentidentifizierer, es beginnt mit einem Buchstaben, optional gefolgt von weiteren Buchstaben oder Ziffern, Minuszeichen oder Unterstrichen. Aber das kann natürlich auch genau so bleiben, wie es im Prototyp steht.

Mit dem Attribut opf:scheme kann das Schema der Buchidentifikation angegeben werden. Der Wert gibt also das verwendete Schema an, sofern vorhanden etwa 'ISBN', 'DOI', 'URN' oder 'UUID' etc.
Man kann sich natürlich auch selbst ein Schema ausdenken, etwa eigener Name, Wohnort, Datums- und Zeitangabe, eventuell kombiniert mit einem Zufallswert. Es sollte dann nur beliebig unwahrscheinlich sein, daß jemand anderes auf denselben Wert kommt.
Beispiel für eine zufällig erstellte UUID: UUID-Generator (die ändert sich bei jedem Aufruf, kann also bei Bedarf für eigene Bücher verwendet werden).
Eine ISBN kostet Geld und eine DOI kann von einfachen Hobby-Autoren auch nicht selbst erzeugt werden.

Mittels language muß die Hauptsprache angegeben werden, in welcher das Buch verfaßt ist. Zum Beispiel 'de' für irgendein Deutsch oder 'de-de' für Hochdeutsch im Stil der Bundesrepublik. Ebenfalls interessant ist 'de-1901' für die Rechtschreibregeln ab 1901 und 'de-1996' für die Rechtschreibregeln nach der Reform 1996, wobei wohl Reformen der Reform nicht berücksichtigt werden. Bei der Beschränkung auf 'de' gilt jedenfalls keine besondere Festlegung auf eine Rechtschreibvariante oder eine lokale Ausprägung wie etwa den schweizer Stil ohne ß-Ligatur. Trotzdem sollte man natürlich wenigstens auf einheitliche Schreibweise achten, die nicht zu arg vom allgemeinen deutschen Sprachgebrauch abweicht, der wiederum aber über die Jahrhunderte betrachtet auch sehr wandelbar ist.
Der Inhalt des Elementes entspricht jedenfalls einem Wert von xml:lang.
Bei mehrsprachigen Werken ist es leider nicht möglich, eine Weiche einzubauen, mit welcher der Leser gleich auf die für ihn maßgebliche Sprachvariante umschalten kann.

Mit description kann dann eine Beschreibung oder Kurzzusammenfassung des Buches notiert werden. Der Inhalt des Elementes ist also einfacher Text.

Analog wird mittels creator ein Erzeuger oder Schöpfer des digitalen Buches angegeben, als Elementinhalt in freier Form. Gibt es mehrere solche Personen oder sonstige Beteiligte, ist pro Element nur exakt eine Person einzutragen. Weitere Personen sind jeweils mit einem weiteren Element creator anzugeben. Der Attributwert von opf:file-as stellt eine maschinenlesbare Notation des Autorennamens bereit.

Mit dem Element date können relevante Daten zum Werk angegeben werden. Der Inhalt ist eine Angabe im internationalen Datumsformat wie '2013-05-19' für ein Datum oder für Datum und Zeit: '2013-05-19T13:20:20Z'.
Um was für ein Datum es sich handelt, kann mit dem Attribut opf:event angegeben werden. Der Wert 'creation' steht für das Erstellungsdatum 'publication' steht für den Zeitpunkt der Veröffentlichung. 'modification' steht für das Datum einer Veränderung, etwa bei einer Neuauflage.
Dummerweise kann kein Zeitraum wie '2003-07-21/2003-08-06' angegeben werden, was natürlich in Bezug auf das Erstellungsdatum etwas naiv von den Autoren der Spezifikation ist, dafür würde man eher einen Erstellungszeitraum erwarten. Vermutlich soll man sich irgendein schönes Datum aus dem Erstellungszeitraum wählen...

Der Verlag, Verleger, Herausgeber oder allgemein Veröffentlicher des Buches kann im Element publisher notiert werden. xml:lang steht wie bereits beschrieben für die Sprache, in welcher der Inhalt verfaßt ist.

Da es zum Beispiel in Deutschland eine Anbieterkennzeichnungspflicht gibt, muß ein veröffentlichtes Buch entsprechende Informationen enthalten. Das kann etwa in diesem Element geschehen. Dies im normalen Inhalt zu notieren, ist natürlich auch möglich.

Details und mehr Elemente für Metainformationen.

Verzeichnis aller Dateien

Auf metadata folgt das Element manifest mit dem Verzeichnis aller Dateien, die für den Inhalt benötigt werden. Das schließt dann auch Stilvorlagen, Graphiken, Bilder, Audio- und Videodateien etc mit ein.

Die einzelnen Dateien werden jeweils mit einem Element item gelistet und referenziert. Die Reihenfolge ist nicht relevant, es müssen nur alle Dateien gelistet sein, die im Buch präsentiert werden sollen. Dieselbe Datei darf nur exakt einmal gelistet werden.

Jedes Element item hat ein Attribut id mit einem für das Dokument einmaligen Fragmentidentifizierer als Wert. Das wird dann in der nächsten Struktur noch gebraucht, um die normale Lesereihenfolge der Dokumente festzulegen.

Ebenfalls erforderlich ist ein Attribut href, dessen Wert eine URI eines Dokumentes ist, welches zum Inhalt des Buches beiträgt. Zumeist wird dies eine relative Angabe bezüglich des aktuellen Dokumentes sein.

Mit dem ebenfalls erforderlichen Attribut media-type wird der Medientyp oder Inhaltstyp des referenzierten Dokumentes angegeben. Die Angabe erfolgt nach dem Schema von Internet IANA [IANA].

Im Prototyp sind bereits ein paar Einträge für den Inhalt angegeben, die Titelseite und zwei Kapitel, alle im Format XHTML und ein Gedicht im Format DTB. Ferner gibt es ein paar Stilvorlagen im Format CSS und Beispiele für geläufige Bildformate. Als erster Eintrag findet sich dann noch die Datei mit dem Inhaltsverzeichnis für den Leser, welches in einem der weiteren Abschnitte näher erläutert wird.

Hinsichtlich der Namen der Dateien empfiehlt sich eine eingängige Wahl, welche die Funktion der Datei erkennen läßt, wie etwa 'titelseite.xhtml' oder 'einleitung.xhtml' oder 'literaturverzeichnis.xhtml' etc. Die Durchnumerierung der Namen nach Kapiteln ist plausibel, kann aber Arbeit verursachen, falls sich im Laufe der Arbeit die Reihenfolge ändern sollte. Eine genaue Bezeichnung kann also praktikabler sein, verrät andererseits aber nicht gleich die beabsichtigte Lesereihenfolge. Sinnvoll ist jedenfalls eine erkennbare Zuordnung des Fragmentidentifizierers zum Dateinamen, weil dies bei der später im Dokument erfolgenden Festlegung der normalen Lesereihenfolge die Arbeit erleichtert.

Details zum Dateiverzeichnis.

Reihenfolge der Inhalte

Die normale Lesereihenfolge der Dokumente wird auf manifest folgend im erforderlichen Element spine festgelegt. Das Element steht sinngemäß für den Buchrücken oder die Bindung des Buches, bestimmt also darüber, wie eigenständige Dokumente im Buch aufeinander folgen sollen. In spine steht mindestens ein Element itemref.

Mit einem itemref wird jeweils exakt ein item aus manifest referenziert. Ein item darf nicht mehrmals referenziert werden.
Zur Referenzierung wird bei dem Attribut idref des Elementes itemref als Attributwert der Fragmentidentifizierer des item notiert, welcher dort als Wert von id notiert ist. Es müssen oder dürfen nicht alle item aus manifest referenziert werden. Im obigen Beispiel sind das praktisch einfach die Einträge für die Titelseite und die Kapitel.

Details zum Buchrücken.

Einstiegspunkte des Buches

Auf spine kann ein Element guide folgen, mit dem Einstiegspunkte in das Buch angegeben werden können. Typisch können darin fundamentale oder prominente Teile des Buches für einen bevorzugten Zugang notiert werden. Die Interpretation durch das Darstellungsprogramm ist allerdings optional.

Die Angabe wie im Prototyp für wenigstens die Titelseite oder die Buchhülle ist allerdings empfehlenswert, sonst werden einige Programm irgendeinen selbstgemachten Einband für das Buch verwenden, dem dann eben nichts über das Buch zu entnehmen ist, wie es der Autor geplant hat. Auch wenn man dort einen eindeutigen Eintrag für eine Titelseite einträgt, hält das natürlich einige Programme nicht davon ab, trotzdem einen eigenen Einband zu erzeugen, der nicht viel über das Buch aussagt.

Über Einstiegspunkte ins Buch.

Inhaltsverzeichnis für den Leser

Für Bücher im Format EPUB ist es erforderlich, ein Inhaltsverzeichnis für den Leser bereitzustellen. Neben einem optionalen eigenen im normalen Inhalt muß es auch noch eines geben, welches von den Darstellungsprogrammen automatisch als solches erkannt wird und dem Leser automatisch verfügbar gemacht wird.

EPUB 2 verwendet dafür Strukturen von DAISY (DTB). Dies ist eine sogenannte Navigationskontrolldatei (englisch: Navigation Control File for XML applications; NCX).
Einige Angaben darin wiederholen sich, die bereits in der OPF-Datei vorliegen. Ein Beispieldateiname passend zu obigem OPF-Dokument ist 'toc.ncx':

<?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE ncx PUBLIC
     "-//NISO//DTD ncx 2005-1//EN"
     "http://www.daisy.org/z3986/2005/ncx-2005-1.dtd">
<ncx xmlns="http://www.daisy.org/z3986/2005/ncx/" version="2005-1" xml:lang="de">
  <head>
    <!--meta name="dtb:uid"
          content="???Eindeutige Buchidentifikation wie in index.opf ???"/-->
    <meta name="dtb:uid"
          content="5aa280ce-47cd-4779-8524-21abcb0df47e"/>
  </head>
  <docTitle>
    <!--text>???Buchtitel???</text-->
    <text>Der Irrtum als System</text>
  </docTitle>
  <docAuthor>
    <!--text>???Name des Erzeugers???</text-->
    <text>Dr. Olaf Hoffmann</text>
  </docAuthor>
  <navMap>

    <navPoint id="titel"
              playOrder="1">
      <navLabel>
        <text>Titel</text>
      </navLabel>
      <content src="titelseite.xhtml"/>
    </navPoint>

    <navPoint id="k1"
              playOrder="2">
      <navLabel>
        <text>Kapitel 1</text>
      </navLabel>
      <content src="kapitel1.xhtml"/>
    </navPoint>

    <navPoint id="k2"
              playOrder="3">
      <navLabel>
        <text>Kapitel 2</text>
      </navLabel>
      <content src="kapitel2.xhtml"/>
    </navPoint>

    <navPoint id="kaZe"
              playOrder="4">
      <navLabel>
        <text>keine Zauberei</text>
      </navLabel>
      <content src="keineZauberei.dtb"/>
    </navPoint>
  </navMap>
</ncx>

ncx ist das Wurzelelement einer NCX-Datei. Als erstes Kindelement ist ähnlich wie bei XHTML head für Metainformationen anzugeben. Auf head folgt ein Element docTitle mit dem Buchtitel. Danach folgen optional Elemente docAuthor mit je einer Angabe eines Autors. Danach folgt genau ein Element navMap mit den eigentlichen Informationen zur Navigation. Darauf folgt optional ein Element pageList mit Informationen zu allen Seiten oder eher Dokumenten im Buch, also ähnlich dem bereits diskutierten spine, nur hier für den Leser aufbereitet. Optional folgen darauf weitere Elemente navList. Ähnlich wie mit navMap kann damit eine Navigation umgesetzt werden, aber ähnlich wie bei guide besteht sie nur aus direkten Einstiegspunkten ohne weitere Verschachtelung.

Kopfinformationen

Im Element head werden ähnlich wie bei XHTML Metainformationen notiert. Als jüngeres Format vermeidet DTB allerdings eher Wiederholungen. Die Metainformationen werden mit meta-Elementen notiert. Das im Prototyp notierte meta-Element ist für EPUB erforderlich, weitere sind optional möglich. Ähnlich wie bei XHTML wird mit dem Attribut name die Art der Information angegeben, mit dem Attribut content der Inhalt oder Wert der Information.

Die erforderliche per meta-Element notierte Information ist die Buchidentifikation. Das ist dieselbe, welche im OPF-Dokument per unique-identifier im Element package referenziert wird und in dem OPF-Dokument mit dem Element identifier angegeben wird.

Auf head folgt ein Element docTitle - in dem Kindelement text ist erneut der Buchtitel zu notieren.

Danach folgen optional Elemente docAuthor - in dem Kindelement text wird dann jeweils ein Autor notiert. Für jeden Autor wird ein eigenes docAuthor notiert.

Details zu den Kopfinformationen.

Navigation

Das Inhaltsverzeichnis oder die Navigation wird im Element navMap notiert. Im einfachsten Falle, der bei dem Prototyp umgesetzt ist, wird für jedes Kapitel darin ein Navigationspunkt notiert. Dies ist ein Element navPoint.

Erforderlich ist für jedes navPoint ein Attribut id für einen Fragmentidentifizierer. Der Wert ist also einmalig für das Dokument und von der bereits beschriebenen Struktur, beginnend mit einem Buchstaben, optional dann weitere Buchstaben, Ziffern, Minuszeichen und Unterstriche.

Ebenfalls erforderlich ist für navPoint ein Attribut playOrder. Damit werden die Navigationspunkte durchnumeriert, angefangen mit 1 als Wert für den ersten Navigationspunkt, 2 für den zweiten und so weiter.

Der Inhalt eines navPoint beginnt mit einen navLabel für die Beschriftung des Navigationspunktes. Diese steht als Text im Kindelement text. Bei Bedarf kann mehr als ein navLabel notiert werden.

Auf navLabel folgt dann ein Element content, welches den Inhalt referenziert, auf den mit dem Navigationspunkt verwiesen werden soll. Dazu wird src als Attribut von content notiert. Der Wert ist eine URI zum gewünschten Inhalt, im Bedarfsfalle mit angehängtem # und Fragmentidentifizierer, um auf den Beginn des Inhaltes zu verweisen.

Details zur Navigation.

Als Tip sei noch dazu geraten, eine alternative Navigation im Format XHTML bereitzustellen. Als Inhalt eignen sich einfache Listen mit Verweisen auf die Dokumente, welche den einzelnen Kapiteln entsprechen. Unterlisten könnten dann jeweils mit angehängten Fragmentidentifizierern auf gegebenenfalls vorhandene Unterkapitel verweisen.

Der Hauptvorteil solch einer alternativen Navigation liegt darin, daß Leser auch einfach das Buch entpacken können, um leistungsfähigere Darstellungsprogramme verwenden zu können, insbesondere solche, die auch sonst für XHTML, SVG und CSS verwendet werden.

Ein weiterer Vorteil liegt darin, daß in EPUB 3 ohnehin auch eine XHTML-Navigationsliste bereitgestellt werden soll und man sich so bereits darauf vorbereiten kann. Für EPUB 2 ist dies aber immer nur eine zusätzliche Alternative.

Dateien für den eigentlichen Inhalt

Diese Kurzanleitung befaßt sich ja mit den technischen Aspekten, wie man ein Buch erzeugt, nicht wie man es schreibt. Technisch ist es dazu notwendig, den Text oder Inhalt in einem der Formate bereitzustellen, die in diesem Kapitel kurz erläutert werden. Wie man überhaupt sinnvolle Texte schreibt, ist dabei ein anderes Problem, welches nur kurz angeschnitten wird: Schreiben.

Die Dateiformate für den eigentlichen Inhalt für die Version 2 sind XHTML 1.1 und DAISY (DTB). Diese werden dann auch Inhaltsformate genannt, beziehungsweise die Dateien Inhaltsdateien oder Inhaltsdokumente.

In diese Inhaltsdokumente können die Graphikformate GIF, PNG, JPEG/JFIF und SVG eingebunden werden, letzteres mit Einschränkungen und auch als Dateninsel. Eingebettete Graphiken und auch Stilvorlagen müssen im EPUB-Archiv liegen, externe Ressourcen sind nicht zulässig.

Der Prototyp enthält als 'titelseite.xhtml' ein Beispiel samt Stilvorlage und Titelbild als Anregung, wie man eine Titelseite aufbauen könnte. Das Titelbild ist im Format SVG realisiert, was Darstellungsprogramme für EPUB 2 eigentlich interpretieren müssen, von daher wäre es nicht notwendig, eine Alternative dazu anzubieten. Weil ja aber nichts auf der Welt perfekt ist und es eigentlich kein Programm gibt, was genau das tut, was es tun soll, ist als Alternative ein kleineres PNG verfügbar und als Alternative dazu ein JPEG/JFIF.

Die Seite 'kapitel1.xhtml' ist im Wesentlichen leer. Und 'kapitel2.xhtml' enthält als Inhalt XHTML in EPUB für Schnelleinsteiger - als Beispiel nützlich für jene, die noch keine Erfahrung mit XHTML haben, aber schon mal auf die Schnelle lostippen wollen. Insbesondere sollte man die Präsentation mit dem Quelltext vergleichen, um ein praktisches Beispiel zu sehen - das gerade gelesene Dokument ist in XHTML+RDFa verfaßt, verwendet also ein Modul von XHTML 1.1, welches für primären Inhalt von EPUB 2 ausgeschlossen ist, eignet sich also deswegen und aufgrund der größeren Komplexität weniger gut als praktisches Beispiel für die Erstellung von einfachen Buchkapiteln.
Zudem unterscheiden sich die beiden Kapitel in der Art der Einbindung der ebenfalls vorhandenen Stilvorlagen.
Diese Dateien können dann im Bedarfsfalle schon einmal als Vorlagen für eigene Inhalte verwendet werden.

Als kleine Hilfe für die Dichter unter den Autoren habe ich dann auch noch ein Beispiel für ein Gedicht angehängt, umgesetzt im Format DTB: 'keineZauberei.dtb'
Um zu testen, ob das Format von den Darstellungsprogrammen wirklich sinnvoll interpretiert wird, wird per Voreinstellung eine leere Stilvorlage verwendet. Man kann dann einfach auf die alternative Stilvorlage umschalten, um zu vergleichen. Sollte beides nicht funktionieren, hat das verwendete Darstellungsprogramm hinsichtlich EPUB 2 sehr grobe Mängel und ist sicher allenfalls mit großer Vorsicht verwendbar.

Generell sollte die Einteilung des Buches der Struktur folgen, nicht etwa einer festgelegten Menge. Bei gedruckten klassischen Büchern mit einzelnen Seiten, also keine Schriftrollen, wird der Inhalt zwangsläufig durch die Abmessung der einzelnen Seite strukturiert und auf einzelne Seiten aufgeteilt. Bei digitalen Büchern ist das unsinnig. Eine Aufteilung erfolgt hier sinnvoller Weise anhand der im Buch vorhandenen Strukturen, also den Kapiteln, Unterkapiteln oder Abschnitten. Hinsichtlich der Menge an Text pro Dokument gibt es da praktisch kaum Einschränkungen, zumal man kaum einen Text schreiben wird, der einige Megabyte lang ist und keine weitere Strukturierung als etwa Absätze enthält.
Anhand der Menge kann man dann konsistent entscheiden, ob es ausreicht, für jedes Kapitel ein eigenes Dokument zu beginnen, oder ob man dies auch für jedes Unterkapitel tut. Größen unter einem Megabyte dürften in der Praxis für Darstellungsprogramme gar keine Probleme bereiten. Bei deutlich größeren Dokumenten und Geräten mit wenig Arbeitsspeicher und leistungsschwachem Prozessor kann die Handhabung für den Leser dann irgendwann etwas träge werden.

Bei XML-Formaten, für welche es ein Schema wie eine Dokumenttypdefinition gibt, sollte die Dokumenttypdeklaration notiert werden, wonach das Dokument mit einem Validator getestet werden sollte [W3CV]. Sind die zutreffenden Fehler beseitigt, hat man ein korrektes Dokument für sein Buch. Bei einem SVG-Dokument oder einem anderen Format, welches eine andere geeignete Versionsangabe hat, kann man die Dokumenttypdeklaration dann beseitigen, wenn man möchte. Für EPUB geltende zusätzliche Einschränkungen werden so allerdings nicht getestet werden, das muß manuell geprüft werden - oder mit dem noch zu besprechenden Validator, der speziell für EPUB ausgelegt ist.

Auch für CSS gibt es einen Validator [CSSV], der verwendet werden sollte. Da gelten ähnliche Einschränkungen wie für den für XML-Formate mit Schema. Erschwerend kommt noch hinzu, daß CSS keine Versionskennung hat - beim Validator kann man allerdings angeben, welche Version man testen möchte. Die für EPUB geltenden zusätzlichen Einschränkungen wird man so auch nicht testen können, auch das ist manuell zu tun.

XHTML

Bei XHTML 1.1 werden einige Module ausgeschlossen, die für EPUB 2 als nicht relevant eingestuft werden. Ausgenommen sind in EPUB von XHTML 1.1 [XHTML] die Module 'ruby', 'forms', 'server-side-image-map', 'intrinsic-events', 'applet', 'frames', 'target', 'iframe', 'scripting', 'legacy'.
Auch RDFa [RDFa] als neuere semantische Erweiterung ist leider noch nicht in EPUB 2 integriert. Die Referenzierung der Bedeutung durch Verweis auf fremde Namensräume wäre aber ohnehin bei einem Buch im Format EPUB von begrenztem Nutzen, wenn man den URIs ohne Netzanschluß gar nicht folgen kann. Gleichwohl kann man dies bei Bedarf zu einem anderen Zeitpunkt tun, wenn ein Netzanschluß verfügbar ist, von daher ergibt die Erweiterung auch für derartige Bücher einen Sinn. Entsprechend ist dies dann auch in EPUB 3 bereits vorgesehen.

Mehr zu XHTML.

Digital Talking Book (DTB)

Als semantisch deutlich reichhaltigere Alternative zu XHTML bietet sich DAISY (DTB) [DTB] an. Die Strukturen sind oft ähnlich wie bei XHTML und meistens wurden sogar die Elementnamen, sofern vorhanden, von XHTML übernommen. DTB ist zudem deutlich besser als XHTML für komplette Bücher ausgelegt.

Allerdings ist DTB weniger bekannt und geläufig als XHTML. Dafür werden allerdings Hilfen, Richtlinien und Beispiele zum richtigen Gebrauch bereitgestellt [DTBG]. Nach dem bisherigen Eindruck und nach dem, was andere über EPUB schreiben, wird DTB in EPUB praktisch nicht genutzt und wird nur von wenigen Darstellungsprogrammen überhaupt interpretiert, was sehr schade für die semantische und technische Qualität von EPUB-Büchern ist. Bei EPUB 3 ist es wegen der mangelnden Interpretation bereits gestrichen.

Das komplette Format umfaßt auch Strukturen von SMIL, um mit Audiodateien Hörbücher zu verwirklichen und ist in dieser Variante allerdings stark verbreitet. Diesen akustischen Teil spart EPUB 2 allerdings aus und verwendet nur den Teil mit der Textvariante.

SVG

SVG ist ein internationaler Standard für Vektorgraphik und mittlerweile ein etabliertes Format. Bei Computergraphik ist es meist die zugänglichere Variante im Vergleich zu Pixelgraphik und damit dieser vorzuziehen. SVG hat zudem einige eingebaute Methoden, um für Graphik auch barrierefrei Textalternativen im selben Dokument verfügbar zu machen und ist auch von daher ein ideales Format für EPUB gerade auch hinsichtlich des Anspruches, Information von allen für alle verfügbar zu machen.

Die Interpretation von SVG 1.1 [SVG] in EPUB ist daher für Darstellungsprogramme erforderlich. Allerdings schränkt EPUB auch die verwendbaren Bestandteile erheblich ein, ähnlich wie bei XHTML. So ist vor allem Interaktion und deklarative Animation nicht erlaubt, auch keine Skripte. Wird in SVG mit dem Attribut requiredExtensions der Wert http://www.idpf.org/2007/ops abgefragt, so ist dieser immer zutreffend.

Als Dateninsel soll SVG nur in XHTML verwendet werden, nicht in DTB. Ferner können komplette SVG-Dokumente mit den Elementen img und object von XHTML eingebettet werden. Ebenso geht das für img von DTB. Auch SVG-Dokumente dürfen SVG-Dokumente einbetten und SVG-Dokumente können auch von Stilvorlagen referenziert werden.
In EPUB 2 gelten SVG-Dokumente allerdings nicht wie XHTML-Dokumente und DTB-Dokumente als eigentliche Inhaltsdokumente, werden also nicht direkt per NCX als komplett eigenständige Dokumente referenziert oder per OPF spine als Teil der linearen Lesereihenfolge betrachtet. Dies ist erst bei EPUB 3 möglich.

Wird SVG in XHTML verwendet, so ist das Wurzelelement svg als inzeiliges Element überall erlaubt, wo auch das Element img erlaubt ist.

Wer sich nicht mit SVG auskennt, aber ebenfalls damit und mit einem Texteditor oder Skript Graphiken realisieren will, mag mit Gewinn das deutschsprachige wikibook über SVG lesen, von dem der Autor dieses Artikels ebenfalls der Hauptautor ist [WSVG].

XML-Dateninseln

Komplette XML-Dokumente dürfen ähnlich wie SVG-Dokumente nicht als primäre Inhaltsdokumente ohne Alternative auftreten.
Für solche Dokumente sind im manifest des OPF-Dokumentes Alternativen anzugeben oder, sofern das ausreicht, per Stilvorlage eine angemessene Präsentation des Inhaltes zu gewährleisten.
Es ist also nicht immer notwendig, daß Autoren für Dokumente mit solchen Dateninseln Alternativen bereitstellen, wenn eine Stilvorlage zur angemessenen Präsentation der Semantik ausreicht. Ansonsten ist eine Alternative in XHTML oder DTB bereitzustellen.

Entsprechende Erläuterungen zur Verwendung kompletter XML-Dokumente sind in den bereits erwähnten Details zum manifest des OPF-Dokumentes zu finden.

In XHTML, nicht in DTB, können auch unter korrekter Namensraumangabe Dateninseln mit Fragmenten aus anderen XML-Formaten verwendet werden. Das erfordert allerdings eine spezielle Syntax, um Alternativen bereitzustellen:
Fallunterscheidung bei XML-Dateninseln

Stilvorlagen

Für Stilvorlagen erfordert EPUB von Darstellungsprogrammen die Interpretation von CSS 2.0 [CSS]. Dabei werden lediglich einige Eigenschaften ausgenommen und nur wenige ergänzt.

Anders als die anderen verwendeten Formate ist CSS allerdings kein XML-Format. Es weist daher eine ganz andere Struktur auf. Zwar weist es Selektoren für Elemente und Attribute von XML-Dokumenten auf und ist auf diese abgestimmt, die Syntax der Sprache ist aber komplett anders, erfordert also beim Lernen einen neuen Anlauf.
Für die Formate, deren Interpretation für EPUB-Darstellungsprogramme erforderlich ist, haben diese allerdings bereits eine eigene Stilvorlage. Es ist also gar nicht notwendig, als Autor eine eigene Stilvorlage zu erstellen. Diese ist notwendig, wenn man eine abweichende Präsentation erreichen möchte oder auch eine, die bei allen Darstellungsprogrammen ein ähnliches Ergebnis liefert.

Mehr zu CSS für EPUB.

Praxis

Bei der Realisation von Büchern treten an einigen Stellen natürlich immer wieder gleiche oder ähnliche Probleme auf. Auf einige davon wird hier eingegangen. Selbst wenn der restliche Teil des Textes eines Buches etwa nur aus strukturiertem, einfachem Text besteht, so findet sich doch auf der Titelseite meist etwas Graphik. Oder die Metainformationen über das Buch sollen selbst strukturiert erstellt werden, statt sich darauf zu verlassen, daß die Darstellungsprogramme dieselben Informationen aus der OPF-Datei dem Leser komplett bereitstellen. Oder es soll ein Literaturverzeichnis erstellt werden, so daß im laufenden Text auf die zutreffenden Listenpunkte mit Referenzen verwiesen werden kann.

Dazu gibt es hier ein paar Beispiele und eine Diskussion verschiedener Lösungsansätze: Praxisbeispiele

Archiv erstellen

Um das Buch zu einem einzigen Archiv zu komprimieren, wird ZIP verwendet [ZIP]. Notwendig ist dafür ein Programm, mit welchem man die Reihenfolge der Einträge im Archiv festlegen kann und welches die Basis-Kompression '(de)flate' durchführt - und keine andere. In diesem Zusammenhang ist darauf zu achten, daß Programme, die 'zip' als Namensbestandteil tragen, nicht notwendig ZIP-Archive erstellen. Die nicht nur für Linux üblichen Programme 'gzip' oder 'bzip2' tun das nicht, sondern wirklich direkt das Programm 'zip'.

Unter Unix/Linux wird das benötigte Programmpaket bereits installiert sein oder kann einfach wie üblich aus den Paketquellen installiert werden. Bei anderen Betriebssystemen mag das ähnlich sein, ansonsten kann über die angegebene Referenz das Programm bezogen werden.

Die Kompressionsmethode '(de)flate' und die Kodierung von Datei- und Verzeichnisnamen mit UTF-8 sollten die Voreinstellung des Programmes sein.
Es ist exakt ein Archiv zu erstellen. Eine Aufteilung in mehrere Archive ist nicht erlaubt.
Bei sehr großen Büchern wird hingegen die Erweiterung ZIP64 verwendet, was praktisch automatisch erfolgt.
Verschlüsselung per 'zip' ist unzulässig.
Eine Kompressionsrate zwischen 0 und 8 ist zulässig.

Die erste Datei im Archiv muß die beschriebene Datei 'mimetype' mit der Angabe des Inhaltstyps sein und darf nicht komprimiert sein.

Dies zu erreichen, ist allerdings recht einfach. Auf der Konsole (Kommandoeingabe), etwa bei Linux, begibt man sich in das Verzeichnis, in dem das Buch liegt, bei obigem Prototyp also das Verzeichnis 'Buch'. Da Texteditoren gerne Sicherheitskopien von veränderten Dateien anlegen, löscht man diese vor der Archivierung. Dann sind in dem Verzeichnis 'Buch' folgende zwei Kommandos nacheinander einzugeben, um ein EPUB-Buch mit Namen 'Buch.epub' aus einem Verzeichnis 'Buch' zu erstellen:

zip -X0 Buch.epub mimetype
zip -X8ur Buch.epub *

Oder alternativ, damit das Archiv im übergeordneten Verzeichnis angelegt wird:

zip -X0 ../Buch.epub mimetype
zip -X8ur ../Buch.epub *

Oder falls man sich die Einträge für die Verzeichnisse sparen möchte:

zip -X0 ../Buch.epub mimetype
zip -X8Dur ../Buch.epub *

Das erste Kommando bewirkt jeweils, daß die Datei 'mimetype' wie gefordert unkomprimiert im Archiv steht. Mit der Option 'X' wird auf Dateiattribute verzichtet, '0' führt zum Verzicht auf Kompression. Mit dem zweiten Kommando wird auf Stufe '8' komprimiert, '0' geht bei Bedarf auch, dann ist der größte Teil des Archivs sogar lesbar, ohne es zu entpacken. 'u' bewirkt eine Aktualisierung und 'r' eine rekursive Archivierung der Inhalte einschließlich aller Unterverzeichnisse.

Man kann dann gucken, welche Dateien im Archiv wirklich drin sind, wozu 'unzip' verwendet werden kann:

unzip -Z Buch.epub

Oder 'zipinfo':

zipinfo Buch.epub

Jedenfalls sollte dann in der Liste 'mimetype' an erster Stelle stehen, wobei der dort hinsichtlich der vermiedenen Kompression 'stor' oder dergleichen erwähnt sein sollte, beim komprimierten Rest sollte das 'defX' oder 'defN' sein.

Das Archiv auspacken kann man natürlich auch wieder - nicht nur das eigene übrigens. Dazu legt man dann ein Verzeichnis geeigneten Namens an, hier etwa 'Buch', verschiebt das Archiv in dieses Verzeichnis und entpackt einfach mit:

unzip Buch.epub

Nach dem Erstellen kann ein Buch auch getestet werden. Dazu gibt es zum Beispiel einen für alle Betriebssysteme ausgelegten Validator 'epubcheck' per java oder einen Test nach dem Hochladen des Buches mit einem Dienstprogramm [epubcheck].

Dabei ist zu bedenken, daß solch ein Validator nur ein starres Schema abarbeitet, also nicht berücksichtigen wird, was als normative Prosa in einer Spezifikation steht.
Zum Beispiel könnte das Programm bei Dateninseln bemängeln, daß die Elemente der Dateninsel da nicht hingehören, was aber nicht stimmen muß, wenn die Prosa der Spezifikation dort explizit Elemente aus anderen Namensräumen erlaubt oder das Format pauschal als erweiterbar gekennzeichnet ist, wie dies für XHTML der Fall ist, dessen Schema ebenfalls den Aspekt der Erweiterbarkeit mit Elementen aus anderen Namensräumen nicht berücksichtigen kann.
Ähnlich sieht es bei SVG aus, wo bei einigen Elementen wie metadata, desc oder foreignObject Elemente aus anderen Namensräumen als Inhalt explizit vorgesehen sind.
Folglich beseitigt man die Ursachen aller zutreffenden Fehlermeldungen und muß die Bestandteile selber sorgfältig prüfen, die über ein formales Schema hinausgehen.
Solch ein Validator versteht natürlich auch den eigentlich Inhalt nicht, kann also nicht oder kaum beurteilen, ob man die Auszeichnung korrekt für den jeweiligen Inhalt vorgenommen hat oder eben auch Anforderungen hinsichtlich Barrierefreiheit und Zugänglichkeit wirklich erfüllt hat. Von daher ist das Ergebnis eines Validators immer nur als gute Hilfe anzusehen, nimmt dem Ersteller eines Buches aber keineswegs die Arbeit ab, selbst kritisch zu prüfen, ob der Inhalt sinnvoll und barrierefrei gestaltet ist.

Ein weiteres Problem, was dem Autor aufgefallen ist: 'epubcheck 3.0' kann vermutlich DTB-Dokumente nicht testen. Zumindest wird bei Dateien, für die im OPF-Dokument mit dem Inhaltstyp 'application/x-dtbook+xml' pauschal eine kryptische Fehlermeldung ausgegeben. Auch wenn bei SVG-Dokumenten in metadata Elemente aus fremden Namensräumen stehen, etwa um Lizenzbedingungen anzugeben, gibt 'epubcheck' eine falsche Fehlermeldung aus. Ausgereift ist das Programm also vermutlich noch nicht.
Die Entwickler scheinen sich auch hinter unzugänglichen Anmelderitualen von Google zu verstecken, sind also vermutlich nicht wirklich an einer Rückmeldung zu dem Programm interessiert.

Buch mit PHP erstellen

Generell gibt es mehrere Möglichkeiten, EPUB mit PHP zu erstellen.

Warum überhaupt Bücher dynamisch erstellen?
Der Hauptgrund dürfte bei den üblichen Autoren darin liegen, daß dem Leser ein individualisiertes Buch angeboten werden soll oder ein Buch mit individueller Widmung oder in limitierter Auflage mit jeweiliger Buchnummer herausgegeben werden soll.

Näher erläutert wird ein Verfahren auf folgender Unterseite: EPUB mit PHP.

Buch veröffentlichen

Für die Veröffentlichung gibt es natürlich viele Möglichkeiten, auf die hier nicht einzeln eingegangen wird. Die einfachste Methode liegt vermutlich darin, das Buch auf einen Rechner mit einem Dienstprogramm für das Protokoll HTTP zu kopieren und die URI des Buches dann zu verbreiten.
Mittlerweile gibt es aber auch spezielle Anbieter, über welche man seine digitalen Bücher veröffentlichen kann. Nur sollte man sich bei diesen nicht darauf einlassen, ein irgendwie aus irgendwelchen Texteingaben erstelltes Buch automatisch zusammenbasteln zu lassen.
Es ist wichtig, darauf zu bestehen, die volle Kontrolle zu behalten und das selbst erstellte EPUB-Buch veröffentlichen zu können, sonst ist der Anbieter vermutlich nicht als kompetent einzustufen, eventuell sogar unseriös.
Sind Änderungen durch solch einen Verlag oder Vertrieb am Buch notwendig, ist es wichtig, das veränderte Buch vor der Veröffentlichung zu prüfen, also entpacken und alle Dokumente und Metainformationen sorgfältig vergleichen.
Zum Beispiel kann man bei Unix/Linux Textdokumente mit dem Kommando 'diff' vergleichen und so zügig Unterschiede erkennen und prüfen.
Ein seriöser Verlag wird immer von selbst solch eine Kontrolle durch den Autor vor der Veröffentlichung fordern.

Wie es auch gemacht wird, nachdem das Buch veröffentlicht ist, greift in Deutschland eine gesetzliche Regelung (Pflichtablieferungsverordnung, PflAV) [PflAV], welche dazu verpflichtet, Pflichtexemplare zur Archivierung abzuliefern. Gemäß §15 des Gesetzes über die Deutsche Nationalbibliothek:
Ablieferungspflichtig ist, wer berechtigt ist, das Medienwerk zu verbreiten oder öffentlich zugänglich zu machen und den Sitz, eine Betriebsstätte oder den Hauptwohnsitz in Deutschland hat. [DNBG]
Bei digitalen Medien, anders als bei gedruckten Werken etwa, ist die Ablieferung allerdings recht einfach und kostenlos über das Netz zu bewerkstelligen. Abzugeben ist ein Pflichtexemplar, also eine identische Kopie an die Deutsche Nationalbibliothek (DNB) [DNB].
Veröffentlicht ein Verlag oder Vertrieb das Buch im Auftrage des Autors, ist der Verlag oder Vertrieb für die Ablieferung des Pflichtexemplars zuständig.
Veröffentlicht der Autor selbst, ist er selbst der Ablieferungspflichtige.

Gemäß §4 der Pflichtablieferungsverordnung gibt es allerdings auch einige Ausnahmen, etwa wenn weniger als 25 Exemplare veröffentlicht werden, bei körperlichen Werken mit bis zu vier Druckseiten, Sonderdrucken und Vorabdrucken ohne eigene Paginierung und ohne eigenes Titelblatt, Werken der bildenden Kunst und Originalkunst-Mappen ohne Titelblatt oder mit Titelblatt und mit bis zu vier Seiten Text, Vorab- und Demonstrationsversionen von Medienwerken auf elektronischen Datenträgern (die sind dann allerdings öffentlich unzugänglich zu machen, sobald die finale Version erscheint), sowie inhaltlich oder bibliographisch unveränderte Neuauflagen.
Begriffe wie Druckseiten oder Paginierung sind auf digitale Bücher wie EPUBs allerdings schlecht anwendbar, zudem ist die Ausnahme leider nur für körperliche Werke, nicht für rein digitale Werke erwähnt. Wenn man mag, kann man grob eine Druckseite zu unkomprimierten 1500 Byte rechnen (etwa 1500 Zeichen), mit Berücksichtigung der Strukturinformationen der verwendeten Auszeichnungssprache und der Größe von mit UTF-8 kodierten Sonderzeichen eher grob 2000 Byte. Analog zu Druckwerk trifft das also zu, wenn man vor dem Zippen nicht mehr als 8000 Byte für die Inhaltsdateien zusammenbekommt, wobei man also die OPF-Datei, die NCX-Datei, CSS-Dateien, das Inhaltsverzeichnis, das Titelblatt etc und rein dekorative Bilder wohl nicht mitzählen braucht, pro relevantem Bild aber etwa eine Seite extra rechnen kann. Da allerdings die Mindestmenge nur für Druckwerke gilt, trifft sie auch digitale Bücher genaugenommen nicht zu.
Von Demonstrationsversionen ist sicherlich primär nur dann auszugehen, wenn das Buch nur etwa zum Test von Darstellungsprogrammen dient oder nur im Rahmen einer Anleitung zeigt, wie man EPUBs erstellt und inhaltlich sonst nichts zu bieten hat, wie etwa einige Test-Bücher in diesem Projekt.
Bei anderen Werken mit Inhalt ist natürlich ein Zähler empfehlenswert, damit man beurteilen kann, ob die Schranke von 25 Exemplaren noch nicht erreicht ist oder ob man das Buch anmelden muß, wenn sie überschritten wird.
Bei einer Neuauflage ist folglich dann auch inhaltlich etwas zu ändern, damit die Zählung wieder bei 0 beginnen kann. In welcher Weise wiederholte fehlerhafte Abrufe durch dieselbe Person und Abrufe von Robotern bei der Zählung relevant sind, bleibt dabei allerdings offen.
Bei Robotern ist nicht davon auszugehen, daß diese digitale Bücher wirklich lesen, noch dürfen die Inhalte anderweitig etwa von Suchmaschinen ohne explizite Erlaubnis erneut veröffentlicht werden, von daher wird man bei einer Zählung Roboter erst einmal vernachlässigen wollen, jedenfalls bis davon auszugehen ist, daß sie Bücher wirklich zum Lesen herunterladen und nicht nur aufgrund schlechter Programmierung.
Mehrfachaufrufe sind ebenfalls nicht unwahrscheinlich, sofern man da im Zähler keine heuristischen Kontrolle eingebaut hat, sind auch diese nicht zu unterschätzen, kommen in der Praxis also häufig vor. Auf einen realen Leser können also mehrere Zählereignisse kommen, auch von daher gibt es bei digitalen Büchern hinsichtlich der Ablieferungspflicht eine schwer zu kontrollierende Grauzone.
Allerdings ist die Ablieferung auch nicht so kompliziert und zeitaufwendig, daß man sich immer wieder darum drücken sollte, wenn man durch Schätzung die Pflicht zur Ablieferung für plausibel hält.

Anders als einige andere, proprietäre Formate wird EPUB als qualitativ hochwertig genug empfunden, damit Bücher in diesem Format von der DNB als würdig zur Sammlung und Archivierung für die Nachwelt eingestuft werden. Das liegt auch an der einfachen Struktur des Archives und der verwendeten XML-Formate, denn noch einfacher als das Erstellen eines Buches ist der Zugang zur Information ohne spezielle Programme oder Betriebssysteme. Entsprechend ist das Buch dann auch ohne Verschlüsselung abzugeben. Durch das Erstellen eines Buches im Format EPUB bekommt der Autor also eine gute Chance geschenkt, daß sein Werk für die Zukunft aufbewahrt wird, selbst wenn es keine so hohe Verbreitung findet, daß es auch ohne diese Archivierung über die Jahrhunderte überleben kann.
Ist das Buch erst bei der DNB abgeliefert, fällt es natürlich auch leicht, den Nachweis zu führen, wenn andere eine Urheberrechtsverletzung begehen oder ein Plagiat in Umlauf bringen.

Zur Ablieferung ist eine kostenlose Registrierung bei der DNB notwendig. Die Ablieferung von sogenannten Netzpublikationen erfolgt für unabhängige Autoren ohne Verlag ausschließlich für jedes Werk einzeln über ein Formular und durch Hochladen des Werkes mit anschließender automatischer Weiterverarbeitung.
Zum Werk werden dann nur wenige Metainformationen abgefragt, die man ähnlich auch schon in der OPF-Datei hat angeben können oder müssen. Da auch Hilfen vorhanden sind, sollte es nicht so schwierig sein, die Ablieferung zumindest bei einfachen Werken mit genau einem Autor, der alles alleine gemacht hat, umzusetzen. Die so angemeldeten und abgelieferten Netzpublikationen und Metainformation über das Werk werden weitgehend automatisch bearbeitet, wobei dann diverse Mängel dieses automatischen Abgabeverfahrens zutage treten.
Etwa werden die Personen wie Autor und beteiligte Personen nicht automatisch Personeneinträgen der DNB zugeordnet, sondern allenfalls Namenseinträgen. Etwa kann man zu einer Person nicht einmal die eventuell bereits vorhandene GND angeben, um ein Werk einer Person eindeutig zuzuordnen. Auch die Funktionen, die man einer Person in der OPF-Datei sorgfältig zugeordnet hat, sind beim Formular der DNB kaum zuzuordnen, pro Person ist nur eine Funktion vorgesehen und die Auswahl der möglichen Funktionen ist sehr eingeschränkt.
Ein Freifeld für ergänzende Angaben erweist sich in der Praxis als recht nutzlos, weil die zur Auswertung des Formulars verwendete Programme die Angaben darin natürlich nicht verstehen können und sich menschlicher Mitarbeiter derartige Angaben gar nicht erst ansehen.
Insgesamt ist die Ablieferung von Netzpublikationen bei der DNB derzeit technisch eher unausgereift und das System bedarf einer deutlichen Verbesserung (Stand 2015). Offenbar fehlen der DNB allerdings Mittel und Personal, um Netzpublikationen insbesondere von unabhängigen Autoren wirklich gleichrangig zu gedruckten Verlagsveröffentlichungen zu bearbeiten. Es fehlt offenbar auch der Wille oder der technische Sachverstand, um es unabhängigen Autoren für selbst angemeldete Werke einfach möglich zu machen, bei der Verbesserung der Situation zu helfen, um die DNB zu entlasten.
Wer mag, kann das Exemplar in der DNB allerdings sogar frei zugänglich machen und kann damit dann auch eine allgemeine, dauerhafte Verfügbarkeit sicherstellen.

Ähnliche Regelungen zur Ablieferungspflicht mag es auch in anderen Ländern geben. Der Herausgeber oder Verleger eines Buches muß sich also kümmern, welche Regelungen in seinem Land gelten.
In deutschen Bundesländern gibt es zudem meist oft noch eine Ablieferungspflicht für Druckwerke an die jeweilige Landesbibliothek, es ist dann jeweils für einen Veröffentlicher als Einwohner des jeweiligen Bundeslandes zu prüfen, ob ebenfalls ein Pflichtexemplar bei der Landesbibliothek abgeliefert werden muß.
Die Niedersächsische Landesbibliothek etwa sammelt auf Grund des Niedersächsischen Pressegesetzes Druckwerke, aber auch digitale/elektronische amtliche Veröffentlichungen.
Im Gesetz über die Ablieferung von Pflichtexemplaren in Nordrhein-Westfalen sieht dieses Bundesland hingegen auch eine Ablieferungspflicht für digitale Werke vor, wobei weitgehend die Regeln der DNB übernommen werden.
Da sich die Regelungen stark unterscheiden, sollte jeder Veröffentlicher genau prüfen, welches Landesgesetz für ihn zutrifft und ob eine Ablieferungspflicht an eine Landesbibliothek besteht oder nicht.

Eine weitere Pflicht bei einer Veröffentlichung betrifft eine Anbieterkennzeichnung oder ein Impressum, welches in Deutschland und in vielen anderen Ländern vorhanden sein muß. Solche Kontaktinformationen sind also im Buch vor der Veröffentlichung zu notieren. Siehe dazu auch folgenden Abschnitt zu den Metainformationen: Verleger.

Ferner gibt es in Deutschland auch noch rechtliche Besonderheiten hinsichtlich des Titels zu beachten. Hier kann das Markenrecht greifen, was knapp gesagt untersagt, schon in Verwendung befindliche Titel anderer Werke bei einer Veröffentlichung für das eigene Werk zu verwenden; Details dazu: Titelschutz.

Alternativen und Konversion in andere Formate?

Es gibt ja nicht nur EPUB als Format für digitale Bücher. Da stellt sich nun die Frage, ob es sinnvoll ist, Bücher auch in andere Formate zu konvertieren. Da es für andere Formate Programme gibt, die EPUB leider nicht interpretieren, kann das für einige Leser den Zugang zur Information erleichtern.

Jedenfalls ist es immer die bessere Lösung, wenn Geräte und Programme die Interpretation von EPUB implementiert bekommen - es müssen nicht mehrere Varianten desselben Buches bereitgehalten und gepflegt werden. Der Autor kann das für den Inhalt optimale Format wählen oder aber allgemein jenes mit dem wenigsten Barrieren für die Leser.

Eine Konversion kostet Zeit und Arbeit, die man sich sparen kann. Eine Konversion erhöht auch das Risiko von Fehlern und Mängeln und die Wahrscheinlichkeit steigt, daß Informationsverluste eintreten. Das andere Format mag andere Strukturen aufweisen oder nicht über genug oder die passenden Elemente und Strukturen verfügen, um die Semantik des mit EPUB realisierten Inhaltes angemessen abzubilden.

Entschließt man sich also zu einer Konversion, so ist als erster Schritt festzustellen, ob das anvisierte Format über die erforderlichen Strukturen zur semantischen Auszeichnung des Inhaltes verfügt. Wenn nicht oder wenn die Spezifikation eines proprietären Formates nicht allgemein zugänglich ist, so daß der Sachverhalt nicht prüfbar ist, ist das Format von vorne herein für eine Konversion nicht geeignet.

Es gibt natürlich diverse Programme, die vorgeben, nahezu alles in alles automatisch konvertieren zu können. Umfaßt dies auch Formate, die jeweils ein ganz anderes Konzept verfolgen, kann man davon ausgehen, daß eine solche Konversion als Ergebnis eine Markierungssuppe erzeugt, die inhaltlich unsinnig ist, gleichwohl bei oberflächlicher Betrachtung noch lesbar erscheinen mag.
Die Erfahrung mit diversen Konversionsprogrammen zeigt, daß auch bei Formaten mit ähnlichem Konzept praktisch immer eine manuelle Nachbearbeitung geboten ist. Bei Formaten mit sehr unterschiedlichem Konzept ist es oft günstiger, nur Text, Abbildungen, sonstige Informationen aus dem Ausgangsdokument komplett(!) zu extrahieren und die Umsetzung im gewünschten Endformat manuell vorzunehmen.

Die zahlreiche Hilfen, mit denen man mit speziellen Programmen eine automatische Konversion durchführen kann, sind also mit mehr als Vorsicht zu genießen. Von einer naiven Anwendung ist pauschal abzuraten. Nachdem ich mir die Ergebnisse einer solchen Konversion angesehen habe - also entweder von XHTML zu EPUB oder auch von EPUB in ein proprietäres Format und dann wieder zurück nach EPUB - würde ich generell davon abraten - die Ergebnisse werden zumeist Markierungssuppe sein, denen die semantische Information, teilweise auch Metainformationen aus dem OPF-Dokument verlorengegangen ist.

Probiert habe ich das mit Calibre und die Ergebnisse waren schlichtweg erschütternd, zumindest wenn man nicht mit Markierungssuppe angefangen hat, sondern mit semantisch passabel ausgezeichneten Inhalten.

XML-Formate

Als Alternative zu EPUB bietet sich natürlich XHTML selbst an. Insbesondere in der Variante XHTML+RDFa bietet es gute Möglichkeiten, die semantischen Defizite von XHTML auszugleichen. Es ist gut möglich, ein komplettes Buch mit exakt einer XHTML-Datei zu realisieren. Sofern man vorrangig Text hat und nur wenige Bilder, kann man letztere auch direkt in die XHTML-Datei einbetten, ebenso wie die Stilvorlagen. Bis zu einer Größe von wenigen Megabyte ist das eine praktikable Lösung, dann wird die Navigation im Dokument irgendwann doch etwas mühsam. Der Vorteil von einem Archivformat wie EPUB liegt darin, Inhalte auf mehrere Dateien aufteilen zu können, auch ist es hier einfach und möglich, inhaltlich relevante Bilder und andere Inhalte wiederzuverwenden. SVG bietet zur Wiederverwendung von Inhalten ebenfalls Möglichkeiten, die XHTML selber leider nicht aufweist. Mit einer Stilvorlage in CSS kann man aber zumindest dekorative Graphiken wiederverwenden.
Ein sehr großer Vorteil von XHTML ist natürlich, daß es keine besonderen Einschränkungen gibt und die Leser einfach die deutlich leistungsfähigeren Darstellungsprogramme für XHTML verwenden können, statt sich mit teils doch recht mangelhaften Programmen für EPUB herumärgern zu müssen oder das Archiv erst entpacken, um ein leistungsfähiges Darstellungsprogramm für XHTML verwenden zu können, denn bislang werden solche Bücher von diesen Programmen ohne besondere Erweiterungen ignoriert.

DocBook [DB] basiert ebenfalls auf XML und bietet eine gute Alternative für Dokumentationen und Sachbücher, weniger für Belletristik.
Für letztere wiederum speziell ausgelegt ist FictionBook [FB2], ebenfalls ein XML. Obwohl man aufgrund des Namens etwas anderes vermuten könnte, sind Spezifikationen und Anleitungen in russisch abgefaßt. Hier wäre es schön, wenn einmal jemand eine englische oder deutsche Übersetzung der Spezifikation verfassen könnte und ebenfalls eine Anleitung in englisch oder deutsch bereitstellen könnte.

Ein weiteres XML-Format mit einem reichhaltigen semantischen Satz an Elementen ist LML [LML] - vom Autor dieses Textes selbst entwickelt. Es gibt allerdings wohl keine speziellen Programme zur Interpretation dieses Formates, die Präsentation wird also nicht über das hinausgehen, was man für XML-Dokumente erwarten kann, deren Präsentation per CSS festgelegt sind. Funktionalitäten sind dann mit XLink oder XHTML-Dateninseln umzusetzen. Umgedreht können natürlich auch LML-Dateninseln in XHTML oder EPUB in Kombination mit geeigneten Stilvorlagen verwendet werden, um semantische Defizite von XHTML oder auch DTB zum kompensieren. Ausgezeichnet eignet sich LML auch für die Kombination mit XHTML+RDFa.

TEI [TEI] ist eine weitere sehr mächtige Sprache zur Auszeichnung von Literatur. Mittlerweise basiert sie auch auf XML. Ähnlich wie bei LML wird es allerdings wohl ebenfalls Einschränkungen bei der Funktionalität und der Präsentation geben, wenn dazu nur gängige Programme und Stilvorlagen verwendet werden. TEI bietet allerdings explizit Stilvorlagen im Format XSL an, um TEI nach EPUB und diverse andere Formate zu transformieren. Die Qualität der Ergebnisse sind dem Autor jedenfalls nicht bekannt. Vom Umfang von TEI und der Flexibilität und der Mächtigkeit von XSL ist es jedenfalls sicherlich möglich, qualitativ hochwertige Ergebnisse zu erzielen.

Eine weitere Gruppe von Formaten ergibt sich aus diversen Büroprogrammen, etwa OpenOffice, LibreOffice, KOffice, Calligra, MicrosoftOffice etc. Das von OpenOffice, LibreOffice, KOffice und Calligra verwendete Format ODF ist ebenfalls ein Archivformat, wobei Textinhalte ebenfalls in XML-Dateien stehen. Das Format ist allerdings primär dafür gedacht, Vorlagen für den Druck auf Papier zu erstellen, nicht direkt digitale Bücher mit semantisch guter Textauszeichnung.
Die zugehörige Spezifikation ist frei einsehbar und recht umfangreich, hinsichtlich des Umfangs an semantisch für Literatur relevanten Strukturen jedoch noch deutlich sparsamer ausgelegt als XHTML und daher eher suboptimal, um damit digitale Bücher zu schreiben. Konversionen von EPUB nach ODF sind daher zwangsläufig inhaltlich verlustbehaftet und sicher nicht empfehlenswert. Umgekehrt empfiehlt sich ein Export von ODF nach XHTML oder Klartext mit anschließender manueller Aufbereitung mit einem Texteditor.

Bei dem Format von MicrosoftOffice/Word ist die Spezifikation der XML-Variante wohl nur teilweise zugänglich oder vollständig, daher ist das Format nicht komplett zu durchschauen. Ähnlich wie mit OpenOffice, LibreOffice lassen sich damit primär Vorlagen für den Druck auf Papier erstellen, keine guten digitalen Bücher mit semantischer Textauszeichnung, dafür ist das Format zu armselig.
Eine Konversion von EPUB ist daher noch weniger empfehlenswert als für ODF. Da üblicherweise auch die XHTML-Ausgabe von Produkten von Microsoft mangelhaft ist, kann man es hier mit einer Klartext-Ausgabe versuchen oder den Umweg über OpenOffice, LibreOffice, KOffice oder Calligra gehen, die das Format meist ausreichend gut einlesen können, um Dokumente dann wieder als Klartext oder XHTML exportieren zu können, worauf dann wieder eine manuelle Aufarbeitung mit einem Texteditor erfolgen muß.

Generell kann es sich bei XML-Text-Dokumenten anbieten, eine Transformation nach XHTML mit einer Stilvorlagendatei im XML-Format XSLT vorzunehmen. Das kann einem eine Menge manueller Arbeit ersparen, manuelle Nachbearbeitung ist allerdings trotzdem wahrscheinlich. Zudem bedingt dies Vorgehen, daß man zunächst eine Stilvorlagendatei in dieser Sprache verfassen muß, die sich für die Quelltextdateien gut eignet. Dies bedingt natürlich auch eine relativ gute Kenntnisse sowohl von XSLT als auch der Struktur der Quelltextdateien.
Liegt der Quelltext nur als Markierungssuppe im Format HTML vor, ergeben sich zusätzliche Probleme, weil beliebiges HTML oder gar eine fröhliche Mischung von HTML und XHTML, die sich lediglich als XHTML ausgibt schwierig mit Programmen automatisch zu interpretieren ist, weil solche Markierungssuppen nicht den einfachen Regeln von XML genügen, sich also auch nicht für eine XSLT eignen. Hier läßt sich allerdings nachhelfen. Mit dem Programm tidy, davon abgeleiteten Programmen oder damit verwandten Programmen läßt sich unter anderem aus HTML-Markierungssuppe ein korrektes XHTML-Dokument oder XML-Dokument erzeugen, welches somit für eine XSLT verfügbar ist, mit welcher sich das Dokument für ein Buch in eine optimale Form bringen läßt.

In diesem Zusammenhang wird auch oft der Begriff der medienneutralen Ausgangsdaten verwendet. Semantisch reichhaltige Auszeichnungssprachen in einem XML-Format eignen sich gut als solche medienneutralen Ausgangsdaten, weil man dann anhand der semantischen Auszeichnung des Inhaltes bei einem bestimmten Endformat die Präsentation festlegen kann. Die Konversion vom semantisch reichhaltigen medienneutralen Ausgangsformat in ein nahezu beliebiges Endformat erfolgt dann etwa per XSLT oder ähnlichen Mechanismen.
Erstellung der Inhalte und gegebenenfalls spätere Korrekturen erfolgen dabei nur im Ausgangsformat, die Konversion erfolgt möglichst automatisch, wobei es bei zum Druck bestimmten Endformaten natürlich immer noch weitere getrennt zu lösende praktische und stilistische Probleme der Anordnung der Inhalte bedingt durch die festgelegte Größe des zu bedruckenden Papiers gibt. Das Ausgabemedium Papier kann hier die Präsentation von Inhalten so stark beeinflussen, daß teilweise auch die Reihenfolge der Präsentation des Inhaltes den beschränkten Möglichkeiten des Mediums angepaßt werden muß. Bei Druckformaten wie ODF ist die Trennung von Inhalt und Layout oder Präsentation also systembedingt nicht komplett wie gewünscht durchführbar.
Zum Druck bestimmte Formate sind folglich nicht medienneutral. Für digitale Präsentation bestimmte Formate berücksichtigen wiederum nicht die Dimensionen des Papiers für einen Ausdruck perfekt. Auch mit Stilvorlagen (XSL(T), CSS) lassen sich die spezifischen Probleme von komplexeren Druckwerken kaum komplett automatisch lösen. Eine für jedes Werk manuell und individuell angepaßte Stilvorlage ist bei komplexeren Druckwerken also ohnehin unvermeidbar und impliziert so immer einen deutlichen Mehraufwand bei Druckwerken.
Der medienneutrale Ansatz ist also immer ein Kompromiß, sofern unter anderem auch ein Druck auf Papier mit festgelegter Größe geplant ist. Auch bei dem Kompromiß ist es allerdings wichtig, zunächst von einem Format auszugehen, bei welchem nur semantisch ausgezeichnet wird, das Ausgabemedium also belanglos ist.
Somit eignen sich also Formate wie LML und TEI, auch XHTML+RDFa zusammen mit SVG sehr gut als Ausgangsformate für den medienneutralen Ansatz. Bei LML und TEI mit einem nicht erweiterten Vokabular ist für automatische Konversionen allerdings besser kontrollierbar, daß keine Information unbeabsichtigt verlorengeht als bei dem XHTML+RDFa oder LML mit erweitertem Vokabular, bei welchen der RDFa-Anteil die Möglichkeit bietet, Strukturen aus beliebigen Namensräumen zu referenzieren, was hinsichtlich einer automatischen Transformation zu beliebiger Komplexität führen kann.
Gerade das Problem von XHTML ohne Erweiterung, wie auch anderer Formaten ist dabei, daß sie semantisch nicht reichhaltig genug sind, um Inhalte nicht trivialer Bücher ausreichend signifikant auszuzeichnen, um gut als medienneutrales Ausgangformat für beliebige Werke dienen zu können, die somit nur unter Kenntnis des Ausgangsformates, nicht des Inhaltes des Werkes, automatisch transformiert werden könnten. Ein weiteres praktisches Problem ist häufig natürlich, daß die Autoren von Anfang an nur Markierungssuppe liefern, kein Werk mit sauberer Struktur und konsequenter semantischer Textauszeichnung.

LaTex, PS, PDF

Jenseits von XML beginnt dann allmählich der Wildwuchs schwerer zu durchschauender Formate. Etabliert ist seit Jahrzehnten, mittels LaTex Bücher in den Formaten PostScript (PS, EPS) oder das davon abgeleitete Portable Document Format (PDF) zu erzeugen. Nützlich ist das Ergebnis also primär als Druckvorlage, nicht für die direkte Verwendung als digitales Buch. LaTex ist sowohl deutlich älter als auch ausgereifter und professioneller für den Zweck der Erstellung von Druckvorlagen als die bereits erwähnten Office-Varianten, die lediglich den Vorteil haben, auf XML zu basieren, allerdings gibt es wohl auch eine Möglichkeit, eine XML-Variante für LaTex zu erstellen und dies dann mit einem allgemein verfügbaren Skript verlustfrei in die originale LaTex-Syntax zu konvertieren. Von daher erweisen sich die neueren Office-Varianten im Grunde als überflüssig.
LaTex ist gut dokumentiert und neben einfachen Texteditoren gibt es auch diverse spezielle Editoren für dieses Format. Somit gehört LaTex sicher noch nicht zum Wildwuchs, geht dem Konzept von XML eben nur voraus, man muß mit der anderen Syntax umgehen können oder eben die genannte Konversionshilfe verwenden.
Die Erzeugung von Dokumenten in den Formaten PS oder PDF erfolgt dann mit diesmal zuverlässigen Konvertern, die gute Ergebnisse liefern.
Besonders oder primär für den Druck sind also solche Bücher gut geeignet oder gedacht. Trotz der starren Formatierung der Inhalte eignen sie sich aber auch in begrenztem Maße für die Darstellung auf Bildschirmen. Das Konzept bei kleinen Bildschirmen ist dabei ähnlich wie bei großen SVG-Dateien - durch Skalierung oder horizontale und vertikale Verschiebung der Inhalte kann der nicht sichtbare Teil davon sichtbar gemacht werden. Da die Lesegeräte für digitale Bücher oft eher einen kleinen Bildschirm haben, empfiehlt es sich dann bei solch einem Format von einem kleinen Darstellungsbereich und einer großen Schrift auszugehen, etwa DIN A5 mit einer Schriftgröße von mindestens 12pt.

Das Konzept von LaTex ist älter als das von XML oder HTML, daher ist die Auszeichnung und Struktur des Inhaltes eher schwieriger durchschaubar als bei XML.
PS selbst läßt sich eigentlich auch direkt mit einem Texteditor bearbeiten, ist aber meist deutlich unübersichtlicher und weniger intuitiv als LaTex-Dokumente oder XML. PDF ist fast immer komprimiert und verschlüsselt abgespeichert, eignet sich daher nicht mehr, um mit dem Texteditor bearbeitet zu werden.

Wegen des stark abweichenden Konzeptes sind die Ergebnisse einer Konversion meist suboptimal. Ein PDF-Ergebnis einer automatischen Konversion wird man dringend nachbearbeiten wollen, um die Stärken des Formates nutzen zu können. Umgedreht wird das XHTML- oder EPUB-Ergebnis einer automatischen Konversion signifikante Mängel aufweisen und wohl nur noch aus Markierungssuppe bestehen, welche im besten Falle noch passabel lesbar präsentiert wird.

Die optimale Konversionsstrategie wird darin bestehen, das PDF in Klartext zu konvertieren und dieses dann mit einem Texteditor manuell in einen brauchbar ausgezeichneten Text zu verwandeln.
Umgedreht wird es ebenfalls sinnvoll sein, XHTML zumindest schrittweise in LaTex umzuschreiben und dann aus dem Ergebnis PS oder PDF zu erzeugen. Dafür kann sich wiederum auch eine Stilvorlagendatei im Format XSLT eignen. Weil das Problem verbreitet und bekannt ist, gibt es sowohl Beispiele für solche Stilvorlagendateien als auch frei verfügbare Skripte, die eine Konversion nach LaTex durchführen können. Bekannt ist etwa das Projekt 'xmltex', mit welchem sich XML direkt in LaTex einlesen läßt.
Die gleichen oder ähnliche Skripte sind auch in der Lage, aus LaTex-Dateien Rohmaterial im XHTML-Format zu erzeugen, welches man dann manuell oder per XSLT für das Buch optimieren kann. Eine automatische Konversion allein ohne Nachbearbeitung wird jedenfalls keine optimalen Ergebnisse liefern.
Pauschal kann man sagen, daß der Weg von einem medienneutralen XML-Format per Transformation nach LaTex der beste ist, um weit fortgeschrittenes Material für eine gedruckte Version eines Werkes zu bekommen.

Mobipocket, Kindle

Ein weiteres bekanntes Format oder eine ganze Formatfamilie ist Mobipocket (Amazon- oder Kindle-Formate). Diese Formate sind proprietär und sind zweifellos in die Rubrik Wildwuchs (überflüssig) einzuordnen. Leider ist (deshalb?) wenig darüber zu finden. Spezifikationen scheinen nicht öffentlich zugänglich zu sein. Ein solches Format ist jedenfalls nicht direkt mit dem Texteditor zu bearbeiten. Es soll sich auch um ein komprimiertes Archivformat handeln. Es ist aufgrund der fehlenden Spezifikation für den normalen Autor auch nicht ersichtlich, wie das Format erzeugt werden kann oder wie man das Archiv öffnen könnte, um die Inhalte zu bearbeiten oder verborgene Informationen zugänglich zu machen.

Gleichwohl bieten Programme wie Calibre eine automatische Konversion etwa nach EPUB an. Das Ergebnis ist dann wieder semantisch armselige Markierungssuppe. Ob das nur an Calibre liegt oder an Mobipocket, kann aufgrund der nicht einsehbaren Spezifikation des Formates nicht beurteilt werden. Von einer Konversion mit Calibre nach Mobipocket ist jedenfalls abzuraten. Gegenüber EPUB bietet das Format auch keine bekannten Vorteile für Autoren oder Leser.
Von Amazon werden ja spezielle Lesegeräte für dieses Kindle-Format angeboten, die dafür aber kein EPUB interpretieren können. Solche Geräte sind technischer Schrott und dienen lediglich dazu, Kunden an Amazon zu binden, haben also für Autoren oder Leser keinerlei Nutzen, für Amazon schon, man kann damit Leuten das Geld aus der Tasche ziehen.

Amazon bietet einen sogenannten KindleGen an, mit dem man zum Beispiel EPUB in das mit Mobipocket verwandte Kindle-Format konvertieren können soll. Das neue Format 'KF8' ist wohl ein erneuter Versuch, offene Standards wie EPUB durch eigene, proprietäre Abkömmlinge zu sabotieren.
Dieser Versuch ist aber recht einfach zu durchschauen, denn 'KF8' wird einfach erzeugt, indem ein EPUB-Buch als Eingabe verwendet wird, wobei die Ausgabe dann ein verschlüsseltes, nicht mehr zugängliches Archiv ist. Der einzige Zweck von 'KF8' scheint also darin zu bestehen, EPUB-Bücher zu korrumpieren.
Bei reichhaltigem, hochwertigem Inhalt wird dieser gezielt durch die Konversion qualitativ verschlechtert.

Bei meinem diesbezüglichen Konversionsversuch des hier diskutierten Prototyps ist das Programm (Version V2.9) gemäß eigenen Fehlermeldungen aber bereits daran gescheitert, mit den XHTML-Elementen abbr und object etwas anfangen zu können.
Vermutlich sucht es auch in der DTB-Datei vergeblich nach einem Element body und bricht die Konversion ab - anders als einige andere Meldungen des Programmes ist es hier nicht eindeutig.
Man muß sich offenbar auf eine Teilmenge von XHTML und von CSS beschränken, um das Programm zu einer Arbeit zu bewegen, die überhaupt zu irgendeinem Ergebnis führt.
KindleGen (Versuche mit der Version 2.9) scheitert auch daran, ganz normal von mir veröffentlichte EPUB-3-Bücher in das eigene Format konvertieren. Von daher ist das Programm nicht in der Lage, Bücher zu konvertieren, die auch nur gängige Inhalte in den normalen Inhaltsformaten XHTML und SVG enthalten.

Bei einem entsprechend einfach nur mit XHTML-Inhalten erzeugten Buch wird allerdings das gute XHTML-Ausgangsmaterial in Markierungssuppe verwandelt, was man erkennen kann, wenn man ohne Kompression konvertiert oder mit Calibre in den Quelltext schaut.
Vorsichtshalber hängt es allerdings ein nur leicht verfälschtes und gekürztes Original nochmal hinten an, wobei dies allerdings mit ungültigem Unfug verändert wurde, damit es nicht etwa noch als gültiges XHTML wie das Ausgangsmaterial verwendbar wäre.

Durch die Dopplung verdreifacht sich aber sogar auch die Dateigröße bei Kompression ungefähr, ohne Kompression vervierfacht sie sich - und das, obwohl KindleGen sogar einige Details vom originalen Inhalt gestrichen hat. Der gestrichene Inhalt hat dem Programm offenbar nicht gefallen.
Außerdem hat das Programm das NCX-Inhaltsverzeichnis verschlampt, ebenso wie die Vektorgraphik für das Titelbild.
Das Programm ist offenbar kein Freund von Zugänglichkeit und Verständlichkeit oder Vektorgraphik mit darin enthaltenem Alternativtext, denn es streicht Erklärungen für Abkürzungen und die barrierefreie Graphik und legt statt der Graphik oder der ebenfalls verfügbaren Alternative im Format PNG lieber eine mangelhafte Kopie im Format JPEG/JFIF an.

Bei dem Konversionsversuch gibt das Programm immerhin aus, was es eigenmächtig aus dem Buch gestrichen hat, verschweigt allerdings die Manipulation an den Graphiken, die immerhin relevante Lizenzbedingungen beinhalten können. Die in der OPF-Datei genannten Lizenzbedingungen werden dem Nutzer auch nicht zur Kenntnis gebracht, wodurch das Programm dann letztlich auch gezielt Lizenzverletzungen fördert, beziehungsweise gezielt die vom Autor angegebenen Lizenzbedingungen oder gar gesetzlich verlangte Pflichtangaben wie das Impressum in der Versenkung verschwinden läßt.

Calibre kommentiert das Ergebnis auch nur mit einer Fehlermeldung, FBreader zeigt immerhin etwas an, ebenso Okular.

Zusammenfassend ist das Programm KindleGen also wohl in der Praxis unbrauchbar. Autoren sollten sich Zensur und Manipulation an Inhalt und Lizenzbedingungen durch solch ein Programm und gleichzeitige Aufblähung der Dateigröße keinesfalls gefallen lassen.

Wenn der Autor eine Konversion mit KindleGen durch andere Personen ohne technische Kenntnisse erschweren will, könnte es also helfen, eine DTB-Datei im Buch unterzubringen. Dies sollte zum Abbruch der Konversion führen, was auch funktioniert, wenn solch eine Datei keinen relevanten Inhalt hat.

Verschiedene Verteiler von Büchern bieten ja auch selbst eigene Programme an, um EPUB in ein Amazon-Format zu verwandeln, beziehungsweise diese automatisch durchgeführte Konversion wird zwangsweise zusätzlich zum EPUB angeboten. Ein Test (2016-01) bei dem Anbieter BookRix hat ergeben, daß die Konversion nach Mobipocket zu einem unvollständigen Buch führt, die Graphiken fehlten komplett, Inhaltsverzeichnisse verweisen im Konversionsergebnis auf darin gar nicht vorhandene Inhalte etc - kurzum, unbrauchbarer Datenmüll wurde produziert. In Calibre war der Text kaum zu lesen, weil offenbar die im Buch vorhandenen Stilvorlagen fehlerhaft interpretiert wurden - ob bereits durch das Konversionsprogramm oder Calibre, bleibt bei dem Amazon-Format erst einmal offen, weil man den Inhalt eines Amazon-Buches ja nicht so einfach etwa mit einem Texteditor untersuchen kann. Jedenfalls ist es natürlich sinnlos, nur die Schriftfarbe aus der Stilvorlage im EPUB zu übernehmen, nicht aber auch die Hintergrundfarbe, bei hellgrauer Schrift aus dem Original und weißem Hintergrund aus dem Konversionsresultat kommt es so natürlich zu Zugänglichkeitsproblemen für die Leser.

Verwendet man hier Calibre zur Konversion, so sind die Ergebnisse im Vergleich interessant, in der Konversion nach Mobipocket sind alle Bilder enthalten, lediglich das Titelbild ist insofern mangelhaft, als sein Aspektverhältnis anders als beim Original bei der Anpassung an den Anzeigebereich verzerrt wird. Die Hintergrundfarbe wird auch hier nicht übernommen, der Text ist somit nur sehr schlecht lesbar, daher ist auch dieses Ergebnis der Konversion letztlich als mangelhaft einzustufen. Trotzdem legt das Ergebnis bereits nahe, daß das Konversionsprogramm von BookRix schlicht mangelhaft ist. Um eine brauchbare Version in Format Mobipocket zu erhalten, empfiehlt es sich, zunächst manuell eine vereinfachte Variante des Buches im Format EPUB zu erstellen und dies dann als Vorlage für die Konversion zu verwenden. Den Möglichkeiten von EPUB ist offenbar das Format Mobipocket nicht gewachsen und die Konversionsprogramme natürlich auch nicht.

Calibre bietet auch eine Konversion nach 'KF8'/'AZW3' an. Das Ergebnis ist deutlich besser, weil die Hintergrundfarbe übernommen wird. Auch die Bilder werden dargestellt, die Präsentation enthält jedoch Fehler. Das Titelbild wird ebenfalls bei der Anpassung an den Anzeigebereich verzerrt, dies passiert, weil Calibre zum einen selbständig die Vektorgraphik zu Pixelgraphik im Format JPEG/JFIF konvertiert, dies aber wieder in Vektorgraphik einbettet und dann ein entsprechendes Attribut in die Graphik einbaut, welches dafür sorgt, daß das Aspektverhältnis nicht erhalten bleibt und so den Fehler absichtlich verursacht. Die Wahl des Pixelgraphikformates sorgt zudem noch für eine schlechtere Qualität der Präsentation und eine höhere Dateigröße.
Auch bei den Graphiken im Inhalt gibt es Probleme. Im Original wird die zentrale Farbe der Graphiken von der aktuellen Textfarbe übernommen, das wird bei der Konversion ignoriert und stattdessen schwarz angenommen - schwarz auf dunkelgrauem Hintergrund ist aber schlecht sichtbar. Der Mangel dürfte daran liegen, daß Calibre in dem verballhornenden Amazon-Format die Graphiken nicht als Fragmente im Inhalt beläßt, sondern als eigenständiges Bild einbettet. Dieses pflegt aber keine Eigenschaften des einbettenden Dokumentes zu übernehmen. Die Methode ist also ungeeignet, mangelhaft oder fehlerhaft. Vorsichtig könnte man das Ergebnis als gerade noch ausreichend bezeichnen.
Dies liegt primär daran, daß 'KF8'/'AZW3' praktisch alle Inhaltsdokumente und Stilvorlagen übernimmt und nur geringfügig verschlechtert, um sie als Standard unzugänglich zu machen. Das heißt, Programme, welche XHTML und SVG interpretieren können, könnten nach einer Überwindung der proprietären Verschlüsselung und Verballhornung auch die Inhalte gut präsentieren, weil es letztlich dasselbe wie das ist, was im EPUB selbst zu finden ist. Die Mängel dürften primär durch unnötige Manipulationen von Calibre verursacht sein. Dies demaskiert zum anderen Amazon mit seinem Format 'KF8' einmal mehr als üble Trickser-Bande, die nur darauf aus ist, mit ihrem eigenen Pseudoformat ihre Kunden per Kundenbindung abzuzocken, zu manipulieren und zu kontrollieren, statt sich an offene Standards zu halten.

Wenn es also notwendig ist, in ein 'Amazon-Format' zu konvertieren, so scheint Calibre die bessere Wahl zu sein, damit kann man jedenfalls noch ausreichende Ergebnisse erzielen, sollte aber genau prüfen, wie schlecht das Ergebnis im Einzelfall wirklich ist. Teils kann man auch ohne wesentliche Nachteile für das Original dort eigentlich redundante Informationen hinzufügen, um das Ergebnis der Konversion zu verbessern. Das so manipulierte oder pessimierte Original selbst muß man zudem ja nicht in Umlauf bringen.

Amazon selbst bietet für wenige ausgewählte Betriebssysteme auch den Kindle Previewer, mit man sich anzeigen lassen kann, wie die Amazon-Formate auf Kindle-Geräten präsentiert werden. Gemäß dieser Simulationen haben Kindle-Geräte praktisch durchgehend Probleme mit jeglicher Art von Stilvorlage. Sofern man also extra für die Erzeugung von 'KF8'/'AZW3' oder Mobipocket eine vereinfachte Version eines EPUB-Buches anfertigt, sollten Stilvorlagendateien entfernt werden, weil deren Interpretation so mangelhaft und lückenhaft ist, daß dadurch massive Zugänglichkeitsprobleme entstehen. Jedenfalls sollten sämtliche Informationen zum Hintergrund und zur Textfarbe und Textgröße entfernt werden, ebenso sämtliche Positionierungsangaben.
Für das ältere Mobipocket ist es zudem dringend zum empfehlen, statt Vektorgraphiken Pixelgraphiken mit zusätzlicher XHTML-Textalternative einzubinden, was dann für solch eine extrem vereinfachte Version eine Konversion etwa mit Inkscape oder Gimp erforderlich macht und zu entsprechend großen Dateien führen wird.
Gemäß dieser Simulationen sind jedenfalls sämtliche Kindle-Geräte als technisch hoffnungslos veraltet einzustufen, denn obwohl jedenfalls die 'KF8'-Variante alle relevanten Informationen vom EPUB übernimmt, ist die Anzeige mangelhaft, was auch für das Kindle-Programm gilt, mit welchem Bücher im Kindle-Format bei wenigen ausgewählten Betriebssystemen präsentiert werden können, zutrifft. Mit diesem kann man auch EPUB-Bücher konvertieren, das Programm scheitert aber genauso wie KindleGen. Geräte und Programme von Amazon erweisen sich also als durchweg mangelhaft.

Die für Calibre erwähnten Darstellungsprobleme für diese Formate liegen also vermutlich nicht allein an Calibre, sondern an den Formaten, beziehungsweise Calibre versucht jedenfalls teilweise das fehlerhafte Verhalten der Kindle-Geräte zu simulieren, vermischt und kumuliert dabei eher Probleme verschiedener Geräte, statt ein bestimmtes zu simulieren.
Umgedreht kann man allerdings auch formulieren, daß weder Calibre noch die Programme von Amazon in der Lage sind, die Schwächen von 'KF8'/'AZW3' oder Mobipocket bei der Formatkonversion automatisch zu berücksichtigen. Auch bieten sie bei der Konversion nicht einmal die Möglichkeit, zwischen verschiedenen vorhandenen alternativen Stilvorlagen eines Buches für die Konversion auszuwählen, womit es für Autoren deutlich einfacher wäre, durch Auswahl einer geeigneten Stilvorlage gleich bei der Konversion für eine passable Präsentation im konvertierten Buch zu sorgen.

Spezielle Editoren verwenden?

Unlängst gibt es ja auch spezielle Editoren oder Erweiterungen für andere Programme zur Erstellung von Büchern im Format EPUB, die insbesondere für unkundige Autoren geeignet sein sollen, die sich die Kenntnisse zur Erstellung von digitalen Büchern nicht selbst aneignen wollen oder welche solche Programme auch einfach zur Arbeitserleichterung verwenden möchten. Bei solchen Programmen ist insbesondere darauf zu achten, welche EPUB-Versionen sie erstellen können. Mittlerweile ist es sicherlich angebracht, daß sich auch bei Bedarf Bücher nach EPUB 3 erstellen lassen. Leider sind mir viele dieser Editoren gar nicht zugänglich, weil es von diesen bislang keine stabile Version davon gibt (die auf dem von mir genutzten stabilen Debian-Linux funktioniert), von daher ist bei vielen dieser Programme oder Erweiterungen sicherlich davon auszugehen, daß sie noch im experimentellen Stadium sind. Ein Autor sollte ein damit erstelltes Buch also unbedingt entpacken und nachkontrollieren, daß wirklich ein gutes Ergebnis erzielt wurde. Das bedingt natürlich doch wieder, daß man sich mit dem Format selbst gut auskennen muß, um die Arbeit solcher Programme beurteilen zu können, was dann die Programme zu einem guten Teil wieder redundant macht.

Eine erster Ansatz zur Kontrolle ist etwa, ein bereits manuell fertiggestelltes Buch mit solch einem Editor weiter zu bearbeiten, Kommentare und Fehlerlisten eines solchen Programmes sind dann anzusehen und das Buch ist auch einmal ohne eigene Änderung und einmal mit automatischer 'Fehlerbehebung' zu speichern und dann mit dem Original zu vergleichen. Hat solch ein Programm nichts verändert oder jedenfalls nichts, was richtig und wichtig für den Inhalt ist, lohnt sich eine weitere Untersuchung des Programmes. Bei Änderungen sollte das Programm auf jeden Fall jede Änderung erst einmal vorschlagen und begründen.

Insgeheime Änderungen sind etwa von Sigil bekannt, was dann vermutlich die mühsame Arbeit des Autors um qualitativ hochwertigen Inhalt sabotiert. Derartige Programme sind also erst einmal mit großem Mißtrauen zu betrachten.

Ein Programm namens Jutoh habe ich auch installieren und selbst testen können, dazu habe ich ein kurz zuvor manuell erstelltes EPUB mit guter semantischer Textauszeichnung und einigen Graphiken erst einmal einlesen lassen. Bereits da hat dieses Programm alle Graphiken entsorgt und die die semantische Textauszeichnung in blödsinnige Markierungssuppe konvertiert. Von daher scheint das Programm weder für Kenner noch für Anfänger sinnvoll zu sein, nach der Empfehlung kann ich von einer Installation zum Zwecke einer Nutzung nur abraten.

Calibre hat inzwischen auch einen Editor eingebaut. Bei diesem ist mir jedenfalls bei meinen Büchern, die nach EPUB 3 erstellt sind, aufgefallen, daß Calibre sehr viele falsche Fehlermeldungen produziert, wenn man ein fertiges Buch überprüfen läßt. Jedenfalls habe ich bei den Versuchen mit meinen Büchern bislang keine korrekte Fehlermeldung gesehen oder auch nur eine, die irgendwie hilfreich wäre.
Speichert man jedenfalls die geänderte Version ab, erhält man immer noch ein Buch nach EPUB 3, welches aber deutlich schlechter ist als das Original, die Änderungen sind nicht nur überflüssig, sie verschlechtern auch die Qualität des Buches und teils gar die zuvor verfügbaren Funktionen und alternativen Zugänge zum Inhalt. Dieser Editor ist also sicherlich noch nicht ausgereift und als experimentell einzustufen. Vor einer Veröffentlichung eines damit erstellten Buches ist es daher unbedingt notwendig, dieses manuell nachzubearbeiten und aufzuräumen.
Mag das ganz gut geeignet sein, um Bücher in anderen Formaten dadurch ganz gut lesbar zu machen, daß es eine Konversion vornimmt, so sind diese Konversion jedenfalls durchweg für eine Veröffentlichung eines als hochwertig gedachten Buches nicht geeignet. Der Editor selbst mag sich für sehr einfache Bücher eignen, die man dann aber wohl komplett mit diesem Editor erstellen sollte und dann im Anschluß manuell bearbeiten. Kann man letzteres, ist aber natürlich der Editor mehr oder weniger redundant, dieser kann dann allenfalls helfen, Syntaxfehler zu vermeiden, welche aber auch der EPUB-Validator entdecken wird.

Verläßliche Editoren oder Hilfsprogramme können einem zweifellos die Arbeit erleichtern, auch ich verwende bei dafür geeigneten Inhalten eigene Hilfsskripte, um sich wiederholende, langweilige Produktionsschritte zu automatisieren. Allerdings scheint es bislang keinesfalls so zu sein, daß man sich auf die verfügbaren Programme verlassen kann oder sollte. Es handelt sich fast immer um unvollständige, experimentelle Projekte, die es notwendig machen, auf Basis eigener detaillierter Kenntnisse bei jedem damit produzierten Buch nachzuprüfen und nachzubessern. Wenn es auf Qualität nicht so ankommt, mögen solche Programme bereits brauchbar sein, wer Wert auf Qualität legt, sollte allerdings mißtrauisch bleiben.

Literaturangaben