Comme on a pu récemment en débattre sur le blog de Virginie, le passage à une industrie numérique du livre demande toute une restructuration de la chaîne de production des contenus.

Choisir la bonne DTD pour la représentation abstraite de son texte, mettre en place un ensemble de bonnes pratiques pour s’assurer de la pérennité de l’information, faire face aux possibilités comme aux limites de chaque format… Il y a de très (trop ?) nombreux paramètres à prendre en compte, pour bien effectuer le virage vers un monde de l’édition numérique.

Note de bas de page

Afin d’illustrer tout cela, voici donc un petit exemple d’une problématique revenant assez souvent: les notes de bas de page.
C’est l’exemple même d’un de ces éléments pour lesquels on ne peut pas séparer le fond de la forme. Mettons de côté le PDF, qui de toute façon se comporte comme une image et peut donc restituer n’importe quel élément de mise en page (et qui est donc en contrepartie très peu adaptable).

En OEB

En OEB (qui sert de base au format Mobipocket et LIT) on est essentiellement limité à du HTML. Les notes de bas de page ne sont donc pas affichés dans le bas de la page, ce sont en général de simples liens qui pointent vers la fin du document:

Cette phrase a une note de bas de page<a href="#footnote1"> [1]</a>
<p id="footnote1">[1] Texte affiché en bas.</p>

Il y a 2 problèmes avec cette représentation.

Tout d’abord au niveau de la mise en page, une note de bas de page perd une partie de son sens si elle n’est pas affichée dans le bas de la page. J’ai pu assez souvent lire que dans un monde numérique, toutes les notes peuvent être représentées de la sorte, via un simple lien. Des études ont montrées que la la très grande majorité des lecteurs lisent les notes de bas de page, je ne sais pas si une étude similaire a été réalisée sur les notes qu’on retrouve à la fin d’un ouvrage, mais je suis prêt à parier qu’un nombre beaucoup plus limité de lecteurs font attention à celles-ci.

Selon les cas, on ne va pas utiliser le même type de notes. Prenons l’exemple de “Guerre et Paix” de Tolstoï. Je suis en train de lire cette oeuvre en anglais, or dans de nombreuses traductions, le traducteur a fait le choix de laisser les passages en français et de traduire ceux-ci dans des notes de bas de page. Etant donné que ces traductions sont indispensables à la bonne compréhension du texte, il est normal qu’elles soient affichées sur la même page. On pourrait déjà dire que devoir faire l’aller-retour entre le corps du texte et les traductions dans le bas de la page aura tendance à couper le rythme de la lecture. Devoir changer de page à chaque traduction deviendrait alors carrément insupportable.

A l’inverse, disons que je suis en train de lire un roman de Proust. Celui-ci avait tendance à considérablement retravailler ses manuscrits. Dans certaines éditions, on trouve des notes détaillant ces modifications d’une version à une autre. Leur lecture n’est pas indispensable à la compréhension du texte, et on pourrait considérer qu’elles sont utiles pour une étude plus détaillée du texte, en guise d’annexe. Dans ce cas, il vaut mieux ne pas mettre ses notes dans le bas de la page, mais à la fin du volume.

Bien sûr, la taille de l’écran reste aussi un facteur important à prendre en compte, et sur un téléphone portable, on peut comprendre qu’il soit difficile d’afficher des notes de bas de page. Mais c’est au lecteur (le logiciel) de décider s’il peut ou non afficher celles-ci dans le bas de la page, via une fenêtre pop-up, ou dans une page séparée. Il ne doit pas y avoir d’incidence dans la représentation du texte.

Un autre problème réside dans l’utilisation de ce fichier comme format “source”. Ce serait une erreur d’utiliser un format aussi limité afin d’effectuer une conversion. On pourrait ajouter un minimum de sens en modifiant le code de la sorte:

Cette phrase a une note de bas 
de page<a href="#footnote1" class="footnote-mark"> [1]</a>
<p id="footnote1" class="footnote-text">[1] Texte affiché en bas.</p>

On ajoute ainsi le minimum d’information sémantique nécessaire, à savoir indiquer que ce lien correspond:

1. à une note de bas de page
2. que la première partie est l’appel de la note
3. que la deuxième partie correspond au texte de la note

Tout cela restant très limité tout de même, car on imagine que d’un texte à l’autre on ne retrouvera pas la même utilisation de @class et qu’en plus, on ne devrait pas avoir besoin de numéroter manuellement les notes si tout cela était correctement représenté.

En EPUB

Le format EPUB est en fait un assemblage de 3 standards: Open Publication Structure (OPS), Open Packaging Format (OPF) et Open Container Format (OCF).
Comparé à son ancêtre l’OEB, l’OPS s’appuie sur deux vocabulaires XML: DTBook et XHTML1.1 (ainsi que du CSS2 pour les feuilles de style). L’EPUB est très flexible grâce à l’OPF qui permet d’employer d’autres formats (utile pour des applications rich-media) ou DTD si on le souhaite, à condition de toujours préciser une solution de replis (un document DTBook ou XHTML1.1 dans ce cas).

… en DTBook

DTBook du DAISY Consortium est un standard essentiellement destiné aux personnes handicapées, et donc orienté sur l’accessibilité. Comparé à du XHTML, on remarquera que le DTBook favorise l’utilisation d’éléments vraiment propres à un livre.
Par exemple pour un chapitre on utliliserait en XHTML 1.1:

<h1>Chapitre 1 Le début</h1>

Alors qu’en DTBook on doit forcément écrire:

<level1 class="chapter">
<h1>Chapitre 1 Le début</h1>
</level1>

Pour en revenir à nos moutons… Selon la documentation DTBook, on doit définir une note de bas de page ainsi:

<noteref class="footnote" idref="fn1">1</noteref>
<note class="footnote" id="fn1">...</note>
 
<noteref class="endnote" idref="en4">4</noteref>
<note class="endnote" id="en4">...</note>

On le remarque tout de suite, ça correspond globalement au dernier exemple que j’ai pu donner sur l’OEB, à savoir suivre un ensemble de bonnes pratiques sur du XHTML. A la différence qu’ici, le vocabulaire est un peu plus étendu (on utilise une balise noteref et une balise note) et que les valeurs pour @class sont fixées (footnote, endnote…). Un certain progrès donc comparé à l’OEB: on différencie les différents types de notes tout en laissant au système de lecture le choix dans la manière de les interpréter, l’utilisation des balises ainsi que de @class et @id étant fixés, on a aussi un format qui peut être utilisé facilement comme format source.

Par contre il y a toujours 2 points qui me fâchent:

1. la séparation entre l’appel de note et la note elle-même n’a pas lieu d’être: on devrait avoir un élément unique dans le corps du texte et non deux éléments. Ca n’a aucun sens, si ce n’est permettre de numéroter comme on le souhaite les notes.
2. la numérotation est manuelle alors qu’elle devrait être automatique. Si j’ajoutais une nouvelle note de bas de page au milieu de mon texte, je devrais alors reprendre toute la numérotation de mes notes de bas de pages ? C’est parfaitement idiot.

Bref, avec du DTBook, on se rapproche un peu de la solution mais on y est pas encore…

… en XHTML 1.1

Bien que DTBook soit une composante de base de l’EPUB, la majorité des documents utiliseront du XHTML 1.1 plutôt, le DTBook se destinant vraiment à un public pour lequel l’accessibilité est primordiale. Il faut donc se pencher sur les possibilités en XHTML 1.1 + CSS 2.0, plus quelques propriétés CSS en plus en oeb-*.

On remarque en particulier 2 valeurs de @display. Les développeurs Web connaissent bien display, par exemple pour cache du texte:

<p style="display: none">Texte</p>

On a donc en plus de cela la possibilité de fixer @display à oeb-page-head ou oeb-page-foot. Pour reprendre l’exemple de la documentation officielle:

<div>
   <div class="myhead" style="display: oeb-page-head">
      The OEB Publication Structure: Introduction
   </div>
   <h2>Introduction</h2>
   <p>...</p>
</div>

Ici ils utilisent donc @display, pour avoir une en-tête de page. Un besoin qu’on peut tout à fait classique, mais pourtant, l’utilisation exacte de ces 2 valeurs ne semble pas tout à fait évident, si on continue de lire la description de ceux-ci:

“The content of an element assigned display: oeb-page-head should be presented only as a header, and the content of an element assigned display: oeb-page-foot should be presented only as a footer. Neither should be simply presented as if it were inline or block. Reading Systems, however, are free to present headers and footers either in special areas as usual for paper publications, or to make them available in another way. For example, a device with a small screen might instead pop them up on demand. For purposes of page layout, these display values are similar to block boxes with an absolute position (i.e. a position value of fixed or absolute). That is, they are removed from the normal flow and a new block box is created with its own flow. Margins, padding and other block characteristics are determined as if the element had position: fixed set.”

Confusion, confusion, confusion… Si ces éléments ne servaient qu’à afficher des en-têtes des chapitres, et autres éléments plutôt décoratifs, pourquoi préciser l’utilisation possible de pop-up ? Ils doivent donc considérer qu’on peut aussi utiliser ces 2 zones, pour afficher quelque chose comme des notes de bas de page non ?
Donc en reprenant mon exemple en OEB, il me suffirait d’ajouter des éléments de style:

<style>
 
.footnote { display: oeb-page-foot }
</style>

Le problème avec l’utilisation de simplement oeb-page-head et de oeb-page-foot, c’est que des en-têtes et des notes de bas de page doivent avoir un comportement complètement différent. Ok pour afficher des notes dans une fenêtre pop-up si l’écran est trop petit, mais afficher le nom de mon chapitre dans une fenêtre pop-up sur chaque page ? Pas question. S’ils ont donc correctement identifié un besoin d’avoir un meilleur contrôle de la page, l’approche retenue est résolument simpliste. Il faut non seulement pouvoir contrôler beaucoup plus d’éléments que cela, mais aussi leur assigner un comportement différent selon la taille de l’écran (oui, ça se complique).

En plus, Adobe Digital Editions 1.5 ne supporte toujours pas oeb-page-head et oeb-page-foot (un mauvais point pour Adobe, même si globalement ils supportent assez bien le standard EPUB). Ils ont ajouté entre temps un support sur oeb-column-number, qui permet d’éviter de passer automatiquement en multi-colonnes (utile sur une page de titre par exemple) mais pas encore sur ce CSS un peu trop limité, préférant recourir à leur solution maison: XPGT.

Adobe et XPGT

XPGT pour XML Page Template, est une extension au standard EPUB employée par Adobe pour Digital Editions. Selon le “EPUB Best Practice Guide” (peut-être devrais-je traduire ce document en français à l’occasion ?), cela regroupe:

• Page Masters – specify XSL:FO page masters to add headers, footers and sidebars as well as multi column layout.
• Dynamic Page Master Selection – choose the right page master based on the environment.
• Dynamic Styling – style the document based on the environment (viewing area dimensions, default font size, device resolution, etc.)

Ce qui donne grosso-modo:

• Définition d’une page en XSL:FO
• Sélection de la bonne définition selon l’environnement
• Appliquer des éléments de style selon l’environnement

Autant y aller assez directement: Adobe sort l’artillerie lourde avec ce système d’extension. Les possibilités sont en effets très étendues en employant ce type de technique. Je n’ai pas encore fait de tests sur Adobe DE avec cette extension et je vous recommande donc de consulter l’exemple dans le “Best Practice Guide”.

Quelques remarques tout de même:

• cette solution est très puissante et s’appuie sur des standards existants
• par contre, sur le plan technique c’est clairement d’un très bon cran au dessus, ce qui limitera clairement le nombre de personnes pouvant travailler avec ce type de documents
• ce n’est pas dans le standard tel que l’IDPF l’entend: ça marchera donc avec les systèmes de lecture Adobe, mais pas avec le reste (qui se contenteront d’ignorer ces définitions et d’utiliser une définition par défaut de la page, ou leur propre système de définition de la page)
• futur choc frontal avec le CSS3 dont le “Working Draft”, indique clairement qu’ils comptent supporter ce type de fonctionnalités

CSS3 Paged Media par le W3C (… ou Opera ?)

De l’autre côté, on peut s’attendre à ce que dans le futur, le support CSS de l’EPUB évolue du CSS 2.0 vers 2.1 puis vers du CSS3.
A en croire le “EPUB Best Practice Guide”, la direction que prend CSS3 n’est pas particulièrement dans les faveurs des ingénieurs d’Adobe:

“CSS specification is evolving beyond CSS2.1 in the shape of multiple CSS3 modules. Several of CSS3 modules aim to the solve the same problems as page template: adding headers and footers, multi-column layout and dynamic styling. All of these modules are still being designed and cannot be relied upon. Since CSS group chose to ignore a lot of previous work in this area (e.g. inventing its own expression syntax for media queries instead of using XPath, designing its own incompatible replacement of page master instead of building on top of XSL:FO), the amount of the implementation work that would be required to achieve parity even with Digital Editions 1.0 is huge. This does not preclude implementing CSS3 syntax for these features if they become stable and gain some acceptance, but it makes too expensive for us to experiment with them at this time.”

En CSS3, on retrouve de nouveau éléments définissant des zones de la page, ainsi que des propriétés spéciales dédidées aux notes de bas de page: W3C Working Draft
Alors que l’utilisation d’une feuille de style XPGT permet de définir l’ensemble des éléments d’une page, en CSS3 ceux-ci sont fixés. Ils ne font pas l’erreur de considérer que les notes de bas de page, puissent s’afficher dans le bas de la page avec tout le reste, et donc une nouvelle zone spéciale est ajoutée: footnote.

L’exemple le plus simple donne le code suivant:

<style>
.footnote { float: footnote }
</style>
 
<p>A sentence consists of words. <span class="footnote">Most often.</span>.

Automatiquement, la note de bas de page est numérotée via un compteur, et le texte affiché dans une zone spéciale en bas de la page dont on peut facilement changer les propriétés. Pour supporter la séparation entre l’appel de note et la note de bas de page, l’exemple suivant est suggéré.

<style>
@media print {
  .footnote { 
    float: footnote;
    content: target-move(attr(href, url)) }
  .marker { display: none }
}
</style>
...
<p>A sentence consists of words<a class="footnote" href="#words"> [3]</a>.
...
<p id=words><span class="marker">[3]</span> Most often.

Si le système de lecture supporte le CSS3, le résultat sera similaire à l’exemple précédent, sinon, il utilisera un lien et affichera le texte de la note à un autre emplacement du document (à la fin principalement). C’est globalement une bonne solution de replis, à l’exception que content: target-move(attr(href, url)) me semble être typiquement le type de propriétés CSS que les navigateurs vont mettre un sacré bout de temps avant de supporter (l’expérience CSS2…).

Je vous conseille de lire l’ensemble de la section consacrée aux footnotes dans le document du W3C pour vous donner une idée exacte des possibilités. De manière personnelle, j’apprécie la simplicité de cette méthode même si elle pose pas mal de questions sur la théorie. Tout d’abord sur la cohabitation entre une approche simplifiée comme celle du CSS3, avec quelque chose de beaucoup plus complexe et puissant comme le XPGT. Ensuite, il y a des exemples dans ce Working Draft (oui, c’est un document en cours de travail, il faut insister la dessus) qui font penser à un langage de transformation, plutôt qu’à l’utilité habituelle du CSS. Finalement, vu le rythme de travail habituel du W3C, on peut raisonnablement se demander quand au juste on disposera d’une spécification finale, qui pourrait être intégrée dans l’EPUB.

Conclusion

Comme on peut le voir, la gestion d’un élément type note de bas de page pose de nombreuses questions. Entre autre, il faudrait se reposer de bonnes questions sur la différence entre fichier source et fichier final, même si la représentation finale est en XML aussi. Un problème essentiel, réside dans le besoin d’avancer vite, pour supporter tout ce qui est nécessaire à une expérience de lecture optimale.

Or les réponses à ces problèmes sont complexes. Si on opte pour des solutions puissantes mais complexes, ça sera aux dépends, des systèmes de lecture qui deviendront plus gourmands en ressources et complexes à développer, ainsi qu’aux créateurs de contenus qui devront intégrer de nombreux facteurs. A l’inverse, des solutions plus simples pourraient montrer leurs limites dans des domaines tels que les publications scientifiques ou la presse.

On remarque un vrai saut qualitatif entre l’EPUB et ses prédécesseurs dans la définition du conteneur et le système de définition des documents/système de replis. Il reste maintenant un travail à faire sur tout ce qui touche à la définition d’une page, la mise en page avancée, la gestion typographique, et l’information sémantique au sein d’un livre. La tendance est aujourd’hui plutôt à mettre le paquet sur l’adoption de la part des éditeurs comme des consommateurs de ces technologies.
Mais il ne faut pas laisser non plus totalement de côté toutes ces considérations plus techniques. Elles auront une incidence sur l’expérience de lecture du consommateur, sur les stratégies à mettre en œuvre côté éditeur, les nouveaux métiers du livre, les fonctionnalités des systèmes de lecture etc…

Je reste un fervent défenseur d’une sorte d’équilibre entre trop de technicité, qui freinerait voir empêcherait l’adoption de standard auprès du plus grand nombre, et de l’autre côté quelque chose de trop simpliste, empêchant de restituer certain type de documents et détériorant l’expérience de lecture.

This entry was posted on Friday, March 28th, 2008 at 3:30 pm and is filed under Réflexions. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.