XML-Know How

Die Paketdatei OPF

8803.png
Abb. 3.2

Sobald ein Kindle-E-Book anstelle einer einzelnen HTML-Datei aus mehreren Inhaltsdokumenten und einem logischen Inhaltsverzeichnis produziert werden soll, ist eine OPF-Paketdatei zur Definition und Steuerung der Paketinhalte notwendig. Der grundsätzliche Aufbau dieser Datei wurde bereits in Kapitel 2.1 ausführlich beschrieben. Die in KF 8 eingesetzte XML-Struktur basiert auf einer Teilmenge der in EPUB 2 definierten OPF-Spezifikation. Die strukturellen Unterschiede werden nachfolgend beschrieben.

Der metadata-Container

Grundsätzlich werden alle 15 Dublin Core Metadaten-Elemente vom Kindle-Format unterstützt werden. Prüft man die Zieldatei durch eine Rückkonvertierung ab, zeigt sich jedoch, dass die Elemente dc:format, dc:relation und dc:coverage im Endformat nicht vorhanden sind. Die weiteren zwölf DCMES-Elemente werden verarbeitet. Verpflichtend sind lediglich die Elemente dc:title und dc:language.

Die OPF-Spezifikation ergänzt die Dublin Core-Elemente um einige optionale OPF-Attribute, mit welchen einige Elemente spezifiziert werden können. Um das Schema, das dem Bezeichner des dc:identifiers-Elements zugrunde liegt, zu definieren (z. B. eine URI), wird die Struktur um das OPF-Attribut opf:scheme erweitert. In dem folgenden Beispiel-Listing wird die Angabe dc:creator um die Information, welche Rolle dem Herausgeber zukommt, ergänzt. Zudem wird mit dem opf:file-as-Attribut eine normalisierte, maschinenlesbare Variante des Inhalts definiert:


<metadata xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:opf="http://www.idpf.org/2007/opf">
<dc:creator opf:file-as="Kämmerle, Andreas" opf:role="aut">Andreas Kämmerle</dc:creator>
[…]
Listing 3.1 Klassifizierung durch die OPF-Attribute

Bei der Verwendung eines OPF-Attributs muss zusätzlich der Namespace xmlns:opf="http://www.idpf.org/2007/opf" am metadata-Container ergänzt werden. Eine exakte Auflistung der möglichen Attribute findet sich in der Spezifikation des OPF-Standards.

Neben den zwei obligatorischen Dublin Core Metadaten muss ein weiteres, formatspezifisches Element zwingend für die Generierung des Kindle Format 8 vorhanden sein. Die Cover-Abbildung der Kindle-Publikation muss innerhalb der Metadaten durch ein meta-Element ausgezeichnet werden, das auf den entsprechenden Eintrag der Grafik im Manifest verweist. Der Wert des content-Attributs entspricht der ID des item-Eintrags.10


<meta name="cover" content="coverID"/>
Listing 3.2 Das meta-Element referenziert die Covergrafik

Der manifest-Container

Das manifest-Element ist identisch zu der im Kapitel 2.1.2 beschriebenen Struktur des Containers. Während in EPUB jedoch sämtliche enthaltene Dateien im Manifest gelistet werden müssen, ist für das Kindle-Format die Aufnahme von CSS- sowie Abbildungsdateien nicht zwingend erforderlich, sofern diese in den HTML-Inhaltsdokumenten referenziert werden.

Die Navigationsdatei NCX, die im folgenden Kapitel 3.2 detailliert beschrieben wird, muss als fester Bestandteil des Formats in den manifest-Container aufgenommen werden.


<manifest>
  <item id="ncx" href="toc.ncx" media-type="application/x-dtbncx+xml"/>
  […]
</manifest>
Listing 3.3 Manifest-Eintrag der NCX-Navigationsdatei

Eine Übersicht über die unterstützten Medientypen von KF 8, zu welchen auch die eingebetteten Schriftdateien zählen, liefert die folgende Tabelle.

MIME-Type

Endung

Bedeutung

application/xhtml+xml

.xhtml

Inhaltsformat

application/x-dtbncx+xml

.ncx

Navigationsstandard

application/vnd.ms-opentype

.otf

Fontformat

application/x-font-ttf

.ttf

Fontformat

image/bmp

.bmp

Abbildungsformat

image/gif

.gif

Abbildungsformat

image/jpeg

.jpg

Abbildungsformat

image/png

.png

Abbildungsformat

image/svg+xml

.svg

XML-basiertes
Vektorengrafikformat

text/css

.css

Stylesheetformat

Tab. 3.1 Die KF 8-Medientypen

Das spine-Element

Auch das spine-Element zur Definition der Dokumentabfolge ist dem Aufbau in EPUB nahezu identisch. Der einzige Unterschied ist die Aufnahme des NCX-Inhaltsverzeichnisses am Containerelement. Es erhält das Attribut toc, dessen Wert der ID des NCX-Eintrags im Manifest entspricht.


<spine toc="ncx">
  […]
</spine>
Listing 3.4 Ergänzung der NCX-Datei am spine-Element

Das guide-Element

Eine weitere notwendige Navigationsstruktur für Kindle-Publikationen ist das guide-Element, das auch in EPUB 2 zum Einsatz kommt. Dieser vierte Container der Paketdatei definiert den Zugang zu zentralen Bestandteilen des E-Books für Kindle-Lesegeräte. Beispiele für diese Strukturen sind das Cover oder der Textbeginn. Diese Angaben legen die Zielpunkte für die Standardnavigation der Lesegeräte wie „Inhaltsangabe“ oder „Textanfang“ fest.

Für die Auszeichnung einer solchen Struktur ist das Element reference zuständig. Ähnlich dem item-Element enthält es mit dem href-Attribut einen Verweis auf die Zieldatei, das type-Attribut ist für die Deklaration des Strukturtyps verantwortlich. Das title-Attribut ist optional und hat aktuell keine Auswirkung auf die Ausgabe. Während der OPF-Standard eine Vielzahl von Publikationstrukturen für das guide-Element definiert, unterstützt das Kindle-Format hiervon lediglich die drei nachfolgenden Typen.

type-Wert

Vorkommen

Bedeutung

toc

verpflichtend

HTML-Inhaltsverzeichnis

text

verpflichtend

Inhaltsbeginn

cover

optional

HTML-Buchcover

Tab. 3.2 guide-Typen des KF 8-Formats

Die Festlegung des toc-Werts als verpflichtend macht deutlich, dass Kindle-­E-Books neben einer logischen NCX-Inhaltsverzeichnisdatei auch ein HTML-Inhaltsverzeichnis enthalten müssen.

Da in KF 8 die Coverabbildung direkt in den Metadaten referenziert wird, ist die Verwendung des Eintrags für das HTML-Cover im guide-Element nicht notwendig, unterstützt wird es aus Kompatibilitätsgründen der Quelldaten zu EPUB 2. Ein typisches guide-Element einer KF 8-Paketdatei sieht also wie folgt aus:


<guide>
  <reference type="toc" title="Inhaltsverzeichnis" href="inhaltsvz.xhtml"/>
  <reference type="text" title="Anfang" href="kapitel1.xhtml"/>
</guide>
Listing 3.5 Das guide-Element

10 In EPUB 2 wurde dieses Element ebenfalls verwendet, um Lesegeräten den direkten Aufruf der Coverabbildung anstelle einer eigenen HTML-Coverdatei zu ermöglichen.