CSS, ePub et la typographie du livre électronique

Le format ePub semble en voie de s’imposer comme le nouveau standard de livre électronique, adapté pour une lecture sur toutes sortes d’écrans : de celui de l’ordinateur jusqu’au téléphone portable.

Or, qui dit « livre », dit « typographie ». On peut rétorquer que parler ainsi d’une publication électronique est encore rester dans la métaphore du livre papier traditionnel. Toutefois, il faut garder à l’esprit que ce dernier a amplement fait ses preuves, et qu’il reste adapté à nos habitudes de lecture, pour les avoir créées. À moins de trouver un moyen révolutionnaire de présenter les contenus, qui changerait radicalement la façon dont nous parcourons un texte, la page de livre « classique » reste la plus adaptée, en particulier pour rester concentré sur un texte long.

Certes, il faut que le texte soit recomposable à la volée selon différents écrans et formats de page. Il doit proposer une navigation aisée en ce qui concerne les notes ou les liens hypertexte. Il peut offrir des fonctions supplémentaires comme la présence d’un dictionnaire lors d’un clic sur un mot, ou l’inclusion de fichiers vidéo et audio. Sans oublier les fonctions de recherche, d’annotation, et d’indexation. Néanmoins, il faut bien penser que derrière tout cela, il y a le lecteur, humain, qui n’est pas forcément disposé à changer ses habitudes.

Étant donné qu’ePub se base sur du XHTML et du CSS (présentement une partie de CSS 2), il semble indispensable d’utiliser au maximum les fonctions présentes et à venir des feuilles de style en cascade.

Les normes CSS 2 et 3, qui sont en développement depuis des années (CSS 2 est une recommandation datant de 1998, voir sur http://en.wikipedia.org/wiki/Css), et pas encore totalement implémentées, semblent porteuses de nombreuses possibilités offrant un compromis entre un texte recomposable à la volée et une typographie soignée. En particulier, le module « CSS 3 Text ». Il existe un site consacré à ces questions, www.webtypography.net, qui s’inspire ouvertement du livre de Robert Bringhurst, The Elements of Typographic Style, qui est considéré à juste titre comme une référence dans la mise en page papier. Ce billet, qui ne prétend pas à l’exhaustivité, est ouvertement inspiré par ce site.

Polices embarquées

Tout d’abord, le format Epub propose d’inclure la police de caractères de son choix, en format Opentype, notamment, ce qui ouvre encore plus de possibilités. Pour cela, il faut faire appel à la propriété @font-face (CSS 3 Web Fonts Module).

L’exemple ci-dessous permet d’importer la police « Goudy Old Style », qui se trouve dans un répertoire « /fonts » du site. Cette police pourra ensuite être utilisée dans le document HTML. Cet import est actuellement supporté par certains navigateurs (Safari, et Opera, notamment).

@font-face {
font-family: "Goudy Old Style";
src: url("http://site/fonts/GoudyOS.otf")}

Toutefois, Epub étant un simple fichier .zip, il semble épineux d’utiliser des jeux de caractères non libres de droits : les polices sont en effet aisément récupérables en ouvrant le fichier, contrairement à l’encapsulage proposé par le format PDF. L’utilisation de caractères libres de droits et de qualité pourrait être un bon compromis (voir la licence SIL Open Font License (OFL) à ce propos : http://scripts.sil.org/cms/scripts/page.php?site_id=nrsi&item_id=OFL).

L’IDPF réfléchit actuellement à la possibilité de brouiller les polices afin qu’elles ne soient pas réutilisables aisément.

Formats de page, titres courants…

Toute la spécification « Paged Media » est consacrée au contenu paginé (par opposition au contenu en « continu » classique des pages web). Une traduction (non officielle) des spécifications de ce module est disponible à cette adresse : http://www.yoyodesign.org/doc/w3c/css2/page.html

Grâce à la règle @page, il est possible de définir les tailles de la justification, des marges, etc. Beaucoup d’autres options concernent des propriétés destinées à l’impression, puisque cette spécification est avant tout dédiée à cet usage. Mais il est intéressant de noter que des pages de gauche et des pages de droite peuvent être distinguées (ce qui permet d’adapter les marges pour une lecture en recto-verso, notamment).

Pour se rapprocher d’une mise en page « classique », la spécification CSS 3 Paged Media ajoute encore des propositions utiles. Notamment les titres courants.

Exemple :

@page :left {
@top-left {
content: "Chapitre 1 : Introduction";
}
}

Cette instruction ajoute la mention « Chapitre 1 : Introduction » sur toutes les pages de gauche.

Césure & justification

Les CSS ne gèrent actuellement pas les césures, ce qui peut occasionner des blancs disgrâcieux dans des textes justifiés. Pour remédier à ce manque, les CSS3 proposent une propriété, hyphenate, qui pourrait s’avérer intéressante, permettant notamment de contrôler le nombre de caractères minimum avant et après chaque mot (hyphenate-before, hyphenate-after), ainsi que le nombre maximal de lignes comportant des césures (hyphenate-lines). Évidemment, effectuer des césures requiert la présence d’un dictionnaire en fonction de la langue du texte : c’est une chose prévue par la spécification (hyphenate-dictionary). Il est possible de faire référence à un dictionnaire interne à la machine ou au navigateur avec la valeur auto, ce qui éviterait d’alourdir chaque fichier (en revanche, la présence de ce dictionnaire est alors indispensable.

L’existence de contenus en plusieurs langues au sein d’un même article est également une donnée à prendre en compte.

Sauts de page, veuves & orphelines

La spécification CSS for Paged Media prévoit une gestion des sauts de page ainsi que des veuves et orphelines, même si cette dernière notion peut ne pas sembler des plus urgentes dans l’ordre des priorités. Comme son nom l’indique, cette notion n’est valable que sur des documents ayant une taille de page définie (règle @page)

page-break-before et page-break-after stipulent respectivement qu’un saut de page doit être fait avant ou après un élément donné. La syntaxe est la suivante :

h1 {
page-break-before:always }

Ici, chaque fois qu’un titre de niveau 1 est rencontré, ce dernier démarre sur une nouvelle page.

.section {
page-break-after:always }

Ici, chaque bloc de la classe « section » doit démarrer sur une nouvelle page.

La propriété page-break-inside empêche les éléments concernés d’être répartis sur plusieurs pages :

h1, h2, h3, h4, h5, h6 {
page-break-inside:never }

Cet exemple stipule que les titres de niveau 1 à 6 ne doivent jamais se retrouver à cheval sur plusieurs pages.

Enfin, en ce qui concerne les veuves et orphelines à proprement parler, l’exemple ci-dessous indique que tous les paragraphes ne doivent jamais avoir moins de 4 lignes au commencement d’une page (widows : veuves), et jamais moins de 4 lignes à la fin d’une page (orphans : orphelines) :

p {
widows:4;
orphans:4 }

Chiffres suspendus

Un autre point de finesse typographique, mais pas franchement prioritaire, est la possibilité d’utiliser soit des chiffres alignés soit des chiffres suspendus (elzéviriens) par l’intermédiaire d’une propriété, et non en utilisant directement la référence Unicode du caractère. Ce qui permettrait de les changer à la volée par une feuille de style.

Peu de polices couramment utilisées pour le web proposent à la fois la variante alignée et la variante suspendue des chiffres. Par exemple, Georgia est la seule police basique qui possède des chiffres suspendus. En revanche, elle ne propose pas de chiffres alignés. Mais cette restriction ne s’appliquerait pas dans le cas d’un livre électronique, s’il est possible d’ajouter la police de son choix, comme précisé plus haut.

Cette distinction n’est actuellement prévue dans aucune des spécifications CSS. Le site Webtypography suggère l’implémentation d’une propriété comme numeral-variant, dans le style de font-variant qui pourrait prendre plusieurs valeurs, comme old-style pour des chiffres suspendus, et lining pour les chiffres alignés. Ou plus simplement, en reprenant les valeurs normal, uppercase, lowercase, small-caps déjà existantes.

Ces quelques propriétés ne constituent qu’une petite partie des choses possibles. Des fonctions bien plus avancées en terme éditorial sont à prévoir. Notamment, en ce qui concerne la gestion des tables des matières, notes de bas de page, ainsi que les références croisées (indispensable pour de l’édition scientifique). Voir à ce sujet le blog d’Hadrien Gardeur, plus connu comme le créateur de Feedbooks : http://blog.feedbooks.com/fr/?p=50

En guise de conclusion, rappelons tout de même que si une présentation très soignée du côté éditeur est souhaitable, il faut néanmoins qu’elle ne soit pas rigide : l’utilisateur doit pouvoir s’il le souhaite afficher le texte selon sa préférence (plus gros, avec une police différente, etc.). C’est un des intérêts de l’édition électronique. Certains sont d’ailleurs plutôt en faveur d’une mise en page la plus simple possible, sans fioritures, afin d’obtenir une adaptation optimale sur des supports très différents.

Liens

http://www.w3.org/TR/css3-text/ : le module CSS Text Level 3 sur le site du W3C.

http://www.alistapart.com/articles/boom : article intéressant sur la réalisation d’un livre en CSS, avec les sources et le résultat final (XHTML + CSS converti en PDF par le logiciel Prince, qui interprète correctement les fonctions CSS 2 liées aux pages, ce qui n’est pas le cas de l’ensemble des navigateurs).

Crédits photographiques : Matt Wright, licence CC. http://www.flickr.com/photos/mattwright/521804/


Vous aimerez aussi...

7 réponses

  1. Tebaldo dit :

    « Le format ePub semble en voie de s’imposer comme le nouveau standard de livre électronique »… pas pour Google (HTML5 à priori) ni Apple (PDF, HTML5 et formats spécifiques), et pas pour les éditions enrichies, en tout cas. Adobe garde d’ailleurs bien la distinction ePub et PDF recomposable.

  2. Soft hyphen dit :

    Quoi, quoi, quoi ! …
    Pas de césures ?
    Et le « trait d’union conditionnel » alors ?
    En HTML :
    ­

    • Pierre André dit :

      Oui, vous avez raison pour le trait d’union conditionnel (soft hyphen). Mais cela implique de les insérer dans le texte, alors que la césure dont il est question ici serait automatique (basée sur un dictionnaire).

      • Soft hyphen dit :

        Ah…
        Le code HTML pour le trait d’union conditionnel
        ne s’est pas affiché comme je le voulais :
        esperluette, s, h, y, point-virgule

        Et, oui, c’est vrai que ça implique de les insérer dans le texte…
        Mais ce n’est pas le plus compliqué :
        tout d’abord, il existe des dictionnaires de césures,
        et ensuite, il commence à y avoir des outils très intéressants pour automatiser la césure…

        Comme par exemple, entre autres :
        http://plugins.spip.net/cesure-automatique

  3. Tebaldo dit :

    Le problème pour la césure de qualité, c’est de la faire à la volée. Passe encore pour des ordinateurs puissants (et même, il faut pour certains ouvrages utiliser des logiciels spécialisés comme InDesign), mais pour des dispositifs légers à base d’encre électronique, c’est quasiment impossible. D’où, soit l’émergence de nouveaux formats, soit l’abandon de la césure pour les contenus courants (mais ce serait dommage).

  4. Mike Cane dit :

    You are the only blog I have seen bring up the issue of hyphenation! Not a single one in America has done so!

    I was confronting this issue back in the *1980s* for word processing software and still cannot believe that near 30-years later it is again being discussed for « eBooks. »

    >>> Hence, the emergence of new formats, or the abandonment of the distinction for the current content (but it would be a shame).

    The current « standard » will be thrown away anyway because it is doomed to failure. The mass public will reject it:

    Why eInk, ePub, And eBooks Will Fail
    http://snurl.com/pj3ev

  5. Bob dit :

    J’avais raté ce billet fort intéressant.
    Je suis confronté en ce moment au même problème : je réédite un livre au format PDF en utilisant Latex : les césures sont donc quasi parfaites. Mais en ePub, le résultats n’est pas franchement propre, blancs, césures aléatoires.
    Alors, est-ce le format que nous devons améliorer ou est-ce les moteurs de lecture ? La spécification ePub prend-elle réellement en compte ces problèmes de césures ?

Laisser un commentaire

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