mercredi 27 mai 2009

Bernard Prost : consultant de l'Asfored participera à la table ronde du vendredi 5 Juin : Normes et standards de l'édition numérique

Grâce au Fil info suivez au jour le jour les dernières news du Read Digital








Bernard Prost formateur et consultant de l'Asfored spécialisé dans l'automatisation et l'industrialisation de l'édition interviendra dans la conférence du 5 juin intitulée : " Normes et standars de l'édition numérique... comment aller au-delà des déclarations d'intention"


Les réflexions de Bernard Prost sur les formats d’e-book nouriront la Table ronde à laquelle il participera

Il n'y a pas un unique format d'e-book : nous n'en sommes qu'au tout début de l'histoire du livre numérique. Comme pour de nombreux objets culturels électroniques (cf la bande vidéo, puis la téléphonie mobile, le DVD haute définition…) des formats concurrents s'affrontent.

Différents acteurs essaient d'imposer leur vue dans le dessein (inavoué) de contrôler tout le marché. Mais contrairement à la musique qui a vu s'imposer le (médiocre) format MP3, l'affichage sur un appareil nomade d'une information publiée risque de voir cohabiter différents formats en raison des bénéfices client et éditeurs envisagés.

Ce qui semble toutefois acquis : les readers doivent être interopérables. Un lecteur ayant acheté un ouvrage en PRC doit pouvoir le lire sur n'importe quel reader du marché.

D'un point de vue comportemental du texte, on distingue deux approches :

* le texte préformaté qui s'affiche à la manière d'une page papier. Le format roi, pour l'instant, est pdf avec ses possibilités de rendu précis (contrôle de la police, du graphisme) et interactivité satisfaisante,
* le texte réorganisable au vol ("flowable") à la manière du HTML et pour lesquels différents formats ont été proposé, en particulier Mobipocket (.prc ou .mobi) et surtout ePub. Si vous voulez en savoir plus sur les logiciels de lecture de fichier epub, jetez un coup d'oeil sur le site Jedisaber.

Document préformaté

Il s'agit de produire un pdf lisible sur l'écran cible, donc produire des "minipages" pdf. Le problème vient de la multiplicité des écrans cibles : la taille de l'écran de l'Illiad diffère de celle du Bookeen et du Kindle, qui diffère de celui de l'iphone. Il faudra dès lors produire le contenu pour chacun de ces écrans. Nous voilà revenu aux affres de la publication des années pré-web-CSS où il fallait investir pour adapter son contenu pour le mac et le PC…

Cette approche, pour l'éditeur, reste acceptable à condition que la production soit automatique : dès lors on choisira un XML d'entrée de processus suffisamment générique pour que le livre numérique puisse être produit automatiquement.

Ca c'est pour la technique.

Pour la qualité de mise en page des e-books qui dit automatisme dit insatisfaction des éditeurs (nous voulons parler de la fonction d'éditeur au sein d'une organisation) ; tant pis si une légende d'image chasse et s'installe sur la page d'après (encore que la non sécabilité de ce type d'information soit facilement programmable dans les automates de transformation), tant pis si une césure n'est pas satisfaisante, tant pis si ce n'est pas impeccable au sens graphique papier…

Le formatage en minipages apporte un avantage collatéral : l'inflation du nombre de pages physiques si d'aventure l'internaute voulait imprimer le livre électronique. Le facteur multiplicatif est au moins de 4 (ie un livre de 300 pages physiques papier va se transformer en ouvrage de 1200 minipages pdf) et jusqu'à 25 pour la presse (un journal de 24 pages, dont on ne prend que les articles et brèves avec peu d'images pèsera 600 minipages). Sans compter le désagrément d'avoir un stock de feuilles volantes en lieu et place d'un classique p-book….
Document flowable

L'approche est encore moins contrôlable par l'éditeur : que l'utilisateur change la fonte ou la taille de la police, le texte se "recompose" au vol avec plus ou moins de bonheur.

Aujourd'hui, un format comme celui de Mobipocket (.PRC) est ultra simple : le contrôle graphique est réduit. Des objets bien maîtrisés sur le web, comme les tableaux, deviennent carrément illisibles sur un reader. Certes cela peut s'améliorer et on peut imaginer avoir bientôt (2010…) un système d'affichage de la page qui ressemble davantage à un navigateur classique qu'à une page d'e-paper.

A court terme on se contentera d'un système très primitif, par une transformation XML->HTML simple. L'effort portera sur la signalisation graphique (pour visualiser les niveaux hiérarchique du livre par exemple), la signalisation navigationnelle avec un usage local des yahoo bar et un usage étendu des tables des matières locale (par exemple au niveau du chapitre).


Aucun commentaire:

Enregistrer un commentaire