- Même un EPUB sans DRM validé peut être traité comme « corrupted » sur Kobo, et le problème ne vient pas d’une erreur de format de fichier mais de la compatibilité du moteur de rendu
- epubcheck est l’outil de validation de référence de fait pour vérifier la structure d’un EPUB et sa conformité aux règles, mais il ne détecte pas les problèmes d’un analyseur CSS ancien propre à certains moteurs de rendu
- Kobo utilise RMSDK, le moteur de rendu d’ebooks propriétaire d’Adobe, conçu à l’origine autour d’EPUB2 puis légèrement mis à jour pour EPUB3, sans avoir été modernisé
- La cause du problème était une seule ligne,
max-width: min(150px, 30vw);, et ce code CSS level 4 pourtant valide n’est pas pris en charge par RMSDK, ce qui empêche le chargement du livre dans Adobe Digital Editions et sur Kobo
- Pour vérifier la compatibilité avec Kobo, epubcheck ne suffit pas : une validation supplémentaire consistant à ouvrir réellement le fichier dans Adobe Digital Editions est nécessaire
Le problème a commencé avec un EPUB qui passait epubcheck
- Les outils Adobe sont souvent utilisés parce que la Creative Suite est un standard de fait dans le secteur ou parce qu’il existe peu d’alternatives, et le point de départ de cet article est une frustration envers les logiciels Adobe
- Le nouveau livre a été distribué sous forme de fichier
EPUB sans DRM fourni directement aux lecteurs, et il a passé le contrôle epubcheck après plusieurs étapes avant sa diffusion
epubcheck est l’outil de référence de fait pour vérifier qu’un ebook est bien formé, et la validation exige que le manifest reflète sans omission tous les éléments et images du livre
- Si l’ordre des éléments HTML est incorrect ou si le fichier s’écarte ne serait-ce qu’un peu des règles de l’International Digital Publishing Forum, la validation échoue
- Obtenir un résultat 100 % conforme avec
epubcheck n’est pas simple pour un débutant, mais pour les professionnels de l’édition, l’outil joue un rôle proche d’un linter de types ou d’une suite de tests formels
- L’attente naturelle est qu’un livre qui passe
epubcheck fonctionne ensuite dans n’importe quel lecteur ou application compatible EPUB
Le message « corrupted » n’apparaît que sur Kobo
- Le nouveau livre passait
epubcheck ruleset 3.3, mais un lecteur a signalé l’apparition du message « corrupted »
- Pour vérifier une éventuelle compatibilité descendante, une version EPUB2 a aussi été fournie, mais le même problème est apparu alors même que ce fichier respectait lui aussi complètement les règles
- Ce lecteur a indiqué que le livre ne s’ouvrait sur plusieurs générations d’appareils Kobo
- Le même EPUB fonctionnait sans problème dans d’autres environnements, notamment Amazon Kindle, Apple Books et Thorium
- L’enquête a montré que Kobo utilise RMSDK, le moteur de rendu d’ebooks propriétaire d’Adobe
La cause a été circonscrite à RMSDK et Adobe Digital Editions
- RMSDK est le moteur central d’Adobe Digital Editions et il est également utilisé sur plusieurs appareils Kobo ainsi que sur d’anciens appareils Sony et Nook
- Ce moteur a été conçu vers 2010 principalement autour d’EPUB2, puis légèrement mis à jour pour EPUB3, sans véritable modernisation
- Le fait que Kobo utilise RMSDK n’a pas immédiatement résolu l’écart entre les résultats d’
epubcheck et ceux de Kobo, mais cela a donné une direction au débogage
- Une fois le livre importé dans Adobe Digital Editions, le chargement a échoué comme prévu, sans afficher le moindre message d’erreur
- En essayant de le recharger, un message indiquait qu’il s’agissait déjà d’un livre ajouté et qu’il ne pouvait pas être importé à nouveau, mais l’écran restait blanc
- Plusieurs variantes du fichier ont ensuite été créées et testées, et toutes continuaient à passer
epubcheck
- Réorganisation de l’arborescence des dossiers, suppression des métadonnées, suppression de l’attribut de langue, génération d’un nouvel UUID, aplatissement des répertoires, changement d’extension, régénération du ZIP, modification du
manifest
- Malgré tous ces essais, l’échec de chargement dans Adobe Digital Editions se répétait
La vraie cause : une ligne de CSS valide
- En désactivant la feuille de style, le livre s’est soudain chargé, ce qui a permis de restreindre le problème à la feuille de style
- Après avoir créé d’autres variantes n’appliquant qu’une partie de la feuille de style, une seule ligne fautive a été identifiée
.copyright img {
max-width: min(150px, 30vw);
}
- Ce code est un code CSS level 4 parfaitement valide, mais RMSDK ne le prend pas en charge
- En remplaçant cette ligne par l’ancienne forme
max-width: 150px;, le livre s’ouvrait normalement dans Adobe Digital Editions
- L’analyseur CSS de RMSDK semble figé autour de l’état de 2013 et ne prend pas en charge flexbox, grid, les fonctions mathématiques ni les propriétés personnalisées
- Lorsqu’il rencontre du CSS qu’il ne comprend pas, il plante silencieusement au lieu de proposer un repli ou une erreur claire
epubcheck effectue une vérification CSS de base, mais il ne peut pas, fondamentalement, valider le CSS contre un moteur de rendu précis et défaillant
Ce qu’il faut retenir pour valider la compatibilité Kobo
- Même en 2026, puisque Kobo s’appuie toujours sur RMSDK pour le rendu des livres, une seule ligne de CSS valide peut suffire à transformer un EPUB valide en « corrupted file »
- Dans ce cas, Kobo ne parvient pas à ouvrir l’ensemble du livre, sans message d’erreur clair ni mécanisme de repli
- Une nouvelle version a été publiée pour éviter le problème et faire en sorte que les lecteurs ne rencontrent plus la même erreur
- Dans un monde idéal, RMSDK devrait sortir de son état de vétusté côté CSS ou au minimum fournir une gestion correcte des erreurs, mais le problème reste entier aujourd’hui
- Pour s’assurer de la compatibilité avec Kobo,
epubcheck seul ne suffit pas : il faut vérifier le chargement réel dans Adobe Digital Editions
- EPUB est un excellent standard ouvert pour les livres numériques, mais de nombreuses implémentations révèlent des défauts fondamentaux dans une architecture qui privilégie les restrictions d’accès
1 commentaires
Commentaires sur Hacker News
Adobe a toujours fonctionné comme ça. Ils ont gaspillé l’énorme part de marché de Flash alors qu’il aurait suffi de dépenser quelques millions de dollars en QA, et ils ont fini par amener tous les fabricants de navigateurs à s’accorder sur l’idée que « le web se porterait mieux sans un partenaire aussi peu fiable ».
J’ai sorti quelques projets en Flash à l’époque, et c’était un logiciel horrible, rempli de Heisenbugs : des plantages aléatoires et des changements dans une zone qui cassaient des fonctionnalités sans rapport dans d’autres modules. Ça coûtait dans les 800 dollars, il n’y avait pratiquement aucun support, et même après avoir signalé plusieurs bugs facilement reproductibles avec des cas de test réduits, je n’ai reçu qu’un message automatique me disant qu’ils étaient peut-être corrigés dans la version suivante et que je n’avais qu’à acheter une licence au prix fort pour vérifier
Il y avait aussi MusicWorks, et les deux étaient réservés au Mac au tout début. Rien que d’en parler trahit mon âge
Les couches empilées des systèmes de build JavaScript et les « standards du web » sont bien plus compliqués que le simple fait de dessiner quelque chose, d’écrire quelques fonctions simples, puis de produire un fichier statique qu’on peut intégrer partout ou télécharger. Avec les alternatives à Flash, on passe bien trop de temps à configurer les choses, et ces « standards » sont pires
Je déteste Steve Jobs pour avoir tué Flash, et je déteste aussi Adobe pour avoir si mal géré l’une des technologies les plus incroyables du web. Les enfants qui grandissent aujourd’hui ne savent pas à quel point Flash paraissait magique. C’était comme un Roblox ou un Minecraft pour le web
Les sites web restent encore inférieurs à Flash du début des années 2000. Des décennies ont passé et on n’en imite qu’une partie de la puissance, sans jamais retrouver sa simplicité
J’ai longtemps essayé de créer un logiciel de lecture de livres électroniques et j’ai fini par envisager un pacte avec le diable en essayant de construire dessus avec RMSDK
Mais il est totalement impossible d’y accéder. Je ne veux pas seulement dire que la licence est trop chère pour un développeur indépendant — même si c’est aussi vrai —, mais qu’il n’y a littéralement personne à qui parler. L’adresse e-mail indiquée sur le site ne répond jamais, pas même avec un « merci pour votre intérêt » ou un « nous vous recontacterons »
J’ai demandé à un collègue qui avait travaillé là-bas comment obtenir l’accès à RMSDK ; il a fouillé la documentation interne sans rien trouver. J’ai aussi essayé de contacter sur LinkedIn des gens qui semblaient liés à RMSDK, avec le même résultat
Pendant ce temps, les éditeurs ne distribuent la plupart de leurs livres qu’à travers l’un des fournisseurs de DRM connus, comme Apple, Amazon ou Adobe, et les deux premiers sont totalement fermés. Si ce n’est pas une pratique monopolistique anticoncurrentielle, je ne sais pas ce que c’est
Si je ne me trompe pas, les appareils Kobo utilisent un moteur de rendu plus avancé si le nom du fichier se termine par
.kepub.epub. Ça semble reposer sur ePub 3, mais je ne sais pas si cela corrigera le problème évoqué iciPersonnellement, je convertis mes ePub avec kepubify(https://pgaskin.net/kepubify/try/) avant de les transférer sur ma Kobo
https://standardebooks.org/help/how-to-use-our-ebooks#kobo-f...
J’aime vraiment beaucoup la Kobo Clara Colour, et elle serait parfaite s’ils supprimaient simplement le lecteur Adobe. J’ai aussi essayé KOReader, mais j’aime les livres de bibliothèque OverDrive et la Kobo Store, donc je n’ai pas complètement basculé
Malheureusement, epub et epubcheck ne sont pas non plus, comme le dit l’auteur, des références excellentes et incontestables. Quand W3C, Inc. a repris la gestion de la spécification autour d’ePub 3.1, ils ont simplement référencé WHATWG HTML et les spécifications de navigateurs toujours plus volumineuses([1])
Ces « standards vivants » n’ont ni gestion de versions ni QA. Résultat : en s’appuyant sur une version de HTML qui redéfinissait les en-têtes et le sectionnement, ePub 3.2 a rendu non conformes des ePub existants. C’est pour cela que Calibre et d’autres outils recommandent encore la 3.1, voire mieux, la 2
Le fait que la fonction CSS
min()soit rejetée montre aussi à quel point reprendre en bloc une spécification CSS excessivement complexe n’aide pas beaucoup. Les liseuses ne sont pas des navigateurs mis à jour en permanence[1]: https://news.ycombinator.com/item?id=41326179
En cas de problèmes de compatibilité EPUB, il faut toujours suspecter le CSS en priorité. Utiliser des fonctionnalités CSS « modernes » puis se plaindre de l’absence de flexbox ou de grid, c’est une façon de penser de développeur web
Ce n’est pas parce qu’EPUB partage une partie de sa pile avec le web que les deux se recouvrent totalement, ni qu’ils devraient le faire. La plupart des liseuses intégrées à écran e-ink n’utilisent pas un navigateur pour le rendu ; elles embarquent dans leur firmware une chaîne d’outils HTML/CSS de parsing et de rendu conçue pour cet usage, puis ne la mettent à jour que très rarement. Si ça vous intéresse, regardez crengine de KOReader ou Crosspoint reader qui tourne sur ESP32
Cet article de blog dégage un peu trop une voix d’IA excessivement sûre d’elle, mais il ne faut pas se laisser avoir
Pour ceux qui cherchent un appareil, il y a aussi le PineNote
https://pine64.org/devices/pinenote/
C’est plus cher et il y a moins de logiciels prêts à l’emploi, mais c’est bien plus direct, avec beaucoup moins de contraintes, en ce qui concerne la propriété de l’appareil et les logiciels qu’on peut y exécuter
Il existe aussi des articles qui résument très bien l’expérience d’utilisation du PineNote
https://shom.dev/posts/20250308_pinenote-day-one/
https://shom.dev/posts/20250406_a-pinenote-only-5-day-weeken...
Kobo ne limite pas non plus ce qu’on peut faire. On peut sideloader un logiciel alternatif de lecture d’ebooks comme KOReader pour améliorer les fonctions du lecteur intégré
Kobo est en train de réécrire entièrement son logiciel de lecture d’ebooks, et dans l’UE on peut télécharger la bêta. Il est presque certain qu’il n’est plus basé sur RMSDK
Adobe a été un mauvais gestionnaire, puis a encore davantage irrité les utilisateurs finaux et les plateformes en ratant la migration avant de revendre le tout à un tiers, livrant pratiquement sur un plateau le marché du DRM EPUB à LCP. Les plateformes quittent Adobe plus vite que jamais
Le passage « J’avais peur du moment où j’appuierais sur le bouton de validation après avoir terminé un livre sur lequel j’avais travaillé pendant des mois. Il trouvait toujours quelque chose à redire » m’a rappelé un étudiant en master au bord des larmes en essayant de compiler un premier brouillon d’article LaTeX
Il avait pris beaucoup trop littéralement le conseil « écris d’abord, pense à la mise en forme plus tard », au point de n’essayer de compiler pour la première fois qu’à l’approche de la date limite
Difficile de savoir quel effet la date limite imminente a eu sur cette perception ;-P
Si le lecteur utilise au départ un lecteur ePub qui prend en charge quelque chose comme
max-width, ou au moins l’ignore, il faut déjà s’estimer heureux :-PPersonnellement, en utilisant des lecteurs ePub, j’ai parfois dû corriger moi-même des fichiers qui ne fonctionnaient pas ou s’affichaient bizarrement à cause de styles inutiles. J’ai aussi entendu parler de fichiers qui ne posaient aucun problème chez moi mais étaient illisibles chez quelqu’un d’autre, et je me dis que, sauf si une mise en forme sophistiquée est vraiment nécessaire, il vaut mieux s’en tenir au HTML le plus basique possible, du genre qu’IE4 ne rendrait pas trop mal
Du coup, il m’arrive de penser à créer un outil epub reconstruct qui recompose un ePub en HTML/CSS le plus simple possible. Idéalement, ce devrait être paramétrable pour une compatibilité maximale
Je me suis souvent dit qu’on devrait définir un sous-ensemble qui fonctionne vite sur n’importe quel ordinateur et n’utiliser que ça pour les pages web que je crée. Si quelqu’un définissait aussi ce périmètre pour l’ePub, ce serait bien plus utile
Adobe Digital Editions et RMSDK ont récemment été vendus à Wipro Engineering : https://helpx.adobe.com/enterprise/kb/eol-faq-adobe-digital-...
Je comprends la frustration de l’auteur, mais combien de lecteurs utilisent vraiment des lecteurs ePub anciens, non mis à niveau, ou impossibles à mettre à niveau ? Si l’auteur veut que son œuvre soit accessible à tous les lecteurs, il doit s’aligner sur le plus petit dénominateur commun
Si ce dénominateur commun correspond à quelque chose de 2013, c’est regrettable, mais c’est la réalité du marché