Das Standardformat von E-Books ist .epub. Es wird von den meisten Softwareunternehmen und auch den Herstellern von E-Book-Readern unterstützt.

Laut Wikipedia ist EPUB (Akronym für electronic publication) ein offener Standard für E-Books vom International Digital Publishing Forum (IDPF), der den älteren Standard Open eBook (OEB, bzw. Open eBook Publication Structure, OEBPS) ersetzt.

Er unterstützt DRM-Mechanismen.

Auf EPUB basierende E-Books erlauben eine dynamische Anpassung des Textes an die jeweilige Bildschirmgröße des Lesers und eignen sich damit insbesondere für die Ausgabe auf Mobile Devices. Im Gegensatz dazu wird beispielsweise der Text bei PDF wie im gedruckten Buch angezeigt. Bei kleinen Ausgabegeräten kann eine derartige Darstellung jedoch für den Leser unbefriedigend sein, falls er bei einer individuell angenehmen Anzeigegröße des Textes häufig hin- und herscrollen muss.

Wichtig: Die Formatvorlagen von Word dienen direkt als Basis des internen CSS, das beim Umwandeln in HTML entsteht und somit auch an EPUB weitergegeben wird.

Der übliche Weg zu einem E-Book führt über HTML.

D.h., man sollte eigentlich immer aus dem Ur-Format (Word, FrameMaker, InDesign) heraus erst einmal im HTML-Format abspeichern. Unter anderem werden dabei die Bilder automatisch auf eine kleine Auflösung heruntergerechnet (was gewünscht ist!).

Wichtig im Ur-Programm: saubere und konsistente Zuweisung von Formatvorlagen (FVs). In Word unbedingt alle nicht verwendeten FVs löschen!

Die HTML-Datei kann dann mit einem HTML-Editor nachbearbeitet werden. Ein guter HTML-Editor ist NVU (obwohl seit 2006 nicht verändert). Vorteile:

• eingebauter CSS-Editor
• einfache Befehle zum Bereinigen des HTML-Codes

HTML wird dann

• entweder einem reinen Konverter wie KindlePreviewer
• oder einem EPUB-Editor zugeführt

Unterschied zwischen beiden Programmtypen:

• in einem Konverter kann der Code nicht editiert werden
• EPUB-Editoren haben ihre Stärke im Bearbeiten des Codes, können oft aber nur ein einziges Format erzeugen, nämlich EPUB. Sigil ist z.B. ein solcher Editor. Calibre oder Jutoh sind Editoren, die per einfachem direktem Befehl auch andere digitale Formate wie MOBI erzeugen können.
• EPUB-Editoren haben den Charme, dass sie einen direkten Zugriff auf die XML-Daten zulassen, die sich im EPUB-Archiv verstecken. Denn eine EPUB-Datei ist ein ZIP-Archiv.
• Man könnte an die verschiedenen Inhalte auch ohne einen speziellen EPUB-Editor herankommen, indem man einfach .zip an die Erweiterung .epub hängt und dann das Archiv entpackt und die Daten z.B. mit einem ASCII-Editor wie Notepad anschaut und evtl. bearbeitet.

• MSWord2Epub: erzeugt riesige EPUB-Dateien, in denen fast jedes Wort mit einem span-Tag umgeben ist.

Die folgenden EPUB-Editoren werden (auf ihren Homepages, aber auch von machen „Experten“) angepriesen, haben aber alle die Schwäche des Unausgereiftseins. Manche können noch nicht einmal ein Inhaltsverzeichnis erzeugen; sehr schlecht sind auch fast immer die Suchen/Ersetzen-Möglichkeiten oder auch überhaupt das Arbeiten im Quellcode. Teilweise führen Sie zum Absturz des Rechners.

• Namo
• Ultimate ebook Creator

• Word2cleanhtml (https://word2cleanhtml.com): erzeugt sauberen HTML-Code, der kopiert und z.B. in Sigil eingefügt/importiert werden kann.
• Convertio (https://convertio.co/de): erzeugt sauberen EPUB-Code, der z.B. mit Sigil oder calibre weiterbearbeitet werden kann.

• KindleGen: zum Konvertieren von HTML-Dateien im Batch-Verfahren in Mobi oder AZW
• KindlePreviewer: zum Konvertieren von einzelnen HTML-Dateien im in Mobi

• OpenOffice/LibreOffice: writer2epub. Sauberer Code, aber keine Info mehr über ursprüngliche Formatvorlagen
• Papyrus Autor: Sauberer Code, aber keine Info mehr über ursprüngliche Formatvorlagen
• TextMaker: einigermaßen brauchbarer Code, aber Bilder müssen alle neu eingebunden werden, weil verzerrt
• InDesign: Aus InDesign heraus kann direkt .epub erzeugt werden, indem Menü <Datei - Für Digital Editions exportieren> [CS6 und älter] bzw. <Datei - Exportieren - EPUB (umfließbar)> [CC] gewählt wird.
  • Das Gute bei InDesign ist, dass beim Exportieren alle wichtigen Einstellungen, insbes. die Bildauflösung betreffende, vorgenommen werden können. Das bedeutet u. a., dass die Bilder in einer Auflösung von 300 dpi im ID-Dokument eingebunden sein können und automatisch als 150-dpi-Bilder im EPUB landen.
  • Der ID-Weg scheint mir zumindest bei E-Books, die keine hohen Ansprüche an Layout und Funktion stellen, der einfachste zu sein. Komplexe Layouts sind immer schwierig in EPUB umzusetzen, auch mit anderen Programmen.
  • Funktionale E-Books mit ID können Defizite aufweisen. So lässt sich zwar sehr einfach ein funktionaler Index erzeugen, bei Seitenbereichsangaben ist aber die zweite Seite nicht aktiv. Falls ein in jeder Hinsicht guter funktionaler Index benötigt wird, muss der Weg von Word über Jutoh gegangen werden. Aber gut: Jede ID-Datei kann in eine Word-Datei konvertiert werden, die die Indexmarken der ID-Datei als XE-Felder enthält. Das ist die Voraussetzung für die Weiterverarbeitung mit Jutoh.
  • Bei der Prüfung eines aus ID erzeugten EPUBs mit einem EPUB-Checker werden meist Schriften bemängelt. Eine komfortable Prüfung kann mit dem FlightCrew-Plugin von Sigil vorgenommen werden. Dieser Checker gibt auch gleich Tipps für die Korrektur der Fehler.
• FrameMaker: aus http://forums.adobe.com/message/2646481:
  • 2. 09.03.2010 11:07 (in response to viand)
  • Helpful AnswerRe: Epub in Framemaker
    
  • The ePub format is essentially a specific form of XHTML that is wrapped up in a ZIP container. If your document formatting is not overtly complex, you may be able to use FM's XML export option to create suitable files for subsequent processing into .epub format. Alternatively, a tool such as mif2go ( http://www.omsys.com/dcl/mif2go_main.htm ) may give you better control on the export process than FM's internal conversion table approach.
  • There are some tips for InDesign users and how-to's that are also applicable (to a larger extent) to FM users - you just have to do things in the FM way. See: http://www.adobe.com/products/indesign/epub/howto/
  • Adobe has more general info available on epub and eBooks at: http://www.adobe.com/products/creativesuite/design/crossmedia_resource s/ebooks_software.html and http://www.adobe.com/devnet/digitalpublishing/
  • From the exported XML or xHTML files, you'll need to use a tool like Calibre (see: http://calibre-ebook.com/about#features) to convert the files into an .epub file.
  • There are also other converters starting to surface, such as http://www.pdf-epub-converter.com/ or http://www.pdftoepub.com/ which try to convert from PDF to epub format. So you could then try to create PDFs from FM instead (but you'll have to gauge how well this works for you, as you'll be converting a conversion so to say).
  • Finally, if you do get to an epub file format, you should check it using a tool like ePubCheck at: http://code.google.com/p/epubcheck/ to ensure that it's correct and complies with the specifications.
  • Alternatively, if it's just an eBook format that you're after, there's an older FM tutorial on creating eBooks from FM at: http://www.adobe.com/epaper/tips/frm7tagpdf/index.html

Alle diese Editoren können html importieren und in xhtml umwandeln. Jutoh und Calibre können auch doc- oder docx importieren. Die Bearbeitungsmöglichkeiten sind vielfältig. Sowohl in Sigil als auch in Calibre muss zur Bearbeitung in die Quellcode-Ansicht gewechselt werden (was aber nicht unbedingt ein Nachteil ist); Jutoh bietet eine sehr komfortable und lesitungsfähige WYSIWYG-Oberfläche, lässt aber einen Wechsel in den Quellcode zu.

• Sigil (https://sigil-ebook.com): Die große Stärke von Sigil ist die Transparenz. Alle Schritte der EPUB-Erzeugung liegen offen. Man bewegt sich zwar hauptsächlich im Quellcode, trotzdem bietet das Programm sehr gute Hilfen an, um z.B.
  • ein Inhaltsverzeichnisse zu erzeugen,
  • ein oder mehrere Stylesheets einzubinden,
  • Bilder in einer Bilddatenbank zu verwalten,
  • Kapitel und Abschnitte zu erzeugen,
  • in einer WYSIWYG-Ansicht die Ergebnisse zu kontrollieren.
  • Darüber hinaus verfügt es über eine mächtige RegEx-basierte Suchen-/Ersetzen-Funktion.
  • Hilfe zu Sigil: http://www.kraussverlag.de/sigil-auf-deutsch.htm.
  • Plugins für Sigil: https://www.mobileread.com/forums/showthread.php?t=247431
  • mit dem Plugin ePub3-itizer können aus Sigil heraus EPUB3-Dateien erzeugt werden!
  • Sigil hat wechselvolle Geschichte, aber es wird weiterentwickelt (Stand: 09/2021)
  • inzwischen ist es (nicht nur wegen des Plugins ePub3-itizer) EPUB3-fähig
  • EPUB2-Books können mit dem Plugin FlightCrew geprüft werden, EPUB3-Books mit dem Plugin EpubCheck (Achtung: neueste Version verwenden; Dez. 2022: 0.4.6.2)

• Jutoh (http://www.jutoh.com): Jutoh ist der wohl mächtigste E-Book-Editor überhaupt.
  • Der Metadaten-Editor von Jutoh ist umfangreicher als der von Sigil; in Jutoh kann z.B. die ISBN damit eingepflegt werden (in Sigil müsste man das manuell im Quelltext machen, was auch nicht schlimm wäre).
  • Ein großer Vorteil von Jutoh ist auch, dass es zahlreiche Export-Möglichkeiten bietet. Es kann neben EPUB auch Mobi erzeugen, wobei es dazu sinvvollerweise auf KindleGen zurückgreift.
  • Darüber hinaus kann es .odt (also das Open Document-Format) exportieren, das sich einfach mit Libre Office öffnen lässt. Die Ergebnisse sind erstaunlich gut: Jutoh übergibt sämtliche Formatvorlagen in der korrekten Weise an .odt. Ist eine Datei erst einmal in Libre Office, kann sie vorn dort als Word- oder auch als PDF-Datei ausgegeben werden. Das eröffnet fantastische Möglichkeiten des Single Source-Publishing! Nur ist jetzt EPUB das Ausgangsformat und die anderen Formate wie odt, docx und pdf werden daraus erzeugt. Weshalb eigentlich nicht! Sogar Indexeinträge werden an ODT bzw. Word übergeben!

• Calibre (http://calibre-ebook.com): Calibre dient drei Zwecken:
  • der Konvertierung von Word-, PDF- und/oder HTML-Daten in EPUB oder weitere E-Book-Formate wie Mobi, AZW usw.
  • der Bearbeitung von EPUB-Daten (Mobi und andere Formate können nicht direkt bearbeitet werden, sondern müssen aus den bearbeiteten EPUB-Daten erzeugt werden, was aber sehr einfach geht)
  • der Verwaltung von E-Books. Das heißt, mit Calibre lassen sich Dateien auf E-Reader kopieren, darüber hinaus können die im Hauptspeicher von E-Readern liegenden Dateien gelöscht oder verschoben werden.
  • Calibre ist damit das vielfältigste E-Book-Tool überhaupt.

Um alle Möglichkeiten rund um E-Books ausschöpfen zu können, empfiehlt es sich, alle genannten Stand-Alone-Konverter und -Editoren an der Hand zu haben.

sehr gute Quellen mit Übersicht und Erläuterung:

http://www.data2type.de/xml-xslt-xslfo/epub-ueberblick/

https://friendsofepub.github.io/eBookTricks/

https://idpf.github.io/a11y-guidelines/ bzw. https://idpf.github.io/a11y-guidelines/content/style/reference.html

1. zunächst die EPUB-Datei am besten mit Sigil öffnen
2. CSS-Code (komplett oder auch nur zum Teil, z.B. der Code für das Element h1) herauskopieren (markieren, dann Strg-c)
3. NvU oder KompoZer öffnen, neue HTML-Datei beginnen und den kopierten CSS-Code einfügen: Dabei aufpassen: der Code muss zwischen dem style-Anfang und -Ende-Tag stehen.
4. Damit die CSS-Bearbeitungseffekte gleich gesehen werden können, etwas Probetext eingeben und diejenigen Formatvorlagen zuweisen, deren Einstellungen dann im CSS verändert werden sollen.
5. WYSIWYG-Ansicht, geteilte Ansicht oder „Vorschau“ wählen
6. internen CSS-Editor aufrufen (Menü <Extras - CSS> oder F11)
7. im Editor links die „Regel“ (also die „Formatvorlage“) anklicken
8. rechts die Registerkarten anklicken, auf denen Einstellungen zum Text, Hintergrund, zu den Begrenzungen, zur Box, zu Listen und Tönen vorgenommen werden können. Die Effekte sind sofort zu sehen.
9. wenn Code fertig bearbeitet, wieder kopieren und zu Sigil wechseln
10. in Sigil alten Code durch den neuen ersetzen
11. mit F2 kann schnell zwischen Code- und Vorschau-Ansicht umgeschaltet werden: wichtig, um den Efekt der CSS-Änderung zu kontrollieren
12. falls etwas nicht so aussieht wie gedacht, kann der CSS-Code nun relativ einfach direkt in Sigil nachbearbeitet werden

Anstatt den Code hin und her zu kopieren, kann auch einfach

1. von Sigil aus das CSS als Datei gespeichert und
2. die Datei in NvU oder KompoZer eingeladen werden.
3. Änderungen wieder speichern
4. in Sigil aktualisieren.

Mit calibre können die folgenden Formate direkt importiert und in ein E-Book-Format umgewandelt werden (Auswahl der wichtigen Formate):

• doc
• docx
• html
• otf
• rtf
• pdf
• txt

Wenn aus Word erst html erzeugt wird, was zu empfehlen ist, dann sollte Speichern als „Webseite, gefiltert“ gewählt werden (nicht einfach nur Webseite).

Mit calibre können direkt die folgenden Formate erzeugt, also exportiert, werden (Auswahl der wichtigen Formate):

• MOBI
• epub
• FB2
• LRF

• PDF documents are one of the worst formats to convert from. They are a fixed page size and text placement format. Meaning, it is very difficult to determine where one paragraph ends and another begins. calibre will try to unwrap paragraphs using a configurable, Line Un-Wrapping Factor. This is a scale used to determine the length at which a line should be unwrapped. Valid values are a decimal between 0 and 1. The default is 0.5, this is the median line length. Lower this value to include more text in the unwrapping. Increase to include less.

• Also, they often have headers and footers as part of the document that will become included with the text. Use the options to remove headers and footers to mitigate this issue. If the headers and footers are not removed from the text it can throw off the paragraph unwrapping.

• Some limitations of PDF input is complex, multi-column, and image based documents are not supported. Extraction of vector images and tables from within the document is also not supported.

Wichtiges und tolles Tool für EPUB-Dateien: http://code.google.com/p/epubcheck/
Siehe aber auch unten: Validierung mit Sigil (FlightCrew-Validator)

EPUB-Dateien können, unabhängig von EPUP-Check-Programmen, mit Adobe Digital Editions (ADE) geprüft werden. Die Prüfung besteht einfach nur darin, das EPUB anzeigen zu lassen. ADE ist sozusagen der Industriestandard für die Anzeige von EPUB. Wenn beim Durchschauen in ADE irgendetwas auffällt, sollte es in einem EPUB-Editor wie Sigil korrigiert werden,

Achtung: ADE kann sich „verschlucken“ mit dem Ergebnis, dass gar nichts mehr angezeigt wird. Das kann zum Beispiel bei DRM-geschützten EPUBs passieren, und zwar nachdem die Adobe-ID-Daten eingegeben und akzeptiert worden sind! Lösung:

• ADE schließen
• Den Ordner „My Digital Edition“ im benutzerzugeordneten Dokumente-Verzeichnis umbenennen (einfach _alt dranhängen) und ADE neu starten.
• Nun wird eine jungfräuliche Bibliothek angezeigt, in die man die EPUBs wieder einladen und anzeigen lassen kann.

• die Einstellungen, die in Word unter „Weboptionen“ (Datei - Optionen - Erweitert, dann ganz unten) vorgenommen werden können, scheinen keinen Einfluss auf die HTML-Daten zu haben, zumindest nicht auf die, die man erhält, wenn man „Website, gefiltert“ als Speicherformat wählt; es gibt nur eine Ausnahme: die Schriftcodierung. Hier sollte wohl am besten UTF-8 gewählt werden, damit Sonderzeichen eine bessere Chance haben, korrekt angezeigt zu werden.
• die Dateiinformationen sollten bearbeitet werden, denn sie ergeben in calibre die Metadaten! Diese können zwar auch dort nachgepflegt werden, aber falls man noch einmal zurück zu Word muss, um grundsätzliche Änderungen vorzunehmen, wäre es sehr praktisch, wenn die Metadaten OK wären.

• erstaunlich: die harten (manuellen) Formatierungen, z.b. Fett- und Kursivauszeichnungen, bleiben erhalten, ebenso alle Leerzeilen!
• die in Word verwendeten Formatvorlagen ziehen sich bis zum EPUB durch:
  • Schriftauszeichnungen (h'fett, kursiv usw.) bleiben erhalten
  • Schriftgrößen werden von Absolutwerten in Relativwerte umgerechnet; Näheres: siehe Sigil und Calibre
• wichtig: alle überflüssigen Formatvorlagen entfernen, wobei „überflüssig“ bedeutet, dass keine Textstellen damit ausgezeichnet sind. Da man die in Word von Hause aus integrierten Formatvorlagen nicht löschen kann, bleiben einige von ihnen bei der Umwandlung in HTML erhalten und sollten mit NVU entfernt werden.
• Formatvorlagennamen ohne Sonderzeichen (also auch ohne Umlaute)!
• Formatvorlagen für Überschriften sind entscheidend für das IHV! (siehe aber unten: Überschriften-Gestaltung; IHV-Erzeugung in Sigil; IHV-Erzeugung in Calibre)
• Weiteres zur Übernahme von Formatvorlageneinstellugnen: siehe Word-2003-Handbuch, S. 532 f („Veränderungen in HTML“)
• wie so oft, wenn es darum geht, Daten aus einem Programm herauszubekommen, zeigt sich auch jetzt wieder, dass es entscheidend auf die saubere und konsistente Formatierung mit Formatvorlagen ankommt! Tests mit dem Kap 6 der Formelsammlung (viele Formeln, viele Bilder) haben gezeigt, dass die besten Ergebnisse erzielt werden, wenn in Word sämtliche nicht verwendeten Formatvorlagen gelöscht werden, bevor man die Datei im HTML-Format (gefiltert) abspeichert.

Beachtet werden sollte, dass die Datenübergabe aus Word an ein EPUB grundsätzlich den gleichen Gesetzen unterliegt wie eine Datenübergabe an ein Layout-Programm!

Niemand würde auf die Idee kommen zu behaupten, die Übergabe von Word-Daten an ein Layout-Programm sei eine einfache Sache. Vielmehr ist (seit den Urzeiten des DTP) klar, dass immer ein Profisetzer oder Grafiker sich um das Layout in InDesign, Quark oder FrameMaker zu kümmern hat und nicht etwa der Autor bereis in Word sämtliche Gestaltungsmerkmale festlegt. Das einzige, was der Autor machen kann, ist möglichst sauber zu arbeiten und für sämtliche Formatierungen Formatvorlagen zu verwenden.

Genau wie in einem Layoutprogramm muss auch in einem EPUB-Programm dafür gesorgt werden, dass die Gestaltung stimmt. Das heißt, im EPUB-Programm sind im CSS sämtliche Formatierungen festzulegen.

Wissen muss man u. a., dass den Word-Absatzformatvorlagen im EPUB (genauer: in XHTML) Klassen des p-Elements entsprechen, analoges gilt für die Zeichenformatvorlagen von Word: Ihre Entsprechung in EPUB sind Klassen des span-Elements.

Das heißt, um eine Grundformatierung des EPUBs auf Basis der in Word vorgeleisteten Formatierung hinzubekommen, sollten im CSS für das EPUB Klassen definiert werden, die dieselben Namen haben wie die Formatvorlagen in Word. Ein solches CSS ist die Basis für die Weiterverarbeitung in EPUB. Es sollte irgendwo separat, also unabhängig von dem, was aus Word herüberkommt, existieren. Am besten legt man sich eine Muster-EPUB-Datei an, die das CSS als separate Einheit enthält. Das CSS, das aus Word heraus beim Abspeichern als HTML-Datei erzeugt wird, sollte im EPUB dann durch die Muster-CSS ersetzt werden.

In der Muster-CSS sollten auch sämtliche anderen gewünschten Formatierungen (die nur im EPUB eine Rolle spielen oder in Word nicht möglich sind) definiert sein.

• Schriftgrößen werden von Absolutwerten in Relativwerte umgerechnet; bei Zeilenabständen kann es bzgl. der Umrechnung Probleme geben (Näheres dazu: siehe Sigil und Calibre)
• erstaunlich: Tests (Kindle, iPad) zeigen, dass die Einstellungen zum Zeilenabstand, die in word vorgenommen und die von Calibre umgerechnet bzw. in Sigil manuell editiert wurden, keinerlei Rolle für die Anzeige auf einem Reader spielen! Das CSS für die Reader überschreibt diese Einstellungen! Es kann natürlich sein, dass man den Werten per Sigil das Attribut „wichtig“ zuweisen muss - das gilt es noch zu testen (vgl. E. Castro).
• im Grunde ist die Erkenntnis des letzten Absatzes überhaupt nicht erstaunlich, denn E-Reader müssen ja die Freiheit besitzen, den Zeilenabstand den Gegebenheiten anzupassen. Würde man es schaffen, den Zeilenabstand festzusetzen, wäre diese Funktion von E-Readern außer Kraft gesetzt. Man sollte eher anders herum argumentieren und v.a. handeln:
  • Entweder bereits im Quellprogramm (also etwa Word) sämtliche festen Werte für Zeilenabstände auf „einfach“ stellen
  • oder im EPUB-Programm (z.B. Sigil) ein CSS verwenden, dass für den Fließtext keinerlei Vorgaben macht, dass also bei allen p-Element-Klassendefinitionen nichts enthält außer dem Namen der Klasse! Lediglich bei Spezialschriften müsste in der betreffenden Klasse der Font definiert werden, alle anderen Werte bleiben leer.

wird im CSS bei der Definition einer .p-Klasse erreicht. Beispiel:

.P_Vfll_fliess_n_u_haengend {\\
font-size: 1.00em;\\
text-align: left;\\
margin-top: 1.00em;\\
margin-bottom: 1.00em;\\
margin-left: 4.50em;\\
margin-right: 00.00em;\\
text-indent: -4.50em;\\
padding-top: 5px;\\
padding-bottom: 5px;\\
padding-left: 10px;\\
padding-right: 10px;\\
}

Hier wird ein hängender Einzug  erzeugt, indem margin-left auf einen bestimmten Wert (hier 4.50em) und gleichzeitig text-indent auf denselben Wert, allerdings negativ, eingestellt wird.

text-indent ist der Befehl für den Texteinzug in der ersten Zeile.

Überschriften sollten grundsätzlich über das CSS gestaltet werden. Welche Möglichkeiten es gibt, kann auf der Seite https://wiki.selfhtml.org/wiki/CSS nachgelesen werden.

Wenn man eine Schattierung vergibt (Anweisung background:<Farbe>), wird zwar der gesamte Absatz hinterlegt, aber der Text stößt links und rechts direkt an die Ränder der Schattierung (nach oben und unten ist - wohl wegen der Ober- und Unterlängen der Zeichen - etwas Abstand). Dasselbe gilt für Rahmen, die mit der Anweisung border (border-top, border-bottom usw.) erzeugt werden.

Um Abstand zu bekommen, muss eine Überschrift entweder in eine Tabellenzelle gesteckt werden (denn nur hier gibt es die Anweisung border-spacing) oder man muss den gesamten Absatz mit einem div-Element umgeben, in dem Schattierung und Rahmen eingestellt werden.

Beispiel für eine reine Schattierung:

<div style="border:none;padding-top:1pt;padding-left:8pt;padding-bottom:12pt;
padding-right:4pt;background:#D9D9D9;">

<h3>Dies ist eine Überschrift</h3>

</div>

Wird bereits in Word mit Rahmen um einen Absatz gearbeitet, so kommt dieser tatsächlich als umgebendes div-Element nach HTML bzw. XHTML herüber. Eine Schattierung in Word ist dagegen eine Eigenschaft der Absatzfpormatierung selbst, d.h., sie steckt im HTML oder XHTML als Attribut im jeweiligen Absatzelement. Um einer Schattierung inneren Textabstand (padding) zuweisen zu können, muss sie aus dem Absatzelement in das div-Element verschoben werden. Leider kann bei Schattierungen nicht bereits in Word Einfluss auf den Abstand vom Text genommen werden. Das heißt, man muss im EPUB Folgendes machen:

• background-Anweisung (also die Schattierung) im Absatzelement löschen
• falls noch nicht vorhanden, div-Element um Absatz anbringen
• im div-Element: background-Anweisung (also die Schattierung) einfügen; falls Anweisung für Rand enthalten, auf „none“ stellen, damit nur die Schattierung wirkt
• im div-Element: padding-Anweisungen einbauen.

Rahmen:
Da ein Rahmen bereits korrekt als div-Element aus Word herüberkommt, brauchen im EPUB nur noch die gewünschten Werte eingestellt zu werden.

Klassen definieren:
Am einfachsten arbeitet es sich auch bei Rahmen und Schattierungen, wenn sie über das CSS gestegelegt werden können. Das heißt, man muss im CSS entsprechende „Klassen“ definieren, etwa

div.rahmen {
border-top:2px solid black;
border-left:2px solid black;
padding-top:4pt;
padding-left:8pt;
}

und

div.schattierung {
border:none;
background:#D9D9D9;
padding-top:1pt;
padding-left:8pt;
padding-bottom:12pt;
padding-right:4pt;
}

Dann kann im div-Element im Text einfach Bezug auf die Klasse genommen werden, etwa:

<div class="schattierung">

<h3>Dies ist eine Überschrift</h3>

</div>

Das ist natürlich deutlich komfortabler und effizienter.

In den meisten Anleitungen zum Vorbereiten eines E-Books in Word heißt es:

• Ein Seitenumbruch sollte in Word keinesfalls mit dem Befehl „Seitenumbruch“ herbeigeführt werden, sondern ausschließlich mit der Absatzeinstellung „Seitenumbruch oberhalb“.

Beides ist nicht wirklich richtig!

Bedacht werden muss vielmehr, dass in einem EPUB jedes Kapitel in einer separaten htm-Datei liegt. Die Frage lautet: Wie schafft man im EPUB eine Aufteilung der Kapitel auf separate htm-Dateien?

Schön wäre es, wenn die Word-HTML-Datei beim Einladen ins EPUB-Programm automatisch aufgeteilt werden könnte. Dazu bietet calibre tatsächlich entsprechende Möglichkeiten: Per path-Anweisung kann es die Struktur von Word-Dateien erkennen und eine Aufteilung auf separate htm-Dateien im EPUB vornehmen. Dabei spielt aber die Absatzeinstellung „Seitenumbruch oberhalb“ von Word keine Rolle! Vielmehr nutzt calibre die Namen der Formatvorlagen (in diesem Fall der FV, die für eine Kapitelüberschrift in Word verwendet wurde). Und insofern ist es auch unerheblich, ob ein Seitenumbruch in Word auf andere Weise, nämlich per Befehl „Seitenumbruch“ erzeugt wurde.

Lediglich, wenn das Word-HTML direkt - etwa mit Sigil - in EPUB umgewandelt wird und man ausschließlich mit dem im word-HTML vorliegenden CSS weiterarbeitet, hat die Absatzeinstellung „Seitenumbruch oberhalb“ eine Bedeutung. Aber man sollte keinesfalls so vorgehen, sondern immer

• mit einem sauber entwickelten Muster-CSS arbeiten (siehe oben: Formatvorlagen und CSS)
• und im EPUB-Programm sämtliche Überschriften neu formatieren (wozu natürlich, falls man sich auskennt, ein Makro verwendet werden könnte).

Außerdem muss man wissen, dass nur dann keine Probleme mit der Formatierung von Überschriften und deren Darstellung auf E-Readern auftreten, wenn jedes Kapitel eines E-Books in einer separaten htm-Datei im EPUB liegt. Die Formatierung mit dem h1-Element allein reicht nicht aus! Ja, es ist sogar so, dass - wie Tests gezeigt haben - manche Formatierungen (wie etwa die Vergabe von Rahmen oder Schattierungen) nur dann funktionieren, wenn im h1-Element die Anweisung „page-break-after: always“ nicht enthalten ist! Eine solche Amnweisung führt etwa in iBook dazu, dass eine leere Seite vorgeschaltet wird, die nur den Rahmen und/oder die Schattierung enthält! Fehlt die Anweisung dagegen und sind alle Kapitel in separaten htm-Dateien enthalten, klappt die Anzeige in iBook einwandfrei.

• <hi>Separate htm-Dateien werden automatisch von allen E-Readern so verstanden, dass eine neue Seite eröffnet werden soll. Das heißt eine zusätzliche Anweisung „page-break-before: always“ ist absolut überflüssig bzw. bei iBook sogar kontraproduktiv.</hi>

• alle Bilder müssen in der Zeile verankert sein
• Bildnamen: Achtung: iBooks bringt eine Fehlermeldung „Ressource konnte nicht gefunden werden“, wenn ein Bildname zu lang oder zu komplex ist! Dann z.B. mit Sigil das Bild umbenennen.
• Bilder in einem Pixelformat (z.B. jpeg) scheinen am besten geeignet zu sein
• Vektorgrafiken werden, zumindest von EPUB und MOBI, zwar „verstanden“, aber sie können nicht vergrößert dargestellt werden (soll wohl ab EPUB 3 und KF8 gehen); insbesondere Formeln können dadurch evtl. sehr klein geraten und unleserlich sein; daher zwei Möglichkeiten:
  • Grafiken von vornherein groß genug anlegen, Formeln z.B. mindestens mit einer 12pt-Schrift (evtl. sogar 14pt)
  • alle Grafiken in Pixelbilder umwandeln und diese anstelle der Vektorgrafiken einbinden
• zum Vergeben der richtigen Bildgrößen (für Pixelbilder) ist zu beachten, dass die meisten Reader eine Auflösung von 600 * 800 Pixel haben (Breite mal Höhe); Adobe schlägt vor, Bildern eine etwas kleinere Größe zu geben, damit sie auf allen Readern und sowohl senkrecht als auch waagerecht gut zu erkennen sind: 450 * 600 Pixel
• Falls man sich in Word die Größe in Pixeln anzeigen lassen möchte, muss unter <Optionen - Erweitert - Anzeigen> das Häkchen bei „Pixel für HTML-Features anzeigen“ gesetzt werden; ruft man dann für eine Grafik das Größen-Fenster auf, werden die Absolutwerte nicht in cm oder mm, sondern in px angezeigt und können auf einfache Weise angepasst werden.
• Word wandelt beim Abspeichern als HTML die vorhandenen Grafikformate in andere um; so wird z.B. aus gif jpg (was ja prinzipiell nicht verkehrt ist); aber: man hat keinen Einfluss darauf, was Word macht! Daher kann es nötig sein, die von Word erzeugten Grafikformate durch andere zu ersetzen. Bei der üblichen Abspeicherung einer Word-Datei als „Website, gefiltert“ landen die Grafiken alle in einem separaten Ordner. Entweder ersetzt man die Grafiken gleich dort, oder man verlagert das Ersetzen in die später vorliegende EPUB-Phase, denn auch dort kommt man an die einzelnen Grafiken heran.
• Umwandeln von Grafikformaten: z.B. mit ACDsee oder ähnlichen Programmen (geht im Batch-Verfahren)
• <hi>Wichtig: am besten Bilder gleich in einem Pixelformat (jpg oder png) in Word einbinden, und zwar in der gewünschten Größe und Auflösung. Erst dann in HTML umwandeln! Da bei der Umwandlung (Webseite gefiltert) alle Bilder in zu kleiner Auflösung im separaten Bildordner abglegt werden, sollten sie auf jeden Fall vor der Weiterverarbeitung zu epub oder mobi ausgetauscht werden.</hi>

Wie Tests zeigen, legt Word die Bilder in einer sehr kleinen Auflösung im HTML-Bild-Ordner ab (wenn im Format Webseite, gefiltert gespeichert). Die erste Tat, die vollbracht werden sollte, ist, diese Bilder durch die Originalbilder, die in Word eingebaut sind, zu ersetzen, denn diese haben, wenn man es richtig angestellt hat (siehe oben) die korrekte Größe und Auflösung! Allerdings muss man aufpassen, dass dadurch nicht die EPUB- bzw. die MOBI-Datei zu groß wird. Wenn eine MOBI-Datei mehr als 10 MB hat, gibt es Anzeige-Probleme (wenn eine solche Datei z.B. direkt auf einen E-Reader geladen wird); daher erlaubt Amazon das Hochladen von Dateien, die größer als 10 MB sind, nicht. Am besten ist es wohl zu schauen, welche der kleinen HTML-Bilder ausreichen und welche Bilder ausgetauscht werden sollten, damit man auf einem E-Reader alles erkennen kann.

Austausch:

1. das übliche ZIP-Verfahren auf die Word-Datei anwenden und die Bilder aus dem ZIP-Archiv herauskopieren, dann
2. die Bilder im HTML-Bild-Ordner durch die hochaufgelösten ersetzen (evtl. müssen zunächst die Dateinamen angepasst werden, z.B. hinsichtlich der Nummerierung: 1 durch 001 ersetzen usw.)
3. nun im HTML-Quellcode die Angaben zu den Dateinamen und Dateinamenerweiterungen anpassen
4. außerdem unbedingt die Angabe der Bildgrößen löschen; Word setzt nämlich beim HTML-Export bestimmte Größen fest. Eine solche Festsetzung ist überflüssig, da alle E-Book-Reader die Bilder automatisch auf die Bildschirmgröße verkleinern, falls sie größer sein sollten. Ist ein Bild kleiner als der Bildschirm (also kleiner als 600 px x 800 px), so wird es in Originalgröße dargestellt.
   

Eine typische Bild-Zeile im HTML-Code sieht folgendermaßen aus:

<p class="dfbild"><img id="Grafik 273" src="Dokument_und_Formatvorlagen_word_2010_12_mal_17_130223-Dateien/
image014.png" border="0" height="295" width="322"></p>

Hier kann die Angabe zu height und width komplett gelöscht werden. Danach sieht die Zeile wie folgt aus:

<p class="dfbild"><img id="Grafik 273" src="Dokument_und_Formatvorlagen_word_2010_12_mal_17_130223-Dateien/
image014.png" border="0"></p>

<hi>Alternativ zu diesem Batch-Verfahren kann natürlich jedes Bild direkt in der Vorschau-Ansicht gegen ein anderes ausgetauscht werden! Dazu einfach über den Button „Grafik einfügen“ das neue Bild wählen; anschließend das alte löschen.</hi>

1. EPUB-Datei mit sigil öffnen und in der Inhalts-HTML-Datei die Verweise auf die Grafiken ändern, und zwar die vorhandenen Dateierweiterungen der Grafikdateien (z.B. .jpg) durch die neuen Dateierweiterungen (z.B. .gif oder .png) ersetzen
2. entsprechend mit sigil die OPF-Datei bearbeiten: auch hier aus den vorhandenen Dateierweiterungen die neuen machen
3. nun Sigil schließen
4. EPUB-Datei durch Anhängen von .zip in ZIP-Archiv umwandeln
5. Archiv öffnen und vorhandene Grafikdateien (z.B. *.jpg) löschen;
6. entsprechende Grafikdateien im neuen Format (z.B. *.gif oder *.png) hineinkopieren; dabei darauf achten dass die Dateinamen (bis auf die Erweiterung) identisch sind.
7. Archiv schließen und .zip wieder wegnehmen; es liegt also wieder eine normale EPUB-Datei vor
8. zur Prüfung die EPUB-Datei wieder mit Sigil öffnen und schauen, ob alles OK ist; dabei auch die Sigil-interne Validierung drüberlaufen lassen; zur Not entsprechende Korrekturen direkt in Sigil vornehmen

<hi>Wie bei der HTML-Datei (s.o.) kann auch im EPUB jedes Bild direkt in der Buch-Ansicht ausgetauscht werden!</hi>

• Bild- oder Grafikrahmen, die in Word übereinander liegen (das sind „Komplexbilder“), entsprechen nicht der epub-Syntax. D.h., bei einem Validitiy-Check werden diese Stellen als Fehler ausgewiesen und bereinigt. Nach der Bereinigung stehen alle Rahmen in eigenen Absätzen, m.a.W.: die Rahmen sind von den Bildern, über denen sie gelegen waren, entkoppelt. Das darf natürlich nicht sein. Um das zu verhindern: vorher in Word alle „Mehrebenen-Bilder“ auf eine Ebene reduzieren. Das geht praktisch nur, indem entweder das Vefahren „Acrobat als Bild-Zwischencontainer“ angewandt oder mit einem Screenshot-Programm gearbeitet wird (vorzuziehen ist das Screenshot-Verfahren, weil einfacher). Danach liegen alle Bilder a) als Pixelbilder vor und b) sind sie auf eine Ebene reduziert.

• Tests zu Formeln zeigen, dass diese nach der Umwandlung in epub und auch in mobi (Umwandlung aus epub mit calibre) immer noch als Vektorgrafiken verstanden werden. Vektorgrafiken können aber anscheinenend bisher mit allen E-Book-Formaten nicht vernünftig verarbeitet werden! Sie werden zwar angezeigt, bleiben aber so klein, wie sie ursprünglich angelegt wurden und reagieren auf keine Schriftvergrößerung. Außerdem können sie nicht per Anklicken als Bilder vergrößert werden, wie das bei Pixelbildern der Fall ist. M.a.W: auch hier gilt: alle Formeln sollten am besten direkt in der Word-Datei in Pixelbilder umgewandelt werden!

Wenn das EPUB aus InDesign heraus erzeugt wurde, kann es passieren, dass die Bilder in div-Elementen eingekapselt sind, die erzeugt werden, weil die Bilder in InDesign in Rahmen stecken. Das Problem: Die Größen der Bilder werden durch die Rahmengrößen vorbestimmt. Mit anderen Worten: Selbst, wenn ein Bild (das vielleicht Text enthält) ursprünglich groß genug war, damit alles erkannt werden konnte, wird es auf einem E-Book-Reader zu klein wiedergegeben. Grund: Die Rahmengrößen, die innerhalb von InDesign vergeben wurden, führen zu class-Attributen von div-Elementen im EPUB. Die Eigenschaften der class-Attribute stecken im CSS, und hier schreibt InDesign Breite und Höhe in absoluten Pixel-Werten hinein. Das heißt, man muss

• die Breiten- und Höhenangaben auf max stellen oder
• sie entfernen oder
• die Attribute aus den div-Elementen löschen oder
• die div-Elemente durch einfache p-Elemente ersetzen.

Probleme bereiten u.a. die Tabellen:

• breite Tabellen in Bilder umwandeln
• bei allen anderen Tabellen:
  • aufpassen, dass bereits in Word keine Sonderfarben für die Ränder genommen werden (sollte am besten nur schwarz sein)
  • sämtliche width- und height-Angaben rausnehmen, denn sonst kann der jeweilige E-Reader nicht seine eigenen Funktionen zum Einsatz bringen; wichtig ist ja, dass Tabellen immer die jeweilige Bildschirmbreite ausnutzen; das aber klappt nur, wenn keine width- und height-Angaben enthalten sind.
• Da Sigil keinen Tabellen-Editor hat, ist es am besten, Tabellen bereits auf HTML-Ebene zu bearbeiten, also z.B. in KompoZer

• wenn irgendwo „-moz-use-text-color“ auftaucht:

1. nachfolgende rgb-Werte komplett löschen
2. „-moz-use-text-color“ durch „currentColor“ ersetzen (vgl. z.B. https://stackoverflow.com/questions/2283010/what-is-moz-use-text-color)
3. beim Ersetzen mit RegEx aufpassen, dass Zeichen, die als Steuerzeichen verstanden werden könnten (wie „-“ oder „(“, „)“ ) mit Backslash versehen werden, also z. Suche nach \(, wenn nach Klammer gesucht werden soll
4. wenn irgendwo „windowtext“ als Farbattribut auftritt, ebenfalls durch currentColor ersetzen

• in Word erstellen
• als PDF abspeichern
• aus Acrobat heraus als Bild, am besten im png-Format, abspeichern; png ist das moderne gif-Format.

siehe Calibre und Sigil

• beim „Säubern“ des HTML-Codes besser das Häkchen bei „Leerbereiche“ wegnehmen, weil sonst auch sämtliche Leerzeilen rausgeworfen werden. Ich habs zwar noch nicht sytematisch untersucht, aber es scheint so zu sein, dass Leerzeilen bei der Umwandlung in EPUB oder MOBI erhalten bleiben und so zur optischen Trennung von Absätzen genommen werden können.
• Das CSS kann geändert werden:
  • insbesondere können/sollten den Styles andere Schriften bzw. Schriftschnitte zugewiesen werden, wobei allerdings die zugewiesenen Schriften nicht in das EPUB eingebettet werden (das geht erst ab EPUB 3 bzw. KF8). Trotzdem scheinen die jeweiligen Reader auf bestimmte vorgegebene Schriften anders zu reagieren als auf die Standardschriften Times New Roman und Arial! Die Schriftschnitte und Schriftgrößen scheinen sich irgendwie bis zum Reader hin zu erhalten. Achtung: Um zu erreichen, dass die Schriftschnitte wirklich erhalten bleiben, vorsichtshalber im CSS-Editor auf der Registerkarte „allgemein“ in der entsprechenden zeile das Häkchen „wichtig“ setzen (vgl. auch E. Castro und Adobe-Anleitungen)
  • Hat man in Word durchgängig mit eigenen Formatvorlagen gearbeitet, können sämtliche Word-interne Formatvorlagen, die in die HTML-Datei gewandert sind, gelöscht werden. Einfach im CSS-Editor alle MSO-Stile der Reihe nach anklicken und entfernen.

Falscher Split: Einen falschen Split (also Seitenumbruch) im E-Book kann man am besten hier in Sigil korrigieren:

• einfach die beiden XHTML-Dateien im Buchbrowser markieren und den Befehl Menü<Datei-Zusammenführen> wählen!
• das Gute: Sigil führt automatisch die „content.opf“ nach

Fehlender Split, also das Einbringen eines Seitenumbruchs:

• in der Buch-Ansicht Cursor an die Stelle setzen, wo gesplittet werden soll, dann Menü <Bearbeiten-Teilung an Cursor>; man landet in einer neuen XHTML-Datei, die von Sigil einen beutralen Namen erhält: Section0001.htm; sie wird im Buch-Browser angezeigt.
• auch bei dieser Aktion führt Sigil die „content.opf“ nach!

CSS: Das CSS befindet sich im Ordner „Formatierungen“: stylesheet.css. Doppelklick drauf, öffnet den CSS-Editor von Sigil. Hier können sämtliche Formatierungen nachträglich geändert werden. Am wichtigsten sind wahrscheinlich die Einstellungen zur Schrift.

Clips und Formatvorlagen: In Sigil gibt es, anders als z.B. bei Jutoh, kein Fenster, in dem die aus dem CSS zur Verfügung stehenden Formatvorlahgen (FV) angeboten werden. Dafür hat Sigil ein mächtiges Werkzeug mit den sog. Clips! Diese nutzen u.a. die RegEx-Fähigkeiten von Sigil aus. Ein Clip könnte z.B.

<p>\1</p>

sein. Markiert man in der Quelltext-Ansicht eine Textstelle und weist ihr über das Clip-Fenster diesen Clip zu, fasst Sigil die Markierung als „Ausdruck 1“ auf (der Befehl \1 greift auf diesen Ausdruck zu) und umgibt ihn mit dem p-Element. Achtung: in der Buchansicht führt ein Clip manchmal einen falschen Code aus, daher nur in der Quelltext-Ansicht mit Clips arbeiten!

Angelegt werden Clips im Clip-Editor:

Hier können auch eigene „Gruppen“, also aufklappbare Menüs, angelegt werden, in die man die eigenen Clips einbaut. Ist z.B. im CSS ein span-Befehl zum Kursivieren definiert, der etwa „Hervorkursiv“ heißt, so legt man einfach den Clip

<span class="Hervorkursiv">\1</span>

im Clip-Editor ab.

Ruft man nun das Clip-Fenster auf, kann man hier einfach auf den Clip klicken und schon wird das span-Element um die markierte Textstelle gelegt!

Clip-Fenster:

Das heißt, mit Clip-Editor und Clip-Fenster lassen sich ganz einfach alle Formatvorlagen anlegen und anwenden! Besser und effektiver geht es kaum.

Einbindung und Ersatz von Grafiken: siehe Bilder und Grafiken

IHV:

• Funktionales IHV: In Sigil einfach die Überschriften mit den Formatvorlagen h1, h2, h3 usw. versehen und dann Menü<Werkzeuge-Inhaltsverzeichnis-Inhaltsverzeichnis erzeugen>; es geht ein Fenster auf, in dem man wählen kann, welche Überschriften übernommen werden sollen. Dieses IHV ist das funktionale, das in der toc.nx landet, also dasjenige, das unbedingt in jedem E-Book enthalten sein muss.
• IHV im Text: Dies wird auch HTML-IHV genannt. Dazu Menü<Werkzeuge-Inhaltsverzeichnis-Erstelle HTML-IHV> wählen
• Ein Problem sind die Seiten, die keine Überschriften haben, aber doch in beide IHVs aufgenommen werden sollen, also alle Seiten der Titelei: Titelseite, Copyright-Seite, Widmung usw. Da Sigil nur aus vorhandenen Überschrift-Auszeichnungen (also h-Elementen) die IHVs erzeugen kann, müssen die Titeleiseiten mit verborgenen h-Elementen ausgestattet werden, und zwar am besten mit <h1>-Elementen, weil diese dann hierarchisch auf derselben Ebene stehen wie die eigentlichen Überschriften 1. Ordnung. Das „Verbergen“ geschieht einfach dadurch, dass in das öffnende h1-Element ein Titel geschrieben wird nach dem Muster

  <h1 title="Copyright"></h1>

  Danach IHVs neu erzeugen! Die Copyright-Seite steht nun mit dem Text „Copyright“ sowohl im funktionalen IHV als auch im HTML-IHV!

• Anmerkung: Das Kennzeichen nicht verborgener Überschriften ist Text zwischen Anfangs- und Endelement, also z.B.

  <h1>Einleitung</h1>

• Wie könnte man die Titeleiseiten auf andere Weise ins HTML-IHV bringen? Einfach, indem man manuell Anker auf jeder Titeleiseite setzt und dann vom HTML-IHV aus dorthin verlinkt.
• <hi>Anmerkung: Es ist grundsätzlich nicht nötig, das IHV bereits in Word zu erzeugen, im Gegenteil: In Sigil geht es viel einfacher und sauberer!</hi>

• Was aus Word über HTML aber (leider) nach Sigil herüberkommt, sind die IHV-Textmarken, die Word setzt, sobald in word ein IHV erzeugt wird. Deswegen „leider“, weil diese Textmarken den jeweiligen Überschriftentext einschließen; das aber führt zu einer falschen Formatierung, nämlich einer blauen Unterstreichung, auf allen ADE-basierten E-Readern (ADE: Adobe Digital Editions), zu denen auch das ipad mit iBooks gehört. Um diese Falschformatierung zu entfernen, muss in Sigil mit RegEx gearbeitet werden:
  • 1. Durchgang: Suche nach

    <a name="_Toc[0-9]*">

    ersetze durch nichts; nun nicht irritieren lassen, dass Sigil eine Fehlermeldung anzeigt - die Endelemente der Anker-Tags müssen in nachfolgenden Durchgängen entfernt werden:

  • 2. Durchgang: Suche nach

    </a></h1>

    ersetze durch

    </h1>

  • 3. Durchgang: Suche nach

    </a></h2>

    ersetze durch

    </h2>

  • usw.

• Löschen der versteckten Textmarken (also der IHV-Textmarken) in Word: siehe Word. Diese Textmarken bereits in Word rauszuwerfen, hat den Vorteil, dass beim Epub-Check in Sigil von vornherein viel weniger Fehlermeldungen kommen und außerdem die ansonsten für manche Textmarken komplizierte RegEx-Suche nicht benötigt wird.

Navigation und Semantik

• rechter Mausklick auf eine der texttragenden htm-Dateien, dann „Semantik hinzufügen“

• Die Semantik ist wichtig für das Führen („Guiding“) des Lesers durch ein E-Book; die einstellungen führen zu guide-Einträgen in der „content.opf“. Hier ein Beispiel:

  <guide>
      <reference href="Text/TOC.xhtml" title="Inhaltsverzeichnis" type="toc" />
      <reference href="Text/cover.xhtml" title="Buchdeckel" type="cover" />
      <reference href="Text/Titelblatt.htm" title="Titel-Seite" type="title-page" />
      <reference href="Text/Widmung.htm" title="Widmung" type="dedication" />
      <reference href="Text/Chronologie.htm" title="Schlussschrift" type="colophon" />
      <reference href="Text/Quellen_Bilder_und_Literatur.htm" title="Quellenangaben" type="bibliography" />
      <reference href="Text/Namensverzeichnis.htm" title="Index" type="index" />
      <reference href="Text/Teil_1.htm" title="Text" type="text" />
    </guide>

  Anscheinend reagieren aber nur Kindle-E-Books auf diese Einstellungen.

• Achtung: Wenn man bei der Vergabe der Semantik nicht aufpasst, stimmt nach der Umwandlung der EPUB-Datei in Mobi oder AZW die Navigation nicht mehr!

Eine weiter hinten stehende htm-Datei darf keinesfalls mit dem Semantik-Attribut „Text“ ausgezeichnet werden, sonst kann es passieren, dass diese Datei auf dem Kindle als „Anfangsdatei“ verstanden wird. Klickt man im funktionalen IHV auf „Anfang“, landet man nicht auf der ersten Seite (oder dem HTML-IHV), sondern mittendrin im Buch, nämlich genau bei der semantisch nicht korrekt ausgezeichneten Datei! Falls man nicht weiß, welchen Semantik-Eintrag man nehmen soll, muss ausprobiert werden (also immer wieder die EPUB-Datei mit dem Kindle Previewer in mobi umwandeln und anschauen). Oder anders herum: Falls die Navigation auf dem Kindle nicht funktioniert, kann es an falsch vergebenen Semantik-Tags liegen!

Validierung:

• Mit Sigil kann eine EPUB-Validierung durchgeführt werden, und zwar auf der Basis des FlightCrew-Validators! Das sollte auf jeden Fall gemacht werden; notwendige Korrekturen können direkt in Sigil ausgeführt werden.

• Interessant: für jedes Ausgabeformat können Voreinstellungen vorgenommen werden; so kann z.B. für EPUB eingestellt werden, dass kein Split in mehrere HTML-Dateien vorgenommen wird! Falls doch falsche Splits in eine Epub-Datei hineingeraten sind, könnten sie auch noch mit Sigil entfernt werden (s.o.). Sind andrerseits zu wenige Splits enthalten, so brauchen nur die allgemeinen Konvertierungseinstellungen von calibre (siehe unten) entsprechend geändert zu werden.
• Schriftgrößen werden in Einheiten von 1 em (Breite des kleinen Buchstaben m als Schrifthöhe der Versalbuchstaben) gemessen - das scheint die Bezugs-Einheit für die Default-Schriftgröße bei allen Readern zu sein. Calibre verwendet als Defaultschriftgröße anscheinend 12pt; d.h. alle Schriftgrößenvorgaben in Word (die am besten über Formatvorlagen gesetzt werden, damit sich ein einheitliches Bild ergibt) beziehen sich auf 12pt. Hat z.B. eine Überschrift in Word 18pt, dann bekommt sie in Calibre 1,5 em zugeweisen. Und genau diese, von Calibre zugewiesenen Werte sind im CSS in Sigil zu sehen und können auf Wunsch geändert werden.
• Wichtig: Der Zeilenabstand wird anscheinend von Calibre nicht umgesetzt, wenn er in Word fest vorgewählt wurde; d.h. 14.4pt in Word bleiben 14.4pt im EPUB. Und die werden anscheinend auch auf den Reader übertragen! Der Zeilenabstand sollte also auf jeden Fall nachträglich editiert und korrigiert werden, und zwar auf einen relativen Wert: „normal“ oder Teile von 1em, also z.B. 1.2. Aufgepasst: bei der Relativangabe darf die Einheit em nicht mitgenannt werden, also nicht 1.2em, sondern tatsächlich nur 1.2.
• Zu Schriftgröße und Zeilenabstand siehe auch allgemeine Anmerkungen oben.
• Ein funktionales IHV (Inhaltsverzeichnis) kann auf zwei Weisen erzeugt werden:
  • per Allgemeinen Konvertierungseinstellungen für Struktur und Inhaltsverzeichnis oder
  • indem calibre das in Word automatisch angelegte IHV erkennt und verarbeitet

Allgemeinen Konvertierungseinstellungen:

• Bei „Strukturerkennung“ in der Zeile „Kapitel erkennen“ den XPath-Ausdruck bearbeiten, und zwar den class-Befehl am Ende: //*[((name()='h1' or name()='h2') and re:test(., '\s*((chapter|book|section|part)\s+)|((prolog|prologue|epilogue)(\s+|$))', 'i')) or @class = 'chapter']. Wenn z.B. in Word die Überschriftformatvorlagen df_titel, df_u0, df_u1, df_u1nachtitel, df_u1nachu0, df_u2 und df_u2nachu1 verwendet wurden, dann werden in der HTML-Datei daraus die entsprechenden Klassen (wobei Sonderzeichen wie das Underline-Zeichen in html wegfallen!), d.h., der XPath-Ausdruck müsste lauten: //*[@class = 'dfu0' or @class = 'dfu1' or @class = 'dfu1nachtitel' or @class = 'dfu1nachu0' or @class = 'dfu2' or @class = 'dfu2nachu1']
  • Außerdem einstellen, dass keine Pagebreaks per Kapitelmarkierung vorgenommen werden: „Kapitelmarkierung“ auf „none“ stellen. Was allerdings gar nicht übel ist: Linien vor den Überschriften einziehen lassen („Kapitelmarkierung“ auf „rule“ stellen).
  • Schließlich vorgeben, vor welchen Überschriften die Pagebreaks eingebaut werden sollen: bei „Seitenumbrüche einfügen“ entsprechenden XPath-Ausdruck eintragen:

• Bei „Inhaltsvereichnis“ ebenfalls per XPath-Ausdrücken angeben, welche Klassen genommen werden sollen:

Auf Basis des in Word automatisch erzeugten IHV:

• Man muss in Calibre nicht den Befehl „Verwendung des automatisch erzeugten IHV erzwingen“ anwenden, damit das in Word automatisch angelegte IHV genommen wird; Calibre greift immer dann auf das Word-IHV zurück, wenn keine XPath-Befehle bei den allgemeinen Konvertierungseinstellungen eingetragen wurden (siehe oben).
• Aber aufgepasst: In Word werden im Hintergrund (!) Textmarken in das Dokument eingebaut, wenn ein automatisches IHV erzeugt wird. Die Textmarken können aber auf manchen Readern (nicht auf allen!) zu Anzeigeproblemen führen (Text, der an an Textmarken „dranhängt“, wird als blau unterstrichener Link dargestellt). D.h., man sollte immer Tests auf unterschiedlichen Readern bzw. in unterschiedlicher Reader-Software (Kindle-App, Adobe Digital Editions usw.) machen. Word-Textmarken bleiben auch oft stehen, obwohl der ursprüngliche Zweck, weswegen sie in Word angelegt wurden, nicht mehr erfüllt wird:
  • ein Absatz ist mal mit einem Überschriftformat ausgezeichnet worden, das anschließend wieder weggenommen wurde, weil der Absatz nun normaler Text sein soll. Übrig bleibt eine TOC-Textmarke.
  • eine Grafik ist im Absatz verankert, dann aber wieder entfernt worden. Übrig bleibt evtl. eine OLE-Textmarke.

Lösung des Problems: am besten direkt in Word die Textmarken löschen (vor dem Löschen mit „Gehe zu“ prüfen, ob die jeweilige Textmarke sinnvoll ist oder nicht). Es kann auch ein Makro von J. Lyon verwendet werden, das alle Hintergrund-Textmarken auf einen Schlag entfernt. Man kann die Anker (die in HTML mit dem Anker-Tag ausgezeichnet sind) auch noch auf HTML- oder EPUB-Ebene mit den entsprechenden Programmen (NVU, Notepad oder sigil) entfernen, was bei Nutzung von RegEX kein Problem ist. Man mache sich klar: Das Word-eigene IHV spielt bei einem E-Book eigentlich keine Rolle. Wichtig ist einzig und allein das funktionale IHV, das im E-Book zur NAvigation dient.

Bei der Konvertierung ins MOBI-Format wird übrigens das IHV, egal, auf welche Weise es erzeugt wurde, immer erkannt!

Im Unterschied zu Querverweisen (die beim Abspeichern als HTML-Datei verloren gehen) kommen alle Links in epub an.

Links können außerdem nachträglich mit einem HTML-Programm wie Nvu oder direkt im EPUB-Programm Sigil gesetzt werden.

Wichtig zu wissen ist v.a., dass im HTML-Code sämtliche Link-Ziele (Anker), die in Word vergeben wurden, erhalten bleiben! D.h. also, dass z.B. Textmarken, die in Word definiert wurden, vorhanden sind. Und zwar werden sie z.B. in Nvu oder auch in Sigil „benannte Ziele“ genannt.

Beispiel:

<a href=„#postscript1“>PostScript</a>

Hier wird vom im Text angezeigten Wort „PostScript“ ein Link auf die Textmarke #postscript1 gesetzt.

Syntax:

<a href=„…“> Linkbeschreibung </a> steht für interne & externe Links. „Linkbeschreibung“ ist das im Browser bzw. im E-Book angezeigte Wort, das zusätzlich in blauer Farbe und unterstrichen kommt, was das Kennzeichen für einen Link ist.

• a ist die Abkürzung für anchor (Anker);
• href ist die Abkürzung für hyper reference (Hypertext-Referenz, Hyperlink).

• Word: jedes Ziel muss in einer langen Liste von möglichen Zielen (also Textmarken) im Link-Fenster einzeln ausgewählt (also angeklickt) werden.
• NvU/KompoZer und Sigil: hier könnte zwar auch aus einer Liste ausgewählt werden, aber falls die Ausgangsstelle (von der aus verlinkt werden soll) genauso heißt wie das Ziel, kann die Textstelle erst kopiert und dann ins Link-Fenster eingefügt werden; es muss lediglich vor dem Zielnamen das Rautenzeichen eingegeben werden; die Raute dient als Kennung dafür, dass der Link in die aktuelle Datei hineingeht. Das heißt aber, der Prozess kann mit einem Makroprogramm beschleunigt werden:

1. Textstelle mit Ziel-Namen kopieren
2. per Strg-l Linkfenster aufrufen
3. # eingeben, dann
4. Strg-v, damit Ziel-Name aus Zwischenablage eingefügt wird
5. OK

Ergebnis: Links erst in NvU oder Sigil einbauen!

Es hat demnach nicht immer Vorteile, alle wichtigen Dinge (wie auch die Verlinkungen) im ursprünglichen Programm (hier: Word) auszuführen! Um Doppelarbeit zu sparen, darf in Word nicht verlinkt werden.

Achtung: Die Linkziele sollten natürlich in Word vorbereitet werden, indem man Textmarken einbaut. Dabei darauf achten, dass kein Text markiert, sondern dass die Textmarken nur an der Cursorstelle eingebaut werden. Sonst gibt es im EPUB Probleme mit der Formatierung der Anker (s.u.).

Querverweise sind sowieso neu zu verlinken!

In NVU/KompoZer und Sigil werden Links gesetzt, indem in der Normalansicht eine Textstelle, von der aus verlinkt werden soll, markiert wird, dann Ctrl-l; es geht ein Fenster auf, indem das Linkziel ausgesucht werden kann; OK.

Es ist klar, dass das Ziel existieren muss.

• in NvU/KompoZer sind die Ziele Anker mit Element <a> und Attribut „name“, also z.B. <a name=„test02“></a>
• in Sigil sind die Ziele Anker mit Element <a> und Attribut „id“, also z.B. <a id=„test02“></a>
• falls ein Ziel fehlt, einfach mit dem Ziel-Befehl (NvU/KompoZer) oder dem ID-Vefehl (Sigil) einbauen.
• falls die name-Attribute nach der Umwandlung von html in EPUB Probleme bereiten, dann in Sigil per Suchen/Ersetzen in id-Attribute umwandeln.

Falls der Textinhalt der markierten Textstelle mit dem Namen der Textmarke (also des Linkziels) identisch ist, kann ein kleines Makro (in MacroExpress) verwendet werden, das den markierten Text kopiert und im Verlinkungsfenster von NvU/KompoZer oder Sigil einfügt.

Das Anker-Element wird auf einigen Readern und insbesondere in einigen ePub-Betrachtungsprogrammen wie ADE in blauer Schrift und unterstrichen (also wie ein Link) dargestellt. Nach meiner Untersuchung sind betroffen:

Fazit: Alle Geräte oder Software, die auf ADE aufbauen, zeigen diesen Effekt, andere Geräte/Software nicht. Zum Glück gehört der Kindle zur letzten Gruppe (kein Effekt).

Anscheinend gibt es keinerlei Möglichkeit, den Effekt über das CSS zu beeinflussen!

Lösungsmöglichkeiten:

1. Wenn es nur um Anker in Überschriften geht, so ist zu bedenken, dass man sowohl das HTML- als auch das funktionale IHV (und nur für diese werden Überschriftanker benötigt) auch durch xPath-Einstellungen in calibre erhält oder einfach in Sigil erzeugen kann. In beiden Fällen werden neue id-Attribute erzeugt, die nicht in einem a-Element stecken, sondern in einem span- oder p-Element. Und die bereiten keine Probleme. D.h. letztlich, dass man dann die stehengebliebenen a-Elemente samt der in ihnen enthaltenden id-Attribute komplett löschen kann. Das geht am besten mit RegEx in Sigil: Suche nach „<a id=„_[a-zA-Z0-9]*“>[a-zA-Z0-9 ?]*</a>“ [hier wird angenommen, dass es sich um eine Textmarke handelt, die am Anfang ein Underline-Zeichen hat, gefolgt von beliebigen Buchstaben und Zahlen sowie von beliebig vielen Blanks und Fragezeichen], ersetze durch „“, also durch nichts.
2. Bei allen Ankern, insbesondere solchen, die nicht Überschriften betreffen:
   • Die id-Attribute aus den Ankerelementen herausnehmen und z.B. in ein Span-Element stecken; denn – und das ist die erstaunliche Erkenntnis – als letztlicher Anker reicht das id-Attribut allein aus! Es kann sich in jedem beliebigen Element befinden! [Hinweis darauf gefunden bei: http://www.mobileread.com/forums/archive/index.php/t-166994.html] Natürlich hat man das Problem, sämtliche Ankerelemente zu bearbeiten und zu entfernen und die id-Attribute anders zu verteilen. Eine gute Möglichkeit besteht darin, direkt in Sigil mit Suchen/Ersetzen zu arbeiten: Suche nach „<a id“, ersetze durch „<span id“; anschließend noch suche nach „</a>“, ersetze durch „</span>“. Beim zweiten Suchen/Ersetzen-Lauf muss man natürlich aufpassen, dass man nicht aus Versehen die abschließenden Tags von „<a href…>“ erwischt, denn die dürfen nicht verlorengehen.
     • In den Griff bekommt man das durch Nutzung von RegEx in Sigil, und zwar indem man zwischen ersten und zweiten Lauf einen weiteren dazwischenschaltet: Suche nach „(<span id=„_[a-zA-Z0-9]*“>[a-zA-Z0-9 ?]*</a>)“ [hier wird angenommen, dass es sich um eine Textmarke handelt, die am Anfang ein Underline-Zeichen hat, gefolgt von beliebigen Buchstaben und Zahlen sowie von beliebig vielen Blanks und Fragezeichen; außerdem muss durch die äußeren runden Klammern eine Gruppe gebildet werden], ersetze durch „\1#“; dann kann der dritte Lauf sein: suche nach „</a>#“, ersetze durch „</span>“. Dadurch werden nur diejenigen End-Tags erwischt, die zu den ursprünglichen „<a id“-Tags gehörten.
   • Das Problem besteht nur dann, wenn der Anker - wie es natürlich bei Textmarken oft ist - Text umfasst. M.a.W.: Wenn man Anker einfach „so“, also ohne Text, verwendet, kann kein Text falsch formatiert werden! Folgerung: a) in Sigil brauchen nur die End-Tags der Anker so versetzt zu werden, dass die Anker ganz allein für sich stehen, ohne Text einzuschließen. Das ist allerdings nicht auf einen Schlag mit RegEx möglich, sondern man müsste entweder manuell vorgehen oder in ein Programm mit Makromöglichkeiten wechseln. b) Bereits bei der Vorbereitung in Word Textmarken immer setzen, ohne Text zu markieren! c) Auch im HTML-Programm oder in Sigil oder Calibre können nachträglich Anker (oder wie es in Sigil sinnigerweise heißt: IDs) eingefügt werden, und das kann immer an der Stelle geschehen, an der der Cursor blinkt, es muss kein Text markiert werden.

• siehe auch oben bei Sigil

• das Attribut „name“ im Element a, das von Word für Textmarken verwendet wird, ist in XHTML nicht bekannt und muss durch „id“ ersetzt werden, also z.B.:

• Querverweise aus Word werden bereits in HTML nicht umgesetzt, daher kommen sie auch nicht zu ePub herüber; Grund: im Unterschied zu Hyperlinks sind Querverweise REF-Felder, und bei Feldern kommen (vgl. Papier zu Word 2003 bzgl. Umsetzung in HTML) nur die Feldinhalte herüber. Hyperlinks sind zwar auch Felder, aber sie werden, wohl weil sie auch ins Internet verweisen können, programmtechnisch anders gehandhabt als alle anderen Felder: sie werden korrekt übernommen.