E-Books Discussion sur le format Epub

[Coolmicro]

Nous avions commencé une discussion sur l'epub, en détournant honteusement le sujet de Robert sur Cyrano - https://www.mobileread.com/forums/showthread.php?t=36651

Zelda a ensuite créé un sujet en anglais sur le forum epub, mais bon, nous ne nous exprimons pas tous facilement en anglais, moi le premier, il semble utile qu'il y ait un sujet sur ce format, en français, quitte à ce que Zelda transmette au forum en anglais les idées qui lui semblent intéressantes (à mettre en sticky, peut-être? étant donné l'importance du sujet).

J'ai fait beaucoup de tests, réfléchi sur la question, discuté avec Hadrien par mail.

Mes tests ont eu lieu avec Calibre. Il est apparu que lorsqu'on on entrait du HTML obtenu avec Word ou OpenOffice dans Calibre, le résultat apparaissait correct au premier abord, mais Epubcheck révélait ensuite de nombreux problèmes.

Par contre, lorsqu'on entre de l'ODT (OpenOffice par exemple) dans Calibre, le résultat est bon, les problèmes résiduels qui demeurent étant dus à Calibre, et non au document lui-même. Voir pour ceux que ça intéressent :
https://www.mobileread.com/forums/sho...=29350&page=20
https://www.mobileread.com/forums/sho...=29350&page=21

Je rappelle que la discussion précédente tournait autour du besoin d'un logiciel accessible à tous, pas trop compliqué, mais produisant des epub de qualité.

Je pense que Calibre pourrait plus ou moins y parvenir un jour (car c'est déjà un bon logiciel), mais je n'en suis pas sûr, car c'est difficile avec un logiciel qui a pour ambition de tout accepter en entrée, et plusieurs format en sortie. Il serait nettement préférable qu'apparaisse un logiciel spécialisé pour la production de l'epub, qui ne fasse que ça.

Contrairement à ce que je pensais et à ce que j'ai pu dire précédemment, j'ai enfin compris qu'il est impossible de produire un bon epub en entrant, par exemple, du HTML. Il faut entrer des flux XHTML structurés pour qu'un logiciel puisse fournir en sortie un epub correct. Mais, fournir de tels flux XHTML n'est pas à la portée de tout le monde, et je continue de penser que le traitement de texte est la seul base pour que le commun des mortels, avec des connaissances informatiques moyennes, puisse faire des ebooks ou des documents divers.

La conclusion de tout ça est qu'à mon avis, la seule base possible pour alimenter un logiciel de production d'epub, en dehors de flux XHTML, est le format ODF (ODT pour le traitement de texte), qui est le seul qui soit ouvert, libre, standardisé et suffisamment structuré. Les tests faits avec Calibre montrent déjà que c'est possible, et il est probable que le travail déjà effectué au niveau de Calibre concernant l'epub pourrait en partie être réutilisé pour un autre logiciel si nécessaire. De plus avec OpenOffice (qui n'est pas la seule application à travailler avec l'ODF, mais qui est la plus connue et la plus accessible), il est possible et facile de styler entièrement un document selon des normes précises qui seraient édictées, par exemple, par le logiciel destiné à produire de l'epub. On peut même imaginer qu'un modèle OpenOffice soit fourni en complément d'un tel logiciel, avec les styles devant être utilisés pour la structuration du document (pourquoi pas un style parties de niveau 1, un style chapitres de niveau 2, un style sections de niveau 3, etc)

[zelda_pinwheel]

excellente initiative, coolmicro ! merci. j'en ai fait un sticky. je pars pour l'apéro MR là mais je reviendrai pour la discussion.

[Coolmicro]

Bonne nouvelle, la nouvelle version d'Adobe Digital Edition vient de sortir, et elle prend enfin en compte la justification des lignes.

Mauvaise nouvelle: cette justification doit être codée dans les balises du XHTML, et ne s'applique donc pas si le fichier XHTML n'intègre pas la justification.

Le lecteur n'a donc pas vraiment la possibilité de choisir de justifier ou non son texte, contrairement, par exemple, à un lecteur comme Mobipocket.

Donc, pour le moment, il vaut mieux intégrer la balise justify, la majorité des lecteurs préférant se voir "imposer" la justification des lignes plutôt que cette justification soit absente.

[Coolmicro]

Autre bonne nouvelle: dans la dernière version de Calibre, les derniers bugs qui posaient de sérieux problèmes de validité pour les ebooks epub produits, ont été corrigés (sauf une "coquetterie" du développeur, par ailleurs sans grande importance). De plus il y a maintenant 3 niveaux possibles pour la table des matières.

Voici le résultat que nous avons obtenus sur un fichier qui posait de nombreux problèmes auparavant:
http://ebooksgratuits.com/epub/loti_...nchantees.epub
Rappelons que nous utilisons, en entrée de Calibre, un document odt (OpenOffice).

Sans atteindre à la qualité professionnelle et à la souplesse de Feedbooks, c'est quand même maintenant une bonne solution, envisageable pour produire des ebooks epub de qualité.

[Hadrien]

Par contre tu devrais ajouter une marge au moins à droite: Adobe DE a la mauvaise manie d'afficher les numéros de page dans la marge droite, et cela risque de poser problème si tu n'en as pas, avec ces numéros s'affichant par dessus le texte.

[Hadrien]

J'ai l'impression que tu as des soucis de métadonnées aussi vu ce qui est affiché dans DE, il faudrait que je décortique ton OPF...

[Coolmicro]

Originally Posted by Hadrien

Par contre tu devrais ajouter une marge au moins à droite: Adobe DE a la mauvaise manie d'afficher les numéros de page dans la marge droite, et cela risque de poser problème si tu n'en as pas, avec ces numéros s'affichant par dessus le texte.

C'est le même problème que pour la justification, il faut pallier les insuffisances de Adobe DE en mettant dans l'ebook des choses qui ne devraient pas y être. Dans Mobipocket Reader, ou même dans FBReader (qui est pourtant loin d'être un modèle en matière de fidélité du rendu), l'utilisateur peut définir ses marges, et c'est ainsi que cela doit être.

Comme tu l'as souligné à plusieurs reprises, l'organisation artisanale d'ELG ne permet pas de faire ensuite la mise à jour d'un format lorsqu'il y a des changements au niveau de ce format. Donc, si j'introduis ces marges, elle resteront et se surajouteront aux marges du lecteur lorsque Adobe DE aura enfin implémenté cette fonction.

J'ai essayé avec des marges toutes petites (0,3 cm de chaque coté) et j'ai demandé aux utilisateurs de petits écrans de tester (iphone+stanza).

C'est toujours:
http://ebooksgratuits.com/epub/loti_...nchantees.epub

[Coolmicro]

Originally Posted by Hadrien

J'ai l'impression que tu as des soucis de métadonnées aussi vu ce qui est affiché dans DE, il faudrait que je décortique ton OPF...

Je ne pense pas que tu fais allusion à la faute d'orthographe due à une trop grande précipitation. Donc, la seule chose que je vois, qui peut te paraître anormale, c'est l'absence d'accent. C'était volontaire car les titres ou noms d'auteurs saisis avec accents dans Calibre me donnent des caractères bizarres sous Adobe DE (peut-être parce que je travaille sous Linux, sous sous XP virtualisé ??). Aussi j'ai fait le choix de virer les accents pour les tests...

Mais, comme tu peux le voir dans la dernière version de Loti, les accents sont en place: il m'a fallu éditer le fichier OPF manuellement pour cela...

[Coolmicro]

A propos du livre de Loti, Hadrien, je voudrais discuter de ce qui m'apparaît comme le seul défaut de Feedbooks concernant l'édition des livres. Je ne parle évidemment pas de validité des formats, sur ce plan vous êtes irréprochables, mais du nommage des parties et chapitres, et de la numérotation automatique.

Chez ELG, nous attachons une grande importance au respect maximum de l'édition papier utilisée, et le nommage des parties et chapitres, le mode de numérotation et le libellé de numérotation, en font partie. Encore plus important: quand un auteur comme Loti fait le choix de numéroter les chapitres à la suite, sans recommencer la numérotation à chaque chapitre, cela a une signification littéraire, et les parties n'ont plus alors exactement le même rôle que dans une numérotation qui recommence à chaque partie. C'est le cas du livre en exemple.
Il faudrait que la numérotation et le libellé automatique de numérotation soient débrayables dans l'interface Feedbooks, qu'on ait la possibilité de mettre:
PREMIÈRE PARTIE
....
SIXIÈME PARTIE
et
I
II
III
...
XLVII
toujours en prenant l'exemple du même livre.
Je parle évidemment de ce que le lecteur voit, cela n'empêche pas que vous gardiez votre numérotation en interne dans votre BD.
Il faut aussi signaler que parfois, un numéro de chapitre est absent d'un livre, et que cela signifie parfois que ce chapitre a été perdu (cas de la littérature populaire publiée en feuilleton); dans ce cas, toute édition sérieuse se doit de respecter la numérotation absente du chapitre absent.

[Hadrien]

C'est cela qui n'est pas bon sur l'auteur dans l'OPF:
<dc:creator opf:role="aut" opf:file-as="Loti Pierre">Loti Pierre</dc:creator>
Tu devrais avoir:
<dc:creator opf:role="aut" opf:file-as="Loti, Pierre">Pierre Loti</dc:creator>

Sinon après avoir étudié l'OPF, je ne sais vraiment pas ce qu'il a foutu Kovid, il déclare son propre namespace (xmlns:calibre="http://calibre.kovidgoyal.net/2009/metadata") mais il utilise des balises meta pour series_index et rating.

Sinon je vois un autre problème potentiel: les livres fabriqués par Calibre sont très loins d'avoir des identifiants uniques. Ce fichier a "280" comme identifiant, ce qui n'est pas du tout assuré d'être un identifiant unique. Or le standard stipule bien que c'est le devoir du producteur de contenu d'associer un identifiant unique à son fichier ePub/livre.

Pour la numérotation: dans ce cas la tu peux utiliser des sections plutôt que des chapitres, et tout numéroter toi même manuellement (tu perdras juste nos en-têtes de chapitre). Plus tard sinon on permettra surement soit de modifier le template, soit de forcer une numérotation manuelle. Mais à l'heure actuelle, c'est quand même plus simple de partir d'une automatisation, étant donné que pour la grande majorité des livres, il ne sera pas nécessaire de modifier la numérotation, et donc ça simplifie les choses pour les auteurs se publiant chez nous ou les contributeurs.

[Coolmicro]

Merci pour les explications.
Pour l'auteur, il est fort probable que j'aie mal saisi, car il y a 2 champs, et je n'avais pas compris les différences. Je vais voir ça.
Puisque que tu parles mieux anglais que moi, pourrais-tu discuter des problèmes que tu évoques ci-dessus avec Kovid, dans ce sujet : https://www.mobileread.com/forums/sho...=29350&page=23 ?
Il faudrait en particulier lui demander de prévoir un champ pour qu'on puisse saisir nous-même l'identifiant, son logiciel ne mettant un identifiant que dans le cas où le champ identifiant est laissé vide par le créateur de l'ebook. Ainsi on pourrait mettre un identifiant unique basé sur les 4 premières lettres du nom de l'auteur, les 4 premières lettres du nom du titre, et une série de chiffres unique propre à ELG, ce qui assurerait un identifiant absolument unique.

[NicolasR]

Bonjour à tous et merci pour les réflexions.
Je trouve moi aussi que les epub générés à partir d’ODT avec Calibre sont plus propres.
Mais il y a un GROS MAIS : les gestions des notes de bas de page et des toc.
Quand je soumets un .odt avec des notes de page à Calibre, les renvois ne marchent pas (ni dans un sens, ni dans l’autre). Alors qu’à partir d’un .html généré par OOo, Calibre génère des notes qui marchent bien.
Et aussi, pour une raison que j’ignore, Calibre n’arrive pas à générer une toc correcte, même quand je mets bien des Titre1 dans mes .odt ou .html. Calibre fait une toc… avec les notes de bas de page, ce qui ne m’intéresse pas vraiment ! Il faut à chaque fois que j’ouvre l’epub dans Sigil, puis que je génère une .toc avec Sigil, et là ça marche.
Je n’ai pas encore essayé avec Atlantis…

[Maxguevara]

Salut tout le monde ! Bon ptite question pour les connaisseurs...

Je suis en train de fignoler mon EPub et je voulais intégrer dans ma CSS une propriété pour gérer mes césures (qui sont immondes quand gérées par IBooks).

Seul problème, j'ai trouvé en CSS3 les propriétés hyphenate-before, hyphenate-after et hyphenate-lines qui, en théorie, permettent de gérer exactement ce que je veux... Sauf qu'une fois intégré dans ma CSS... IBooks s'en contre-fiche et fait ce qu'il veut, c'est à dire n'importe quoi !

Quelqu'un aurait une idée ? J'ai essayé de le mettre dans le body, dans le texte tout court, avec -epub- avant la propriété, rien à faire...
Z'auriez une idée les gens ???

Merci d'avance !! ^^

[Arios]

Maxguevara,

Peut-être ne l'as-tu pas remarqué, mais le fil que tu as choisi pour ton message est inactif depuis mars 2010: c'est plutôt ancien.

En ce qui concerne ta question, je ne peux pas d'aider parce que je n'utilise ni iBooks, ni un iPad d'ailleurs.

Tu as probablement plus de chance d'obtenir une (ou des) réponse(s) ici: https://www.mobileread.com/forums/forumdisplay.php?f=170 ou là: https://www.mobileread.com/forums/forumdisplay.php?f=179

Je te suggère de créer un nouveau fil (New Thread) avec un titre aussi explicite que possible en expliquant clairement ton problème: les réponses risquent de l'être aussi. (You should do it in English of course)