Du code HTML des livres numé­riques

J’ex­plore le code des ePub et je tombe sur des choses étranges : du code que je n’au­rai jamais accepté d’au­cun inté­gra­teur web avec qui j’ai travaillé jusqu’à présent, même d’un débu­tant.

Je ne parle pas des livres extrê­me­ment mal faits mais bien de livres dont l’en­semble du code fait croire qu’il a été produit par des outils intel­li­gents, voire nettoyé à la main par quelqu’un dont c’est le métier.

Ces livres là conti­nuent à avoir un code qui me semble étrange. Les moteurs de rendu des logi­ciels de lecture sont parfois mauvais. Il semble que les astuces et compro­mis se doivent d’être bien plus nombreux que ceux sur nos navi­ga­teurs web. Alors je demande à ceux dont c’est le métier, pouvez-vous m’éclai­rer un peu sur ce qui est normal ou pas, habi­tuel ou pas, jugé de qualité ou pas ?

Voici quelques exemples de ce que j’ai trouvé :

Images

<img alt="image" height="97%" src="…" style="width: 373px; height: 560px; ">

La couver­ture a pour texte alter­na­tif « image ». Dans d’autres exemples j’ai trouvé « couver­ture », « cover » et même « image.png ». Malgré mes recherches je n’ai trouvé aucun livre qui ait un texte alter­na­tif vide ou conte­nant le titre du livre (qui sont les deux choix que j’au­rai discuté dans le cadre d’un site web, suivant le contexte).

Dans d’autres images j’ai parfois trouvé des textes alter­na­tifs vides mais rare­ment. Le plus souvent c’est « image », « carte », ou « illus­tra­tion ». Je n’ai cher­ché que sur un échan­tillon mais d’ori­gine diverse : Aucun texte alter­na­tif présen­tant une réelle alter­na­tive – même limi­tée ou tronquée.

Sachant que le livre numé­rique offre poten­tiel­le­ment une réelle avan­cée sur l’ac­ces­si­bi­lité des textes aux personnes malvoyantes, je me dis qu’on gâche là une superbe oppor­tu­nité.

<img alt="cover" height="100%" src="…">

Dans mes explo­ra­tions j’ai vu pour un petit quart de livres conte­nant certaines illus­tra­tions avec un texte alter­na­tif anglais. « Cover » revient assez souvent. Là, il y a vrai­ment un lais­sez-faire que je ne peux pas comprendre quand le code est nettoyé à la main.

<img alt="image" height="97%" src="…" style="width: 373px; height: 560px; ">

Vient ensuite, et je l’ai retrouvé sur plusieurs sources diffé­rentes, un code qui m’étonne vrai­ment : un attri­but hauteur spéci­fié à 93, 95 ou 97%, cumulé à une CSS qui précise un nombre de pixel exact. J’ai même vu un 562.255px traî­ner, c’est dire l’exac­ti­tude – et mon incom­pré­hen­sion. Spéci­fier une taille rela­tive en attri­but ou une taille fixe en style peuvent se comprendre indé­pen­dam­ment l’un de l’autre. Je n’ar­rive cepen­dant pas à conce­voir dans cas il peut être perti­nent d’as­so­cier les deux.

Titres

Les titres c’est le domaine qui devrait être simple. On fait du <h1>, du <h2>, et ainsi de suite. Pour des raisons de compa­ti­bi­lité je peux comprendre qu’on ait une hiérar­chie qui ne soit pas la hiérar­chie théo­rique, mais…

<h1 id="Couverture" title="Couverture"></h1>

Je vois souvent des titres vides, tout simple­ment. J’au­rai pu le comprendre pour des raisons de compa­ti­bi­lité pour des entêtes de chapitre mais à y regar­der de plus près j’ai une part très signi­fi­ca­tive de livres qui n’ont aucune balise <h1> du tout, et qui fonc­tionnent très bien partout où je les ai essayé. Pourquoi ces titres vides ?

<p><a id="a2"></a><span class="t1"><b>Chapitre I – </b></span><span class="t1"><i>…</i></span></p>

À l’in­verse, j’ai donc bien des livres où les titres sont de simples para­graphes mis en gras avec une police de carac­tère spéci­fique. Je ne comprends pas.

<h1 id="PageTitre" title="Page Titre"></h1>

De même, la page de titre est un mystère pour moi. La grande majo­rité des livres choi­sissent de ne pas marquer comme titre <h1> le titre du livre, et de réser­ver 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 fonc­tion­ner de certains lecteurs qui construisent des sommaires auto­ma­tiques.

<h1 id="PageTitre" title="Page Titre"></h1>
<div>
<span>…</span>
</div>

Sur un livre récent et proba­ble­ment traité à la main j’ai même trouvé une combo avec une balise titre vide suivie d’un titre sous forme de para­graphe. C’était pour la page de titre (et non un titre de para­graphe).

Et le corps de docu­ment

<title>002</title>

Dans la plupart des lecteurs, la balise <title> reste inuti­li­sée, mais tout de même… Une bonne majo­rité reprend le nom du chapitre en court ou une indi­ca­tion simi­laire. Quelques irré­duc­tibles conti­nuent à simple­ment numé­ro­ter le fichier xhtml, avec de plus un numéro qui ne corres­pond pas à celui du chapitre. C’est dommage, on se coupe de poten­tielles réuti­li­sa­tions plus tard dans d’autres contextes.

<html xmlns="http://www.w3.org/1999/xhtml">

Un sur deux ne précise pas la langue du livre dans la balise <html> ou dans la balise <body> (ni aucune autre d’ailleurs). L’in­for­ma­tion existe peut être dans les méta­don­nées du livre lui-même, mais il s’agit selon moi d’une erreur si on veut permettre la lecture orale du livre.

<p>&nbsp;</p>

C’est cette marque qui m’a décidé à aller voir plus loin. J’ai l’im­pres­sion de reve­nir aux années 2000. Même dans un trai­te­ment de texte plus aucun profes­sion­nel ne devrait faire de chose pareille, alors chez un éditeur… Je ne connais pas les problèmes de compa­ti­bi­lité des logi­ciels de lecture mais il y a-t-il vrai­ment des lecteurs qui ne sauront pas reprendre des règles CSS simples de marge et d’es­pa­ce­ment ?

…moi ?</p>

C’est arrivé rare­ment, et plus exac­te­ment je n’ai pas réussi à retrou­ver de livres présen­tant ce problème, mais je me rappelle clai­re­ment l’avoir rencon­tré dans mes lectures : des manques d’es­paces insé­cables devant ou après certaines ponc­tua­tion, avec des retours à la ligne malheu­reux. Sur des livres avec un éditeur dont c’est le métier c’est presque inex­cu­sable.

<h1 id="Toc13" title="Treize">TREIZE</h1>

Dernier point relevé aujourd’­hui, la présence de titres en lettres capi­tales, sans utili­ser le style CSS dédié à cet usage. Je soupçonne un manque de compa­ti­bi­lité mais je doute quand même : Cette fonc­tion­na­lité est plutôt bien implé­menté dans les moteurs web depuis long­temps.

Pouvez-vous m’ai­der ?

Vous allez me dire que je suis poin­tilleux et qu’on se moque de tout ça, mais je n’ai relevé que ce qui pour moi relève de la faute. Même avec les correc­tions ci-dessus on reste trop souvent avec un code en excès de <div> et <span>, avec des classes super­flues et redon­dantes un peu partout, avec un mélange étrange et injus­ti­fiable de styles en ligne et styles externes.

Bref, je suis poin­tilleux par nature mais croyez bien que dans ce billet je suis encore loin de la qualité que j’at­tends d’un inté­gra­teur web avec qui je travaille. Là j’ai l’im­pres­sion de deman­der le mini­mum.

Je suis convaincu qu’il doit exis­ter des raisons à certains de ces choix. Je ne suis donc pas vrai­ment là pour poin­ter du doigt, mais pour expo­ser ma pensée et espé­rer que vous saurez m’ex­pliquer ces choix ou les contraintes qui ont mené à ces choix, pour que je comprenne et que je reparte moins igno­rant que je ne suis arrivé.


Publié

dans

, ,

par

Étiquettes :

Commentaires

19 réponses à “Du code HTML des livres numé­riques”

  1. Avatar de antoine

    Initiative très intéressante ! Peux-tu nous dire quels ont été les livres numériques qui t’ont servi d’exemples ?… Je suis bien conscient que ma question peut être délicate.

    1. Avatar de Éric D.
      Éric D.

      Je préfère éviter. L’objectif n’est pas de montrer du doigt, d’autant que ce dont je parle font plutôt partie des bons élèves si j’en crois certains retours comme celui du premier lien.

  2. Avatar de Mickaël Simon

    Quelques remarques rapides :

    * sur l’image de couverture, le code minimal et suffisant est expliqué sur le blog ADE : http://blogs.adobe.com/digitaleditions/2009/03/working_with_the_cover.html

    * sur la lecture orale : ce n’est pas obligatoire avec epub2 (OPS, section 3 « This specification does not require that Reading Systems implement text-to-speech or other read-aloud technology. ») ;

    * sur les lettres capitales : ADE ne comprend pas la propriété ‘font-variant’, qui date de 1996 ;

    * toutes les erreurs de code données en exemple ici sont bien contraires aux « EPUB Best Practices d’Adobe » : « If you have a heading, use the heading element. If you have a paragraph, use a paragraph element, etc. ».

    1. Avatar de Éric D.
      Éric D.

      Pour la lecture orale, la spec parle des logiciels de lecture qui ne sont pas obligés de la supporter (mais qui le peuvent, d’ailleurs certains le font). Elle ne dégagent pas du tout les auteurs du livre de faire du code accessible. Au contraire même puisque qu’en signalant que ce n’est pas une obligation des lecteurs, la spec implique bien qu’une partie des lecteurs aura cette possibilité.

    2. Avatar de Mickaël Simon

      Je suis curieux : quel moteur de rendu epub2 supporte la lecture orale ?

    3. Avatar de Éric D.
      Éric D.

      à peu près tous ceux qui sont simplement basés sur une intégration webkit directe dans Windows ou Mac. Même s’il n’est pas représentatif, Readium devrait donner tout ce qu’il faut pour un lecteur d’écran par exemple.

      Bon, le fait que l’image de couverture annonce « image » ne rend pas totalement mauvaise l’expérience d’une lecture d’écran non plus, mais ça reste quelque chose que je trouve dommage.

      Ça ne coutait pas cher de mettre au moins un texte alternatif vide. Quelqu’un a quand même passé du temps à remplir gentiment « couverture » ou « image » alors qu’il aurait mieux valu ne rien faire.

    4. Avatar de Mickaël Simon

      D’accord, donc en dehors des machines dédiées. Je connaissais la fonction Read Aloud spécifique à Apple. Je vais reprendre mes fichiers et relire les bases en attendant la sortie « EPUB 3 Best Practices ».

  3. Avatar de Nico
    Nico

    « &nbsp; »
    C’est cette marque qui m’a décidé à aller voir plus loin. J’ai l’impression de revenir aux années 2000. Même dans un traitement de texte plus aucun professionnel ne devrait faire de chose pareille, alors chez un éditeur… 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 ?

    Ou alors le qu’on retrouve souvent (en fait, même Sigil le fait comme ça). La simple et bonne raison pour laquelle les devs Sigil ont choisi cette solution étant que &nbsp; ne sera pas converti vers Kindle (alors que le le sera, tout comme les marges définies via CSS). D’ailleurs, Adobe a une documentation « EPUB Best Practices 1.0.3 » au format EPUB qui est bien cachée mais qui annonce clairement que les mises en page pour paragraphes, sauts de ligne, etc. doivent UNIQUEMENT passer par les styles, et pas avec un bricolage HTML, que ce soit   ou . Là, pour le coup, c’est quasiment une faute pro de remplacer par   au lieu de le faire via la CSS si on trouve que n’est pas bon…

    Pour les marges et espacements, oui, il y a des problèmes. Mais il y a des problèmes sur d’autres choses toutes simples comme les images sur ibooks, qui ne seront pas centrées si le texte est justifié dans la CSS (et qu’il faudra donc placer entre balises spans), ou des styles tout à fait standard qui ne passent parfois pas chez Adobe…

    En fait, c’est simple : on parle aujourd’hui de HTML5 et CSS3 pour EPUB3 à venir, le support EPUB « dans la vraie vie » équivaut au web de 1998. Les fabricants et devs se foutent juste de notre gueule, clairement.

  4. Avatar de karl

    On se souvient de l’export de Word vers HTML. Et bien voilà les mêmes enjeux qui arrivent en masse pour les auteurs. Les auteurs utilisent des outils et n’ont aucune connaissance du HTML (et ne doivent pas forcément en avoir une). Le monde de l’édition ne dégage pas encore assez de revenus pour engager des professionnels capables (compétence et temps) de fabriquer des epubs corrects. L’outil Pages de Apple permet de faire des exports… mais malheureusement avec du code pourri.

    En fait, c’est une étude sur les outils de production qu’il faudrait réaliser et de voir sectoriellement qui utilise quoi. La chaîne de production est définitivement faible et coûteuse.

  5. Avatar de Mickaël Simon

    Est-ce que les exemples cités viennent d’ePub francophones ? J’ai l’impression que les anglophones attachent beaucoup plus d’importance à la qualité du code ou que les discussions sont publiques : il suffit de suivre le hastag #eprdctn (https://twitter.com/search/eprdctn) pour s’en convaincre.

    1. Avatar de Éric D.
      Éric D.

      Uniquement du francophone, oui. Du libre de droit (créé main), différents éditeurs (grand, petit, pure player), et j’ai volontairement cherché deux livres de groupes de contrefaçon car j’avais en mémoire qu’ils reprenaient les livres à la main pour les retoucher.

      Je n’ai pas non plus fait une étude scientifique pour autant, j’ai regardé peut être une dizaine de livres en surface, et quatre ou cinq sérieusement seulement.

      Je ne suis donc pas en train de dire « ils sont nuls ces éditeurs ». Je plus là pour embrasser leurs contraintes avant de pousser plus loin.

    2. Avatar de Lecteursencolere

      Les ePubs anglophones sont dans la même veine contrairement à ce que l’on pourrait croire.
      N’oublions pas que la majorité sont vendu via Amazon (format propriétaire et DRM) et Barnes&Nobles (format propriétaire et DRM), c’est donc transparent pour des utilisateurs coincé dans leur éco système

    3. Avatar de Mickaël Simon

      « Je ne suis donc pas en train de dire : ils sont nuls ces éditeurs » : oui oui, j’ai bien compris et je ne l’ai pas pris comme ça.

  6. Avatar de Sébastien Périer

    Le   ne devrait pas passer. Sur iBooks, un ePub avec ça va générer des erreurs et l’utilisateur en sera averti par un gros rectangle jaune en tête de livre ou de chapitre (en fonction du découpage) avec la liste des   détectés ainsi que la ligne dans le HTML sur laquelle ils se trouvent.

    J’ai eu souvent ce problème sur mes premiers ePubs de tests exportés d’Adobe InDesign et analysés, puis modifiés main sous Sigil. InDesign ajoute des   quand on importe un document Word sans styles prédéfinis et que l’on saute deux lignes pour faire une délimitation entre deux paragraphes par exemple. Avec l’utilisation des styles ça ne devrais pas arriver (au pire, on aura une balise vide si l’auteur ne sais pas gérer les marges des styles et que l’intégrateur dans InDesign ne fait rien de plus pour le corriger), mais il est possible qu’un coquille reste.

    A noter que comme dit plus haut, le   affiche des erreurs sous iBooks, mais que de façon assez surprenante, il m’a été possible de soumettre un livre avec une telle erreur via leur outil iTunes Producer et le livre a été publié sans problèmes… (heureusement qu’ils permettent la mise à jour).

  7. Avatar de zelda
    zelda

    Je crée des livres numériques pour des éditeurs. Je suis passée à l’epub après des années de web et un peu d’expérience print, je fais mon code à la main et j’essaye au maximum de faire du code propre, sans superflu et sans incohérences. Je fais parfois des erreurs comme tout le monde et je me doute qu’en cherchant on trouvera toujours un détail à reprendre dans mes livres, mais *jamais* je ne rendrais du code à un client comme j’en ai vu dans certains livres que j’ai acheté (la plupart, même). D’ailleurs ça me démange tellement que je refais quasi systématiquement le code des livres que j’achète avant de les lire.

    Malheureusement, comme vous le dîtes, on voit beaucoup de n’importe quoi, c’est même assez choquant quand il s’agit de livres édités par des professionnels. Je pense que cela vient du fait que la plupart de ceux qui se sont reconverties en édition numérique n’ont aucune ou peu d’expérience avec le html / css, ignorent donc des principes de base derrière les règles pour valider un fichier, et n’ont souvent qu’une connaissance partielle même des balises qui servent à créer des livres.

    Ainsi donc l’attribut alt est nécessaire sur chaque image pour valider le code, mais selon le contexte, il vaut en effet parfois (souvent) mieux le laisser vide, et surtout cela n’a aucun sens d’y indiquer « image », ni même « couverture » puisque cela doit être indiqué dans les meta-données. Par contre pour l’image de couverture, y indiquer le titre du livre a du sens.

    De même je vois beaucoup d’informations de mise en forme qui devraient être précisées dans les css, et non pas dans le code html directement, comme la taille des images. Les tailles du style « 562.255px » sont des vestiges d’une conversion automatique depuis un logiciel de traitement de texte ou de mise en page papier et devraient être reprises.

    Les titres vides sont une aberration qui semble se généraliser, pourtant j’ai du mal à y voir une quelconque justification. Soit il y a un titre, auquel cas il faut le mettre dans la balise approprié, ne serait-ce que pour respecter une structure sémantique du document (sans parler de la table des matières). Si il s’agit d’un titre que l’on ne souhaite pas inclure dans la table des matières, il est possible de l’en exclure sans recourir à des bricolages de code (Sigil le fera tout seul même, il suffit de décocher une case ou de rajouter l’attribut dans la balise). Si l’on a une image que l’on souhaite faire figurer dans la table des matières (la couverture du livre par exemple), il suffit de mettre l’image directement dans la balise h, et de rajouter un attribut « title » pour définir le texte à afficher dans la table des matières (et en l’occurrence, de penser à renseigner l’attribut « alt » aussi). En aucun cas il n’est justifié de créer une balise h vide suivi du titre dans une balise p. Tout au plus, créer une balise h normal avec un titre que l’on souhaite faire figurer dans la tdm sans l’afficher dans le livre, et masquer ce titre avec une règle css (« display: none » par exemple), mais ça me parait un cas relativement rare.

    Les balises title ; selon le contexte, le plus approprié sera le titre du livre ou bien du chapitre en cours.

    La langue du livre : il s’agit de l’une des trois méta-données obligatoires pour un epub valide, il est donc superflu d’indiquer cela à nouveau dans le code html. Même en supposant que l’epub puisse être lu ailleurs que sur une liseuse, un moteur de rendu qui gère l’epub doit pouvoir lire ces méta-données et cela devrait être suffisant pour des fonctionnalités de synthèse vocal.

    Les balises p avec un espace insécable au lieu de gérer les marges dans les css, ainsi que l’absence de l’insécable pour la ponctuation ; du mauvais code, tout simplement.

    L’usage de capitales directement dans le code sans utiliser un style de transformation de texte est malheureusement dû au fait que les moteurs de rendu ne sont pas encore capables de gérer ce style, pourtant assez basique.

    C’est vrai qu’en parallèle au code automatisé ou simplement mauvais, il y a le problème des lacunes des moteurs de rendu actuels (même pour des styles basiques, comme text-transform). En plus des lacunes il y a les bugs divers et qui varient de l’un à l’autre, nous obligeant à tester sur un maximum de supports différents pour vérifier le rendu, le summum étant les implémentations propriétaires (iBooks en est jusqu’ici champion) qui obligent à utiliser des hacks à la IE6 des années noires de la guerre des navigateurs (que nous revivons version ebooks aujourd’hui, merci Apple !). Les span vides un peu partout ? C’était un bug d’iBooks qui refusait de tenir compte de la règle pour l’alignement du text (ferré à droit, centré) autrement (aujourd’hui corrigé, encore heureux, mais il en reste bien d’autres).

    Tout cela étant, optimiste, je me dis que forcément avec la généralisation du numérique on verra forcément des améliorations, autant du côté du code que du rendu. J’espère juste qu’elles ne tarderont pas trop.

    1. Avatar de Lecteursencolere

      On est bien d’accord Zelda :)

      La langue du livre va commencer à prendre son importance avec l’apparition des dictionnaires, surtout dans un livre multi langue. Et si la gestion de la césure se développe également, ce sera une nécessité.

      Les balise   ou peuvent éviter des soucis de conversion vers MOBI. Kindlegen et autres ont parfois des soucis avec la CSS interpara, allez savoir pourquoi…

  8. […] Du code HTML des livres numériques, article du blog Carnet de notes (n.survol.fr) […]

  9. Avatar de Pan
    Pan

    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 &#160; 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.

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *