Auf dem Weg zum E-Buch — konkrete Umsetzung mit Hindernissen. [Update]

Es ist soweit, nach meiner bisher sehr ausführlichen “Grundlagenforschung” werde ich mit meinem Manuskript “WordPress Anwenderhandbuch” folgende Vorgehensweise ausprobieren:

  1. Buch in Word schreiben
  2. als “gefiltertes HTML” exportieren
  3. in Sigil zum EPUB aufbereiten
  4. mit Hamster zu MOBI umwandeln

Das heißt noch lange nicht, daß dies der “beste” Weg ist, aber irgendwo muß man ja mal anfangen…


Vorbereitungen in Word

Auf der einen Seite gehört zum souveränen Umgang mit einer Textverarbeitung auch die Nutzung aller zur Verfügung stehenden Funktionen. Auf der anderen Seite heißt es zur Vorbereitung eines E-Buches, auf möglichst viel davon zu verzichten. Deshalb kopiere(!) ich den kompletten Manuskriptordner, um erst das Dokument und später auch die verknüpften Bilder diesbezüglich optimieren zu können — falls etwas schiefgeht oder doch ein druckfähiges Manuskript benötigt wird, sollte man nicht mit den Originalen arbeiten.

Schon im Original angepaßt: Brottext ohne Leerzeile nach Absatz, Bilder jeweils allein in einer Zeile, keine Spielereien mit Layout (umfließen und so).

In der Titelei die unterschiedlichen Schriften und Größen gelöscht, das kann man später effektiver in Sigil nachbauen. Stattdessen schonmal an ein separates Titelbild als Bilddatei denken. Es wird zum Teil vom EPUB-Editor, spätestens jedoch von Amazon KDP angefordert.

Traurig, aber wahr: Tabellen als Grafik einbinden (zumal in diesem Fall die aufgelisteten Sonderzeichen nicht sicher dargestellt werden können). Selbst wenn neue Standards echte Tabellen erlauben, sollte es auf einem “alten” Kindle Keyboard funktionieren.

Für Kapitel-Überschriften ohne Änderung die entsprechenden Formatvorlagen “Überschrift 1” usw. verwenden. Manueller Seitenumbruch ist nicht notwendig (wird z. T. sogar ignoriert). Ein von Word erstelltes Inhaltsverzeichnis löschen, es wird später zuverlässiger von der E-Book-Software erstellt.

Bei der Gelegenheit möglichst viele Formatvorlagen vereinfachen Formatvorlagen nutzen, aber vereinfachen.oder sogar löschen, insbesondere die von Word automatisch anlegten, zum Beispiel aus der Titelei.

Formatvorlagen nutzen, aber vereinfachen.

Das Schöne dabei ist, daß Word in der Seitenleiste bei Bedarf jeweils die Anzahl der betreffenden Instanzen anzeigt, so daß man den Aufwand abschätzen und anschließend den Fortschritt kontrollieren kann. Die Formatvorlage für Tastenkappen vereinfachen (ich kann sie später im CSS wieder optimieren, Hauptsache, die Markierung im Text bleibt bestehen). Obwohl es später möglicherweise Mehraufwand bedeutet, lasse ich meine Abbildungsdateiinfo auch erstmal drin, da man damit später ggf. fehlende Bilder besser rekonstruieren kann.

Nicht ausprobiert habe ich das Makro “Word macro for clean HTML code”, das alle diese Arbeiten erledigen soll, Info bei Mobile Read . — Selbst wer gleich in Libre Office arbeitet und das dort verfügbare Plugin einsetzt, sollte solche Vereinfachungen berücksichtigen.

Alle Sonderzeichen (z. B. Numerierungs-Kügelchen bei Schritt für Schritt oder Pfeile) aus dem Text entfernen, da sie nicht einheitlich unterstützt oder gar nicht umgesetzt werden.

Spezialitäten zum Layout und Feldfunktionen löschen, wie beispielsweise Kopf- und Fußzeilen, Seitennumerierung, automatische Numerierung der Abbildungen, Querverweise.

Zum Schluß das ganze je nach weiterem Vorgehen speichern:

  • als doc für Mobipocket Creator (kann ggf. auch gefiltertes HTML verwenden)
  • als “gefiltertes HTML” für Sigil u. a., die ausschließlich mit HTML arbeiten
  • als rtf für alle Fälle…

 

Bilder vorbereiten

In meinem ersten Versuch denke ich noch, daß man verknüpfte Bilder ja immer noch extern nachbearbeiten könne. Stimmt im Prinzip auch, ist aber aufwendig, wenn sie erstmal in der EPUB-Struktur verschwunden sind. Besser ist es, vorher alle Bilder in der Größe zu optimieren — denn zumindest Amazon erhebt ab einer gewissen E-Buch-Größe zusätzliche eine “Transportgebühr” und gerade bei einem Fachbuch mit vielen Bildern ist dies eine ernstzunehmende Stellschraube.

Bilder können Dateien aufblähen.

Bilder können Dateien aufblähen.

Einige der großen Screenshots mit 2.000 Pixel wie beispielsweise die “Gegenüberstellung” oder die Ansicht zur “Bildbearbeitung” optimiere ich von Hand, indem ich den Ausschnitt enger fasse und auch die absolute Größe verringere. Das bringt teilweise schon Ersparnis von 30 bis 50 Prozent der Dateigröße (die beim größten Einzelbild ursprünglich bei mehr als 900 Kilobyte liegt). Doch wie eingangs kurz erwähnt, sind die Bilder noch immer in 100-Prozent-Qualität. Nach einigen manuellen Versuchen Riot (Radical Image Optimization Tool) für das beste Verhältnis von Bildqualität zu Dateigröße, reduziere ich mit der Stapelverarbeitung von Irfanview die JPG-Qualität generell auf “55”. Insgesamt schrumpfen so ursprünglich fast 5 Megabyte auf ca. 1,1 Megabyte. Die Bildqualität ist für 1:1-Darstellung in Ordnung, zumal die meisten Bilder später sogar noch etwas verkleinert werden.

Tipp: Wenn man sich als Selfpublisher mit einem E-Book versuchen will, sollte man sich einigermaßen mit HTML und CSS auskennen. Das erleichtert das Verständnis der notwendigen Arbeitsschritte und hilft enorm kleine Korrekturen direkt im Code vornehmen zu können.

 

Nach Sigil importieren

Jetzt folgt der Import nach Sigil, was prinzipiell einfaches Öffnen der HTML-Datei bedeutet. Der Anleitung folgend speichere ich den frischen Import sofort ohne weitere Bearbeitung als EPUB, um sicherzustellen, daß alles klappt. Es wird fortan im EPUB-Format gearbeitet (das ist nur die eine Datei mit dem Namen des Projektes), auch wenn das Buch noch lange nicht fertig ist (die o. g. Import-Dateien/Ordner müssen also nicht mehr gesichert werden).

Tipp: Zu Sigil gibt es ein sehr ausführliches Handbuch. Erfreulicherweise ist es kein PDF, sondern ein EPUB. Man sollte es zu Rate ziehen, ich habe es parallel im kostenlosen Sony EPUB-Viewer geöffnet. Wahlweise auch online unter http://web.sigil.googlecode.com/git/files/OEBPS/Text/introduction.html.

 

Styles bearbeiten

Auch wenn das Sigil-Handbuch schon bei den ersten Schritten auf Metainformationen und Kapitelaufteilung hinweist, sollte man sich gerade nach einem auf Word basierenden Import erst den Styles widmen. Diese sind nämlich im Header der Quelldatei eingebettet und würden gerade nach einer Aufteilung des Textes in jede Teildatei übernommen und die Handhabung unnötig erschweren. Über “Datei | Hinzufügen | Leeres Stylesheet” lege ich eine externe CSS-Datei an, in die ich die o. g. Styles-Definition der Einzeldateien kopiere (und im Header natürlich lösche). Dann wird die externe Styles-Datei wie üblich eingebunden. Dies geht bequem und sicher über die Seitenleiste, Rechtsklick auf die betreffende Datei “Verknüpfe Stylesheets”, die entsprechende Datei auswählen.

Wenn man schonmal dabei ist (und Sigil vertraut) kann man die Funktion “Werkzeuge | Löschen unbenutzter Stylesheetklassen” die umfangreiche Datei auch gleich von Ballast befreien. Gerade bei einem Word-Export sind trotz meiner Reinigungsmaßnahme eine Menge unbenutzter Formatvorlagen als Styles übernommen worden. Sigil zeigt vor dem Löschen freundlicherweise erstmal alle Klassen an, die auf der Abschußliste stehen — weg damit.

Und es geschieht ein kleines Wunder: Bis zu dieser Optimierung wurden nicht alle Styles im Dokument korrekt angezeigt, obwohl sie bei einem (flüchtigen) Blick in den HTML-Code korrekt eingebettet sind. Jetzt — mit der zentralen Styles-Datei — sind fast alle vorhanden. Sogar meine “Tastenkappen” (grau unterlegter Text) und spezielles kursiv (kursive Times) sind dabei.

Was bleibt davon im E-Book übrig?

Was bleibt davon im E-Book übrig?

Es ist die Frage, was davon im E-Book übrig bleibt bzw. praxistauglich ist. In der Kindle-Definition sind ja einige Sonderzeichen bis jetzt nicht darstellbar. Bei einer ersten “Gegenprobe” im externen EPUB-Viewer fällt leider schon eine Menge davon weg…

Kapitel aufteilen

Obwohl ich im Original Seitenumbrüche hinter jedem Kapitel habe, sind sie nach der Übertragung zu Sigil verschwunden. Macht nichts, man kann sie jetzt einfügen (muß man aber nicht, kann die Handhabung aber vereinfachen und ist für manche Reader später besser handhabbar). Auf “Einfügen | Teilungsmarkierung” (Strg-Shift-Return) oder das Icon in der Einen Text in Kapitel aufteilen.Menüleiste klicken. Die Beschriftung ist etwas irreführend, denn es wird keine Markierung eingefügt, sondern der Text unmittelbar in eine zweite Datei usw. aufgeteilt. Da freue ich mich, daß die Style-Definition nun extern liegt, sonst müßte man bei Änderungen jeden Header einzeln bearbeiten. Gleichzeitig benenne ich die “sections0001” in der Seitenleiste den Inhalten entsprechend um, zum Beispiel “kapitel_1_dashboard.htm”.

Inhaltsverzeichnis erstellen

Wenn man mit der Aufteilung fertig ist, kann man sich dem Inhaltsverzeichnis widmen. Dazu gibt es oft schon am rechten Rand eine Spalte oder im Menü “Werkzeuge | Inhaltsverzeichnis | Inhaltsverzeichnis erzeugen…” oder (Strg-T).

Mit <h1 >, <h2 > usw. ausgezeichnete Kapitelüberschriften werden erkannt.

Mit <h1>, <h2> usw. ausgezeichnete Kapitelüberschriften werden automatisch erkannt.

Mit <h1>, <h2> usw. ausgezeichnete Kapitelüberschriften werden automatisch erkannt — das ist der Lohn für sauberes und strukturiertes Arbeiten. Trotzdem tauchen manchmal leere Zeilen auf (roter Rahmen): Das sind beim Teilen verwaiste leere Zeilen, die man einfach abwählen kann (ich lösche sie aber von Hand im Quelltext, damit sie nicht doch noch im unpassenden Moment auftauchen).

Das Inhaltsverzeichnis wird erstellt, aber nicht automatisch angezeigt (es sei denn, man hatte schon das Fenster der Standardkonfiguration). Über “Ansicht | Inhaltsverzeichnis” (Alt-F3) kann man es anzeigen lassen. So hat man nicht nur die Kontrolle, daß alle Kapitel richtig erkannt wurden, sondern kann es bei der weiteren Arbeit praktisch nutzen: Anklicken, um zu einem bestimmten Abschnitt zu springen.

Erstmals überlege ich mir, weitere Projekte direkt in Sigil zu schreiben: Einerseits muß man auch eine “gefilterte” Word-Datei recht aufwendig nachbearbeiten, andererseits ist Sigil doch recht komfortabel — zumindest, wenn man sonst einen HTML-Editor gewohnt ist.

Theoretisch soll dieses Inhaltsverzeichnis als interne “toc.ncx” schon ausreichen, man kann aber aus Kompatibilitätsgründen zusätzlich noch ein HTML-Inhaltsverzeichnis erzeugen. Dazu reicht es, in “Werkzeuge | Inhaltsverzeichnis | Erstelle HTML Inhaltsverzeichnis” auszuwählen, sinnvoll in Hinblick auf die Umwandlung zu MOBI. Es wird automatisch eine neue Datei “TOC.xhtml ” angelegt, in der sich ein voll funktionsfähiges Inhaltsverzeichnis befindet. Bei Änderungen muß man den Vorgang einfach wiederholen, es wird dann aktualisiert überschrieben.

Bild

Umwandlung ins MOBI-Format via “Hamster”.

Gegenprobe

In Sigil sieht bisher alles prima aus, auch meine Zeichensatzeinstellungen für kursive Times bei serifenlosem Brottext oder die angedeuteten Tastenkappen (grau hinterlegt mit schmalem Rahmen) werden übernommen (ist ja auch alles sauber per CSS definiert!). Daß diese Feinheiten im fertigen E-Buch abweichen überrascht mich nicht wirklich, weil sich ja der Leser die Schrift selbst aussuchen können soll. Ich würde es aber gut finden, wenn meine Einstellungen erstmal als “Empfehlung” übernommen würden und der Leser sie ggf. Gegenprobe im EBUB-Reader. anschließend seinen Wünschen anpassen kann.

Meine Gegenprobe des E-Buchs mache ich mit folgenden Geräten:

  • EPUB: Sony Reader (Software), Calibre (Software) und TrekStor (Hardware)
  • MOBI: Kindle Previewer (Software), Kindle App (Software), Keyboard Keyboard (Hardware) und Kindle 4 (Hardware)

Unerfreulich dagegen, daß es gerade beim EPUB nicht nur deutliche Abweichungen an ganz harmlosen Stellen gibt, sondern es teilweise unlesbar wird. Beispiele:

  • Die Kapitelüberschriften sind mal linksbündig und mal zentriert — kann man mit leben…
  • Strichaufzählungen (hier eigentlich “bullets”) haben nur einen winzigen Punkt vorweg, beim TrekStor ist auch die Schrift winzig, obwohl ich alle Aufzählungen von Hand auf Standards eingestellt habe.
  • Bei der numerierten Aufzählung ist die vorangestellte Ziffer groß, der folgende Text unleserlich klein (jeweils in Relation zum gut lesbaren Brottext), manchmal werden aus Ziffern auch Bullets (also eine ungeordnete Liste).
  • Bildunterschriften werden mal gefettet und mal “normal” dargestellt, was natürlich nach einem Seitenumbruch im Reader zu Irritationen führen kann.
  • Infokasten mal mit mal ohne Rand oder so fett, daß es eher nach Trauerrand anmutet; bei MOBI durch Einrückung ersetzt.

 

Silgil Sony EPUB Reader Sony EPUB Reader Test auf echter Hardware Calibri EPUB Kindle Previewer Echter Screenshot Kindle Keyboard

Sigil, Sony EPUB Viewer (Bild & Liste), TrekStor (eBook Player 5), Calibri Viewer, Kindle Previewer (E-Ink Kindle), Screenshot Kindle Keyboard

Da diese Fehler nicht einheitlich, sondern fallweise auftreten (insb. bei meiner einzigen EPUB-Hardware), sehe ich momentan wenig Aussicht auf Besserung, ich habe keine Lust tagelang um technische “Ausnahmen” herumzudoktern. Das Verrückte: Die Umwandlung der selben(!) Datei mit dem “Hamster”-Konverter zu MOBI bringt weitgehend das gewünschte Ergebnis (es fehlt zwischendrin eine Kapitelmarke).

Eine vorbereitete Word-Datei wird von Mobipocket Creator bearbietet.

Eine vorbereitete Word-Datei wird von Mobipocket Creator bearbeitet.

Sollte ich vielleicht doch primär im MOBI-Format arbeiten? Etwas genervt mache ich mit der selben(!) vorbereiteten Word-Datei und den unbearbeiteten Originalbildern eine Gegenprobe mit Mobipocket Creator . Dabei hat man auf die Erzeugung wie bei einer “black box” keinen Einfluß, gibt lediglich ein paar Metadaten und das Cover-Bild ein. Leider werden trotz vorheriger Abfrage von <h1> usw. und festen Seitenumbrüchen keine Kapitel erzeugt, auch das Inhaltsverzeichnis fehlt beim Probedurchlauf (das müßte man in Word vorab optimieren). Trotzdem ist das Ergebnis der PRC(!)-Datei erschreckend gut. Und die fertige Datei ist ohne alle Optimierungsarbeit auch nur 1,8 Megabyte groß.

Fazit

Die Arbeitsweise mit Sigil gefällt mir, zumal ich mich mit HTML oder CSS auskenne und somit Sonderfunktionen nutzen und optimieren kann. Entscheidend dabei ist, daß man so hinter die Kulissen sehen kann und nicht einer “black box” ausgeliefert ist. Fraglich ist allerdings, in wie weit ich weiterhin EPUB berücksichtige. Einerseits müßte ich mir sowieso eine Vertriebsplattform suchen, wobei die Verfechter des “offenen Standards” alle ihr eigenes Süppchen kochen. Selbst beim derzeit massiv beworbenen “Tolino” ist auf den Geräten nur der Shop des jeweiligen Verkäufers installiert. Um “alle” potentiellen EPUB-Kunden zu erreichen, müßte ich mich mit mindestens vier oder fünf Anbietern auseinandersetzen — und würde es trotzdem nicht “allen” recht machen. Andererseits zeigt meine nun schon seit Wochen mit hohem Aufwand durchgeführte Umsetzung, daß das hochgelobte EPUB in der Praxis seine Macken hat: Die selbe Datei auf drei unterschiedlichen Geräten mit drei unterschiedlichen Ergebnissen, die leider zum Teil auch Fehler enthalten (was natürlich auch am “gefilterten HTML” von Word liegen kann) — was aber alles dem Autor angelastet wird und am Ende optimiert man wieder tagelang an den Macken herum wie zu Zeiten des Netscape Navigator oder IE, statt sich auf die Inhalte konzentrieren zu können. Das Verrückte ist aber, daß die selbe EPUB(!)-Datei durch einen Konverter zur Umwandlung ins MOBI-Format gejagt, auf einem Kindle einwandfrei funktioniert. Wohlgemerkt, im EPUB(!)-Editor Sigil ist die Darstellung ebenfalls einwandfrei und auch Calibri zeigt ein gutes Ergebnis (es scheint also eher an der Interpretation in der Software/Hardware zu liegen und nicht am EPUB selbst).

[Update]

Neben der fast schon desaströsen Darstellung von Listen fallen mir auch einzelne zu groß geratene Tastenkappen auf. Bei manueller Kontrolle wird der Übeltäter entlarvt: Obwohl mit class="Tastenkappe" das Format umfassend definiert ist, hat “irgendjemand” im Verlauf der Umsetzung noch ein überflüssiges style="font-size:12pt;" hinzugefügt, das jetzt die Größenanpassung der zentralen CSS-Datei aushebelt.

Zusätzliche Größenangaben ruinieren die class-Definition.

Zusätzliche Größenangaben ruinieren die “class”-Definition.

Ich vermute, daß dies eine Erblast aus dem Word-Export ist, so daß ich bei einem weiteren Projekt vielleicht in Word schreibe (wg. Rechtschreibkontrolle und so), dann aber radikal auf Text-Export gehe und in Sigil lupenreine CSS-Klassen hinzufüge. Für diesen Fall nehme ich mir nochmals die Strichaufzählungen vor und versuche mit globalem Ersetzen überflüssige Tags zu tilgen — bis zu 100 Treffer allein für “font-size: 12pt;”. Auch bei anderen Klassen werden Teile der Style-Definition zusätzlich in den Tag geschrieben, so daß die Änderungen der zentralen CSS keine Chance haben. Infokästen werden zusätzlich von <hr /> eingerahmt. — Und siehe da, schon sieht auch das EPUB wieder etwas freundlicher aus. Außerdem wird die Datei insgesamt fast 100 Kilobyte kleiner…

Comments

comments

Leave a Reply

Your email address will not be published.