Dein ePub ist in Ordnung

 (andreklein.net)
2 Punkte von GN⁺ 1 일 전 | 1 Kommentare | Auf WhatsApp teilen
  • Selbst DRM-freie EPUBs, die die Validierung bestehen, können auf Kobo als „corrupted“ behandelt werden; das Problem liegt nicht an einem Dateiformatfehler, sondern an der Kompatibilität der Rendering-Engine
  • epubcheck ist das De-facto-Standardwerkzeug zur Prüfung von EPUB-Struktur und Regelkonformität, erkennt aber keine Probleme mit veralteten CSS-Parsern bestimmter Renderer
  • Kobo verwendet RMSDK, Adobes proprietäre Rendering-Engine für E-Books; sie wurde auf Basis von EPUB2 entwickelt und später nur leicht für EPUB3 aktualisiert, aber nicht modernisiert
  • Ursache des Problems war die eine Zeile max-width: min(150px, 30vw);; dieser gültige CSS level 4-Code wird von RMSDK nicht unterstützt und führt in Adobe Digital Editions und auf Kobo dazu, dass das Buch nicht geladen werden kann
  • Um die Kobo-Kompatibilität zu prüfen, reicht epubcheck allein nicht aus; zusätzlich muss tatsächlich in Adobe Digital Editions getestet werden, ob sich das Buch öffnen lässt

Das Problem begann mit einem EPUB, das epubcheck bestand

  • Adobe-Werkzeuge werden oft genutzt, weil die Creative Suite Industriestandard ist oder es an Alternativen mangelt; die Grundkritik dieses Textes entspringt daher Frust über Adobe-Software
  • Das neue Buch wurde als DRM-freie EPUB-Datei verteilt, die Leser direkt erhalten, und bestand vor der Veröffentlichung nach mehreren Schritten die Prüfung mit epubcheck
  • epubcheck ist das De-facto-Standardwerkzeug zur Prüfung sauber aufgebauter E-Books; bestanden wird nur, wenn das manifest alle Bestandteile und Bilder des Buchs lückenlos abbildet
  • Schon wenn die Reihenfolge von HTML-Elementen nicht stimmt oder man nur leicht von den Regeln des International Digital Publishing Forum abweicht, schlägt die Validierung fehl
  • Ein EPUB zu erzeugen, das epubcheck zu 100 % besteht, ist für Einsteiger nicht einfach, für Publishing-Fachleute erfüllt das Tool aber eher die Rolle eines Typlinters oder einer formalen Testsuite
  • Die naheliegende Erwartung ist, dass ein Buch, das epubcheck besteht, in jedem EPUB-kompatiblen Reader oder jeder App funktionieren sollte

Nur auf Kobo erscheint „corrupted“

  • Das neue Buch bestand epubcheck ruleset 3.3, doch ein Leser meldete die Anzeige „corrupted“
  • Um mögliche Abwärtskompatibilität zu prüfen, wurde auch eine EPUB2-Version bereitgestellt, aber selbst diese Datei verursachte trotz vollständiger Regelkonformität dasselbe Problem
  • Der betreffende Leser berichtete, dass sich das Buch auf mehreren Generationen von Kobo-Geräten nicht öffnen ließ
  • Dasselbe EPUB funktionierte in anderen Umgebungen wie Amazon Kindle, Apple Books und Thorium problemlos
  • Die Untersuchung ergab, dass Kobo Adobes proprietäre E-Book-Rendering-Engine RMSDK verwendet

Die Ursache ließ sich auf RMSDK und Adobe Digital Editions eingrenzen

  • RMSDK ist die Kern-Engine von Adobe Digital Editions und wird auch auf mehreren Kobo-Geräten sowie älteren Sony- und Nook-Geräten verwendet
  • Die Engine wurde um 2010 herum mit Fokus auf EPUB2 entwickelt und später nur leicht für EPUB3 aktualisiert, aber nicht modernisiert
  • Dass RMSDK im Einsatz ist, löste den Widerspruch zwischen epubcheck und dem Kobo-Ergebnis nicht sofort, gab dem Debugging aber eine Richtung
  • Als das Buch in Adobe Digital Editions geladen wurde, schlug der Ladevorgang wie erwartet fehl, ohne dass eine Fehlermeldung erschien
  • Beim erneuten Versuch erschien die Meldung, das Buch sei bereits hinzugefügt worden und könne nicht importiert werden, während der Bildschirm weiß blieb
  • Danach wurden zahlreiche Varianten der Datei zum Testen erstellt, und alle Varianten bestanden weiterhin epubcheck
    • Es wurden eine Umstrukturierung der Ordner, das Entfernen von Metadaten, das Entfernen des Sprachattributs, das Erzeugen neuer UUIDs, das Abflachen der Verzeichnisstruktur, das Ändern der Dateiendungen, das Neuerstellen des ZIPs und Änderungen am manifest ausprobiert
    • Trotz all dieser Versuche scheiterte das Laden in Adobe Digital Editions weiterhin

Die tatsächliche Ursache: eine gültige CSS-Zeile

  • Nachdem das Stylesheet deaktiviert wurde, lud das Buch plötzlich, wodurch sich der Problemraum auf das Stylesheet eingrenzen ließ
  • Nach weiteren Varianten, in denen jeweils nur Teile des Stylesheets angewendet wurden, ließ sich die problematische Zeile identifizieren
.copyright img {
    max-width: min(150px, 30vw);
}
  • Dieser Code ist vollständig gültiger CSS level 4-Code, wird jedoch von RMSDK nicht unterstützt
  • Nachdem der Code auf die ältere Schreibweise max-width: 150px; geändert wurde, ließ sich das Buch in Adobe Digital Editions normal öffnen
  • Der CSS-Parser von RMSDK ist ungefähr auf dem Stand von 2013 stehen geblieben und unterstützt weder Flexbox noch Grid, mathematische Funktionen oder benutzerdefinierte Eigenschaften
  • Trifft er auf CSS, das er nicht versteht, stürzt er nicht mit Fallback oder klarer Fehlermeldung ab, sondern stillschweigend
  • epubcheck führt zwar grundlegende CSS-Prüfungen durch, kann CSS aber grundsätzlich nicht gegen einen bestimmten Renderer validieren, der selbst fundamental fehlerhaft ist

Die Lehre für die Prüfung der Kobo-Kompatibilität

  • Selbst 2026 kann Kobo durch die weitere Nutzung von RMSDK als Basis des Buch-Renderings dazu führen, dass eine einzige gültige CSS-Zeile ein ansonsten gültiges EPUB in eine „corrupted file“ verwandelt
  • In diesem Fall kann Kobo das gesamte Buch weder mit einer klaren Fehlermeldung noch mit einem Fallback öffnen
  • Um das Problem zu vermeiden, wurde eine neue Version veröffentlicht, damit Leser denselben Fehler nicht erneut erleben
  • In einer idealen Welt würde RMSDK seinen veralteten CSS-Stand hinter sich lassen oder zumindest eine Fehlerbehandlung bieten, doch aktuell besteht das Problem weiter
  • Um die Kobo-Kompatibilität zuverlässig sicherzustellen, reicht epubcheck allein nicht aus; es muss auch in Adobe Digital Editions tatsächlich geprüft werden, ob das Buch lädt
  • EPUB ist ein hervorragender offener Standard für E-Books, doch viele Implementierungen offenbaren grundlegende Mängel in einer Struktur, die Zugriffsbeschränkungen priorisiert

Verwandte Beiträge

1 Kommentare

 
GN⁺ 1 일 전
Hacker-News-Kommentare

  • Adobe war schon immer so. Sie haben den enormen Marktanteil von Flash verspielt, obwohl die Alternative schlicht gewesen wäre, ein paar Millionen Dollar für QA auszugeben, und am Ende alle Browserhersteller zu der Einsicht gebracht, dass „das Web ohne einen so unzuverlässigen Partner besser dran ist“.
    Ich habe damals ein paar Dinge mit Flash veröffentlicht, aber es war grauenhafte Software voller zufälliger Abstürze und Heisenbugs, bei der Änderungen in einem Bereich völlig irrelevante Funktionen in anderen Modulen kaputtmachten. Es kostete ungefähr 800 Dollar, Support gab es faktisch keinen, und obwohl ich mehrere Bugs mit minimierten Testfällen eingereicht habe, die leicht reproduzierbar waren, bekam ich nach dem nächsten Release nur die automatische Antwort, sie könnten behoben sein und ich solle eine Lizenz zum vollen Preis kaufen, um das zu überprüfen.

    • Ob man Steve Jobs nun mag oder nicht: Die Entscheidung, Flash auf dem iPhone nicht zu unterstützen und stattdessen auf HTML5 zu setzen, hat den Niedergang von Flash massiv beschleunigt.
    • Flash war besser, als es noch VideoWorks hieß ;)
      Es gab auch MusicWorks, und beide waren reine Mac-Produkte aus der allerfrühesten Zeit. Schon dass ich das erwähne, verrät mein Alter.
    • Als Publishing-Medium ist Flash bis heute unerreicht, wenn es um Einfachheit geht.
      Die übereinandergestapelte Struktur von JavaScript-Build-Systemen und die „Webstandards“ sind viel komplizierter, als einfach etwas zu zeichnen, ein bisschen einfache Logik zu schreiben und dann eine statische Datei zu erzeugen, die man überall einbetten oder zum Download anbieten kann. Sobald man eine Flash-Alternative nutzt, verbringt man viel zu viel Zeit mit Konfiguration, und diese „Standards“ sind auch noch schlechter.
      Ich mag Steve Jobs nicht, weil er Flash getötet hat, und ich mag Adobe nicht, weil sie eine der erstaunlichsten Technologien des Webs so miserabel verwaltet haben. Kinder, die heute aufwachsen, wissen nicht, wie magisch Flash war. Es war so etwas wie Roblox oder Minecraft für das Web.
      Websites sind noch immer schlechter als Flash in den frühen 2000ern. Jahrzehnte sind vergangen, und wir ahmen nur einen Teil seiner Möglichkeiten nach, ohne auch nur annähernd an seine Einfachheit heranzukommen.

  • Ich wollte ziemlich lange Software für E-Book-Reader entwickeln und habe am Ende versucht, notfalls einen Pakt mit dem Teufel einzugehen und auf RMSDK aufzusetzen.
    Aber es gibt überhaupt keinen Weg, Zugang zu bekommen. Ich meine nicht nur, dass die Lizenz für unabhängige Entwickler zu teuer ist, obwohl auch das sicher stimmt, sondern dass es buchstäblich niemanden gibt, mit dem man sprechen könnte. Auf E-Mails an die Adresse auf der Website kommt keinerlei Antwort, nicht einmal ein „Danke für Ihr Interesse“ oder „Wir melden uns wieder“.
    Ich habe einen früheren Kollegen gefragt, der dort einmal gearbeitet hat, wie das Verfahren für den Zugang zu RMSDK aussieht, und er hat in internen Unterlagen nachgesehen, aber nichts gefunden. Dasselbe Ergebnis bekam ich, als ich auf LinkedIn Leute gesucht habe, die offenbar etwas mit RMSDK zu tun hatten, und sie gefragt habe.
    Gleichzeitig vertreiben Verlage die meisten Bücher nur über einen der bekannten DRM-Anbieter wie Apple, Amazon oder Adobe, und die ersten beiden sind vollständig geschlossen. Wenn das kein wettbewerbswidriges Monopolverhalten ist, was dann?

    • Ich habe viele Bücher mit der FBReader-App gelesen; sie stellen auch ein SDK zur Verfügung, das in anderen Apps verwendet werden kann.

  • Soweit ich weiß, verwenden Kobo-Geräte eine weiterentwickelte Rendering-Engine, wenn der Dateiname auf .kepub.epub endet. Ich glaube, sie basiert auf ePub 3, aber ich weiß nicht, ob das dieses Problem behebt.
    Ich persönlich wandle ePubs vor dem Übertragen auf meinen Kobo mit kepubify(https://pgaskin.net/kepubify/try/) um.

    • Ja, genau so mache ich es auch mit allen meinen Dateien. Auch Verlage wie Standard Ebooks bieten kepub-Downloads an, und wie hier erklärt wird, gibt es auch Probleme mit dem Adobe-Reader.
      https://standardebooks.org/help/how-to-use-our-ebooks#kobo-faq
      Ich mag den Kobo Clara Colour wirklich sehr, und wenn man nur den Adobe-Reader entfernen könnte, wäre er perfekt. Ich habe auch KOReader ausprobiert, aber ich mag die Bibliotheksbücher über OverDrive und den Kobo Store, deshalb bin ich nicht vollständig umgestiegen.

  • Leider sind epub und epubcheck, wie der Autor sagt, kein unumstrittener hervorragender Maßstab. Als W3C, Inc. um ePub 3.1 herum die Pflege der Spezifikation übernahm, haben sie schlicht WHATWG-HTML und die immer weiter anwachsenden Browser-Spezifikationen referenziert ([1]).
    Solche „lebenden Standards“ haben weder Versionierung noch QA. Das Ergebnis ist, dass ePub 3.2 auf einer HTML-Version basiert, in der Header und Sectioning neu definiert wurden, und dadurch ältere ePubs nicht mehr konform sind. Deshalb empfehlen Calibre und andere Werkzeuge weiterhin 3.1 oder, noch besser, 2.
    Auch der Fall, dass die CSS-Funktion min() abgelehnt wird, zeigt, wie wenig hilfreich es ist, die übermäßig komplexe CSS-Spezifikation einfach komplett zu übernehmen. E-Book-Reader sind schließlich keine Browser, die ständig auf dem neuesten Stand gehalten werden.
    [1]: https://news.ycombinator.com/item?id=41326179

    • In der ePub-Welt ist weithin bekannt, dass es die vernünftigere Wahl ist, 3.1 oder 2 als Ziel zu nehmen.
      Bei EPUB-Kompatibilitätsproblemen sollte man immer zuerst CSS verdächtigen. „Modernes“ CSS zu verwenden und sich dann zu beschweren, dass es weder Flexbox noch Grid gibt, ist eine Denkweise aus der Webentwicklung.
      Nur weil EPUB und das Web Teile des Stacks gemeinsam haben, bedeutet das nicht, dass sie vollständig deckungsgleich sind, und das müssen sie auch nicht sein. Die meisten dedizierten E-Ink-Reader verwenden zum Rendern keinen Browser, sondern haben eine zweckgebundene HTML/CSS-Parsing- und Rendering-Toolchain in die Firmware eingebrannt, die nur sehr selten aktualisiert wird. Wer sich dafür interessiert, kann sich crengine in KOReader oder den auf dem ESP32 laufenden Crosspoint reader ansehen.
      Der Blogpost riecht nach einem übertrieben selbstsicheren AI-Stil, aber davon sollte man sich nicht täuschen lassen.

  • Für Leute, die nach einem Gerät suchen, gibt es auch das PineNote
    https://pine64.org/devices/pinenote/
    Es ist teurer und es gibt weniger sofort nutzbare Software, aber in Bezug auf Geräteeigentum und darauf, welche Software man ausführen kann, ist es deutlich direkter und mit weniger Einschränkungen verbunden
    Es gibt auch gut aufbereitete Berichte zur Nutzung des PineNote
    https://shom.dev/posts/20250308_pinenote-day-one/
    https://shom.dev/posts/20250406_a-pinenote-only-5-day-weeken...

    • Ich würde gerne wissen, ob du das PineNote selbst ausprobiert hast. Es kostet 400 Dollar und wird als „für Linux-Entwickler mit umfangreichem Wissen über Embedded Systems oder mit mobiler Linux-Erfahrung“ beschrieben. Auch die verlinkte Community-Firmware wurde seit über einem Jahr nicht aktualisiert
      Kobo schränkt ebenfalls nicht ein, was man tun kann. Man kann alternative E-Book-Reader-Software wie KOReader sideloaden und so die Funktionen des eingebauten Readers verbessern
    • Auch der Open-Source-60Hz-E-Ink-Bildschirm dieser Person ist einen Blick wert: [video] https://www.youtube.com/watch?v=nHbA2-_qzH4

  • Kobo schreibt seine E-Book-Reader-Software tatsächlich komplett neu, und in der EU kann man die Beta herunterladen. Sie basiert mit ziemlicher Sicherheit nicht mehr auf RMSDK
    Adobe war als Verwalter schlecht und hat später die Migration vermasselt, indem es das Ganze an einen Drittanbieter weiterverkauft hat, was Endnutzer und Plattformen nur noch mehr verärgert hat, und damit den EPUB-DRM-Markt praktisch auf dem Silbertablett an LCP abgegeben. Plattformen lösen sich schneller denn je von Adobe

    • Ich würde gerne wissen, ob du die Beta ausprobiert hast. Mich würde interessieren, ob sie tatsächlich deutlich besser ist

  • Bei der Passage „Ich hatte Angst vor dem Moment, in dem ich bei einem nach Monaten der Arbeit fertiggestellten Buch auf den Validierungs-Button drückte. Es fand immer irgendetwas zum Beanstanden“ musste ich an Masterstudierende denken, die den Tränen nahe waren, als sie versuchten, einen LaTeX-Paper-Entwurf zu kompilieren
    Sie hatten den Rat „erst schreiben, über das Format kann man später nachdenken“ allzu wörtlich genommen und erst kurz vor der Deadline zum ersten Mal versucht zu kompilieren

    • Insgesamt hat das wahrscheinlich trotzdem ziemlich viel Zeit gespart. Schon allein wegen der Kompilierzeit hätten sie mit früheren Iterationen womöglich viel mehr Zeit verschwendet
      Welchen Einfluss die nahende Deadline auf dieses Gefühl hatte, ist allerdings unklar ;-P

  • Man kann froh sein, wenn Leser überhaupt einen ePub-Reader verwenden, der so etwas wie max-width unterstützt oder zumindest ignoriert :-P
    Ich persönlich musste bei der Nutzung von ePub-Readern gelegentlich selbst Dateien reparieren, die wegen unnötiger Styles nicht funktionierten oder seltsam dargestellt wurden. Ich habe auch gehört, dass Dateien, die bei mir problemlos waren, für andere unlesbar waren, und wenn es nicht um wirklich notwendige aufwendige Formatierung geht, scheint es mir besser zu sein, bei möglichst einfachem HTML zu bleiben, das selbst IE4 nicht völlig falsch rendern würde
    Deshalb denke ich manchmal darüber nach, irgendwann ein Tool epub reconstruct zu bauen, das ePub in möglichst schlichtes HTML/CSS umstrukturiert. Idealerweise sollte es für maximale Kompatibilität konfigurierbar sein

    • Selbst in Ziel-Webbrowser-Umgebungen funktioniert HTML/CSS nur so gerade eben, daher verstehe ich nicht, warum irgendjemand dachte, das sei eine gute Idee für Bücher
      Ich habe oft darüber nachgedacht, einfach eine Teilmenge festzulegen, die auf jedem Computer schnell läuft, und nur diese für meine Webseiten zu verwenden. Wenn jemand so einen Rahmen auch für ePub definieren würde, wäre das sehr viel nützlicher
    • Das ist wohl so, als würde man beim Malen die Mitte frei lassen, weil irgendeine Person eine gesprungene Brille haben könnte und das Bild dann seltsam sähe. Oder vielleicht sollte man den Brillenherstellern sagen, sie sollen bessere Brillen bauen, und die Künstler ihre Kunst machen lassen

  • Adobe Digital Editions und RMSDK wurden kürzlich an Wipro Engineering verkauft: https://helpx.adobe.com/enterprise/kb/eol-faq-adobe-digital-...

    • Ich frage mich, ob das ein Verkauf war oder eher Outsourcing

  • Ich verstehe die Frustration des Autors, aber wie viele Leser verwenden wirklich ePub-Reader, die alt sind und nicht aktualisiert wurden oder nicht aktualisiert werden können? Wenn ein Autor sein Werk allen Lesern zugänglich machen will, muss er sich am kleinsten gemeinsamen Nenner orientieren
    Wenn das irgendetwas aus dem Jahr 2013 ist, dann ist das bedauerlich, aber das ist die Realität des Marktes

    • Ich habe das so verstanden, dass neue Kobo-Geräte, die 2026 erscheinen, CSS-Regeln mit einer Adobe-DRM-Software verwenden, die 2013 stehengeblieben ist