Erfahrungen mit der Veröffentlichung von E-Books mit TextMaker

[Torsten65]

Mich würde interessieren, ob jemand E-Books als Selfpublisher bei Amazon & Co. veröffentlicht hat und welche Erfahrungen mit dem ePub-Export aus TextMaker für diesen professionellen Bereich gewonnen wurden.

Entsprechen diese ePubs den technischen Anforderungen der Distributoren? Sehen sie nach der "Veröffentlichung" auf den Geräten so gut aus wie geplant?

Ich freue mich auf eure Erfahrungen.

[beiti]

Ich habe den Beitrag gerade erst entdeckt, auch wenn er schon über einen Monat alt ist. Falls meine Antwort zu spät kommt, bitte einfach ignorieren.

Ich habe in der Tat ein eBook bei Amazon, bei Tolino-Media sowie über XinXii bei einer Reihe weiterer Shops veröffentlicht.
Mein eBook habe ich mit TextMaker ausgegeben. Allerdings habe ich es vor der Veröffentlichung noch ziemlich umfassend mit Hilfe von Sigil nachbearbeitet. (Sigil ist ein Programm, mit dem man die "Innereien" von EPUBs sehen und nachbearbeiten kann. Man kann Bearbeitungen teils automatisieren, also man muss nicht für jeden Versuch wieder komplett von vorn beginnen.)

Die eBook-Ausgabe von TextMaker ist für den eigenen Bedarf nicht schlecht, aber sie widerspricht doch an vielen Punkten den Vorgaben der eBook-Shops. Das fängt schon an bei der Schriftgröße und -farbe. Amazon hat hierfür ein dickes Anleitungs-PDF rausgegeben, das alle Details der Kindle-Veröffentlichung erklärt. Andere Anbieter haben ihre eigenen (weniger umfangreichen) Anleitungen. In der Praxis wid man sich meist an den Amazon-Kindle-Vorgaben orientieren. Dann passt es für die anderen Anbieter auch.
Es gibt auch Dinge, die in keinem Handbuch stehen und die man nur durch das Testen verschiedener Lesegeräte rausfindet. Dazu gehört z. B. dass Amazon-Kindle-Geräte mittlerweile als Default sämtliche benutzerdefinierten Schriftarten ignorieren oder dass die Tolino-Geräte sämtliche Formatierungen komplett verwerfen, wenn man sogenannte Media Queries ins CSS einbaut. (Ja, ich weiß, ich gehe hier schon in Details.)

Gut, ich bin da vielleicht auch ein Spezialfall, weil ich mich ziemlich umfangreich in das Thema EPUB eingearbeitet und die Amazon-Voraben zumindest ein Stück weit studiert habe. Das machen vermutlich die Wenigsten.
Ich weiß jetzt nicht genau, was passieren würde, wenn man ein eBook einfach ohne jedes Hintergrundwissen mit TextMaker ausgibt und unbearbeitet bei Amazon hochlädt. Soweit ich weiß, korrigiert Amazon manche Fehler bereits automatisch. Ich persönlich würde mich da ungern drauf verlassen. Amazon ist erst mal recht großzügig und nimmt fast alles an (ich habe bei Amazon schon Selfpublisher-Bücher mit den scheußlichsten Formatierungen gekauft). Aber wenn sich dann die Leser beschweren und/oder schlechte Bewertungen abgeben, rutscht man in der Verkaufsstatistik schnell nach hinten.
Die Herausforderung bei eBooks ist ja immer, dass sie auf allerlei Geräten gut lesbar sind – auf einem 4"-Handy genauso wie auf einem PC mit großem Monitor.

Es macht sicher auch einen Unterschied, ob man ein reines Textbuch hochlädt oder (wie in meinem Fall) ein Werk mit relativ vielen Abbildungen. Reine Texte wie Romane oder bilderlose Sachbücher sind auf jeden Fall einfacher zu handhaben. Sobald Bildmaterial im Spiel ist, muss man sich mit Abbildungsgrößen und Dateigrößen auseinandersetzen. Andernfalls erscheinen die Bilder zu groß oder zu klein, und entweder ist die Qualität sehr schlecht oder die Dateigröße bläht sich zu sehr auf (was Amazon mit dem Abzug hoher "Liefergebühren" bestraft, die den Gewinn auffressen können). Die Art und Weise, wie TextMaker Bilder ins EPUB einbindet, ist nicht problemlos für die Veröffentlichung geeignet und erfordert auf jeden Fall etwas Eigeninitiative (Dateien vorher skalieren und passend komprimieren, Einbindung in Prozentgrößen statt Pixelmaßen etc.). Sonst sind Beschwerden von Lesern vorprogrammiert.

[Torsten65]

Vielen Dank für deine umfangreiche Antwort. Sie kommt früh genug, da ich noch im Schreibprozess bin. Ich kann alternativ mit Jutoh arbeiten, wollte nur hören, ob ich mir diesen Umweg sparen kann.

Vielleicht hat SoftMaker ein Interesse daran, hier entsprechend nachzuarbeiten, zumal man mit den Sprachtools von TextMaker so gut schreiben kann.

[beiti]

Jutoh kenne ich nur von ein paar Versuchen mit der Testversion. Macht auf mich einen guten Eindruck; offenbar hat sich da jemand sehr viele Gedanken gemacht. Ob man ohne tiefe Einarbeitung immer zum Ziel kommt, weiß ich nicht. Zumindest für komplexere Werke wird man sich da auch einige Kenntnisse aneignen müssen und nicht nur mit Voreinstellungen arbeiten können. Das Handbuch zu Jutoh liest sich, soweit ich mich erinnere, wie eine komplette Einführung ins EPUB-Format.
Für mich habe ich dann entschieden, dass es sinnvoller ist, gleich mit TextMakers EPUB-Export zu arbeiten und die Einarbeitungszeit in Sigil zu investieren. Ob es mit Jutoh einfacher gewesen wäre, kann ich nicht sagen.

Falls das hier mal zufällig jemand mitliest, der es mit meiner Methode versuchen möchte, zähle ich im Folgenden kurz auf, wo ich die EPUBs aus TextMaker nachbessere. Das vermittelt vielleicht auch einen Eindruck vom Aufwand.
Für alle Sachen, die man an mehreren Stellen des EPUBs ändern muss, bietet Sigil eine programmierbare Suchen-Ersetzen-Funktion.

--------------------------------

Zuerst füge ich mit Sigil immer ein HTML-Inhaltsverzeichnis ein, das dann noch vor dem Buchtext steht. (Amazon empfiehlt dies zusätzlich zum EPUB-Inhaltsverzeichnis, das TextMaker bereits selber korrekt anlegt.) TextMaker kann zwar mittlerweile auch ein HTML-Inhaltsverzeichnis erzeugen, aber der Kindle-Konverter findet und verlinkt es dann nicht richtig; deshalb mache ich das lieber mit Sigil, wo es einwandfrei klappt.

In der Content.css sollten etliche Eigenschaften für den Fließtext verschwinden, weil man lt. Amazon die Formatierung des Fließtextes komplett dem Reader überlassen soll. Das betrifft Einträge wie line-height, font-family, color und border. Die lösche ich ersatzlos raus.
Außerdem setze ich für die Überschriften-Ebenen h1, h2, h3 etc. immer 'text-align: left', damit die Kindle-Reader längere Überschriften nicht so hässlich auseinanderziehen.
Wenn man weitere Formatvorlagen definiert hat (aus denen beim Export Klassenstile werden), kann man ggfs. dafür auch noch Anpassungen machen. Das Suchen-Ersetzen in Sigil arbeitet mit vielerlei regulären Ausdrücken, so dass man letztlich fast alles irgendwie automatisiert bekommt.

Wenn ich Bilder eingebunden habe, entferne ich in den xhtml-Dateien deren Höhen- und Breitenangaben und ersetze sie durch Prozentzahlen. Das ist allerdings etwas komplexer und lässt sich nur gut automatisieren, wenn man schon beim Einbau der Bilder in TextMaker ein paar Vorkehrungen trifft. Daher will ich es an dieser Stelle nicht weiter erläutern. (Für reine Text-E-Books braucht man das eh nicht.)

Dann füge ich in Sigil noch die Cover-Datei ein. Auch hier gilt wieder: Man kann es schon beim Export mit TextMaker machen, aber der Kindle-Konverter verarbeitet das Titelbild dann nicht richtig. Macht man es mit Sigil, funktioniert es.

Zum Schluss kümmere ich mich noch von Sigil aus um die Metadaten. Ich passe den Titel an und entferne überflüssige Einträge (z. B. Überarbeitungs-Datum). Aber das sind schon Feinheiten, die fürs Funktionieren der EPUB-Datei nicht wichtig sind.

Bis man alle diese Sachen mal ausgetüftelt hat, vergeht einige Zeit. Aber wenn man die Ersetzen-Vorgänge speichert ("Gespeicherte Suchbegriffe" in Sigil), kann man sie auf neue Versionen desselben Buches (oder auf gleichartige Bücher, die z. B. mit denselben Absatzvorlagen arbeiten) jederzeit erneut anwenden. Die ganze Nachbearbeitung dauert dann jeweils nur wenige Minuten.

[FFF]

Wenn ich das so lese, fände ich es toll, wenn Du von Inhaltsverzeichnis und Cover je ein Beispiel bauen könntest, und das SM schicken. Wenn sie die je drei Dateien vorliegen haben, sollte es ihnen (leichter) möglich sein, TM so anzupassen, dass der Output dann auch paßt.

[beiti]

Ich glaube, die Erkennung scheitert nur an Kleinigkeiten (das Inhaltsverzeichnis bzw. das Cover müsste irgendwo in einer Steurungsdatei eingetragen werden).
Ist schon eine Weile her, dass ich mich genauer damit befasst habe. Habe in letzter Zeit kein EPUB mehr exportiert.
Ich werde das gelegentlich nochmal anhand der jüngsten TextMaker-Version testen.

[beiti]

Okay, jetzt habe ich mich mal hingesetzt und die Sache durchprobiert.

Wenn man die EPUBs aus TextMaker durch KindleGen (d. h. den standardmäßigen Konverter für Amazon-E-Books) jagt, kriegt man insgesamt drei Fehlermeldungen bzw. drei angeblich fehlende Elemente:
– TOC (Table Of Content)
– SRL (Start Reading Location)
– Cover

Der Eintrag TOC bezieht sich auf ein HTML-Inhaltsverzeichnis, also das sichtbare (zusätzliche) Inhaltsverzeichnis am Anfang des Buches. TextMaker kann so eines erstellen. Dazu muss man irgendein Inhaltsverzeichnis im Textdokument eingefügen. TextMaker ersetzt das normale Inhaltsverzeichnis automatisch beim Exportvorgang durch ein EPUB-gerechtes Inhaltsverzeichnis mit verlinkten Überschriften. Die Datei ist dann quasi die erste Inhaltsdatei und heißt Content0001.xhtml. (Noch praktischer wäre, wenn TextMaker immer von sich aus so ein sichtbares Inhaltsverzeichnis beim EPUB-Export einfügen würde und wenn die Datei einen eindeutigeren Namen hätte, etwa Inhalt.xhtml.)
Das Problem ist jetzt, dass KindleGen das Inhaltsverzeichnis nicht von selber findet. Damit es klappt, muss die betreffende Inhaltsdatei in der content.opf verlinkt sein, und zwar zwischen <guide> und </guide>. Hier muss, wenn das Inhaltsverzeichnis die Content0001.xhtml ist, folgende Zeile eingefügt werden:
<reference type="toc" title="Inhaltsverzeichnis" href="Content/Content0001.xhtml"/>

Unter SRL erwartet Kindle eine Angabe, mit welcher xhtml-Datei der Haupttext beginnt. Das ist die Stelle, auf die alle Kindle-Reader automatisch nach dem ersten Öffnen eines Buches springen (und wo man auch später hinkommt, wenn man im Menü "Gehe zum Anfang" wählt). Im einfachsten Fall wäre das die Content0001.xhtml. Wenn man jedoch ein Inhaltsverzeichnis am Anfang platziert hat (siehe voriger Abschnitt), kriegt dieses den Namen Content0001.xhtml und der wirkliche Textanfang rutscht weiter auf Content0002.xhtml.
Die fehlende Referenzierung behebt man auch wieder mit einem Eintrag in der content.opf zwischen <guide> und </guide>:
<reference type="text" title="Text" href="Content/Content0002.xhtml"/>

Mit Cover ist das Titelbild gemeint. TextMaker kann eines einfügen, wenn man es beim EPUB-Export ausdrücklich angibt. Es taucht dann im EPUB in einer separaten xhtml-Datei namens Cover.xhtml auf. Die Referenzierung in der content.opf zwischen <guide> und </guide> erledigt TextMaker in diesem Fall bereits korrekt, aber KindleGen erkennt es trotzdem nicht. Das funktioniert erst mit einem zusätzlichen Eintrag, und zwar einer Verlinkung der Bilddatei weiter oben in der content.opf zwischen <metadata [...]> und </metadata>:
<meta name="cover" content="Cover.jpg" />

Führt man diese drei Änderungen durch, verschwinden zumindest die drei Fehlermeldungen in KindleGen.

[Torsten65]

Wenn ich das so lese, fände ich es toll, wenn Du von Inhaltsverzeichnis und Cover je ein Beispiel bauen könntest, und das SM schicken. Wenn sie die je drei Dateien vorliegen haben, sollte es ihnen (leichter) möglich sein, TM so anzupassen, dass der Output dann auch paßt.

Das wäre doch ein Anfang.
@beiti: Vielen Dank für dein "Rezept" und deine Erfahrungswerte. Du hast dich hier wirklich tief eingearbeitet.

Jutoh macht wirklich gute Exporte und hat einen höchst zuvorkommenden Entwickler (Ein-Mann-Betrieb). Ähnlich wie hier in SMO ist Julian Smart immer an Feedback interessiert und offen für neue Features. Ich habe eine Zeit lang komplett in Jutoh (Editor) geschrieben, weil sich das Programm langsam in Richtung Autorensoftware entwickelt. Man kann Profile für diverse Outputs anlegen: Normseite (odt-Dokument, funktioniert auch in Richtung TM), Mobi, ePub und diverse andere (E-Book-)Formate.

Allerdings ist das Handling in TM einfacher und – die Sprachtools (Duden-Korrektor, Wörterbücher, Synonyme etc.) sind bekanntlich legendär. Ich schreibe in TM einen Roman sogar im Format der Normseite (mit Courier New und ohne Schnickschnack). Schön wäre in diesem Zusammenhang, wenn man für den ePub-Export eine andere Schriftart wählen könnte.

Insgesamt wäre – und das ist hier die Diskussion – ein publikationsfähiges ePub natürlich genial und vielleicht für SM ein weiteres Argument für das Marketing.

Noch eine Frage, beiti: Du bettest das Cover für Amazon ein? Ich dachte, Amazon erwartet das Cover als separate Datei?

[beiti]

Schön wäre in diesem Zusammenhang, wenn man für den ePub-Export eine andere Schriftart wählen könnte.

Die Frage ist, was das überhaupt nützt.
Amazon empfielt ja ausdrücklich, für den Fließtext keine Schriftart festzulegen und die Wahl stattdessen dem Reader zu überlassen (bei Kindle-Geräten ist das dann standardmäßig Bookerly). Nur für besondere Absätze oder Überschriften ist das Festlegen anderer Schriftarten "erlaubt".

Technisch muss man unterscheiden, ob die Schriftart nur mit Namen im EPUB festgelegt wird oder ob sie auch eingebettet wird.
Wenn sie nur mit Namen eingebettet ist (z. B. als font-family: Arial), hängt es davon ab, ob der Reader diesen Namen erkennt. Etwa im Fall von Arial ist das bei Kindle-Readern der Fall und sie stellen die Schrift dann in einer serifenlosen Standardschrift da. Die Tolino-Reader und andere erkennen den Namen Arial hingegen nicht, so dass dann alles in deren Standardschrift erscheint. (Was überall funktioniert, sind generische Font-Namen wie sans-serif oder monospace.) Wenn man irgendwelche exotischen Schriftartennamen verwendet, die der Reader nicht passend ersetzen kann, erscheint der Text auf jeden Fall in Standardschrift.
Wenn man nun die Schriftarten als Font-Dateien einbettet, könnte man ja theoretisch auch exotischere Fonts verwenden (sofern deren Einbettung erlaubt ist). Aber da verhalten sich die Reader wieder unterschiedlich. Die Kindle-Geräte sind (seit einer bestimmten Firmware-Version) so eingestellt, dass eingebettete Schriftarten standardmäßig ignoriert werden. Erst wenn der Nutzer in den Einstellungen explizit diese "Verleger-Schriftart" anwählt (was wohl nur die Wenigsten tun), wird sie wirklich dargestellt. Die Tolino-Reader stellen die eingebettete Schriften bereits standardmäßig dar, aber man kann sie natürlich abschalten.

Ich wünschte immer noch, TextMaker hätte zusätzlich die wählbare Option, Schriftarten-Namen im EPUB komplett wegzulassen. Das würde sich besser mit der Amazon-Richtlinie vertragen und Unsicherheiten beseitigen.

Du bettest das Cover für Amazon ein? Ich dachte, Amazon erwartet das Cover als separate Datei?

Das ist irgendwie doppelt gemoppelt. Man soll es einbinden (sonst meckert KindleGen), aber trotzdem auch noch separat hochladen.
Ich denke mal, das separate Hochladen ist eher historisch bedingt und hat damit zu tun, dass man bei Amazon wahlweise auch eine "lose" HTML-Datei oder sogar eine Word-Datei hochladen kann. Das stammt noch aus einer Zeit, als es keine EPUB-Programme gab.

[Torsten65]

Ich wünschte immer noch, TextMaker hätte zusätzlich die wählbare Option, Schriftarten-Namen im EPUB komplett wegzulassen. Das würde sich besser mit der Amazon-Richtlinie vertragen und Unsicherheiten beseitigen.

Ja, das passt und hier habe ich mich missverständlich ausgedrückt. Zwischendurch gebe ich vorab Leseproben als ePub weiter und wollte hier Courier New auf den eReadern vermeiden. Mit deiner Idee wäre das vermutlich noch eleganter zu lösen; einbetten wollte ich Schriften keinesfalls.

Das ist irgendwie doppelt gemoppelt. Man soll es einbinden (sonst meckert KindleGen), aber trotzdem auch noch separat hochladen.
Ich denke mal, das separate Hochladen ist eher historisch bedingt und hat damit zu tun, dass man bei Amazon wahlweise auch eine "lose" HTML-Datei oder sogar eine Word-Datei hochladen kann. Das stammt noch aus einer Zeit, als es keine EPUB-Programme gab.

Vielen Dank für deine Ausführung zu diesem Punkt.

[beiti]

Zwischendurch gebe ich vorab Leseproben als ePub weiter und wollte hier Courier New auf den eReadern vermeiden.

Mir ist vorhin noch was dazu eingefallen. Der EPUB-Export in TextMaker bietet ja die Option "Benutzerdefiniertes CSS anhängen".
Diese Stylesheets funktionieren hierarchisch. Das Stylesheet in der EPUB-Datei überschreibt die Vorgaben des Readers. Und wenn innerhalb der CSS-Datei im EPUB einem Element weiter unten andere Attribute zugewiesen werden als oben, gelten die weiter oben zugewiesenen nicht mehr. Deswegen kann man durch Anhängen eines Stylesheets im Prinzip alle Formatierungen überschreiben.

Du könntest dir für deine Zwecke also eine CSS-Datei zurechtlegen, die allen vorkommenden Element- und Klassenstilen eine andere Schriftart zuweist. Die brauchst du dann künftig nur noch beim Export anwählen.
Eine CSS-Datei ist übrigens ein einfaches Textdokument, das man mit dem Editor erstellen kann und dem man die Endung .css verpasst.

Der Inhalt kann in etwa so aussehen:

Code: Alles auswählen

.Normal { font-family:serif; }
h1 { font-family:serif; }
h2 { font-family:serif; }
h3 { font-family:serif; }

In diesem Beispiel wird den drei Elementstilen für die Überschriftenebenen (h1, h2 und h3) sowie dem Klassenstil für die Absatzvorlage Normal (.Normal) jeweils die generische Schriftart serif zugewiesen. Der Reader nimmt dann einfach die nächstbeste Serifen-Schrift, die er kennt. Die von TextMaker ursprünglich zugewiesene Schriftart wird ignoriert.

Du müsstest halt eine CSS aus einem von dir exportierten EPUB anschauen und dort auslesen, welche Element-und Klassenstile verwendet werden. Wenn du immer mit denselben Formatvorlagen arbeitest, werden auch die Stile im CSS immer gleich heißen. (Elementstile wie h1, h2 etc. verwendet TextMaker praktisch nur für die Überschriften. Alles Andere wird über Klassenstile formatiert, die man am einleitenden Punkt erkennt. TextMaker erzeugt ihre Namen aus den Namen der Formatvorlagen, ggfs. unter Weglassung der Umlaute.)
Für alle Stile, die in deinen EPUBs vorkommen, müsstest du so einen Eintrag nach obigem Muster erzeugen (also der Name des Stils, danach die Attribute inkl. abschließendem Semikolon in geschweiften Klammern.
Klingt jetzt erst mal kompliziert, aber es wäre ja nur eine einmalige Arbeit.

[Torsten65]

Vielen Dank für deine ergänzenden Ausführungen. Ich bin bis dato ziemlich unbeleckt in diesen Dingen (lediglich Basics in HTML), aber ich sehe, dass sich die Arbeit lohnen könnte. Ich nehme deine CSS als Basis und frickle mal ein bisschen herum.

Nebenbei: Calibre kann ebenfalls E-Books bearbeiten und viele Schreibende erzeugen ihre ePubs damit. Ich nutze Calibre intensiv, aber eher zur Verwaltung meiner (digitalen) Bibliothek.

Hast du Erfahrungen mit Calibre in puncto ePub-Erzeugung/-Bearbeitung?

[beiti]

Hast du Erfahrungen mit Calibre in puncto ePub-Erzeugung/-Bearbeitung?

Ein bisschen vor einigen Jahren, aber Experte für Calibre bin ich nicht. Mein Wissensstand ist, dass Calibre teils recht eigenwillige EPUBs und MOBIs erzeugt, die Amazon dann gar nicht akzeptiert. Ausführlich getestet habe ich das aber nicht. Da gibt es ja endlose Einstellmöglichkeiten, so dass man bei entsprechender Einarbeitung sicher auch ans Ziel kommt.

Amazon ist natürlich auch sehr eigenwilllig. Mittlerweile empfehlen sie, für KDP die EPUBs direkt hochzuladen und nicht mehr vorher in MOBI zu konvertieren. Amazon erstellt daraus dann drei MOBI-Varianten, von denen den Käufern je nach Firmware-Stand ihres Kindle-Readers die Bestmögliche ausgeliefert wird.
Wenn man jedoch Dateien selber auf einen Kindle kopiert, muss man sie vorher mittels KindleGen in MOBI konvertieren. Und dabei erzeugt KindleGen bisher nur die zwei älteren Format-Varianten, die z. B. noch keine automatische Silbentrennung unterstützen (was gerade für deutschsprachige Texte im Blocksatz teils hässlich aussieht). Amazon will offenbar nicht, dass man das bestmögliche Layout ohne Beteiligung des Shops bekommen kann. Vielleicht haben sie Angst, dass dann zu viele Kindle-E-Books über andere Shops verkauft würden.
Wie das Kindle-Buch später auf aktuellen Readern aussieht, kann man also nicht vorab auf dem eigenen Kindle testen. Man kann es lediglich mittels "Kindle Previewer" am PC simulieren.

[Torsten65]

Hammer, es funktioniert!!

Ich habe die CSS um die Absatzvorlagen ergänzt, die in der von TM erzeugten CSS vorhanden waren (auch wenn ich nicht alle nutze.

Code: Alles auswählen

.Normal { font-family:serif; }
h1 { font-family:serif; }
h2 { font-family:serif; }
h3 { font-family:serif; }
.Fu_zeile { font-family:serif; }
.Kommentartext { font-family:serif; }
.Kopfzeile { font-family:serif; }
.Textk_rper { font-family:serif; }
.Textk_rper_Zeileneinzug { font-family:serif; }
.N_chsteSzene { font-family:serif; }
.Textk_rper2 { font-family:serif; }
.Textk_rper_Einzug2 { font-family:serif; }
.Kommentarthema { font-family:serif; }

Das Ergebnis ist perfekt. Ich habe es mir im Calibre-Viewer angesehen und von Calibre aus auf meinen neuen Paperwhite geschickt.

Komisch nur, dass auf dem Paperwhite Blocksatz dargestellt wird, während die Ausgangsdatei in TM linksbündig ist.

Nochmals vielen Dank für deine wertvolle Hilfe. Das hat mir wirklich weitergeholfen.

[Torsten65]

Amazon ist natürlich auch sehr eigenwilllig. Mittlerweile empfehlen sie, für KDP die EPUBs direkt hochzuladen und nicht mehr vorher in MOBI zu konvertieren. Amazon erstellt daraus dann drei MOBI-Varianten, von denen den Käufern je nach Firmware-Stand ihres Kindle-Readers die Bestmögliche ausgeliefert wird.

Das habe ich auch schon gehört, daher rät Julian Smart von Jutoh mittlerweile auch zu ePub für Amazon.

Wenn man jedoch Dateien selber auf einen Kindle kopiert, muss man sie vorher mittels KindleGen in MOBI konvertieren. Und dabei erzeugt KindleGen bisher nur die zwei älteren Format-Varianten, die z. B. noch keine automatische Silbentrennung unterstützen (was gerade für deutschsprachige Texte im Blocksatz teils hässlich aussieht). Amazon will offenbar nicht, dass man das bestmögliche Layout ohne Beteiligung des Shops bekommen kann. Vielleicht haben sie Angst, dass dann zu viele Kindle-E-Books über andere Shops verkauft würden.
Wie das Kindle-Buch später auf aktuellen Readern aussieht, kann man also nicht vorab auf dem eigenen Kindle testen. Man kann es lediglich mittels "Kindle Previewer" am PC simulieren.

Das mache ich tatsächlich direkt aus Calibre heraus. Calibre weiß, an welches Gerät ich sende und kovertiert direkt in MOBI. Das landet dann auf meinem Paperwhite über meine Kindle-Bibliothek bei Amazon. Dort verbleibt es, bis ich es aus der Bibliothek lösche. Das Ergebnis ist sehr gut - bis auf die fehlende Silbentrennung (daher ist Blocksatz hier unschön, was ich an sich präferiere).