A l’occasion du Salon du Livre de Paris, j’ai eu la chance d’assister au séminaire organisé par l’IDPF (International Digital Publishing Forum) le 25 mars dernier. L’objectif de ce séminaire technique était de présenter aux éditeurs les fonctionnalités de l’ePub3 et les perspectives offertes par ce standard. Je rends compte ici de ce que j’ai pu y entendre.
L’IDPF est un organisme de normalisation dont le sujet de travail principal est la normalisation du format ePub. Le séminaire s’est ouvert sur une conférence introductive de Bill Mc Coy, directeur exécutif de l’IDPF, qui avait pour objet de démontrer entre autres que la distinction entre sites internet, applications natives et livres numériques a de moins en moins de sens aujourd’hui avec la mutualisation des moyens de développement entre ces plateformes. Il pose le constat que le modèle économique de l’application native ne fonctionne pas : elles coûtent trop cher à produire et les modalités de production ne sont pas scalables à l’ensemble du catalogue d’un éditeur qui publie plusieurs centaines ou milliers de titres par an. Il est donc nécessaire de faire évoluer ce mode de travail. Il est probable qu’à l’avenir on se dirige de plus en plus vers un format de contenus structuré qui sera réutilisable dans plusieurs contextes. L’ePub3 est appelé à jouer un rôle dans ce contexte grâce à la conjonction avec HTML5.
La présentation d’HTML5 était effectuée par Robin Berjon qui représentait le W3C (je m’excuse d’avance pour l’inexactitude probable avec laquelle je vais rapporter ses propos…) L’ePub3 était présenté par Daniel Weck du consortium Daisy (un organisme qui travaille sur l’accessibilité du livre numérique) (ses diapos en ePub dans le texte ici.)
HTML5 est plus une galaxie de normes qu’une norme unique. Il y a une centaine de spécifications liées entre elles qui incluent HTML5 proprement dit mais aussi d’autres standards tels que CSS par exemple (pour la mise en forme), Javascript, etc. L’ensemble est désigné sous le terme générique de « the Open Web Platform ».
HTML5 apporte de nouvelles fonctionnalités par rapport au HTML traditionnel :
– support natif de la vidéo et de l’audio : on n’a plus besoin d’installer un plug-in (ex. Flash) pour lire ces médias
– interactivité native grâce à « canvas », une sorte de langage qui permet de coder directement en HTML des applications interactive (jeux, 3D…) de même type que ce qu’on pouvait faire avec Flash
– de nouvelles fonctions de présentation (il semblerait qu’on puisse faire des ligatures grâce à HTML5 et CSS par ex. :-)
– le support natif de Ruby (utile pour les écritures japonaises et chinoises), MathML (pour les équations mathématiques) et SVG (images vectorielles qui permettent par exemple d’agrandir les images sans pixellisation)
l’amélioration des formulaires
– de nombreuses APIs qui permettent notamment d’interagir avec le terminal (dans le cas d’un terminal mobile cela permet de gérer par exemple l’orientation portrait/paysage, de détecter les vibrations, d’interagir avec le micro, la lumière ambiante, etc.)
– une meilleure sémantique de structuration de la page qui permet maintenant de distinguer un en-tête et pied de page, des menus de navigation, etc.
On le voit, toutes ces nouvelles fonctions de HTML5 sont extrêmement pertinentes dans le contexte d’un usage en mobilité et plus spécifiquement dans le contexte du livre numérique enrichi.
Dans la mesure où ePub3 est complètement basé sur HTML5, on dispose nativement de tout l’outillage nécessaire pour ajouter des médias, interagir avec des terminaux de lecture de type eReader / tablette, et structurer le contenu d’une manière cohérente avec les pratiques traditionnelles du livre (en séparant le texte lui-même du paratexte – titres, tables des matières, notes, etc.)
ePub3 est donc basé sur HTML5 mais vient également y ajouter un certain nombre d’éléments :
– l’empaquetage : en plus de l’empaquetage physique (un fichier ePub est en fait une sorte de « zip » qui contient plusieurs fichiers) il s’agit de déclarer toutes les composantes d’un paquet : navigation linéaire, table des matières, liste des pages physiques (permet des renvois depuis les références du livre imprimé)
– le paquet peut aussi contenir des métadonnées et inclure les polices spécifiques dont on a besoin pour la présentation. Cela permet à l’ePub d’être autonome et autodescriptif ;
– l’accessibilité : à l’origine le consortium Daisy travaillait sur son propre format XML pour les personnes en situation de handicap (le XML Daisy). Ils ont décidé de s’impliquer dans la normalisation d’ePub3 pour palier aux défauts d’accessibilité qui étaient ceux d’ePub2. Il est ainsi possible de synthétiser automatiquement une lecture audio à partir du texte en faisant appel à certaines fonctions de CSS (choix du type de voix, ajout d’un fichier de prononciation pour les termes ambigus par ex.)
– un système de liens performants, le système CFI (Canonical Fragment Identification) gère les notes de bas de page – qui deviennent d’ailleurs plutôt des pop-up dans ce contexte – et les tables des matières directement en HTML5 (en ePub2, il y avait un format distinct pour encoder la table des matières. Le fait qu’elle soit un simple fichier HTML permet de la présenter comme une page normale et pas seulement comme un outil de navigation)
– les méthodes de cryptage, de signature et de gestion des DRM.
A titre d’illustration de ces potentialités, un autre intervenant, Peter Meyers, nous a présenté trois exemples de livres numériques qui tirent tout le potentiel du média interactif :
– The good man, une nouvelle interactive
– Welcome to Pinepoint par Paul Shoebridge et Michael Simons (en Flash) qui fonctionne un peu comme un scrapbook multimedia
– Fish, un essai de Robin Sloan conçu pour la lecture sur smartphone.
Il s’agit ici d’inventer de nouvelles modalités d’écriture et de lecture dans un monde numérique.
Luc Audrain d’Hachette a ensuite présenté la problématique de l’industrialisation de la production de livres numériques pour les gros éditeurs.
Il a commencé son exposé en notant que contrairement à une idée reçue, transformer un livre papier en livre numérique n’est pas une opération qu’on fait une fois pour toutes. Au contraire, il faut la répéter plusieurs fois : pour corriger des erreurs, pour prendre en compte des nouvelles versions du format, etc. L’industrialisation de la production est donc d’autant plus une nécessité.
Il nous propose ensuite une grille d’analyse matricielle permettant de différencier les types d’ouvrages en fonction de leur niveau de structuration et de l’importance de la mise en page :
– peu structuré, peu maquetté (ex. romans)
– très structuré, peu maquetté (ex. dictionnaires)
– très structuré, très maquetté (ex. livres de recettes de cuisine)
– peu structuré, très maquetté (ex. livres d’art).
Cette grille permet de faire un choix entre deux stratégies de conversion : les ePub adaptables (dont la mise en page se réorganise en fonction de la taille et du format de l’écran) et les ePub fixés (qui respectent strictement la maquette d’origine).
Le ePub adaptable est très immersif et adapté à la lecture linéaire. Interopérable, il peut être produit à partir d’un flux XML. Cependant, la mise en page est limitée.
Le ePub fixé respecte la maquette du papier ce qui permet des coûts de production très bas. Toutefois, on perd en accessibilité et on ne distribue que sur un nombre limité de plateformes.
Pour Luc Audrain, si on ne fait que du texte, cela ne vaut pas la peine de passer à ePub3 qui n’est pas encore largement supporté, il vaut mieux rester à ePub2.
Plusieurs chaînes sont possibles pour produire les ePub adaptables :
– export ePub direct à partir d’InDesign : nécessite une grande vigilance de base sur la conception du fichier InDesign et de reprendre les ePub à la main ;
– deuxième possibilité, on structure un fichier Word pour obtenir de l’XML. Ce fichier XML est ensuite utilisé pour générer le PDF imprimeur et une version XML du contenu. On stocke l’ensemble dans un système de DAM (Digital Asset Management). L’ePub peut être généré en sortie. Cette chaîne fonctionne si on travaille à partir du fichier remis par l’auteur : pour le rétrospectif, on doit repartir du PDF imprimeur, voir du scan+OCR de la version papier.
Pour l’ePub fixé, on part de la maquette du papier et on produit :
– soit du HTML5+CSS (on crée un cadre dit « viewport » et ensuite on positionne les blocs de texte et d’image en absolu)
– soit une image vectorielle (SVG) ce qui revient au même principe en utilisant une technologie différente. N’importe quel PDF peut être facilement transformé en SVG, mais ce format n’est pas toujours supporté dans les logiciels de lecture d’ePub
– soit par une simple image de type JPG (méthode à l’abandon car fournit une expérience de piètre qualité notamment quand on agrandit l’image). Toutefois il peut être utile d’intégrer l’image dans le HTML5 afin qu’elle puisse servir de présentation alternative si le format n’est pas supporté.
Les contenus fortement structurés sont de plus en plus souvent stockés dans une base de données. Des équipes éditoriales les préparent alors en vue d’en faire des publications : vers du papier, des applications, des sites web, des fichiers ePub. Il existe des outils sur le marché permettant de gérer ce type de chaîne. Les auteurs n’écrivent plus uniquement pour le papier mais produisent des contenus.
Enfin il reste évidemment possible de créer un ePub ex-nihilo. L’outil Bluegriffon par exemple est un éditeur Web wysiwyg pour HTML5 et il permet également de générer des ePub2 et des ePub3.
La dernière étape réside dans le contrôle qualité. Il existe des outils de validation comme ePubcheck pour la structure des fichiers ePub. Il faut ensuite procéder à une validation visuelle grâce à un lecteur d’ePub comme Readium.
Une présentation de Marc Bide, du consortium EDItEUR a permis de rappeler que les métadonnées jouent un rôle encore plus important pour le livre numérique que pour le livre imprimé, car elles sont l’unique moyen de trouver le livre pour l’utilisateur final. Elles sont donc capitales pour la chaîne de distribution, mais aussi pour la bibliothèque personnelle de l’usager : tous les ebooks embarquent un minimum de métadonnées à cette fin. Toutefois celles-ci ne sont pas toujours suffisantes : c’est quand même énervant quand on a tous les livres d’une série d’être obligé de regarder dans wikipédia pour savoir dans quel ordre les lire !
L’ISBN est important pour faire le lien entre l’ouvrage et ses métadonnées. Marc Bide rappelle qu’il est important de fournir des ISBN différents pour la version papier et pour la version numérique. En effet, l’ISBN sert à différencier les éditions et non à les relier. On fournit un ISBN différent pour chaque format entrant (ex. PDF et ePub) ; c’est par contre optionnel si on a différents formats de sortie (ex. ePub et Mobi).
EDItEUR a sorti en 2009 une nouvelle version d’Onix, Onix 3.0, qui est beaucoup plus adaptée au livre numérique que l’ancienne version Onix 2.1. Elle permet entre autres de décrire des contraintes d’usage associées à un livre numérique.
Pour l’IDPF, la problématique majeure aujourd’hui est de faciliter l’adoption de l’ePub3 qui n’est pas encore très largement supporté, et même quand il l’est c’est souvent de manière incomplète.
Le BISG (Book Industry Study Group) maintient un outil qui permet de savoir quelle plateforme supporte ou non quelle fonctionnalité d’ePub3 : le ePub3 support grid.
Pour pallier à cette problématique, les tenants de l’HTML5 et de l’ePub3 encouragent le développement en « fallback design » : c’est-à-dire un design qui s’adapte aux capacités des différentes plateformes.
Il en existe deux sortes :
– « graceful degradation » : le développement est effectué en visant les plateformes les plus performantes, mais si une fonctionnalité n’est pas supportée, des formats alternatifs sont proposés
– « progressive enhancement » : la version présentée par défaut est la plus basique, ensuite on teste en javascript l’environnement de l’utilisateur et on fournit progressivement les contenus plus avancés si la plateforme le permet.
L’IDPF s’implique également dans le développement de Readium, qui est considéré comme le logiciel de lecture d’ePub3 de référence. Le jour du séminaire, l’IDPF annonçait la création de la Readium Foundation, dont l’objectif est de fournir des briques logicielles pour accélérer l’adoption d’ePub3. L’un des moyens utilisés sera la création d’un Readium SDK que les développeurs pourront utiliser pour intégrer les fonctions de Readium dans leurs propres applications.
Figoblog 