Pünktlich zum Start des neues Jahres hat Amazon ein Update seiner Kindle Publishing Guidelines veröffentlicht, die nun in der Version 2017.1 vorliegen. Das umfangreiche Papier mit allen technischen Vorgaben für das Publizieren ist die zentrale Informationsquelle für jeden, der eBooks erstellen und über Amazon vertreiben möchte – vom Konzern-Verlag bis zum Selfpublisher. Wichtig vor allem: Hält man sich nicht an die hier niedergelegten Richtlinien, sind Reklamationen von Amazon vorprogrammiert, die im Zweifel bis zur Sperrung eines Titels im Shop gehen können. Was hat sich mit dem aktuellen Update getan?

Die Version 2017.1 findet sich hier zum Download, die umfangreiche Update-Übersicht sollte jedoch nicht verunsichern: viele der Änderungen sind eher redaktionelle Updates, zusätzliche Beispiele oder betreffen nur sehr selten verwendete Publikationsformen wie eBooks in asiatischen Sprachen, Fixed-Layout-eBooks für Amazon, Wörterbücher oder Kindle-Edition-Titel. Die spannendsten Änderungen aus meiner Sicht:

Erzwungene Standard-Werte für zentrale Layout-Eigenschaften

Neben den immer schon recht elaborierten Richtlinien zu Content-Formatierung und CSS-Aufbau in Kapitel 9.3 („Text Guidelines“) stößt man beim Lesen über folgenden neuen Absatz, der in eine neue Richtung zeigt:

An diesen Vorgaben ist sowohl der Inhalt interessant, wie auch der Prozess ihrer Umsetzung: Die Vorgaben werden nicht wie an vielen anderen Stellen erst durch das Qualitätssicherungs-Team bei Amazon geprüft, auch findet der jüngst von mir beschriebene Mechanismus der Default Stylesheets hier keine Anwendung. Stattdessen lässt die Formulierung „applied during the upload process“ darauf schließen, dass Amazon beim Import in Ihre Umgebung tatsächlich hart in den Quellcode eingreift und HTML/CSS-Deklarationen anpasst. Das Überschreiben von Layout-Deklarationen durch Default Stylesheets und User Themes ist auch in anderen Reader-Umgebungen ja durchaus gängige Praxis –  aber die Manipulation von Dateiinhalten ist doch noch einmal ein etwas rabiaterer Eingriff in den eBook-Titel.

Inhaltlich aber ist gegen die hier genannten Anpassungen wenig einzuwenden:

• Die Schriftgröße für den Fließtext („majority of the content“) auf 1em zu normalisieren, ist grundsätzlich ausgesprochen sinnvoll. Für den Body-Text immer genau 1em Größe zu verwenden, gehört ohnehin zum Best Practise für EPUB-CSS, der für quasi alle Anwendungsfälle gelten sollte. Wer hier nicht sicher ist, sollte  einen Blick ins eigene CSS werfen, falls Überschriften im Verhältnis zum Fließtext plötzlich unerwartet groß oder klein erscheinen sollten.
• Die Schriftart-Definition für den Fließtext wird von einzelnen Elementen entfernt und stattdessen dem body-Element zugeordnet. Auch das ist ausgesprochen sinnvoll und sollte in von Menschen geschriebenen CSS-Dateien für EPUB eigentlich immer so definiert sein. Nur, wenn viel mit verschiedenen Font-Definitionen gearbeitet wird und das body-Element keine Default-Definition für font-family enthält, kann es durch den Eingriff eventuell zu merkwürdigen Nebeneffekten bei der Vererbung der Definition kommen.
• Erzwungene Schriftfarben für den Fließtext werden komplett entfernt. Das ist sicher der radikalste der drei Eingriffe: er zielt hauptsächlich darauf, dass der Text bei Umschaltung auf ein Nacht-Theme (weiße Schrift auf schwarzem Grund) noch sichtbar bleibt – und adressiert die Unsitte einiger Tools zur EPUB-Generierung (ja, wir schauen dich böse an, InDesign!), jedem Textelement explizit die Schriftfarbe Schwarz zuzuweisen.

Zusammengefasst: Probleme für die eBook-Formatierung sind durch die Eingriffe eigentlich nur zu erwarten, wenn in CSS-Dateien Layout-Definitionen auf eine Weise vorgenommen werden, die ohnehin dem Best Practise widerspricht – oder wenn man sich blind auf die CSS-Generierung durch InDesign verlässt (was auch aus vielen anderen Gründen eine eher schlechte Idee ist). Oder, wie es Jiminy Panoz in seinem Artikel dazu ausgedrückt hat:

…those fixes aren’t what you could call overrides, they’re alterations produced on an industrial scale in order to provide users with a minimum viable UX.

Verbindliche Qualitäts-Standards für eingebundene Bilder

Ein weiteres Kapitel mit neuen Vorgaben betrifft Bilder, die in die eBook-Dateien eingebunden werden. Hier werden erstmals verbindliche technische Daten vorgegeben, die für optimale Qualität der Bilddarstellung sorgen sollen:

Hört sich zunächst einmal nach einer Einschränkung an, ist aber eigentlich eher ein Vorteil: Wo andere Plattformen wie Apple oder Kobo überhaupt nur Maximalgrößen und Beschränkungen angeben, aber keinerlei Input für eine optimale Darstellung geben, werden hier verbindliche Daten genannt – damit kann man arbeiten als eBook-Produktioner. Als Hilfestellung wird noch folgende Tabelle mit Rechengrößen mitgegeben:

Übersicht über optimale Dateigrößen und Auflösungen für eingebundene Bilder (Quelle/Copyright: Amazon)

Test-Checkliste für Kindle eBooks

Obwohl der Abschnitt wohl schon länger existiert, ist er mir erst beim Durchlesen von Version 2017.1 so richtig aufgefallen: Unter Kapitel 8.1 („Testing Kindle Books“) gibt es eine sehr präzise Beschreibung für den Test- und QS-Prozess für Kindle-eBooks – sollte jemand für seine Amazon-Titel noch keine systematische Qualitätssicherung betreiben und auf der Suche nach einer guten Checkliste sein: das wäre eine prima Quelle dafür!

Fazit

Entgegen meiner ersten Erwartungen beim Überfliegen der Änderungsübersicht handelt es sich eher um kleinere, aber im Detail durchaus entscheidende Änderungen, die Amazon hier im Prozess vornimmt. Die Kindle Publishing Guides sollten ohnehin zur Pflichtlektüre für jeden eBook-Produktioner gehören – genauso wie die Vorgaben von Apple und von Kobo, die ähnlich ausführlich ihre technischen Richtlinien dokumentieren. Nur für den Tolino fehlen bisher schmerzlich ähnliche Publishing Guides, wie sie die großen internationalen Anbieter regelmäßig veröffentlichen. Oder, wie es Martin Kraetke neulich auf Twitter ausgedrückt hat:

Dateibegrenzungen bei @Tolino_de sind so wie Obergrenzen bei der CSU: Es gibt sie, sie sind unverhandelbar, aber man kennt ihre Höhe nicht.

— so-called M. Kraetke (@mkraetke) November 8, 2016

Aber vielleicht ändert sich das ja auch bald – jetzt, wo das technische Backend von Tolino in die Hände von Kobo übergeht? Denn Kobo war mit seiner auf Github veröffentlichten technischen Dokumentation immer schon vorbildlich, und für eine so zentrale Plattform wie Tolino wäre eine ähnliche Dokumentation ein schönes Signal.