Was kann ein eBook nicht?

Die meisten eBook-Projekte scheitern in Verlagen daran, dass Hersteller, die in InDesign, QuarkXPress oder LaTeX denken, ihre Vorstellungen einfach nicht als eBook umgesetzt bekommen. Einerseits liegt das daran, dass Verlage – und da merkwürdigerweise vor allem die Hersteller – keine Vorstellung von eBooks haben. Wie ich schon vorletzte Woche in dem Artikel „Was kann ein eBook überhaupt?“ schrieb, sind eBooks nun mal keine Bücher! Aber ein weiterer Grund ist, dass eBooks wirklich grundlegende Elemente der Typographie und des Buchsatzes nicht beherrschen, was ein Armustzeugnis für eReader-Hersteller und eBook-Shops ist!

Über eine Woche saß ich nun an diesem Artikel und trug all die Dinge zusammen, die ein eBook nicht kann. Die Liste ist unendlich lang! Angefangen mit Dingen, die ein eBook wirklich gar nicht beherrscht, wie Silbentrennung, über Dinge, die sehr stark vom Anzeigegerät abhängig sind, wie z.B. Bildumläufe, bis hin zu Dingen, die möglich sind, aber komisch herumzicken, wie z.B. Fußnoten. Nach diesen umfassenden Fehlansätzen werde ich hier nicht auf die technischen Feinheiten all der unmöglichen oder problematischen Dinge eingehen, sondern auf die Hauptgruppen, die das Unvermögen des eBooks bedingen.

Eingeschränkter Zeichensatz

eBooks können nicht jede Schriftart und damit nicht jedes potenziell mögliche Zeichen darstellen. Das ist ein Problem, das für Laien schwer zu verstehen ist, für Hersteller ein Ding der Unmöglichkeit und für Techniker ein unverständliches Armutszeugnis. Ich versuche, das Problem kurz zu umschreiben. Es gibt einmal einen Code – ideal für alle europäischen Sprachen wäre UTF-8. Dieser Code macht es möglich, zwei Zeichen eindeutig voneinander zu unterscheiden, also sicherzustellen, dass ein a nicht mit einem b verwechselt wird. Auf den Code wird nun eine Schriftart montiert, die dafür sorgt, dass ein a auch wie ein a aussieht. Hier gibt es die erste Diskrepanz: Der Code enthält 1.114.112 Zeichen, eine durchschnittliche Schriftart enthält nur einen Bruchteil davon. Codes, für die kein Schriftzeichen vorhanden ist, werden als Fragezeichen oder Käsekästchen dargestellt. Der Normalnutzer kennt das Phänomen aus dem Textverarbeitungsprogramm, wenn er eine für das Englische optimierte Schriftart verwendet, die keine Umlaute kennt. eReader haben im Hintergrund zwar oft einen UTF-8-Codesatz, aber nur sehr selten dafür geeignete Schriftarten. Der Kindle kommt in seiner Standardschrift mit den meisten Zeichen zurecht, kennt aber z.B. keine verkürzten Leerzeichen. Beim Sony werden nur Sonderzeichen aus dem Deutschen und Französischen unterstützt, griechische Zeichen oder Sonderzeichen osteuropäischer Sprachen werden nicht dargestellt.

Dadurch  in der Regel nicht möglich: viele Fachtexte, fremdsprachige Zitate, korrekte Schreibung ausländischer Namen, typographische Feinheiten wie Achtelgeviert in Abkürzungen, mathematische Formeln etc.

Unausgereifte HTML-Engine

Jedes eBook enthält neben dem sichtbaren Inhalt Steuerungsbefehle,  die dafür sorgen, dass Text kursiv oder fett ist, dass Absätze beginnen und enden etc. Das läuft über die Auszeichnungssprache HTML bzw. XHTML. Diese Steuerungsbefehle tun von sich aus nichts, sie müssen von eReadern (also der Software, die man sich selbst installiert bzw. die auf Lesegeräten installiert ist) interpretiert werden. Dazu wird eine HTML-Engine benutzt. Für Browser – also die Darstellung von Internetseiten – haben sich drei Engines durchgesetzt: Gecko von Firefox, Trident/Tasman vom InternetExplorer und das wohl mächtigste WebKit, das von allen anderen üblichen Browsern benutzt wird. Dass Google Chrome innerhalb von einem Jahr die Verbreitung von Firefox eingeholt hat, verdankt es eben dieser hochentwickelten Engine. Im Browserbereich dreht sich alles um diese HTML-Interpretation und es sind Tausende von Entwicklern, die daran sitzen. Daher ist es unverständlich, wieso eReader-Hersteller – egal ob Software-Entwickler oder Hardware-Hersteller, die ja ebenfalls mit nichts anderem als HTML arbeiten – nicht auch auf das unter freier Lizenz stehende WebKit zurückgreifen. Doch bis auf wenige Ausnahmen kochen die eReader-Leute ihr eigenes Süppchen, was entsprechend unausgereift ist. Ergebnis ist, dass viele Befehle wie z.B. <nobr></nobr>, ein Tag, der den Zeilenumbruch in seinem Inhalt verhindert, nicht unterstützt wird. Natürlich kann man nicht verallgemeinern: Der Sony beherrscht <nobr>, obwohl es nicht ePUB-konform ist. Der Kindle bricht die Darstellung ab, und in den iBook-Store von Apple kann man die Datei gar nicht erst hochladen, wenn sie <nobr>s enthält. Was uns zum nächsten Punkt bringt.

Dadurch in der Regel nicht möglich: Nicht umbrechende Wortgruppen, Textfluss um Bilder, Rahmen und Hintergrundfarben für Textblöcke, durchgestrichener oder geschwärzter Text, Kombination verschiedener Schriftarten, etc.

Fehlende Standards

Jetzt stutzt vielleicht der eine oder andere. Es gibt doch ePUB, und das ist standardisiert. Ja, ich meine auch gar nicht die Formate, in denen ein eBook vorliegen kann. Ich meine das, was ein eReader aus dem Format macht! Z.B. unterstützt das ePUB die CSS-Angabe „font-family“. Mit dieser Angabe kann man bestimmen, ob eine serifenlose oder eine Serifenschrift verwendet werden soll. Da die Reader-Hersteller aber möglichst viele Optionen in ihren Einstellungen anbieten wollen, überschreiben sie diese Angabe. Was kein Problem wäre, wenn dadurch nicht beide Schriftschnitte zusammengeschmissen würden. Es geht also eine vom Autor/Verlag beabsichtigte Information verloren. Eine aufwändigere Gestaltung eines eBooks ist nicht möglich, weil Angaben, die im Reader A gut aussehen im Reader B nicht nur schlecht aussehen, sondern das Lesen verhindernde Darstellungsfehler verursachen können. Das Schlimmste, was eReader machen, ist der aufgezwungene Textfluss. Es ist für Bücher zwar nicht üblich, aber eBooks sehen meistens in linksbündigem Satz besser aus als im Blocksatz. Der Grund dafür ist, dass eReader die Silbentrennung nicht beherrschen und dadurch im Blocksatz gewaltige Lücken im Text entstehen. Die Silbentrennung an sich ist auch wieder so eine Sache. Es gibt in UTF-8 das weiche Trennzeichen, das Trennstellen in Worten angibt, die erst dann angezeigt werden, wenn das Wort am Zeilenende erscheint. Inzwischen kann das jeder beliebige Browser, aber kein einziger* kaum ein eReader richtig! Darüber hinaus verwenden die Reader für ihre gestümperte Silbentrennung irgendwelche pseodo-internationalen Silben-Pettern, die die unmöglichsten Trennungen erzeugen.

Dadurch in der Regel nicht möglich: einheitliche Gestaltung, korrekte bzw. verlagsgesteuerte Silbentrennung, svg-Grafiken, etc.

Zusammengefasst

Die meisten eBook-Leser nehmen eBooks nicht für voll, weil sie unglaublich fehlerbehaftet sind und bereits von der Gestaltung her mit einem gedruckten Buch nicht mithalten können. Das liegt jedoch nicht an den Büchern selbst. Die meisten Verlage machen sich unglaublich viel Mühe mit ihren Werken. Es liegt einzig und allein daran, dass die eReader-Hersteller bzw. -entwickler falsche Prioritäten setzen. Statt eine solide Silbentrennung zu entwickeln, basteln sie an effekthascherischen Umblätteranimationen. Damit eBooks tatsächlich einen Absatz finden, müssen Verlage ihre Ansprüche bei den eReadern durchdrücken. Immerhin tun sie das bei den Druckereien auch.

Im nächsten Teil dieser Reihe werde ich mich der Frage stellen: „Was sollten eBooks können?“ Bis dahin!

 

* Ich muss mich hier korrigieren, beziehungsweise präzisieren:
1. &shy; wird von dem ePUB-Validator, den viele Shops (z.B. iTunes) nutzen, um defekte Dateien direkt beim Upload auszusortieren, als nicht zulässig erkannt, was die Nutzung bei umfassender Distribution unmöglich macht. Jedoch ist es möglich, die nummerische Angabe zu nutzen: &#173;
2. Weiche Trennzeichen werden von Software-Readern, die auf Smartphones oder Tablets laufen, besser bedient als von eInk-Geräten. Das liegt daran, dass diese oft auf der ohnehin vorhandenen WebKit-Engine aufsetzen. iBook ignoriert die Trennzeichen, weil er eine eigene, durchaus gut funktionierende Trennung beherrscht. Bluefire hat keine eigene Worttrennung, nimmt die weiche Trennung aber korrekt an. Über Kobo reden wir mal nicht, das Ding ist echt mies. Kindle beweist mal wieder, das Mobi ePUB meilenweit hinterherhinkt. Beim Umwandeln werden die Trennzeichen nämlich in Ermangelung einer Entsprechung entfernt – logischerweise also keine Trennung, weder auf dem eInk noch in der App. (Diese hat übrigens eine grausige Worttrennung.) Der Sony trennt, zeigt aber kein Trennungszeichen an, was eher darauf hinweist, dass das Zeichen zwar als Trennungszeichen, aber eben nicht als weicher Trenner erkannt wird, sondern als eine Art breitenloses Leerzeichen interpretiert wird.

10 Comments on Was kann ein eBook nicht?

  1. Wie kommst du darauf, dass der Sony keine Anker unterstützen würde?
    Bereits der alte PRS-505 konnte Anker ich kann mir nicht vorstellen dass es da Rückschritte gab. Die Verlinkungen zu einem bestimmten Textteil ist sowohl aus dem Text heraus wie auch aus dem toc aus möglich. Das einzige Detail das bedacht werden muss ist,
    dass ePUB, xhtml konform, nicht zum name verlinkt, sondern zur id.

    Was allerdings nichts daran ändert, dass sehr viele ePUBs einfach keine Anker enthalten, weil sie nicht entsprechend aufgearbeitet wurden. Was ein Armutszeugnis für die Verlage ist.

  2. Mich wundert bei dem Sony-Reader eher, dass er zum Beispiel keine Anker unterstützt. Man müsste also für jedes kleine Unterkapitel(i.e. 4.2.2) eine eigene xhtml-Seite erstellen(was dann beim Nachbearbeiten echt nervt).
    Man muss bei der Kapitelauswahl immer das unterste Kapitel anwählen: Ich will Kapitel 4, kann aber nur 4.1.1.1 auswählen(natürlich ein bisschen übertrieben).
    Manchmal ist es auch so, dass der Seitenumsprung nicht gelingt: Ich bin auf Seite 98 blättere um und bin wieder auf Seite 48.
    Dass dann Zeilenumbrüche da noch nicht gehen finde ich nicht so tragisch 😉

  3. Ich glaube nicht, dass der automatisierte weiche Umbruch ein Problem ist. Zum Biespiel haben Textverarbeitungsprogramme diese Silebntrennung ja alle integriert (holen sie sich halt aus nem Wörterbuch). Irgendwo habe ich mal gelesen, dass es die Ressourcen von Readern stark beansprucht, wenn weiche Umbrüche „berechnet“ werden müssen. Ich bin der Behauptung aber nicht nachgegangen.

    Auch im Web kein Problem. Unter http://www.goethe-hamburg.de haben wir ein (sehr) kleines Joomla-Plugin, dass die Silbentrennung automatisch erledigt. Nach Angabe des Plugins nicht perfekt, allerdings ist mir nie ein Fehler aufgefallen. Einzigst, aber das ist ein Browserproblem, das Copy & Paste sieht übel aus (weil alle Bindestriche mitgenommen werden). Das Problem haben, soweit ich das getestet habe, ale Browser. Nicht fragen, warum wir es trotzdem machen 😉

    Oh, Sony hat den T1 gerade neu rauß. Hat mein Vater, sehr sehr leicht und noch ne Nummer besser als mein 650er (den ich im Vergleich zu reinen Ebook-Readern für den meisten sehr überlegen erachte). Allerdings wird der PRS+-Patch noch nicht unterstützt, den ich aber brauche, um u.a. (meine) Ordnung in meine Sammlung zu bringen – noch so eine Sache, beider die Hersteller schnarchen.

  4. Schande, Stimmt! Der Sony hat den ja genommen nur nicht richtig angezeigt! Mist, es wird Zeit, dass ich wieder einen Sony bekomme, ich liebe die Geräte! Wirklich die beste Wahl wenn es um gestaltungsgetreue Anzeige geht. Dass keine eBooks mit &shy; ausgezeichnet werden liegt daran, dass andere Geräte dies als Fehler interpretieren und als ? darstellen. Außerdem ist es etwas trickreich einen Text automatisch und grammatisch korrekt mit Trennstellen zu versehen und da sich Hersteller von eBooks heutzutage noch mit viel banaleren Problemen rumschlagen … Aber da hast du mich auf eine Schwachstelle aufmerksam gemacht der ich gleich mal nachgehen muss.

  5. Guter Artikel.

    Es stimmt allerdings nicht 100%, dass kein Ebook-Reader den weichen Umbruch beherrscht (&shy). Mein Sony PRS-650 macht den, vergisst nur dummerweise beim Umbruch einen Bindestrich einzufügen. Man muss allerdings auch sagen, dass ich noch nie ein kommerzielles/freies Ebook hatte, wo die weichen Umbrüche gesetzt wurden…

    Bisher hatte ich keine großen Probleme mit Schriftsätzen, aber ggf. könnte man beim Sony entsprechende Schriftarten hinzufügen. Entweder indem man das Ebook bearbeitet (Styles) oder über den (inoffiziellen) den PRS+-Patch.

  6. Keineswegs, der Umgang der Reader mit den Inhalten bezieht sich auf die aktuell verbreiteten Geräte und so wie sich die Entwicklung bisher dargestellt hat, glaube ich nicht, dass die neue Generation vom November sehr viele Änderungen geschweige den Besserungen erbracht hat. Und ePUB3 ist zwar ein guter ansatz, aber die Frage ist, wie lange es dauert, bist die Geräte dieses Format entsprechend interpretieren. Das ist nicht wie bei Browsern, bei denen alle zwei Monate eine neue Version rauskommt, weil Chrome den Markt aufgewirbelt hat.

  7. Das Problem ist, dass du dann ein PDF hast! Was willst du bei digitaler Distribution mit einem PDF? Damit gibst du doch alle Vorteile eines eBooks auf. Lies dazu mal meinen Artikel http://www.typearea.de/2011/04/pdfs-als-ebook/ . Einen 800 Seiten Roman möchte ich nicht auf einem selbstleuchtenden Monitor lesen und auch nicht unbedingt über den haushaltsüblichen Tintenstrahldrucker ausdrucken, abgesehen von den Kosten macht sich eine Blättersammlung im Bett eher schlecht. Der Artikel hier betrifft daher richtige eBooks, als ePUB, mobiPocket oder HTML.

  8. Vieles (wohl das meiste) stimmt in diesem Posting. Was allerdings zu Widerspruch anregt, ist die Tatsache, dass den eBook-Readern angelastet wird, wenn sie nicht-standarkonforme Dinge wie nicht „verstehen“, ignorieren oder gar als fatal behandeln. Die Zeiten solcher laxen Behandlung von Content sollten der Vergangenheit angehören.
    Zur Silbentrennung belibt zu sagen: mit EPUB3 zieht JavaScript in eBooks ein und damit prophezeie ich auch Silbentrennung!

  9. Guido Busch // 4. Dezember 2011 um 16:27 //

    Wo ist das Problem? Man nehme LaTeX, eine geeignete Distribution (etwa MikTeX) und erstelle sich die wunderbarsten Bücher SELBST (als PDF, also STANDARD) — inkl. math. Formelsatz (perfekt!) oder sogar Chemie, Musik, Poesie… DAS REICHT DOCH. Als Reader brauch ich Foxit oder Acrobat, als „Abspielgerät“ einen PC, Laptop oder Netbook fertig. Verlage BRAUCHT man NICHT. Wenn etwas wirklich gut ist, so verbreitet es sich inzwischen — Social Networks Rapidshare und Blog-Netzen sei Dank — von selbst. Preis auf Anfrage oder „Donations“. Ausdruck in höchster Qualität.

  10. Roman Blöth // 4. Dezember 2011 um 14:54 //

    Ein wichtiger Faktor betrifft Fachliteratur, wie ich bemerkt habe: Es fehlt die räumliche Orientierung, die offenbar beim Verinnerlichen des Gelesenen hilft. Wenn ich mich daran erinnere, in welchem Teil eines Fachbuches ich eine Information gelesen habe, so hilft mir dies beim auswendig lernen. Diese räumliche Orientierung fehlt bei einem eBook leider völlig.
    Nicht zu vernachlässigen sind jedoch auch umgekehrt die Dinge, die ein gedrucktes Buch nicht kann…

2 Trackbacks & Pingbacks

  1. Sehr netter Artikel über eBooks un… « Google+ « Abseits.cibis.de « cibis.de
  2. type:area» Blogarchiv » ePUB3 – Eine erste Wahrnehmung

Leave a comment

Deine E-Mail-Adresse wird nicht veröffentlicht.


*