Bonne nouvelle pour les développeurs qui haïssent le format mobi7, les MAJ des liseuses Kindle et Kindle Touch (ont-elles été déployées automatiquement au fait ?) apportent le support du nouveau format Amazon, KF8.

Ce nouveau format apporte un nombre incalculable de choses — il faut dire qu’on partait de très loin avec mobi7 — qui vont nous permettre de beaucoup mieux gérer les styles des livres Kindle. Niveau typographie, même les fontes intégrées et les small-caps sont gérées. C’est dire si Amazon a fait un effort.

Je n’ai pas pu encore me pencher à fond sur le sujet mais je prends quand même le temps de partager ma première exploration. N’hésitez donc pas à donner de plus amples informations dans les commentaires si vous avez remarqué quelque chose qui ne se trouve pas dans cet article.

Aperçu

Le plus simple est de vous présenter ces choses visuellement — désolé d’avance pour la qualité des images.

Mais je vais commencer par le plus important : vous n’aurez plus besoin de « mobifier » votre EPUB. Même avec des mises en pages / styles complexes, la conversion s’avère très très bonne.

Le code de l’EPUB de base n’a pas été modifié. Avec mobi7 (à gauche), impossible de gérer la marge à droite. Avec KF8, plus aucun souci. Pour info, dans l’image de gauche (mobi7), la police du heading est intégrée comme image.

Vous pourrez remarquer d’autres choses sur cette image : les polices intégrées (format TTF ou OTF) et les lettrines passent également ! Notez bien que je n’ai pas pris le temps de caler la lettrine pour le moteur de rendu Kindle. C’est celui de la version EPUB. Nota Bene : les fonts sont automatiquement « obfuscated » (protégées pour être rendues inutilisables par d’autres).

Confirmation dans l’image suivante en ce qui concerne les polices intégrées.

Et pour les small-caps…

Par contre, pas de support first-line, first-letter, before, after, etc.

J’ai pu remarquer que d’autres choses sont supportées : les bordures par exemple, mais également les images de fond (même les motifs répétés passent tranquillement). Et les vrais tableaux sont enfin possibles. Je n’ai pas pu pousser encore plus loin mais c’est déjà franchement pas mal. Nous risquons donc d’aller de bonnes surprises en bonnes surprises, d’autant que la MAJ ne semble pas boguée…

edit : autre nouveauté intéressante, les images peuvent désormais être agrandies. Grosso modo, il n’y aura donc plus absolument besoin de les afficher en plein écran, ce qui nous apporte quand même un confort supplémentaire dans la gestion de contenus illustrés (tutoriels avec captures d’écran par exemple). Par ailleurs, il est possible de développer les bandes dessinées pour lecture sur Kindle et Kindle Touch (mode case par case). / edit 7 : De plus, il est possible d’effectuer une rotation de 90° d’un simple tap sur l’image, ce qui peut être pratique quand l’image est plus large que haute. Là, je n’en voudrais pas du tout à la concurrence de copier sans vergogne cette fonctionnalité. Nous en avons cruellement besoin pour la non fiction.

edit 2 : On peut réellement prévoir des mises en page complexes avec le format KF8… la preuve avec cette table des matières sous forme de grille d’images (les liens sont fonctionnels).

edit 3 : Les listes sans puces passent, les images en float passent, text-shadow et box-shadow semblent être pris en compte.

edit 4 : support de background-color et de border-radius (coins arrondis).

edit 5 : Kindle Previewer 2 semble prendre en charge la conversion des fichiers EPUB3. Par contre, il faudra que je jette un coup d’œil au code des samples que j’ai utilisés pour la conversion car la mise en page était parfois très bizarre…

edit 6 : pas de support linear=no. Confirmation du code bizarre des samples utilisés en edit 5.

Problèmes

Si vous intégrez des polices, il y a de très grandes chances que vous fassiez tous vos réglages typographiques avec cette police (font-size, line-height, etc.). Or, les polices OTF intégrées sont désactivées par défaut sur les liseuses. Du coup, vos réglages s’appliquent à Caecilia, la police utilisée par Amazon… Et là, je vois les problèmes arriver rapidement : du genre le lecteur qui n’est pas averti de la présence de polices intégrées et qui va se dire qu’on a fait de la merde. D’autant qu’il faut aller les activer dans un menu appelé « Modifier la taille de police » alors que les fonctions qui y sont présentes permettent aussi de régler l’interligne ou le nombre de mots par ligne…

Apparemment, rien n’avertit le lecteur de la présence des polices intégrées. Ni boîte de dialogue qui lui demanderait de choisir de les activer ou pas à l’ouverture du fichier, ni autre mention visible. Bref, ma solution-rustine sera pour l’instant d’ajouter un disclaimer à l’ouverture :

Ça demande 2 minutes, il suffit de spécifier la page comme référence « Texte » et c’est un pis-aller acceptable. Histoire de donner un feedback au lecteur, ce disclaimer utilise une des polices intégrées au livre afin qu’il puisse se rendre compte qu’il les a bien activées.

Que les choses soient bien claires : nous n’avons pas pour idée d’imposer les polices que nous avons choisies, nous croyons que les lecteurs doivent avoir le choix. En ce sens, la solution d’Apple nous apparaît comme la plus équitable : les polices intégrées sont affichées par défaut mais le lecteur peut les débrayer, les réglages typographiques par défaut seront alors forcés. Selon moi, cette solution pourrait être améliorée en permettant au lecteur de pouvoir choisir son interligne, comme il est possible de le faire chez certains concurrents, dont Amazon. Cela ne tient qu’aux revendeurs / développeurs finalement : offrir la possibilité de débrayer les polices intégrées ET une gestion affinée de certains réglages importants : interligne, taille de police, nombre de mots par ligne, etc. Ainsi les intérêts des éditeurs et des lecteurs pourront être rendus compatibles.

Maintenant, cette solution est loin d’être parfaite.

Dans l’app Kindle Mac et Windows, les polices intégrées sont prises en compte et affichées par défaut mais… il n’est pas pour l’instant possible de les débrayer. Du coup, nous nous retrouvons avec une incohérence UX au sein de l’écosystème Kindle sur ce point, ce qui rend le disclaimer caduque… en plus de parasiter l’expérience de lecture. Quand je vous parlais d’expérience utilisateur déficiente, ceci est un cas d’école…

En outre, les polices intégrées ne sont pas supportées dans les apps mobiles Kindle. Caduque et parasite encore une fois.

J’ose donc espérer que les choses seront corrigés rapidement — et s’ils pouvaient « revoir » l’app iOS vu que la nouvelle UI est catastrophique…

Plus besoin de mobi7 ?

Eh bien… si… et je sais que ça ne vous plaît pas du tout.

D’une part, le format KF8 ne sera pas supporté sur les anciens devices Amazon (Kindle 2 par exemple). En France, nous ne devrions pas avoir trop de problèmes puisqu’officiellement, seuls les nouveaux Kindle sont disponibles.

Mais il ne fait aucun doute que mobi7 sera encore utilisé un bon moment puisqu’Amazon a rajouté des bouts de code ici et là pour permettre la différenciation de certains contenus (tableaux normaux dans KF8 qui peuvent être remplacés par des images dans mobi7 par exemple). Donc à vous de voir si vous souhaitez toujours utiliser le format mobi7, sachant que vos livres pourraient être achetés à l’étranger et que des personnes ont fait importer un Kindle d’ancienne génération en France… Dans ce cas, vous feriez bien de préparer une feuille de styles basique à intégrer dans le fichier EPUB qui sert à la conversion Kindle pour gagner un maximum de temps.

Pour les apps mobiles Kindle, les choses sont très vagues. Tout un tas de choses ont été dites dans les articles web concernant leurs mises à jour, mais la situation est tellement floue que des choses erronés ont été écrites (par exemple, « il y a support de KF8 parce que support de Kindle audio et vidéo »… qui était déjà supporté en mobi7 sur iOS). Si quelqu’un peut nous éclairer à ce sujet, il est le bienvenu.

Conclusion

Globalement, le format KF8 est une bonne nouvelle — si on ne prend pas en compte le côté format propriétaire dans un écosystème fermé bien évidemment. Il permet de soigner la typographie, de gérer du contenu complexe avec des « mises en écran » adaptées et de gagner un maximum de temps à la conversion. De ce que j’ai pu voir jusqu’à présent, le rendu est d’ailleurs plutôt bon, ce qui nous change franchement de ce que nous devons endurer ces derniers temps…

Maintenant, le fait est que la fragmentation est un réel problème. Et cela ne s’applique pas qu’à Kindle, mais également à EPUB. Plus nous aurons à gérer des choses et les vérifier X fois, puis les réadapter pour tel ou tel revendeur qui zappe arbitrairement les valeurs pour les styles de certaines balises HTML, plus il y aura de bugs, de mauvais rendus à l’écran de certaines liseuses et applications, de temps de développement nécessaire et j’en passe. En d’autres termes, si les revendeurs n’aident pas un peu les développeurs avec des outils et documentations lors de la transition vers EPUB3, j’ai bien peur que nous allions au devant de très gros problèmes…

PS : Kindle Previewer n’a pas encore été mis à jour pour émuler KF8 sur Kindle e-ink. Vous feriez donc mieux de tester directement sur la liseuse ou, au pire, de vous fier au rendu Kindle Fire.

PS 2 : Une MAJ de Kindle Previewer est disponible et permet de prévisualiser le rendu e-ink en sélectionnant « Kindle Touch » dans le menu « Appareils ». Elle gère également les polices intégrées. Vous pouvez donc désormais vous y fier.