Doch die Wissenschaft, man weiß es,
achtet nicht des Laienfleißes.
Christian Morgenstern
Erstellt: 2013/2018
Autor: Dr. O. Hoffmann (Weitere Projekte des Autors, Kontakt)
Im Folgenden wird ausführlich erläutert, wie der Inhalt eines digitalen Buches der Version EPUB 2 erstellt wird.
Die Version 2 ist zwar technisch als veraltet anzusehen, allerdings gibt es zahlreiche Bücher, die in diesem Format veröffentlicht wurden, diverse Hilfsprogramme setzen nach wie vor auf Version 2.
Daher kann es also Gründe geben, auch heute noch Version 2 zu verwenden.
Version 3 ist einerseits bei dem, was wirklich funktioniert, etwas umfangreicher, ist andererseits aber bei ähnlichem Buchinhalt etwas einfacher zu erstellen.
Falls es also doch Version 3 sein soll: Erläuterungen zur Erstellung des Buchinhaltes in Version EPUB 3.
Ansonsten geht es hier weiter:
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.
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>
Oben gibt es erst einmal 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.
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.
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.
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.
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.
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.
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.
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.
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 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].
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
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.
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