Le blogde Chapal & Panoz

Livre numérique et qualité

Le livre numérique emprunte énormément au web. L’ouverture de la conférence Tools of Change (et #W3Cebook) n’aurait pas pu mieux nous la rappeler puisque la collaboration entre IDPF (organisme en charge du standard ouvert EPUB) et W3C (communauté en charge des standards du web) a été au cœur des débats.

Une autre idée importante est que ces organismes ont plus que jamais besoin des éditeurs pour connaître leurs besoins et savoir où aller. Or, aujourd’hui, les éditeurs se mettent seulement à apprendre ces nouvelles compétences et, en attendant, doivent faire confiance à d’autres pour gérer tout ou partie de leur production numérique. Cela pourrait se révéler être une catastrophe pour peu que des contrôles qualité stricts ne soient pas mis en place.

La « confiance aveugle »

Dans le domaine du livre numérique, la « confiance aveugle » consiste paradoxalement à ne juger le travail qu’au niveau purement visuel.

Dans chaque fichier (X)HTML qui constitue le contenu du livre numérique, par exemple un chapitre ou une section, le contenu est structuré à l’aide d’éléments sémantiques. Ces éléments permettent d’indiquer un rôle : ceci est un titre, cela est un paragraphe, ceci est une emphase, cela est le titre d’une œuvre, etc.

Le problème est qu’une vérification visuelle ne peut garantir le bon usage de ces éléments sémantiques puisque le livre numérique supporte également CSS, un langage utilisé pour décrire la présentation de ces éléments sémantiques. Par conséquent, on peut très bien faire passer un élément sémantique pour un autre visuellement.

Le titre d’un chapitre, par exemple, pourra être marqué

<h1>Titre du chapitre</h1>

ou

<p class="titre-centre">Titre du chapitre</p>

avec, niveau CSS

p.titre-centre {
   font-size: 2em;
   text-align: center;
   text-indent: 0;
   …
}

Dans le deuxième cas, le marquage n’est pas bon du tout. Le titre n’utilise pas l’élément sémantique qui lui est dédié, à savoir h1. En réalité, ce n’est qu’un paragraphe dont on a modifié la présentation pour le faire ressembler à un titre.

Or, quand la structure n’est pas marquée à l’aide des éléments sémantiques corrects, il y a problème. Le moteur de rendu ne pourra pas par exemple rendre une structure correcte au lecteur (si, par exemple, les styles de présentation CSS ne sont pas supportés, et le support CSS n’est qu’optionnel pour EPUB 3). Plus grave encore, cela a un impact dévastateur sur l’accessibilité du contenu (aux personnes avec un handicap).

Cet exemple est malheureusement très courant, et on peut le considérer comme l’erreur de base à ne pas faire. Si vous pensez que ce ne peut pas être réellement possible de coder aussi mal, la preuve par l’image :

Nous nous concentrons ici sur le paragraphe déguisé en titre (chap-tit) mais sachez que d’autres choses ne vont pas du tout ici…

Bref, si vous retrouvez ceci dans vos fichiers, considérez qu’ils ne sont pas d’une qualité suffisante pour être commercialisés. Ils pourraient même poser de gros problèmes de pérennité. Ne comptez même pas sur certains revendeurs connus pour vous aider : les intérêts commerciaux passant avant les intérêts communs, des fichiers non valides sont quand même distribués… C’est pour ces raisons qu’il faut absolument mettre en place une vérification du code et ne pas partir du principe que tout est OK.

Un code illisible est un bon indicateur de qualité

Un code illisible peut être plusieurs choses.

Cela peut être les styles de présentation qui sont directement indiqués dans les éléments sémantiques (balises) alors qu’il serait plus judicieux de les organiser dans une feuille de styles CSS.

<p style="font-size: 12px; text-indent: 10px; 
line-height: 18px; margin: 0px; text-align: justify;">'A
cheap sort of present!' thought Alice. 'I'm glad they
don't give birthday presents like that!' 
But she did not venture to say it out loud.</p>
<p style="font-size: 12px; text-indent: 10px;
line-height: 18px; margin: 0px; text-align: justify;">
'Thinking again?' the Duchess asked, with another dig of
her sharp little chin.</p>
<p style="font-size: 12px; text-indent: 10px;
line-height: 18px; margin: 0px; text-align: justify;">'I've
a right to think,' said Alice sharply, for she was beginning
to feel a little worried.</p>

Cela peut être des classes d’éléments sémantiques dont on a beaucoup de mal à déterminer la fonction parce que leur nom est particulièrement mal choisi (courant lorsque la production est automatisée).

Impossible de deviner la fonction de certaines classes ici. C’est pourtant typiquement ce que vous exportera InDesign… et les maquettistes consciencieux ne savent que trop bien qu’ils doivent modifier à la main ensuite pour obtenir quelque chose de correct.

Cela peut également être une feuille de styles en embonpoint, compréhensible seulement par une machine (même son créateur étant incapable de la reprendre), qui répertorie des centaines de classes dont 90 % ne sont pas utilisées.

2187 lignes dans la CSS, des classes à déchiffrer, etc.

Pour information, une feuille de styles CSS adaptée à un roman dépasse rarement les 500 lignes. Si elle en fait beaucoup plus, c’est qu’il y a un problème. Dans les faits, cela veut simplement dire qu’on a utilisé une feuille de styles générique et qu’on a pas enlevé ce qui n’est pas utilisé.1 Or, comme la feuille de styles est chargée entièrement, les styles non utilisés sont donc chargés pour rien.

Combien de classes ne sont pas utilisées dans l’exemple ci-dessus ?

La liste ne rentre même pas dans un écran d’iMac 24 »…

D’une part, ces pratiques multiplient les risques de problèmes. Quand tout est illisible, il devient difficile de suivre et l’on fait des erreurs.

D’autre part, si quelqu’un doit reprendre ces fichiers parce qu’il y a problème, alors il devra tout reprendre de zéro pour faire les choses correctement. Du temps perdu uniquement parce que le travail a été mal fait au départ, et pour avoir corrigé une pelleté de fichiers posant problème, certains excellent vraiment là-dedans… Et les fichiers ont toujours la même origine.

Les petits détails embêtants qu’il faut savoir repérer

Nous arrivons au stade où il faut un peu connaître l’écosystème du livre numérique, ses limitations et ses bonnes pratiques. C’est quelque chose qui n’est pas forcément facile à faire, d’autant que les gens qui maîtrisent entièrement le sujet sont assez peu nombreux — et ne se trouvent pas forcément là où nous pourrions le penser. Cela exige des tests, des tests et encore des tests. Force est de constater qu’aujourd’hui, nous sommes plus sur le mode « ça passe visuellement sur iPad donc c’est OK ».

On pourrait par exemple citer les valeurs font-size exprimées en pixels ou points, qui interdiront aux lecteurs de modifier la taille de caractères sur certains appareils de lecture. C’est une très mauvaise pratique EPUB encore très commune aujourd’hui, malheureusement.

On pourrait également citer les propriétés préfixées -webkit- sans leur équivalent standard, epub ou adobe (quand ceux-ci existent, bien sûr). Cela ne fait que démontrer que le fichier a été codé pour iBooks… et tant pis pour les autres

On pourrait éventuellement se concentrer sur le nombre de valeurs de styles CSS qui s’annulent entre elles, signe que la feuille de styles n’est pas aussi bien pensée qu’elle le devrait.2

Et ainsi de suite, les domaines d’amélioration étant assez nombreux.

Est-ce si grave de transiger sur la qualité ?

Premièrement, cela revient à commercialiser un produit avec des défauts de conception/fabrication. Vous ne le feriez pas avec une voiture, pourquoi le feriez-vous avec un livre numérique. La réputation de l’éditeur est en jeu, et elle le sera de plus en plus. Dans quelques années, l’éditeur qui commercialisera des fichiers codés n’importe comment sera peut-être considéré comme l’éditeur qui publie des livres papier de mauvaise qualité. C’est à méditer.

Deuxièmement, quand le code pose des problèmes aux revendeurs et développeurs d’applications ou services de lecture, et quand les fichiers qui posent problème sont trop nombreux, alors l’écosystème n’est plus sain et des décisions lourdes de conséquences sont prises.

Parce que les fichiers deviennent ingérables, leurs styles de présentation sont ignorés par défaut, ou alors certains sont remplacés par des styles choisis par les développeurs, ou parfois ces fichiers sont tout bonnement modifiés… pour ne plus poser de problème.

Ces décisions se répercutent à l’ensemble des éditeurs, y compris ceux qui mettent un point d’honneur à publier des fichiers de qualité. Ils ne peuvent malheureusement que se plaindre aujourd’hui, les choses ne changeront que quand la qualité moyenne des livres numériques ne posera plus de problème. En attendant, c’est tout l’écosystème qui pourrit lentement mais sûrement…

* * *

  1. L’application Sigil propose un outil très pratique pour lister tous les styles non utilisés.
  2. Même s’il faut avouer que l’on doit parfois dégrader la qualité de la feuille de styles CSS pour tel ou tel revendeur.

2 Comments

  1. 18 février 2013

    À la lecture de cet article, on se pose une fois de plus la question du format ePub. Pourquoi un format spécifique là où du HTML assez simple suffirait ?
    Ayant l’habitude de travailler sous OpenOffice/LibreOffice en utilisant les styles de base, je ressens les comportements que vous décrivez comme des héritiers plus ou moins lointains de Word…

    • jiminy
      18 février 2013

      Alors, la question se pose vraiment aujourd’hui avec EPUB 3 — elle se posait déjà timidement avec EPUB 2 — parce qu’il semble qu’il soit assez complexe à implémenter. Les développeurs d’Azardi, Infogrid Pacific, prévient déjà que l’implémentation générale d’EPUB 3 va être très hétérogène, pire que celle d’EPUB 2 qui est déjà loin d’être au top.

      Du coup, on voit apparaître ce genre de réflexions : http://epubzero.blogspot. Et il faut savoir que des tentatives ont déjà été faites avant avec Hpub et Zhook, qui n’ont pas vraiment décollé.

      Dans l’article, nous nous sommes concentrés sur HTML et CSS. C’est vraiment la chose la plus importante à prendre en compte. Nous aurions pu parler des métadonnées, des problèmes de structure, d’EpubCheck qui garantit seulement certaines choses et qui ne doit pas faire l’objet d’une confiance aveugle, des fichiers non valides qui sont quand même distribués par certains revendeurs parce qu’il ne faut pas froisser l’éditeur qui a bien voulu numériser, etc.

      Du coup, ces problèmes existeraient aussi dans un écosystème basé sur HTML–CSS (difficile d’imaginer faire sans CSS, il y a tout une dimension de design éditorial à prendre en compte et à laquelle HTML ne peut offrir de solutions). Les raisons peuvent être diverses, mais le plus décourageant, c’est qu’ils sont plus la norme que l’exception actuellement.
      Ces problèmes là ne sont pas liés au format, ils sont liés à la production. Ils ne sont même pas purement techniques, ils ont également à voir avec l’humain (économies de bouts de chandelle, m’en foutisme, compétences pas forcément adaptées à ce domaine précis, chaîne de production mal pensée, etc.).

      Ce que nous avons également souhaité dire, c’est que l’asynchronie d’information n’aide pas. Parce que les éditeurs ne savent pas forcément encore bien gérer ces nouveaux domaines techniques (pour eux), alors ils ne peuvent pas pousser vers la qualité. Or, beaucoup vont leur dire que tout est possible, qu’il n’y a aucun problème à faire ça, ça et ça alors qu’il est tout simplement impossible de le faire techniquement (et qu’on peut même leur fournir la documentation technique qui explique que c’est impossible). Je ne vais pointer personne du doigt — et de toute manière je n’en ai pas assez —, mais c’est un problème assez grave, d’autant que ce sont ceux qui essayent de faire les choses correctement qui vont crever les premiers à ce rythme.