Gros billet après une non moins grosse enquête autour de la couverture en double sur Kindle. Donc, nous allons nous permettre un petit « tl;dr » : ne faites pas confiance aux guidelines Kindle, elles contiennent des infos erronées et tout un tas de contradictions.

Tout est parti d’une modification survenue dans l’export InDesign CC le mois dernier — notez bien que ça ne concerne pas que l’export ID, je ne le cite que pour l’anecdote ici. Alors que le logiciel exportait la couverture de cette manière :

<spine toc="ncx">

<itemref idref="CoverImage" /> 

…

</spine>

Il l’exporte désormais ainsi :

<spine toc="ncx">

<itemref idref="Cover" linear="no" /> 

…

</spine>

Il convient avant tout de pointer que c’est certainement une mauvaise pratique puisque du contenu secondaire (indiqué à l’aide de linear="no") n’étant pas relié à du contenu principal ne peut être réellement considéré comme du contenu secondaire ; c’est surtout du contenu qui peut ne pas être accessible dans certaines solutions de lecture. En outre, nous pouvons débattre du caractère principal ou secondaire d’une couverture…

Retenez bien le terme « mandatory » (obligatoire en Français) pour la suite de cet article.

Pourquoi ce choix ?

À cause d’anciennes guidelines Kindle (version 2014.1.1 vieille de plus de 6 mois)…

Nous nous intéresserons à la section 3.2.3, « Cover Image Guideline #3: Internal Cover Must Not Appear Twice », où Amazon explique que les ajouts de linear="no" sur l’itemref et le guide cover sur le fichier HTML est la seule méthode possible pour conserver la couverture HTML dans le spine (pour compatibilité avec d’autres revendeurs) tout en ne l’affichant pas en double sur un appareil Kindle.

Seulement, dans les nouvelles guidelines Kindle (version 2014.2 publiée en Octobre 2014), cette section devient :

Do not add cover images to the content in any way other than those described in section 3.2.2, Cover Image Guideline #2: Internal Content Cover Image Is Mandatory, or the cover might appear twice in the book.

Où l’on nous prévient donc qu’il ne faut surtout pas ajouter de couverture HTML même si ce n’est pas marqué noir sur blanc — la section à laquelle le texte renvoie indique qu’il faut l’indiquer à l’aide de meta content="cover", nous déterminons donc qu’il ne faut pas y ajouter un fichier HTML servant la fonction de couverture.

Attention donc, quand Amazon parle de couverture interne, il ne parle pas de couverture inline en HTML mais bien de l’image elle-même. Ajouter (ou conserver) un fichier cover.xhtml dans votre fichier EPUB la ferait donc apparaître en double dans le fichier mobi converti.

Attendez une seconde

Nous sommes loin d’en avoir terminé.

Le fait est que je n’ai jamais appliqué la méthode fournie par Amazon et que je n’ai jamais eu de problème de couverture en double. Par contre, d’autres l’ont suivie à la lettre et ont eu quelques gros soucis… J’ai pu le découvrir lors d’une assez longue discussion avec @elmimmo_ sur Twitter.

Debug time!

J’ai donc pris le premier fichier EPUB trouvé et ai commencé à effectuer quelques tests avec cette fameuse couverture HTML. Je n’ai pas modifié cet EPUB et l’ai envoyé directement dans KindleGen (V2.9 build 1028-0897292) pour conversion.

Remarquez la ligne surlignée en vert, cela pourrait bien vous servir.

Dans le log de conversion, ou « Détails Compilation » de Kindle Previewer, on peut trouver ce message :

Info(prcgen):I1052: Kindle supporte les images couvrent, mais ne supporte pas la couverture HTML. Ainsi en utilisant l'image de couverture spécifiées et couvrent la suppression HTML dans le contenu. URL: /var/folders/…/OEBPS/Text/cover.xhtml

(On remarquera la superbe traduction au passage.)

La couverture HTML est donc supprimée automatiquement — j’ai même décompilé le fichier Mobi pour m’en assurer. Dans mon fichier EPUB, le guide cover est bien renseigné MAIS, et c’est là que ça devient intéressant, le HTML n’est pas en linear="no" alors qu’Amazon me dit que cet attribut est obligatoire dans les précédentes guidelines.

BULLSHIT.

Après de nombreux tests, il se trouve que ces deux attributs ne sont pas des facteurs pris en compte par KindleGen pour conserver ou pas le fichier HTML contenant la couverture lors de la conversion d’un fichier reflowable text…

En cherchant un peu, je me rends compte que la méthode fournie par Amazon remonte à 2011, ce que j’ai pu confirmer en consultant les guidelines de fin 2011 et un fichier, avec ce problème de double couverture, réalisé à cette époque. En cherchant encore, je me rends compte qu’elle ne fonctionne pas à tous les coups depuis 2012. En creusant jusqu’au fond du fond, je me rends compte que beaucoup d’autres ont reporté qu’il n’y avait pas besoin de linear="no" depuis cette même date. Enfin, en allant regarder les release notes de KindleGen :

Kindlegen version 2.3 build 36043
  - Supported new CSS media types to provide distinct styles to mobi and KF8.
  - Improved image quality for comics and children's books.
  - Dual cover image fix for reflowable book.

« Dual cover image fix for reflowable book » sans autre précision. Quelqu’un a-t-il communiqué l’information ? Nous n’en saurons rien. En tout cas, à considérer mon expérience personnelle et ces recherches, on dirait bien que la méthode donnée — que l’on peut du coup considérer comme légèrement erronée — a survécu dans les guidelines pendant 2 ans sans aucune forme de correction.

Après d’autres tests sur la dernière version de KindleGen en date et pour résumer :

• le nom du fichier HTML ne joue pas (cover.xhtml aurait pu être un facteur) ;
• le guide type="cover" ne joue pas ;
• le spine linear="no" ne joue pas (il semblerait que KindleGen pouvait même rejeter le fichier à la fin du livre s’il le trouvait) ;
• le fait d’intégrer la couverture avec du SVG ne joue pas.

Dans ces 4 cas, le fichier HTML est trouvé et supprimé par le convertisseur.

Il existe toutefois 2 cas dans lesquels il est conservé :

• si l’image de couverture n’est pas renseignée avec la balise meta, il est utilisé comme solution de secours mais l’utilisateur n’aura plus accès à la couverture dans le menu « Aller à… » ;
• si l’image de couverture et l’image utilisée dans le HTML ne sont pas les mêmes (ce qui inclut des images similaires n’ayant pas le même nom), alors le fichier est conservé et la couverture sera affichée en double.

Il ne faut donc tout simplement pas utiliser deux images différentes.

Ce dernier comportement peut s’expliquer d’une manière logique : KindleGen prend le premier fichier listé dans le spine de l’EPUB lors de la conversion. Il ne sait pas forcément que c’est une couverture donc se base sur le nom de l’image utilisée en tant que couverture pour décider s’il doit retirer ce fichier HTML ou non. En effet, puisque certains réalisent encore leur page de titre en image, elle serait susceptible de sauter à la conversion si elle est la première page du spine.

Je me suis plongé dans mes fichiers Kindle pour essayer de déterminer plus précisément depuis quand KindleGen exclut la couverture HTML et ai pu remonter jusqu’à juillet 2012.

Donc, depuis au moins juillet 2012, KindleGen (et KindlePreviewer par conséquent) se débarrasse automatiquement du fichier HTML qui contient la couverture si l’image est la même que celle utilisée pour meta.

Un petit détour par les guidelines Kindle Comic Creator permet de voir que des clarifications pourraient être apportées à ce sujet.

Et devinez quoi ?

Tout part en réalité d’un bug (?) de conversion fixed-layout apparu dans la version 2.9 de KindleGen : lorsque la couverture HTML est indiquée en suivant scrupuleusement la méthode des anciennes guidelines, elle est bien présente en double dans le fichier converti même si rejetée à la fin du livre.

Bug ou pas, c’est ce qui a très justement mené à cette mise à jour de cette section 3.2.3. Reste qu’il semble que ces guidelines ne soient pas assez claires et précises en l’état :

• il n’est pas spécifiquement indiqué qu’il ne faut pas intégrer la couverture en HTML mais seulement qu’il ne faut rien faire d’autre que ce qui est indiqué dans la section précédente — ce qui mène à une incompréhension chez pas mal de personnes, y compris les plus attentives comme j’ai pu m’en apercevoir ;
• il n’y a pas de différenciation faite entre reflowable text et fixed-layout alors que je peux constater qu’il en existe bien une ;
• la méthode donnée jusqu’ici n’était même pas aussi correcte que nécessaire et a causé des problèmes pour certains ;
• les guidelines de Kindle Comic Creator et Kids’ Book Creator (fixed-layout) n’indiquent pas non plus, noir sur blanc, qu’il ne faut pas ajouter la couverture comme page dans le livre — cf. image ci-dessus, une capture d’écran illustrant l’ajout de pages en important des fichiers image, dans laquelle nous pouvons trouver le fichier _cover, peut même prêter à confusion.¹

Reste que cela crée une problématique pour le fixed-layout puisqu’il peut y avoir besoin d’intégrer la couverture dans le spine afin de permettre le mode « case par case » pour un comic ou le texte « pop-up » pour un livre jeunesse. Et là, on se retrouvera donc avec la couverture en double…

Ce qu’il est indirectement conseillé de faire par Amazon puisque la section 4.3.7 demande à ce qu’une couverture HTML soit incluse dans les livres pour enfants et qu’elle soit le premier fichier dans le spine. Cette section renvoie ensuite à la fameuse section 3.2.3 qui exige de ne surtout pas le faire. Autrement dit, ô joie, les deux recommandations se contredisent royalement et nous nous arrachons encore un peu plus de cheveux.

Exemple de couverture pour laquelle nous devrions utiliser le mode « case par case », donc distribuer un fichier pour lequel nous devons choisir (ou pas) de respecter les guidelines d’Amazon… tout en sachant qu’il pourra être rejeté (ou pas).

En résumé

Dans l’idéal, puisque nous ne sommes pas à l’abri d’un changement² ou d’un bug du côté de KindleGen³, autant prendre l’habitude de retirer la couverture HTML de votre livre avant conversion, que votre livre soit en reflowable text ou en fixed-layout.

Si vous n’avez pas envie de le faire, consultez les détails de compilation et vérifiez bien la présence de cette info I1052, qui se trouve normalement au début de la liste. Si elle n’y est pas, c’est que vous avez probablement oublié de spécifier la meta (EPUB2) ou la property (EPUB3) pour l’image. Si elle y est, partez du principe qu’elle ne garantit pas que la couverture HTML soit réellement enlevée et vérifiez-le.

Dans le pire des cas, si la couverture apparaît en double lors de la vérification visuelle du fichier, vous saurez comment résoudre le problème.

Ce qui est une nouvelle fois insupportable et lamentable, c’est l’absence de communication du côté du revendeur : les développeurs ne sont pas accessibles, ce genre de bug ou changement se présente, aucun développeur ne répond — y compris sur les forums Kindle —, nous sommes obligés de perdre du temps à vérifier de notre côté pour établir des conclusions sans qu’aucune confirmation officielle ne vienne jamais les valider.

Si Amazon assure que son format propriétaire lui permet un meilleur contrôle sur les fonctionnalités, qu’il fasse au minimum en sorte que les gens qui y travaillent se mettent d’accord et ne documentent pas des choses susceptibles de créer une confusion chez les développeurs.

Au final, nous nous en tiendrons à ce mantra : « Je ne fais pas confiance aux guidelines Kindle et je vérifie. »⁴ Mieux vaut l’adopter dès aujourd’hui puisque la documentation du revendeur n’est pas avare en contradictions et en informations erronées.