Quel format pour le texte numérique ?

Jean-Christophe a publié un intéressant billet : Lire le journal au format PDF, quel plaisir...! Il y vante particulièrement la qualité d'une mise en page au format PDF là où l'HTML a encore bien du mal. À moins d'être de très mauvaise foi, il est impossible de dire le contraire. Par contre, je ne suis pas d'accord avec la conclusion selon laquelle le PDF est le format qui devrait s'imposer sur les futures tablettes de lecture.

Rigidité contre plaisir de lecture

Le PDF propose une mise en page stricte, des polices de caractères intégrés parmi de nombreux raffinements intéressants. PDF impose également, et c'est plus important, un format de page. Chaque page d'un document sera à un format donné (A4, A3, US letter, etc.) Schématiquement, PDF est un Postscript amélioré.

Par le passé, Adobe a essayé d'en faire un format pour le web. Peine perdue et il y a de nombreuses raisons à ceci.

Jean-Christophe dit, entre autre :

Il me semble qu'un retour vers le .pdf et la mise en page traditionnelle s'avère plus que nécessaire pour le plaisir de la lecture et, ce, quels que soient les apports astucieux mais futurs de HTML 5 et CSS 3.

La première question que je me pose est : quel plaisir de lecture vais-je avoir en lisant un PDF A4 sur un Nexus On, un iPhone ou encore un Palm ? Sa mise en page sera peut-être superbe mais je vais être fort déçu de sa rigidité sur un petit écran.

Je crois plutôt que c'est la mise en page traditionnelle, ou plutôt le métier de composition tel qu'il est pratiqué aujourd'hui qui va devoir radicalement changer. Il y a quelques indices à cette affirmation.

Une histoire de formats

Le format d'avenir pour le livre numérique sera sans doute EPUB. Ce format est un conteneur (c'est en fait un zip, à la manière des Open Document) dont le format principal est, je vous le donne en mille... XHTML (il y a aussi DTBook, un autre format XML). On peut également intégrer des CSS, des images, du JavaScript, ce n'est plus ensuite plus qu'une question de plateforme de lecture.

En parlant de plateforme, on peut légitimement s'inquiéter du choix de XHTML comme langage utilisé dans EPUB surtout en dressant le constat des différences flagrantes entre les différents moteur de rendu modernes. Mais, c'est mon second indice, quelque chose va changer en janvier : Apple devrait, selon une conjonction astrale favorable, dévoiler l'iSlate, sa tablette.

De mon point de vue, la tablette n'est pas intéressante pour cause d'absence d'encre électronique et d'une plateforme qui risque d'être la même que celle de l'iPhone, avec tous les niveaux de fermeture que cela comporte. Pourtant, elle fera sans doute un carton. Si c'est le cas, WebKit a de grande chance de devenir le moteur de rendu par défaut du XHTML des documents EPUB.

L'avenir potentiel du format EPUB est assez énorme. Il y a également d'autres raisons qui concernent plus les éditeurs. Un document XHTML peut être analysé, transformé, divisé, remis en page, etc. Avez-vous déjà essayé de parser un document PDF ? Promettez-moi de ne jamais essayer.

C'est tout la différence et, dans un sens, elle donne raison à Jean-Christophe ; PDF est un format final. On pourrait même le résumer par "c'est le document qu'on envoie à l'imprimeur". L'imprimeur peut-être une société qui possède d'immenses rotatives, ou simplement le pékin qui veut imprimer son avis d'imposition. À l'opposé, il existe des formats, comme Docbook, dont le seul but est de travailler sur le contenu, jamais la publication.

XHTML, c'est à la fois son immense avantage et son plus grand défaut, se trouve à la croisée des chemins. Sa richesse est suffisante pour en faire un format de travail idéal et son mariage avec CSS lui permet également d'être un format final. Alors oui, le rendu de ce format peut varier selon les méthodes de rendu. Est-ce un inconvénient ? Pas de mon point de vue, au contraire.

Des métiers en mutation

Dans les dix ans à venir, le livre (ou le journal) va être diffusé sur une multitude de supports, de tailles différentes, en couleurs ou en noir et blanc (la couleur n'est pas pour tout de suite pour le e-ink), avec ou sans connexion à internet, etc. Le rendu du texte devra s'adapter à ces différentes configurations. XHTML n'a pas la rigidité du PDF et, pour cette raison, il sait parfaitement s'adapter à tout type de support.

Je ne m'avancerai pas trop en affirmant que c'est une révolution qui vient. Les imprimeurs s'y sont préparés. Les éditeurs montrent des signes inquiétants d'incompréhension. Les auteurs vont sans doute profiter de ces nouveaux canaux de distribution. Quant aux compositeurs, leur métier va changer. Ils devront probablement apprendre XHTML et CSS. Ils seront également mis en face d'une concurrence de nouveaux venus connaissant bien la conception web, capables de créer des livres d'une forme nouvelle, des livres sans doute actifs. Ces derniers devront cependant parfaitement bien maîtriser le métier de la composition, connaître la typographie mieux que "Helvetica c'est plus joli qu'Arial" et rien ne dit qu'il soit plus simple de maîtriser la typographie qu'apprendre quelques astuces CSS, je parierais même sur le contraire.

Tout n'est donc pas perdu. D'une part j'ai peut-être tout faux et les ebooks de ces dix prochaines années seront diffusés en PDF (ça me ferait mal quand même). D'autre part, la composition sera sans doute le métier du livre qui devra le plus changer mais je n'ai pas d'inquiétude à ce sujet, moins que concernant les éditeurs mais ce sera l'objet d'un autre billet.

Dernier détail concernant XHTML : il n'est couvert par aucun brevet (même si ceux de PDF sont gratuits, ils existent). Ce point est fondamental et peu négociable quand il est question de connaissance et de culture.

Photos: John Morgan, Peter Castleton et Jared.

Comments

GS 7 years, 11 months ago

A vrai dire, XHTML aussi est un format "final", destiné avant tout à l'affichage des informations. Selon votre définition, le meilleur format (portable, ouvert, adaptable à différents supports, etc.) pour le texte numérique serait plutôt le XML TEI - d'autant qu'on peut facilement le transformer en ePub et en PDF. A mon sens, il vaudrait donc mieux militer pour une diffusion du texte électronique au format TEI, en travaillant sur la convivialité des outils de conversion. Par exemple, on peut imaginer un logiciel qui télécharge le texte qu'on vient d'acheter au format TEI, le stocke dans ce format, et l'exporte automatiquement au format nécessaire lorsque l'on veut l'ouvrir avec un logiciel ou un appareil particulier. Mais pour que cela fonctionne (et sur ce point je suis bien d'accord avec vous), il faudrait que les compositeurs et les graphistes print de la vieille école condescendent à s'intéresser à XHTML / CSS, au lieu de répondre "Flash !" comme un seul homme dès qu'il n'est plus question de papier.

François Granger 7 years, 11 months ago

Je pense aussi que le PDF n'arrivera pas à s'imposer face à la multiplicité des formats d'écrans.

Chaque rupture technologique s'accompagne d'une baisse de qualité qui est bien plus facilement accepté par les "consommateurs" que par les producteurs professionnels. C'est souvent l'occasion pour de nouveaux profiles professionnels d'émerger comme producteurs. C'est ce qui s'est passé lors de l'apparition de la PAO en 1985. Les imprimeurs ont regardé ça avec mépris. Des gens innovants ont investit la profession de graphiste en PAO. Ils ont acquis de nouvelles compétences tout en retrouvant petit à petit les notions de qualité typographique anciennes.

Je pense que les concepteurs web maitrisant XHTML et CSS sont à même d'apprendre la typographie, ou suffisamment de typographie pour améliorer et faire progresser la publication électronique aux formats XHTML ou HTML 5. La possibilité d'inclure des fontes dans HTML étant à mon sens l'étape indispensable qui permettra de basculer. Il restera une étape à franchir c'est la possibilité de la coupure des mots (césure). Ca viendra un jour ou l'autre...

Damien B 7 years, 11 months ago

L'apprentissage obligatoire de HTML et CSS serait quand même une régression assez énorme du point de vue de l'évolution de la composition. Pour faire le parallèle avec la CAO paramétrique (vu que c'est ce qu'on cherche à faire : de la composition qui respecte des contraintes plutôt qu'un positionnement absolu), c'est l'outil de création qui est menant et pas le format de stockage de l'information. Si on en est réduit pour l'utilisateur final (ie. le composeur) a devoir connaître le format, ça signifie juste qu'on en est resté à la mentalité de cour de récréation de cette branche de l'ingénierie.

> La possibilité d'inclure des fontes dans HTML étant à mon sens l'étape indispensable qui permettra de basculer.

Il est sûr qu'en rajoutant de la fonte au mauvais endroit, l'équilibre est perturbé et on a un risque de bascule.

Damien B 7 years, 11 months ago

L'apprentissage obligatoire de HTML et CSS serait quand même une régression assez énorme du point de vue de l'évolution de la composition. Pour faire le parallèle avec la CAO paramétrique (vu que c'est ce qu'on cherche à faire : de la composition qui respecte des contraintes plutôt qu'un positionnement absolu), c'est l'outil de création qui est menant et pas le format de stockage de l'information. Si on en est réduit pour l'utilisateur final (ie. le composeur) a devoir connaître le format, ça signifie juste qu'on en est resté à la mentalité de cour de récréation de cette branche de l'ingénierie.

> La possibilité d'inclure des fontes dans HTML étant à mon sens l'étape indispensable qui permettra de basculer.

Il est sûr qu'en rajoutant de la fonte au mauvais endroit, l'équilibre est perturbé et on a un risque de bascule.

Philippe 7 years, 11 months ago

Vite fait (mais je reviendrai) : - XHTML tel que nous le connaissons aujourd'hui est mort. C'est d'HTML5 et de CSS3 dont il faut parler aujourd'hui, et qui, oui, permettent l'inclusion de fontes autres que celles embarquées dans les OS. - La césure auto est possible aussi avec de solutions combinant PHP, Ajax et CSS et s'appuyant sur des dictionnaires de césures. Il y a fort à parier qu'avec HTML5 qui permet aussi de créer des applications (avec ses API), Flash et PDF seront (peut-être) abandonnées. à suivre...

Olivier 7 years, 11 months ago

Damien, qui a dit que l'étape de composition devait se faire avec un éditeur de texte ? :)

On ne viendra pas me raconter qu'Adobe, par exemple, n'a aucun moyen financier et humain pour faire un éditeur EPUB digne de ce nom et utilisable par n'importe qui connaissant déjà inDesign. Ça existe peut-être déjà, je n'ai pas vraiment regardé.

Jean-Christophe Courte 7 years, 11 months ago

Comme Olivier ouvre son excellent billet en me citant, je vais jouer les emmerdeurs à nouveau.

Je pense que le PDF n'est pas un si mauvais format que cela, n'en déplaise à mes amis (François entre autres :-). Il a d'énormes mérites dont celui de délivrer, sans un unique fichier et sans dénaturation par un quelconque navigateur, un produit mis en pages avec soin par son compositeur (ligatures, glyphes, approches, interlettrage, inter-paraphaphes, des meilleurs en j'en passe...).

Contrairement à la solution prônée par Olivier qui consomme de la ressource, ce fichier unique ne fait pas appel à des trucs extérieurs qui peuvent (tiens par ces périodes de grand froid...) tomber en rade momentanément ou ralentir l'affiche de la page.

Pas besoin non plus de continuer à griller des watts supplémentaires pour rapatrier les typos nécessaires depuis des fermes de serveurs lointains (désolé d'aire trivial, mais la plus écolo reste la solution PDF en ce cas.). NB : je ne vois pas l'intérêt de payer annuellement des fondeurs pour des typos que j'ai déjà payé soit-dit en passant — à ce propos, d'aucuns me vendent des licences 7 postes pour leurs typos alors que je suis seul mais ceci est un autre problème...!

Enfin, quid des subtilités des polices OpenType dans les CSS... Je vous recommande de découvrir le boulot fait par underware avec la Liza (typo qui m'a coûté un bras et acquise juste pour le fun)...

Et comme le fichier peut rester au chaud sur mon portable/iPhone/tablette, pas besoin d'être connecté pour l'ouvrir...

François, ta remarque m'amuse. Ancien imprimeur de ville (eh oui, je ne raconte pas ma vie antérieure, juste que je suis pas de la dernière pluie...), je suis passé sans problème à la PAO et fut même l'un des tous premiers à utiliser PDF (version Worksgroup 1.0 Mac et PC sur disquettes) grâce à un certain Antoine D.

J'ai essayé CSS et compagnie mais je n'en suis pas satisfait car ne prend pas en compte les subtilités de la typo (il est vrai que tout le monde se fout des ligatures malheureusement, même mes clients...!) et cela demande un effort monstrueux pour "singer" de manière fort rudimentaire ce que je faisais déjà en 2 minutes sur LisaDraw, puis MacDraw, puis PageMaker ou Illustrator, puis XPress ou FrameMaker et désormais InDesign...!!

Alors, je vous retourne la question puisque c'est si facile : pourquoi n'existe-il pas un éditeur de CSS à la manière d'un simple InDesign...?!

Bref, en attendant que vous ayez une solution à ma porté qui me permettra de placer des blocs très simplement sur une surface, de mettre dans ces blocs des textes avec des formats styles un peu subtils respectant ligatures et approches de paires, des typos de qualité OpenType, des images avec des profils ICC reconnus, gérer des transparences, etc. je vais continuer encore quelques années à faire du PDF avec de très bons scripts pour gérer même des images surgissantes si besoin est.

C'est tout...! Amicalement aux lecteurs de passage

Olivier 7 years, 11 months ago

Jean-Christophe, merci pour la réponse :)

Le support des subtilités OpenType arrive doucement mais sûrement dans les navigateurs.

Concernant Typekit, puisqu'on parle aussi de ça. Je t'en ai donné l'exemple uniquement dans un usage web. Un EPUB embarquera évidemment ses propres polices de caractères (à la manière d'un PDF).

Alors, je vous retourne la question puisque c'est si facile : pourquoi n'existe-il pas un éditeur de CSS à la manière d'un simple InDesign...?!

Je me pose la même question :) Venant d'Adobe, ils n'ont peut-être pas vraiment envie de tuer leur propre format.

Ces outils n'existent pas, ils n'existeront peut-être jamais. Je n'en sais rien et derrière mes quelques affirmations je me pose surtout des question sur l'existence même du livre dans sa forme et son mode de mise en page actuel :)

Damien B 7 years, 11 months ago

Olivier : personne n'a dit qu'il fallait utiliser un éditeur de texte, mais, en revanche, on n'a jamais eu besoin de connaître les formats IGES ou DXF pour travailler en CAO (toujours mon parallèle). Je dis juste que si pour faire des ePUB multi-ratios d'affichage il faut apprendre HTML et CSS, on est dans une impasse :-)

Philippe : pourquoi lier CSS 3 à une version spécifique (et non finalisée) d'HTML ? L'inclusion de polices est une fonctionnalité de CSS 3, utilisable avec XHTML. Pour la césure auto, même combat, il y a une proposition à l'heure actuelle dans le module gcpm de CSS3 (l'algorithmique derrière n'étant pas un problème, ça fait 30 ans qu'on les a) : sortir le mammouth Ajax (et donc une connexion à internet) à chaque fois qu'on tourne la page d'un livre, "it's a trap!"

Jean-Christophe Courte : pour les polices embarquées, ça peut se faire sans aller sur le net, l'ePub est un zip (à la ODF, OOXML ou CHM (non je rigole)) qui va embarquer toutes les ressources nécessaires. La seule différence avec PDF de ce point de vue là est que l'inclusion n'est pas binaire (à moins qu'en PDF seul le sous-ensemble de caractères réellement utilisés soit embarqué ?).

"Alors, je vous retourne la question puisque c'est si facile : pourquoi n'existe-il pas un éditeur de CSS à la manière d'un simple InDesign...?!"

Parce que CSS est un langage de mise en forme indépendant du langage de structuration du contenu. Donc de toute façon on est handicappé par les "subtilités" du HTML (et ça ne s'améliore pas avec HTML 5). Avec inDesign, comme on n'a pas à passer des années-homme de réflexion sur le format, on peut se concentrer sur la qualité de l'outillage ;-)

Damien B 7 years, 11 months ago

Olivier : personne n'a dit qu'il fallait utiliser un éditeur de texte, mais, en revanche, on n'a jamais eu besoin de connaître les formats IGES ou DXF pour travailler en CAO (toujours mon parallèle). Je dis juste que si pour faire des ePUB multi-ratios d'affichage il faut apprendre HTML et CSS, on est dans une impasse :-)

Philippe : pourquoi lier CSS 3 à une version spécifique (et non finalisée) d'HTML ? L'inclusion de polices est une fonctionnalité de CSS 3, utilisable avec XHTML. Pour la césure auto, même combat, il y a une proposition à l'heure actuelle dans le module gcpm de CSS3 (l'algorithmique derrière n'étant pas un problème, ça fait 30 ans qu'on les a) : sortir le mammouth Ajax (et donc une connexion à internet) à chaque fois qu'on tourne la page d'un livre, "it's a trap!"

Jean-Christophe Courte : pour les polices embarquées, ça peut se faire sans aller sur le net, l'ePub est un zip (à la ODF, OOXML ou CHM (non je rigole)) qui va embarquer toutes les ressources nécessaires. La seule différence avec PDF de ce point de vue là est que l'inclusion n'est pas binaire (à moins qu'en PDF seul le sous-ensemble de caractères réellement utilisés soit embarqué ?).

"Alors, je vous retourne la question puisque c'est si facile : pourquoi n'existe-il pas un éditeur de CSS à la manière d'un simple InDesign...?!"

Parce que CSS est un langage de mise en forme indépendant du langage de structuration du contenu. Donc de toute façon on est handicappé par les "subtilités" du HTML (et ça ne s'améliore pas avec HTML 5). Avec inDesign, comme on n'a pas à passer des années-homme de réflexion sur le format, on peut se concentrer sur la qualité de l'outillage ;-)

Jean-Christophe Courte 7 years, 11 months ago

Olivier, qu'Adobe ne développe rien en partant de GoLive ou de Dreamweaver ou même de FireWorks est leur problème...

Il y a un truc qui me sidère (mais je suis très con il est vrai...!), c'est que le PDF est un facsimilé, en gros une chouette photocopie numérique (et donc imprimable et même notable au sens d'ajouter des notes) d'une document fait pour être lu... On a des liens "inside" (étonnant des hyperliens, même ;-), la possibilité de faire des recherche fuil texte, une gestion au poil de la typo, un système avec des ressources intégrées, on sait que la mise en page ne sera pas déformée (et, désolé de revenir la dessus, mais c'est quand même le but d'une mise en pages, de ne pas partir en couille dès que lui l'on tire dessus — sur le PDF, pas d'ambiguïtés ;-).

Et même un machin moins énergétivore que du HTML qui lance plein d'appels surtout si l'on y même des tas de liens externes et divers... J'insiste sur ce point, démontrez-moi en quoi c'est faux. Certes, on peut penser un dispositif qui fonctionne sans connexion mais le PDF fait cela déjà très bien, pourquoi se faire du mal à se faire du bien :-)

Or ce que j'apprécie dans le PDF, c'est justement que l'on respecte la mise en pages, l'esprit dans lequel je l'ai — accessoirement — pensée cette maquette ! Bref, je conçois des objets faits pour être vus et non déformés à tout propos...

Chaque format m'inspire des mises en pages différentes, c'est une contrainte nécessaire. Vouloir pondre un objet mutant en considérant que le format varie, c'est se retrouver de temps à autre, coup de chance, avec un truc qui fonctionne. Et dans 90 % des cas, accepter que cela parte en vrille. Que ce soit moche...!

Naaaan...!

Imagine que tu réalises un croquis... Et que selon la taille de ton écran, ton dessin change de gueule... Tu ne serais pas d'accord. Idem pour une photo.

Eh bien, moi, c'est la même chose. Ma mise en pages doit être respectée et non s'adapter.

Alors, prenons le problème à l'envers. À moi de pondre une mise en pages ou des mises en pages adaptées. Sur un petit écran, je découperais on texte différemment, choisirait une typo idoine. Le truc universel ça ne marche pas. Mieux, le changement de format est l'occasion de proposer des solutions différentes... Sinon à quoi bon me faire appel d'ailleurs.

Bref, ce n'est pas à la machine d'adapter ma maquette au contexte mais bien au graphiste de répondre aux besoins spécifiques à cette contrainte de format. Cela passe par une gestion de styles, des maquettes différentes et la possibilité pour le consommateur final de choisir/télécharger ce qu'il veux... iPhone, écran d'ordinateur ou tablette...!

Damien B 7 years, 11 months ago

"Et même un machin moins énergétivore que du HTML qui lance plein d'appels surtout si l'on y même des tas de liens externes et divers... J'insiste sur ce point, démontrez-moi en quoi c'est faux. "

Même si toutes les ressources sont embarquées dans un seul fichier (ePub), ce sera de toute façon plus coûteux de rendre du HTML, vu qu'il reste le calcul de la mise en page à faire. Mais en même temps, les visionneuses PDF (oui, je parle bien d'Adobe Reader) ne sont pas vraiment un exemple de comportement écologique d'utilisation des ressources informatiques (et on ne parlera pas d'Adobe Flash Player :-)).

Damien B 7 years, 11 months ago

"Et même un machin moins énergétivore que du HTML qui lance plein d'appels surtout si l'on y même des tas de liens externes et divers... J'insiste sur ce point, démontrez-moi en quoi c'est faux. "

Même si toutes les ressources sont embarquées dans un seul fichier (ePub), ce sera de toute façon plus coûteux de rendre du HTML, vu qu'il reste le calcul de la mise en page à faire. Mais en même temps, les visionneuses PDF (oui, je parle bien d'Adobe Reader) ne sont pas vraiment un exemple de comportement écologique d'utilisation des ressources informatiques (et on ne parlera pas d'Adobe Flash Player :-)).

François Granger 7 years, 11 months ago

Jean-Christophe, mon commentaire n'est pas une attaque de ton histoire ou de ton travail. C'est juste un petit rappel de données sociales et techniques.

Je dis en particulier, et par une expérience que tu partages, que le client est prêt à sacrifier la qualité pour d'autres bénéfices.

Dans le cas du "livre électronique", si l'éditeur veut diffuser sur "toutes plateformes", le PDF n'est pas un format réaliste. Tu te voit faire une version pour écran de 3"1/2, pour iPhone/iPod, pour BlackBerry, pour écran de 7", pour écran de 9", puis une version A4 pour tous les écrans de format supérieur ? Ton client éditeur, lui, préférera sans doute éviter de te payer une telle facture. Donc, si il est approché par un graphiste web qui lui dira "une seul version pour tous les formats d'écrans", il répondra "banco".

Quand à l'argument écolo du PDF ;-) Depuis 1989 (et peut être avant) chaque fois que quelqu'un critique la vitesse des produits Adobe (RIP PostScript, Acrobat Reader...) la réponse d'Adobe c'est "It is an engineering issue", ce qui traduit en bon français veut dire : "Achetez une machine plus puissante ou attendez l'année prochaine qu'il y en ai une disponible" ;-)

En résumé, je ne dit pas que HTML+CSS est meilleur que PDF. Je dit que HTML+CSS approche du point ou ils ont une sérieuse chance de devenir le format préféré de diffusion des "livres électroniques".

Quels outils seront utilisés pour les produire, je ne sait pas encore. Mais il existe des "chaines de fabrication" comme LaTex, DocBook ou les XSLT qui, avec quelques améliorations pourraient convenir dans un premier temps pour du tout venant. A titre d'exemple, avec un bon spécialiste du PDF, nous avions travaillé en 2003 sur la production de livres (genre livre de poche) en PDF fini à partir de Word en passant par DocBook et XSLT sans intervention humaine. Cette chaine aurait pu produire du HTML+X sans trop de problème.

Patrick 7 years, 11 months ago

Pour ma part je suis tout à fait d'accord avec Jean-Christophe sur : "Bref, ce n'est pas à la machine d'adapter ma maquette au contexte mais bien au graphiste de répondre aux besoins spécifiques à cette contrainte de format." Je crois que c'est l'essence même de la publication (je ne suis pas typographe), c'est au support d'adapter la taille au confort de lecture. Et puis n'oublions pas que PDF signifie Portable Document Format :-)

Philippe 7 years, 11 months ago

Ça fait un bail que je me suis éloigné du prepress c'est sans doute pour ça que je garde de vielles rancunes contre PDF. Mais PostScript et PDF, si j'en crois J-C, ont dû faire des progrès si — je le cite —, « PDF (...) respecte la mise en pages ». Je reconnais donc que PDF est un formidable format d'échange de documents, mais, il demeure que je partage les points de vue de François : PDF est un format inadapté à la création de documents pour toutes les raisons qu'il a évoqué. Je comprends que les hommes de l'Art souhaitent que ce format soit conservé au nom de la fidélité qu'il restitue : celui de la mise en page telle qu'elle fut conçue. Le problème, et comme je ne suis pas né de la dernière neige, je dirai que je l'ai toujours connu, c'est que les anciens et modernes essaient de se convaincre. Les uns disent qu'ils veulent de la qualité, les autres de l'efficacité. Les premiers quand ils ont voulu conserver leurs outils de production ont disparu. Les autres acteurs de la chaîne graphique ont fait évolué leurs métiers et sacrifié souvent leurs exigences. Une anecdote à ce propos : je bossais pour Apple et j'installais pour Havas des Rips devant les Linos en 86. Le vieux grognard du studio pestait contre les différences de rendu après le ripping (quand il n'y avait pas d'erreurs Postscript) et voulait retourner tout le matos. « La qualité est suffisante. » Pendant les années qui suivront j'ai entendu cette phrase se répéter sur tous les continents : « It's good enough. »

Alors oui, c'est triste mais il va falloir survivre avec la médiocrité ambiante et les contraintes de la vitesse ou vivre dans la nostalgie de ce passé où le temps ne comptait pas et les règles métiers étaient respectées.

Bien à vous tous, Philippe

karl 7 years, 11 months ago

Une autre possibilité pour remplacer le PDF (pas encore complètement mature) mais une possibilité tout de même : SVG (à moins que SVG ne soit utilisé pour le UI.)

html5 et css, c'est à peu près certain. La frontière livre et internet va sauter. C'est un peu comme pour la musique et la vidéo. Nombreuses personnes ont râlé sur la perte de qualité par rapport au vynil du CD. Puis ensuite des fichiers MP3 par rapport au CD. Résultat des courses. Tout le monde se cogne de la qualité, car « It's good enough. »

Damien B 7 years, 11 months ago

Attention au mythe de la qualité du vinyle au MP3... le mp3 traine cette mauvaise image essentiellement parce que l'encodage choisi du temps de Napster était adapté aux débits de l'époque (ISDN bi-canal pour les plus riches, réseaux universitaires pour les plus hors-la-loi). Le fait est qu'un CD est de meilleure qualité d'un vinyle qui n'est pas manipulé avec soin et lu avec un électrophone entretenu, de même qu'un MP3 bien compressé (bien que son modèle psycho-acoustique ne soit pas le meilleur) aura une qualité tout à fait équivalente. Et de toute façon, la musique que les gens achètent au format numérique, ça reste essentiellement du PCM, et après, de l'AAC.

Ce qui ne changera pas, c'est qu'un format a besoin d'un outillage adapté : vive GoLive, vive FrontPage, vive Word. Et franchement, de ce point de vue là, HTML 5 (quand il sortira de son parc à jouets) et CSS 3 (quand il sortira de son laboratoire) sont mal partis.

Damien B 7 years, 11 months ago

Attention au mythe de la qualité du vinyle au MP3... le mp3 traine cette mauvaise image essentiellement parce que l'encodage choisi du temps de Napster était adapté aux débits de l'époque (ISDN bi-canal pour les plus riches, réseaux universitaires pour les plus hors-la-loi). Le fait est qu'un CD est de meilleure qualité d'un vinyle qui n'est pas manipulé avec soin et lu avec un électrophone entretenu, de même qu'un MP3 bien compressé (bien que son modèle psycho-acoustique ne soit pas le meilleur) aura une qualité tout à fait équivalente. Et de toute façon, la musique que les gens achètent au format numérique, ça reste essentiellement du PCM, et après, de l'AAC.

Ce qui ne changera pas, c'est qu'un format a besoin d'un outillage adapté : vive GoLive, vive FrontPage, vive Word. Et franchement, de ce point de vue là, HTML 5 (quand il sortira de son parc à jouets) et CSS 3 (quand il sortira de son laboratoire) sont mal partis.

Ombre 7 years, 11 months ago

Ce qui ne changera pas, c'est qu'un format a besoin d'un outillage adapté : vive GoLive, vive FrontPage, vive Word. Et franchement, de ce point de vue là, HTML 5 (quand il sortira de son parc à jouets) et CSS 3 (quand il sortira de son laboratoire) sont mal partis.

Mouhaha... :D :D :D

Ombre 7 years, 11 months ago

Pour ne pas troller : [url=http://blogs.adobe.com/digitaleditions/indesign-epub.html]indesign supporte epub[/url].

Ombre 7 years, 11 months ago
Jean-Christophe Courte 7 years, 10 months ago

#ombres... Naaaaann, c'est pas vrai...?! le format epub est supporté... Houlà, là... Et depuis la version CS3, c'est fou...!! (même que sous les premières versions de CS4, il était nécessaire d'utiliser les filtres epub de la CS3...)

Et alors...?! Ce format epub respecte ma mise en pages, mes choix typos, le placement de mes images, etc. Ben non. Une autre remarque du même ordre...?!

Simon H. 7 years, 10 months ago

Et paf, l'iPad supporte l'EPUB.

Ombre 7 years, 10 months ago

@Jean-Christophe : pas besoin d'utiliser les sarcasmes, je n'étais tout simplement pas au courant pour inDesign. Je suis tombé par hasard dessus en cherchant des compléments d'informations et j'ai pensé que ça pourrait intéresser certains.

Pour ce que y de la mise-en-page ben non ça ne la respecte pas et comme disait Olivier : «Heureusement». J'ai pas envie de zoomer et dézoomer sur une page en pdf pour lire et suivre son contenu avec mon iPhone. xHtml/ePub est fait pour ça. Chaque média a ses exigence, ici la lecture se fera de façons plus linéaire en définissant un sommaire et des liens vers «chapitres», histoire de ne pas avoir des longs textes à scroller.

C'est plus un travail de designer web quoi...

Essay 7 years, 6 months ago

Je crois que le refus du format PDF n'est pas tout à fait justifié. Maintenant kontendy de nombreux écrits exactement sous ce format et sera très difficile de changer toute la structure existante. Par conséquent, devraient penser deux fois avant de décider de prendre cette mesure. Toutefois, dans l'avenir, je suis sûr que ce processus est irréversible.

writing job 7 years, 3 months ago

Même si toutes les ressources sont chargées dans un seul fichier (ePub), ce sera en tout cas plus cher au format HTML, car il reste le calcul de la mise en page à faire. Mais dans le même temps, les téléspectateurs PDF (oui, je parle bien du logiciel Adobe Reader) ne sont pas vraiment un exemple de comportement écologique des ressources de l'ordinateur (et nous ne parlons pas du logiciel Adobe Flash Player.

Olivia Charm 7 years, 1 month ago

Alors, je vous retourne la question puisque c'est si facile : pourquoi n'existe-il pas un éditeur de CSS à la manière d'un simple InDesign...?!