J’ai déjà eu l’occasion d’émettre quelques réflexions sur le blog anglo-saxon, sur la manière dont le standard devrait/pourrait évoluer.
Avec un million de fichiers ePub distribués sur Feedbooks et les grands groupes d’édition qui s’y mettent, il est plus que jamais indispensable d’avoir une vision critique sur le standard afin de le faire avancer.
Quelques éléments qui méritent d’approfondir cette question…
OPF et images
Pour reprendre les définitions de la spécification OPS, on distingue:
OPS CONTENT DOCUMENT
An XHTML, DTBook, or Out-Of-Line XML Island that conforms to this specification that may legally appear in an OPF Package Document spine element.
OPS CORE MEDIA TYPE
A MIME media type that all Reading Systems must support.
Dans un fichier ePub, on utilise en réalité une multitude de documents inclus dans un conteneur. Pour constituer le document ePub, on précise un ordre de lecture via l’élément spine du fichier OPF (Open Packaging Format, où on décrit les métadonnées et la composition du fichier).
Pour composer le document, on a uniquement le droit de se servir d’OPS Content Documents (à savoir du XHTML, DTBook, ou XML avec sa feuille de style). Alors que tout système de lecture conforme ePub est capable de lire l’ensemble des OPS Core Media Types (comprenant des formats d’images comme le PNG, JPEG, SVG ou GIF), on ne peut pas utiliser ces fichiers directement pour composer son document.
Qu’est ce que cela implique ?
Prenons le cas de la BD. A priori, le format ePub est parfaitement adapté à ce support: on peut mettre dans le conteneur toutes les images, définir leur ordre de lecture et une table des matières.
Mais étant donné qu’on a pas le droit d’utiliser directement des OPS Core Media (les images ici) pour composer son document, pour chaque image il est obligatoire de créer un fichier XHTML uniquement pour afficher une image. Autant dire que c’est particulièrement inutile d’utiliser du XHTML dans ce cas, sans parler des problèmes inhérents au CSS par défaut: si on n’applique pas aussi du CSS pour chacun de ces flux XHTML, on se retrouve avec des marges inutiles pour une image, ainsi qu’une image qui n’est pas centrée.
Le problème est encore plus délicat en ce qui concerne la couverture d’un livre. A l’heure actuelle, il n’y a aucun élément dans les métadonnées pour pointer vers la couverture (certes en DublinCore non qualifié ce n’est pas évident, mais le groupe de travail sur l’OPF ayant justement étendu le DublinCore pour qualifier certains éléments, pourquoi ne pas avoir abordé ce point ?).
Vu qu’il n’est pas possible non plus de directement composer son document avec une image, on se retrouve obligé de devoir définir un flux XHTML.
Mais les complications ne s’arrêtent pas la: cette fois ci la faute en revient à DE. Etant donné que celui-ci considère la page XHTML comme n’importe quelle page plutôt que comme une couverture, il n’étire pas l’image si on utilise pas un format vectoriel.
Ainsi, dans la majorité des fichiers que j’ai pu observer non seulement, la couverture est un document XHTML, mais le plus souvent, c’est un fichier image non vectoriel, qui est inclus dans un SVG (vectoriel) avec des propriétés particulières.
Quelle complexité pour quelque chose d’aussi essentiel qu’une couverture !
J’ai eu l’occasion d’en parler avec Jon Noring il y a déjà quelques mois et d’après ses souvenirs, certains membres de l’IDPF avaient de bonnes raisons de n’accepter que les OPS Content Document dans la composition du document. J’aimerais bien les connaître, car en l’état, cette limitation semble totalement absurde et pousse à une complexité artificielle.
Restitution Vs. Flexibilité
Un autre point qui me saute aux yeux: l’utilisation quasi systématique dans les fichiers commerciaux de polices embarquées. Ainsi chez Penguin, le corps du texte principal utilise une police qui se trouve dans le fichier principal. Je comprend tout à fait ce en quoi c’est une chose que l’éditeur apprécie: on peut reproduire la présentation du livre papier et différencier des ouvrages qui seraient rapidement génériques quand à leur présentation.
Il y a plusieurs problèmes néanmoins quand on utilise systématiquement des polices de caractères embarquées pour l’ensemble du texte. Un problème de vitesse tout d’abord: ces fichiers sont plus lents à s’afficher globalement. Chaque page qu’on tourne prend un peu plus de temps à s’afficher, ce qu’on discerne à peine sur un ordinateur de bureau mais nettement plus sur un périphérique mobile. Ensuite il y a un problème de taille des fichiers. Si j’ai sur mon lecteur 20 livres de chez Penguin utilisant tous la même police embarquée, je vais me retrouver avec 20 fois la même police. Les polices sont assez gourmandes en terme de taille et peuvent facilement doubler la taille d’un fichier. Certes, au lieu d’embarquer des milliers de livres, cela me limitera à quelques centaines d’ouvrages, mais c’est tout de même un gaspillage d’espace disque.
Mais l’essentiel du problème est d’un autre ordre: on se retrouve dans une position où la volonté de restitution de l’oeuvre de l’éditeur rentre en conflit avec la volonté de personnalisation du lecteur.
Un des principaux attraits du Cybook Gen 3 de Bookeen est lié à sa capacité à embarquer les polices que l’on souhaite. Ainsi si plutôt que du Times, je souhaite utiliser du New Century Schoolbook ou du Garamond, pas de problème, je peux changer de police pour l’ensemble du texte.
A partir du moment où l’éditeur définit l’utilisation d’une police embarquée pour l’ensemble du texte, au lieu d’une utilisation pour des passages particuliers demandant une mise en forme précise (une lettre par exemple), il devient très complexe pour le système de lecture de faire la part des choses. Quand doit-il utiliser la police demandée par le lecteur à la place de celle précisée par l’éditeur ?
Cette question d’ailleurs dépasse largement le cadre des polices embarquées, et touche aussi à la mise en forme CSS ou XPGT. Il faut introduire un élément qui est nouveau pour le monde de l’édition: contrairement au livre papier, l’éditeur ne doit pas imposer sa présentation, sa mise en forme. Il faut trouver un nouvel équilibre entre les éléments que l’éditeur considère comme devant absolument être mis en forme à sa manière, et ceux où il faut laisser un degrès de liberté pour le lecteur.
Plus que des considérations techniques, ce qu’on bouscule c’est la manière de penser la présentation du livre. C’est un passage qui risque d’être très difficile pour le monde de l’édition, mais il est indispensable de se poser les bonnes questions et de mettre en place un ensemble de bonnes pratiques pour ne pas frustrer le lecteur, et lui retirer toute une dimension de liberté supplémentaire, qui n’existait pas sur support papier.
Typographie
Restituer l’expérience papier peut tout de même se faire sans marcher sur les pieds de l’utilisateur dans certains cas, à condition d’adopter certaines pratiques. Plutôt que de vouloir imposer leurs préférences, le monde de l’édition doit pousser l’IDPF à aller de l’avant. Je note en particulier choses qui manquent au standard:
- césure des mots
- contrôle de l’affichage sur la page
Avoir un contrôle total des éléments sur la page reste très complexe, et on peut comprendre les choix d’Adobe: à savoir l’utilisation de XSL-FO. Mais sans aller aussi loin, déclarer ne serait-ce que quelques zones particulières de la page, ce serait un premier pas (voir: http://blog.feedbooks.com/fr/?p=50).
- ceux qui veulent orienter le standard vers une restitution maximale (un rendu type PDF donc)
- ceux qui veulent s’inspirer du Web et ouvrir le standard vers plus d’interactivité, de services etc…
Il s’agit de trouver un nouvel équilibre entre éditeur et lecteur, tout en poussant le format et les systèmes de lecture en avant pour proposer une meilleure expérience de lecture.
Tags: ePub
Formidable synthèse, bravo Hadrien, pour les couvertures, l’affichage est excellent sur les versions enPRC, quel différence par rapport à l’ePub dans la conception des fichiers?
pour les typos embarqués, d’accord avec toi, c’est vraiment délicat à trancher, même si j’aime beaucoup la possibilité de choisir sa typo comme sur le Cybook, j’adorerais aussi retrouver des contenus avec des typos que j’apprécie beaucoup dans leurs versions papier, je pense par exemple GallimardQuarto, PhébusLibretto, etc. Pourquoi l’éditeur se priverait de la possibilité de passer ses choix graphiques en version numérique. J’adore Minuit sur le Sonyreader par exemple ! et je me demande si à l’identique d’un livre papier est bien un enfermement, au moins dans sa représentation.
Je pense que l’on va vers des améliorations considérables de la part d’Adobe dans les mois qui viennent. On peut quand même leur faire confiance pour la maitrise typographique
En Mobipocket (PRC c’est un format générique sous Palm), tu déclares la couverture dans les métadonnées, ce qui est bien l’un des seuls points où ce format est mieux conçu.
En typo embarqué en fait, je ne suis pas du tout opposé au fait qu’un éditeur propose sa typo même pour le corps du texte. Mais il y a une différence entre proposer, et imposer.
La différence n’est pas évidente, principalement à cause de l’utilisation du CSS. Il faudrait à mon avis, que les polices soient déclarées mais pas forcément appliquées dans la feuille de style. Ainsi, on appliquerait directement dans le CSS la police à des endroits où c’est indispensable uniquement (en-tête, passe nécessitant une mise en forme différente du texte et ainsi de suite). Le lecteur pourrait pour le corps du texte choisir entre la, voir, les polices embarquées dans le fichier, ou celle de son choix qu’il a transféré sur le lecteur.
Les améliorations ce n’est pas que d’Adobe qu’elles doivent venir. Adobe n’intervient dans cette chaîne que dans la création du système de lecture. Il faut aussi qu’au sein de l’IDPF, les choses aillent de l’avant et qu’on définisse clairement de nouveaux aspects du standard. Il faut aussi que les producteurs de contenus eux-même répercutent certaines pratiques.
Chacun a son rôle à jouer et s’il y a une défaillance quelque part, ça se répercute tout en bas, lors de l’expérience de lecture.
je pense aussi qu’il ne faudrait pas trop vite enterré le pdf, quand je vois la qualité sur le Sonyreader et la possibilité de grossissement maintenant, comment tu vois son avenir sur ces machines ?
Le “grossissement” (ou plutot recomposition du texte ici) est à mon avis une option de dépannage plus qu’autre chose, quand on ne dispose que d’un fichier PDF.
Commercialement par contre, je ne crois pas du tout en l’avenir du PDF sur des machines de petite taille.
Sur des appareils comme le lecteur de Plastic Logic, le PDF a par contre encore beaucoup d’avenir.
énormément de fichiers éditeurs dans un format poche ou semi-poches passent très bien sur le Sony, je fais l’expérience, bien mieux que l’ePub d’ailleurs! je doute que Sony lache cette option de développement qu’il a démarré lors de la dernière mise à jour. j’ai fait le test avec des pdf un peu structuré, appel de notes, renvoi des chapitres, c’est très probant! je crois qu’il ne faut pas enterré si vite le pdf d’autant que comme tu dis, des formats un peu plus grand vont arriver bientot. On parle du lecteur A4, mais un lecteur intermédiare 10pouces convrirait la très grande majorité des formats de livres, à suivre.
Sony n’a pas spécialement fait de choix dans cette direction, c’est plutôt dans le package Digital Editions qu’une demande particulière.
Regardes du côté de Waterstone’s et bientôt de ce qui se fera en France: je doute qu’on voit beaucoup de PDF avec DRM.
Les vendeurs en ligne qui sont à la traîne (comme ebooks.com) présentent volontiers leurs fichiers A4 PDF comme destinées au Sony Reader uniquement car ils n’ont pas encore fait le passage à l’ePub (d’ailleurs c’est un peu honteux de leur part de vendre du A4 comme optimisé pour le Sony Reader).
Les éditeurs et les magasins en ligne ne vont pas se compliquer la vie à proposer plusieurs fichiers PDF en fonction de l’écran, ils préfèrent distribuer des fichiers qui s’adaptent à l’appareil.
merci, docteur Hadrien, on est à l’écoute, quitte à lire 3 fois pour son éducation ! (non, merci bis, ton analyse est très claire, et nous documente…)
me confirme dans l’idée, pour ce qui me concerne à publie.net, d’en rester pour l’instant à bouquet de pdf optimisés selon les formats des quelques principaux lecteurs, ce qui se génère très vite si le texte source est bien structuré, pour gérer au mieux césures, justifs etc
mais ce billet plutôt pour ouvrir à autre demande :
vu hier l’annonce du soft Adobe pour les drm à licence 6500 dollars – est-ce que vous envisagez sur FeedBooks un webservice où vous pourriez de façon payante nous équiper nos eBooks en version protégée ?
est-ce qu’on pourrait envisager un regroupement de micro-éditeurs numériques s’achetant ensemble la licence pour partager frais ?
6500 dollars ce n’est que pour la licence, il faut compter après une petite somme pour chaque activation (vente ou prêt d’un livre).
Faire juste un webservice DRM sans rien d’autre je ne sais pas trop si ça m’intéresse. Je m’intéresse plutôt à des écosystèmes plus complets que cela. Je déconseille sinon de vendre des PDFs avec DRM: autant en ePub si on change d’appareil et que les deux sont compatibles ePub on peut facilement faire la transition, disons d’un appareil 6″ à un appareil 10″, que dans le cas d’un PDF le résultat sera assez piteux. Sans DRM, le problème se pose moins à condition que le service propose plusieurs tailles de PDF.
Merci, merci…
J’ai rarement vu un site aussi peu clair que celui de l’idpf (ceci étant sans doute lié au fait que je n’ai pas le courage d’aller lire la doc en anglais), alors un tel résumé c’est parfait !
Pour ma part, je reste beaucoup sur ma faim concernant la typo. La question des coupure de mots (j’ai lu que « césure » était a réserver à la poésie) est extrêmement complexe, d’autant que liée à la langue (non, pas envie que la typo anglaise devienne la règle internationale, même si ça a déjà commencé).
Je ne crois pas avoir encore lu un livre électronique sans butter sur des fautes de typo — même dans le « Aldo Manuzio » de Bruno — c’est dommage et montre bien la nécessiter de régler ce point, j’espère que tes critiques seront entendues.
Pour l’instant, et concernant l’affichage sur le sony — je dis « le » parce que, finalement, au quotidien, cet objet c’est un livre, un bouquin et je l’appel comme ça — je suis totalement de l’avis de François et Aldus : le pdf est de loin le plus agréable (et je ne touche pas à ce maudit bouton de zoom).
“Contrairement au livre papier, l’éditeur ne doit pas imposer sa présentation, sa mise en forme.”
Cela est d’autant plus vrai pour des questions d’accessibilité. Avec les livres électroniques, la distinction format poche – format normal – gros caractère disparaît. Ces formats correspondaient à des usages différents. Pour des raisons d’accessibilité, il est important que l’utilisateur puisse prendre la main sur la présentation : a minima la taille, la graisse, l’espacement des caractères/mots, l’interligne et la police bien sûr. Cela participe du confort de la lecture et devrait pouvoir être modifié par l’utilisateur. Le formatage de l’utilisateur devrait pouvoir prendre la main sur le formatage de l’éditeur par défaut. Les éditeurs devraient admettre que les lecteurs sont tous différents, qu’il n’y a pas de mise en page parfaite dans l’absolu et qu’un des apports du livre électronique, c’est justement de pouvoir adapter la présentation en fonction de ses propres besoins.
Effectivement, si chaque éditeur y va de sa propre police pour se démarquer (ce qui est compréhensible), il est obligé de l’embraquer dans chaque fichier epub. C’est la seule solution simple. Maintenant aux éditeurs de juger des avantages/inconvénients pour les utilisateurs. Il est vrai également que les performances des livres électroniques vont évoluer.
Pour l’agrément de la lecture la gestion dynamique des césures serait incontestablement un plus. Si j’ai bien compris, si je passe d’une police 10 à 14, j’ai mécaniquement plus de page et la mise en page de chaque page est revue… et donc il faut revoir également les césures. Dans ces conditions il faut effectivement que la gestion des césures soit dynamique via un dictionnaire pour chaque langue – plutôt que d’avoir un fichier avec césure par taille de police, voire par taille de police et police.
Entre ePub et PDF, le choix est vite fait, selon moi, pour un format ouvert (i.e. non propriétaire), léger et compréhensible par tous : ePub. Au format ePub d’évoluer pour égaler, voire surpasser le PDF, en s’inspirant de tes remarques par exemple. Le ePub doit évoluer et s’imposer comme LE standard. C’est l’intérêt de tout le monde.
Notamment, ce qui est génial avec le ePub, c’est qu’à l’instar du HTML chacun peut créer ses livres numériques à la main et éditer ses propres textes. Pas besoin de logiciels coûteux, c’est accessible à tous. C’est aussi enthousiasmant que le web. Avec ePub, chacun peut être un Gutenberg 2.0. Tout un esprit ! (J’ai fait mes premiers livres numériques au format ePub : quelle émotion quand ils s’affichent enfin dans ADE !)
Très pertinente ta remarque sur l’intérêt du format ePub vs PDF par rapport à la gestion des DRM.
Nous sommes bien d’accord. Il faut que le format soit ouvert et léger. Et l’epub est le meilleur candidat. De ce que j’ai compris le problème est aussi dans le rapport entre le format lui-même et le « moteur » contenu dans le lecteur qui l’affiche. Et cette histoire de coupure de mots est à ce niveau là.
De même quelle tristesse de ne pas avoir les ligatures avec ces « moteurs » intégrés livres électroniques (alors que firefox3 les gères !).
Pour le reste, il y a des solutions, comme un dictionnaire intégré dans la machine associé à un dictionnaire spécifique — ou des indications directement dans le source comme on le fait en LaTeX — pour les mots qui risquent de ne pas se trouver dans le dictionnaire.
Pour les polices c’est la même chose, l’OS du livre peut contenir des polices dans un répertoire propre et effacer automatiquement celles du fichier nouvellement installé si la police est déjà en interne — et l’y installer dans le cas contraire… problème de licences sur les polices.
Rien d’insurmontable sans doute, mais des standard à décrire et des accords à trouver entre tous les acteurs.
Merci pour l’idée de l’accessibilité, c’est en effet un point primordial. Quand je vois des personnes lire à la loupe, il est évident que le livre doit s’adapter, que les éditeurs doivent faire cette concession. Le changement du nombre de pages qui en découle nous ramène à la question de comment désigner un emplacement dans le fichier ? La page n’existe plus, reste le pourcentage (ou le ‰), le mot, le kilomot ?
d’accord avec toi, Renaud – mais tu as testé où ça en est, l’ePub, sur Sony ? tant que ce format ne sera pas capable de faire de la justification et de la césure, on continuera à travailler avec le PDF – d’autre part, l’écrasante masse des eBooks gratuits c’est du texte en prose au kilomètre – on annule 300 ans d’histoire de la langue qui s’est faite, poésie mais pas seulement, via la typo, via le rapport au blanc et à la tourne – André du Bouchet en ePub ? – mais moi j’ai besoin d’André du Bouchet…
cela n’enlève rien, évidemment, au souhait partagé d’un standard commun efficace
PS pour Hadrien : petit commentaire perso sur Calibre ? – interface vraiment formidable pour gérer le Sony, en tout cas depuis mon Mac – Olivier, tu as testé en Nunux ?
http://calibre.kovidgoyal.net/
Beaucoup de choses dans les différents commentaires, alors dans l’ordre…
@Renaud: oui l’accessibilité est très importante et c’est un argument qui joue un rôle important au sein de l’IDPF (DTBook, NCX etc…).
Concernant la pagination ça dépend du système de lecture. Digital Edition part du principe qu’un écran n’est pas une page. Ainsi un affichage d’un écran peut se retrouver entre 2 pages. Il y a un certain nombre d’avantages à cela:
- facile de déterminer le nombre total de pages (soit c’est spécifié dans une extension Adobe à part, soit c’est directement lié à la taille des flux XML), ce qui n’est pas évident si c’est vraiment paginé pour une page = un écran (il faudrait alors parcourir tout le fichier ce qui serait très long)
- la taille de la police n’a aucun rapport avec le nombre de pages
- on peut faire une équivalence papier et éléctronique
C’est à mon avis un peu mieux qu’un simple % mais on peut s’y perdre un peu quand on voit affiché en bas de l’écran qu’on est en train de lire la page 6-7.
@Olivier: l’ePub est léger quand au poids de ses fichiers, pas forcément quand à sa complexité.
Je rapelle que tous les fichiers ePub ont dans leurs métadonnées la langue du livre. On pourrait donc facilement utiliser des dictionnaires de césure directement en provenance de l’appareil, pas besoin de les embarquer. On peut aussi à un niveau plus fin, employer xml::lang pour spécifier une langue différente (un passage en latin par exemple). Embarquer dans le fichier le dictionnaire de césure: ce serait utile pour le vocabulaire technique ou pour certaines langues où on est pas sur que le système de lecture dispose d’un dictionnaire de césure.
@F: Calibre est une bonne initiative de Kovid, en particulier pour ceux qui souhaitent utiliser des documents qui ne sont pas dans un format supporté par le Reader. Mais la conversion a ses limites, en particulier en ce qui concerne les formats les plus avancés. Ainsi s’il est surement idéal d’utiliser un fichier ePub comme source pour un autre format, dans le sens inverse c’est très problématique. Quitte à faire, il faut systématiquement employer la représentation de plus haut niveau comme source.
Pour ce qui est de la gestion des fichiers, je ne me sers ni du logiciel de Sony, ni de DE: l’UMS me convient très bien.
@François. C’est vrai que je n’ai pas de Reader et donc que je ne me rends pas compte. Cela dit l’implémentation du ePub dans les machines n’en qu’à ses débuts et le potentiel est énorme. En attendant une meilleure prise en charge du format, c’est sûr qu’il faut se débrouiller au mieux avec les moyens du bord.
En revanche, il ne faudra pas tomber dans les mêmes travers que pour le web. S’il existe différents moteurs de rendu, l’affichage doit identique à livre identique et paramétrage identique pour chaque périphérique (marges, espacements,…) sauf évidemment le nombre de mot par page qui dépend de la taille de l’écran.
De même, le développement d’éventuels ePub propriétaires est à surveiller (la tentation sera grande surtout chez Adobe et Microsoft), comme Netscape versus IE il y a une dizaine d’année (et cela perdure IE vs Firefox).
Après lecture du commentaire d’Adrien : “sauf évidemment le nombre de mot par écran qui dépend de la taille de l’écran”.
Exactement, il faut bien faire la différence entre le format et les systèmes de lecture.
Stanza par exemple supporte déjà la justification et j’ai convaincu Marc il y a plusieurs semaines qu’il devait implémenter un support pour les dictionnaires de césure plutôt que d’utiliser l’entitée HTML dédiée et en insérer partout dans le texte ( pour soft hyphen).
D’ailleurs la très grande majorité des ePub de Feedbooks ne sont pas lus sur DE mais sur Stanza à l’heure actuelle.
Les systèmes de lecture ePub n’en sont qu’à leur début, mais il faut clairement définir des règles à tous les niveaux. Tu as raison Renaud de souligner le cas des navigateurs. L’ePub est assez strict pour ce genre de raisons d’ailleurs (XHTML 1.0 strict par exemple).
merci Hadrien, bis
du coup, je prolonge ici
http://www.tierslivre.net/spip/spip.php?article1396
@F : oui, testé calibre dès sa découverte (Cf billet du 31 juillet). Mais je n’avais pas accroché, Ça tourne sous linux sans problèmes (les bibliothèques sont nativement unix). Pour le moment je n’ai qu’une trentaine de texte dans mon livre… La nécessité d’utilisation de calibre arrivera bien avec le temps et la quantité.
@Olivier Les “fautes de typo” relevées dans la version d’Aldo Manuzio résultent de la gestion du Sony. Je sais que Librii regarde, nous étudions d’autres formats. Car il n’y a pas que les problèmes de césure ou de justification, il y a aussi la gestion de la ligature, des insécables, sans parler des éditions graphiques, interactives, ou animées.
@F “cela n’enlève rien, évidemment, au souhait partagé d’un standard commun efficace”. C’est l’efficace qui coince, et pour un moment, semble-t-il. Tu dis 2 ans dans ton billet, on a vu de tels projets ne jamais se terminer, surtout lorsque les intérêts financiers s’en mêlent. De toutes façons, je ne crois pas à la suprématie d’un standard pour le livre électronique. Je me fendrai aussi d’un billet sur sur le sujet.
on attend ton billet, Bruno, la question du format c’est aussi comment nous autres, en bout de chaîne, on peut l’utiliser et le diffuser, en fonction des supports utilisés par nos lecteurs…
Aldo Manuzio sur ma Sony, vraiment pas grand-chose à reprocher, hors de temps en temps les césures avant les doubles consonnes, mais je ne me rendais pas compte du pb soulevé par Hadrien (on aura des choses, à discuter, dans l’avion pour Montreal!)
PS, Hadrien, tu peux pas nous mettre un “refresh” sur ton captcha, j’arrive même pas à lire les lettres 1 fois sur 2 ?
@Bruno : merci. J’ai aussi vu les autres problèmes, oui… C’est étrange car sur mes pdf les espace autour des tiret sur incise, par exemple, sont parfaitement gérés, là on dirait que les espaces internes sont passées d’insécables justifiantes à espace mot. J’ai aussi des lignes qui n’ont pas du tout d’espaces entre les mots (ou si fin que pas). Si ça peut aider j’ai du mettre des marques pages aux pages sur lesquelles j’ai ces problèmes.
Il faudra que tu nous expliques comment ce peut-être de la faute du lecteur sony avec des pdf. J’ai encore du rater quelque chose concernant la nature des pdf. Je n’utilise jamais les fonctions de zoom. Cet histoire de lignes sans espaces c’est la première fois qu’un pdf me fait ça. Peut-être y-a-t-il plusieurs types de pdf ?
@F et Olivier
Troublant, et qui illustre le niveau de problème. F et Olivier, vous avez à priori la même version d’Aldo Manuzio! Je laisse Librii faire l’état des lieux, on fera le bilan. J’avoue ne pas être un pro de la chose. Je sais que le nouveau firmware a introduit une différence lors du zoom. J’ai d’autres ouvrages dont la place des marges fluctue.
Librii a des projets sur iPhone, également. Le choix du format et de l’appli est en cours. Pour en rajouter pour F, c’est là non seulement délicat quant aux possibilités de composition et de consultation, mais encore plus compliqué pour l’éditeur. Si tu choisis une appli dédiée (eReader, Stanza,…), tu es lié à son modèle économique et ses actions marketing. Si tes titres sont indépendants, tu bénéficies du marketing d’Apple titre par titre. Si je ne me trompe pas. Difficile de prévoir comment tout cela va évoluer.
Hum j’étais en train de réfléchir à partir de quel format source travailler pour republier un livre, et je suis tombé ici. Pour le moment je travaille en LaTeX, qui permet un rendu impeccable tant du point de vue typographique que de la mise en page (césures, espace insécables, etc.).
Mais je réfléchis aussi à export possible vers des liseuses, et là l’export PDF de LaTeX ne me semble pas approprié au vue de vos propos.
Pourquoi un format Docbook ne serait pas adapté à ces machines ? Une css pour gérer la justification et les polices, et un bon moteur d’affichage qui se chargerait des césures. d’autant plus que cela permettrait d’insérer des couvertures en SVG directement.
Bonne remarque Bob, alors:
- Tu peux utiliser du DocBook pour créer de l’ePub, il existe un XSL pour
- Tu peux aussi directement utiliser ta source DocBook comme flux XML dans un ePub à condition d’embarquer aussi une feuille de style CSS
- Le SVG est dans les OPS Core Media de l’ePub et c’est ce qui est conseillé en général pour les couvertures
Comme tu vois donc, l’ePub est assez bien conçu sur ce point, et surtout très flexible. Ce qui manque, c’est le moteur de rendu qui pour le moment est à la traîne.
Bonjour !
Je vois que Calibre à été évoqué ici.
Je l’ai essayé en convertissent des fichiers odt. Il s’agit d’un roman avec des chapitres. Le titre des chapitres en style Titre 1. Open Office en tire sans difficulté une table des matières.
Je pensais que Calibre allait se servir de ça pour repérer les chapitres, mais il n’en est rien. Il me fait un fichier epub sans un seul chapitre.
Quelqu’un a une idée ?
D’expérience, sur les lecteurs portables “eInk”.
Pour l’instant ces lecteurs ne sont pas adaptés à un autre usage qu’une lecture séquentielle car le changement de page est trop lent.
Donc ils servent surtout à lire des romans. Et dans ce cas, le seul avantage de l’epub sur le texte “à plat” est d’offrir plus d’options de classement des livres. Les chapitres servent peu, les images non plus, l’écran n’étant pas adapté.
[...] l’espacement entre les mots et améliorer le “gris typographique”. Pour reprendre la discussion de Feedbooks, je ne crois pas que ce soit à l’IDPF de se pencher sur cette question, mais plutôt aux [...]