Bien bien en retard mais comme c’est toujours d’actualité (erf), quelques pistes.

Spécifier une taille relative en attribut ou une taille fixe en style peuvent se comprendre indépendamment l’un de l’autre. Je n’arrive cependant pas à concevoir dans cas il peut être pertinent d’associer les deux.

Mobi 7.

KindleGen te met automatiquement les images à 100 % de width, donc, pour conserver les dimensions de l’image, il faut les indiquer dans le HTML — par contre, de mémoire, il faut les indiquer avec les attributs width et height et pas avec des styles inline pour qu’ils soient pris en compte… mais je peux me tromper.

Pourquoi ces titres vides ?

Je devine que certains le font pour conserver l’alignement vertical (visuel) du premier paragraphe des chapitres (marge sup trop « chiante » à calculer).

Sinon, une explication plus logique pourrait être que… comme ça sort d’InDesign ou d’un traitement de texte et que le découpage XHTML se fait par rapport à un style ou à un niveau de titre, bah tu mets le style ou le niveau de titre sur une ligne vide pour que le chapitre soit mis dans un autre XHTML lors de l’export.

De même, la page de titre est un mystère pour moi. La grande majorité des livres choisissent de ne pas marquer comme titre le titre du livre, et de réserver ces balises aux titres des sections et des chapitres. Je dois avouer ma grande surprise mais je soupçonne qu’il puisse y avoir une raison vis à vis de la manière de fonctionner de certains lecteurs qui construisent des sommaires automatiques.

Ouais, je pense que c’est à cause des solutions qui construisent des sommaires automatiques, même pas des lecteurs, et ce pour ne pas se retrouver avec le titre du livre dans toc.ncx.

À l’inverse, j’ai donc bien des livres où les titres sont de simples paragraphes mis en gras avec une police de caractère spécifique. Je ne comprends pas.

Pour l’anecdote, je me suis rendu compte il y a peu que souvent, ce genre de truc sort des solutions basées sur XML. Ce qui tend à confirmer la maxime (dont je ne connais plus l’auteur) : « XML, beaucoup d’évangélistes pour le pousser, très peu de spécialistes pour le maîtriser. » Je tendrais même à dire qu’il y a quelque chose qui ne va pas du tout dans le monde du XML parce que les fichiers les plus dégueulasses que j’ai trouvés ces derniers mois sortent systématiquement de solutions XML…

Quelques irréductibles continuent à simplement numéroter le fichier xhtml, avec de plus un numéro qui ne correspond pas à celui du chapitre. C’est dommage, on se coupe de potentielles réutilisations plus tard dans d’autres contextes.

Regarder du côté des outils de prod plutôt, je pense.

Je ne connais pas les problèmes de compatibilité des logiciels de lecture mais il y a-t-il vraiment des lecteurs qui ne sauront pas reprendre des règles CSS simples de marge et d’espacement ?

Oui. Il y en a même qui ne supportent aucune règle CSS simple encore aujourd’hui — et qui sont téléchargées plus de 5 millions de fois, coucou Android —, ce qui pousse certains à demander que l’IDPF mette en place une certification pour les solutions de lecture EPUB (cf. Editech 2014).

Tu as également des apps qui overrident les marges sur les paragraphes. Or, le saut de ligne à beaucoup de sens en Français (parce que le concept de paragraphe est très particulier en Français et largement différent du concept dans les autres langues), donc le perdre fait perdre du sens.

La question n’est pas de savoir si p — nbsp — p est du mauvais code ou pas. C’est juste que tu n’as absolument pas le choix.

Par contre, nous sommes OK que faire du p — nbsp — p pour faire des marges de page, c’est pas du tout à faire.

des manques d’espaces insécables devant ou après certaines ponctuation, avec des retours à la ligne malheureux.

Et c’est presque la norme…

Par contre, pour info, avec EPUB 3 et ses doctypes externes qui se sont envolés, il y a une petite problématique non négligeable : dans nombre d’outils, l’entité HTML chiffrée de l’insécable   est transformée en espace sécable, et ce bug est très répandu — j’ai déjà perdu des milliers d’insécables sur un ouvrage comme ça, raison pour laquelle je me suis intéressé à ce problème.

Dernier point relevé aujourd’hui, la présence de titres en lettres capitales, sans utiliser le style CSS dédié à cet usage. Je soupçonne un manque de compatibilité mais je doute quand même : Cette fonctionnalité est plutôt bien implémenté dans les moteurs web depuis longtemps.

Mais les mecs de chez Adobe n’ont pas daigné intégrer cela dans leur RMSDK — ça vient d’arriver avec l’implémentation de Readium…

Même avec les corrections ci-dessus on reste trop souvent avec un code en excès de et , avec des classes superflues et redondantes un peu partout, avec un mélange étrange et injustifiable de styles en ligne et styles externes.

Les outils, encore et toujours. Suffit par exemple de laisser InDesign exporter tout seul comme un gland et tu te retrouveras avec quasiment tout ce que tu as listé — et Dieu sait que beaucoup de problèmes pourraient être réglés si Adobe ne persistait pas sur son discours « c’est du WYSIWYG, on va pas vous emmerder en vous imposant le panneau de balisage d’exportation à l’export EPUB » (même si ça réglerait déjà une bonne grosse moitié du problème…).

Je ne vais pas dire que c’est la faute des outils, parce que c’est plutôt trivial de repasser derrière et d’améliorer quand tu connais ne serait-ce que les bases HTML et CSS mais force est de constater que la volonté des créateurs d’outils à persister sur le WYSIWYG aura fait énormément de mal à l’écosystème EPUB. On se retrouve quand même aujourd’hui avec des solutions de lecture qui se calent sur les exports typiques de ces outils pour appliquer des overrides, améliorer visuellement les fichiers et régler des incompatibilités (texte noir sur fond noir en mode nuit par exemple) mais, du coup, les mecs qui se cassent à faire des fichiers corrects se retrouvent comme des glands à devoir hacker ici et là pour éviter les overrides.

Bref, comme le proposait Baldur Bjarnason il y a 2 ans, désactivons CSS dans les apps et marrons-nous un bon coup en voyant 90 % des fichiers brûler dans les flammes des div et des span.