Créer un EPUB avec LibreOffice et writer2xhtml (W2X)

[roger64]

Encore du nouveau

Test de l'extension 1.1.7 et propositions

Je viens de recevoir la version 1.1.7 de l'extension W2X que je vous mets en pièce jointe. Elle comprend déjà l'éditeur de méta-données ! Les choses se précipitent.

Le développeur nous demande notre aide pour la tester et faire nos propositions d'améliorations. Il y joint les commentaires suivants:

Extrait

I have attached the latest version of the extension, which now features the rearranged content I mentioned, as well as an editor for meta data.
The meta data editor is called directly from the export dialog. This is not optimal, but I don't want to waste valuable screen real estate on yet another toolbar. It's not completely finished: You cannot add dates yet, but as I probably won't have much time the next week or so to finish it, I send it now.
I hope you can test it and report the problems and deficiencies, you find.

And of course other good ideas are welcome too!

Fin de l'extrait

Après l'avoir remercié, je lui ai indiqué qu'une réponse de notre part arriverait d'ici quelques jours. Je regrouperai à cet effet vos commentaires et propositions.

Merci d'avance de votre aide et de votre participation.

[Coolmicro]

Très bien, je teste ça demain et je ferai directement les retours (avec copie ici) au développeur.

Atlantis bouge aussi. Avec la dernière version 1.6.5.4 encore en beta - http://www.atlantiswordprocessor.com...lantis16fr.exe :
1. Toutes les "dimensions", marges, indentations, etc sont en em (et plus en px ou cm)
2. Quand on met un titre seul sur un paragraphe, et qu'on le barre avec la commande format, le titre apparaît dans la table des matières, mais disparaît du texte lui-même : très pratique lorsqu'il y a un passage un peu long entre la couverture et le premier chapitre, n'est pas Roger...

Par contre, il ne veulent rien entendre, pour le moment, en ce qui concerne le nommage des styles. Je leur ai encore envoyé un mail pour essayer de les convaincre.

[roger64]

@Coolmicro

De mon côté, je continue à tester...

Très bien, je teste ça demain et je ferai directement les retours (avec copie ici) au développeur.

OK. Merci de nous garder dans la boucle. Actuellement, ma principale difficulté est pour l'affichage plein écran des images. Mais je n'exclus pas de ma part une manip fautive comme c'était le cas pour les tableaux.

Alors si tu y es parvenu, avec W2X tout seul (sans toucher au CSS), je suis preneur du réglage exact sur OpenOffice et W2X.

A la base d'ailleurs, j'aimerais savoir: faut-il employer une image 9x12? Cela me parait curieux parce que OO accepte les tailles relatives pour les images comme pour les tableaux.

Atlantis bouge aussi. Avec la dernière version 1.6.5.4 encore en beta - http://www.atlantiswordprocessor.com...lantis16fr.exe :
1. Toutes les "dimensions", marges, indentations, etc sont en em (et plus en px ou cm)

Je lui en ai déjà parlé : Images en %, textes en em mais ça ne fera pas du mal de souligner ce point.

2. Quand on met un titre seul sur un paragraphe, et qu'on le barre avec la commande format, le titre apparaît dans la table des matières, mais disparaît du texte lui-même : très pratique lorsqu'il y a un passage un peu long entre la couverture et le premier chapitre, n'est pas Roger...

Tiens, tiens, d'aucuns m'avaient parlé de perfectionnisme...

[Coolmicro]

Voilà le message que je viens d'envoyer à Henrik :

Hello Henrik,

I tested the new version 1.1.7. Good work !

I list above, small bugs and suggested changes. I am attaching to this mail the files odt and epub used for this test.

* In the TOC, where there are line breaks in the title, they should be converted to spaces :

<navLabel>

<text> CHAPITRE PREMIER TÉMOIGNAGES CONSTATANT L’EXISTENCE DE L’ATLANTIDE</text>
</navLabel>

and not

<navLabel>
<text> CHAPITRE PREMIERTÉMOIGNAGES CONSTATANT L’EXISTENCE DE L’ATLANTIDE</text>
</navLabel>

* Is it possible to add this feature (which exists for Atlantis) : When a Title 1 is hidden (Format - Hidden), as "cover" in the attached example, it would have to appear in the TOC, and not in text.

* For the pictures, cover and others : When the height is greater than the width, and when the size is larger than 200x300px, we should use this code : max-width:100%;height:100%, so that the images are in full screen. For other images, it is better than the width and height are in %, not in cm.

It is better than the first image of the document on the first paragraph - the cover image – is in separate file xhtml, the title page chapter.xhtml for you. Sample :

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN" "http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd">
<html xml:lang="fr-FR" xmlns="http://www.w3.org/1999/xhtml">
<!-- This file was converted to xhtml by Writer2xhtml ver. 1.1.7. See http://writer2latex.sourceforge.net for more info. -->
<head>
<title>Cover</title>
<link href="styles/styles1.css" media="all" rel="stylesheet" type="text/css" />
</head>
<body dir="ltr">
<p class="Standard" dir="ltr" style="margin-left:0em;margin-right:0em;text-indent:0em;text-align:center"><img alt="Cover" class="frameGraphics" id="images1graphic" src="images/image001.jpg" style="margin-left:0em;margin-right:0em;border:none;padding-top:0em;padding-bottom:0em;padding-left:0em;padding-right:0em;max-width:100%;height:100%"/></p>
</body>
</html>

* For margins, padding, indent, it would be much better to use the em unit or % as cm.

* For footnotes, they should be separated with a line or something, of the text at the end of the chapter.

It's all

Best regards

PS : My apologies for my unfortunate English

--

Coolmicro
Coordinateur du groupe Ebooks libres et gratuits

[Coolmicro]

Originally Posted by roger64

Actuellement, ma principale difficulté est pour l'affichage plein écran des images. Mais je n'exclus pas de ma part une manip fautive comme c'était le cas pour les tableaux.
Alors si tu y es parvenu, avec W2X tout seul (sans toucher au CSS), je suis preneur du réglage exact sur OpenOffice et W2X.

Non, tu n'y es pour rien, c'est OO/W2X qui est en cause. J'explique dans le mail les règles que je propose.

[Coolmicro]

La sympathique réponse de Henrik :

Hi Michel
Thanks for your feedback, it's very helpful! Unfortunately I don't have time to work on it the next week or so, but I will return to you as soon as possible.
Have a nice weekend.
Best regards
Henrik

[roger64]

Edition

Un recueil de nouvelles, Tableaux vivants, par Aurélien Scholl
https://www.mobileread.com/forums/sho...29#post1416529
Réalisé 100% avec OO 3.3 plus W2X version 1.1.7
Remarquablement compact pour un assez gros livre.
N'hésitez pas à me faire part des défauts éventuels.
Il y a un tableau page 36 et des exposants partout...

W2X

Oui, il m'avait dit serait absent et c'est pour cela qu'il s'était dépêché de poster sa version sans avoir le temps de finir le champ "dates" dans les meta-data.

Images

A mon avis, il n'y a pas de fatalité OO/W2X, l'EPUB Transcription W2X 1.1.7 le prouve.
Il y a des bonnes méthodes à trouver et j'espère bien y arriver.
On y est bien arrivé pour les tableaux.

Les formats JPG et PNG ne sont pas, me semble t-il, indéfiniment réduisibles ou extensibles (scalables). En matière de scalabilité, l'idéal est l'emploi d'images au format SVG (possible dès à présent avec Libre Office) mais on ne trouve pas toutes les images qu'on veut dans ce format et surtout je ne sais pas si toutes les liseuses les supportent.

Une image a une taille originale (réelle), celle que l'on peut lire dans GIMP, exprimée en pixels, millimètres etc.. Cette taille originale peut être modifiée de façon permanente (création d'une nouvelle taille réelle) ou provisoire (image dite magnifiée ou réduite).
Image Magick modifie les tailles réelles
OpenOffice fait des modifications provisoires (ne touche pas à l'image réelle)

Il y a d'autre part une question de vocabulaire: le mot "relatif" n'a pas le même sens pour OO et pour le CSS.

- OpenOffice calcule en pourcentage par rapport à la taille originale de l'image. Le pourcentage 110, signifiera que l'image sera magnifiée de 10% p/r sa taille réelle. Cette façon de calculer est normale.

- Le CSS calcule en pourcentage par rapport à la taille d'écran du support d'affichage, quel qu'il soit. Il n'y a pas grand sens à fixer un pourcentage supérieur à 100%. Cette façon de calculer est également normale.

Ceci étant dit, je poursuis mes essais

[Coolmicro]

Je ne dis pas qu'il y a une fatalité, je dis seulement que tout se joue au niveau de W2X, il n'y a pas de possibilité au niveau de OO d'indiquer des %, au contraire des tableaux.

Par ailleurs, j'ai un autre correspondant, qui a commencé à faire des versions epub illustrées pour ELG à partir d'algorithmes qui lui sont propres (il a développé son propre convertisseur), et je compte approfondir avec lui sa méthode dont les résultats sont très intéressants (d'après ce que j'ai vu, il semble utiliser des %, mais uniquement pour les largeurs, il ne déclare pas les hauteurs : je lui ai demandé des précisions).

[roger64]

Il s’avère que W2X offre dès à présent une solution complète (texte, tableaux, cadres, images) qui prolonge très efficacement OpenOffice.

W2X et les images:

Ci-joint un petit EPUB de test réalisé exclusivement avec W2X et comprenant quelques images. Il fonctionne bien avec mon PRS-505, aussi avec ADE et Lucidor. Merci de me faire part de vos constatations.

Cet EPUB est 100% W2X. Je n’ai touché ni à la feuille de style CSS, ni aux autres fichiers qui composent l’EPUB.

Traitement des images

W2X offre le choix entre deux techniques pour interpréter les images:
- soit à partir de leur taille relative (au sens OpenOffice du terme, voir mon post d'hier),
- soit à partir de leur taille réelle.

Lors la conception du livre, il est souhaitable de choisir la technique que l’on emploiera car au moment de l’export vers l’EPUB, il n’est pas possible de les mixer. Ce sera l’une ou l’autre.

La première technique peut être utilisée très naturellement (les images sont retaillées à l'écran sur le Writer) pour traiter des images de petite taille et/ou de petites dimensions. Si l’on souhaite utiliser des images plein écran, il est conseillé au moins actuellement, d’employer la seconde. La voici.

La technique «taille réelle».

Elle est extrêmement simple, permet d’obtenir rapidement d’excellents résultats sous forme d’EPUB compacts aux délais d’affichage optimisés.

1. Préparation des images.

Mon PRS-505 a une résolution de 600 par 800 pixels.

Il s’agira de donner aux images plein écran une résolution au mieux égale à celle de ma liseuse et une résolution inférieure pour celles de plus faible dimension.

a- découpe éventuelle sous forme de rectangle 3 x 4
En raison du choix de mes photos, je n'ai pas eu à m'en occuper.

b- mise à l’échelle
On peut utiliser à cet effet GIMP (menu Image/Echelle) ou d’autres programmes équivalents. Voici comment faire avec GIMP: -voir photo jointe-. Il peut être judicieux de laisser de côté quelques pixels et de se contenter d’une largeur de 580 pixels. C’est votre choix.

Cette préparation des images constitue le plus gros de votre travail dans ce domaine. Elle est très rapide.

2. Rédaction du livre et insertion des images

Pour fluidifier l’affichage ultérieur des images plein écran, il est utile de les encadrer par des sauts de page manuels ajoutés dans l’odt et qui sont très bien interprétés par W2X.

3. Export:

Choisir «real size» et «all explicit» pour inclure les sauts de page manuels dans la fenêtre de dialogue de W2X.

C’est vous qui voyez.

[Coolmicro]

Salut Roger,

Excuse-moi, mais je ne vois pas l'intérêt de pallier aux déficiences actuelles de W2X, c'est au développeur à modifier ce qui doit l'être, et je suis persuadé qu'il le fera.

Par ailleurs, il est absolument hors de question, en ce qui me concerne, d'envisager un ebook adapté à telle résolution, et non à telle autre... ou de retailler chaque image (à la limite, la redimensionner, oui, dans certaines limites), et un doc doit pouvoir être utiliser aussi bien pour un PDF que pour un epub.

Dans "W2X et les images.epub", tes images ne sont pas exprimées en %, ni avec la max-width=100%,height=100%, cela ne donne donc rien dès qu'on fait varier la taille de fenêtre dans ADE ou qu'on teste l'image sur un téléphone. Ce que tu appelle des images plein écran, n'en sont pas: selon la fenêtre ADE ou le media utilisé (téléphone par exemple), on se retrouve avec des images largement coupées.

Bref, pour un ebook illustré, il faut absolument retoucher l'epub manuellement pour les images avec W2X, pour le moment (alors qu'avec Atlantis, on peut souvent éviter de le faire).

[roger64]

Bonjour

Merci de tes commentaires ainsi que de tes tests que je ne peux pas réaliser où je suis.

La technique que j’ai décrite plus haut n’est absolument pas remise en cause. J’en conclus simplement qu’il faut la compléter par un tout petit chouia. W2X n’y est pas à 100% mais à 99% et on va lui donner l’ultime petit coup de pouce en attendant le retour d’Henrik.

Mais d’abord, on va trier un peu:

1. Un même document source pour le PDF et pour l’EPUB

C’est natif avec OpenOffice.

Il suffit d'exporter au format PDF. Le même fichier source au format odt made in OpenOffice peut être utilisé sans changement pour produire un PDF ainsi que pour produire un EPUB avec l’extension W2X 1.1.7. Il suffit d’appuyer sur un bouton.

Le voilà ci-joint au format PDF. Les images plein écran sont les mêmes. Les petites images varient parce que j'avais fixé pour elles des résolutions «relatives» (minorées pour les petites images et majorée pour Gang Tux). Ces résolutions relatives sont prises en compte dans le PDF mais pas dans l’EPUB, puisque j’ai explicitement demandé à W2X de les ignorer en prenant l’ «option real size». Tout est paramétrable et je peux fournir à ce sujet des explications plus détaillées.

2. La préparation des images est une corvée fastidieuse .
«ne pas retailler chaque image».

Tu considères la phase de préparation des images comme une contrainte.
Au contraire, je n’arrive pas à concevoir qu’on puisse éditer un livre illustré sans s’occuper des images. Elles peuvent être de provenances, de qualités ou de formats divers qu’il est nécessaire d’harmoniser. Cela ne demande que quelques secondes par image.

Toute image a une taille réelle. Ce n’est pas parce que tu ne te soucie pas de sa taille réelle que ton image en est dépourvue.

Si je donne à mes image plein écran une taille réelle (proche) de 600 x 800, cela correspond à près de 150 dpi. Quant on sait que la résolution d’écran lambda est de 72 dpi, cela signifie que je peux visualiser mon image sans perte apparente de qualité sur un écran normal d’ordinateur. Cela me parait donc suffisant pour un EPUB. On peut certes faire d’autres choix, pour d’autres raisons.

On utilise pour les images un logiciel de traitement d’images, comme on utilise pour le texte un logiciel de traitement de texte. Il n’y a pas que les polices que l’on choisit. Si tu ne veux pas t’occuper de cela, tu chausseras simplement les pointures des autres, et tant pis si elles sont trop grandes ou trop petites. Désolé d’enfoncer une porte ouverte.

3. Le CSS avec l'option % pour les images!!

Ce dernier point concerne les images occupant toute la largeur ou la hauteur de l’écran. Elles sont tronquées par exemple sur un téléphone (il est en effet indispensable de lire des livres illustrés sur nos chers téléphones).

Je reconnais que les smartphones Android (480 x 800 en moyenne) sont un peu justes pour le moment alors que l’iPhone4 avec une résolution de 640 x 960 peut théoriquement lire cet EPUB sans problème de résolution.

Cette «déficience 100%» est commune à beaucoup de logiciels. Si Calibre, fournit un support spécifique pour la page de couverture, il ne le fait pas, je crois, pour les autres images plein écran qui peuvent se trouver dans le corps du texte.

Aujourd’hui avec W2X tu as le choix:
- soit ne pas mettre d’image pleine page dans le corps du texte
- soit modifier manuellement la feuille CSS

4. Comment «réparer» l’EPUB

W2X produit une feuille de style unique très lisible où il est désormais très facile de rajouter cette option 100%. Il suffit d’ailleurs de fixer une seule dimension, hauteur ou largeur en fonction de l’image. Le reste suivra.

J’ai fait l’essai sur mon EPUB test pour les trois grandes images et le manchot. Pour vérifier, j’ai réduit la taille du manchot Tux en réduisant le pourcentage. Cela ne m’a pas pris cinq minutes .

1- Ouvrir l’EPUB avec Sigil (j’ai la version portable Linux 0.2.4)

2- puis pour chaque image concernée (elles sont dans des chapitres différents)
- ouvrir chapterX.xhtml en vue code
- changer A par B (voir photos)

3- enfin sauvegarder

Suivant l’orientation de l’image, il faut passer l’argument width= «100%» ou height=«100%» parce que certaines peuvent avoir des marges latérales ou verticales n'étant pas rigoureusement au dimensions 3 x 4.

Upload

Vous trouverez plus bas:
- le PDF de la première version
- l’EPUB V2 100%
- le code à changer (A et B)

Cela a l’air de fonctionner mais je reste prudent car je ne suis absolument pas un spécialiste du CSS. On trouvera sans doute quelque chose de mieux quand j'aurai repris contact avec le développeur.

Enfin, il me semble qu’il n’y a pas de quoi fouetter un chat....

[Coolmicro]

Salut,

Juste une ou deux précisions. Je n'ai jamais dit que c'était compliqué, j'ai seulement dit qu'il fallait retoucher les fichiers xhtml, ce qui peut être un peu long quand il y a 100 illustrations dans un livre.

Avec Atlantis, il y a moins d'images à retoucher, puisque toutes les illustrations rectangulaire en long sup à 200x300 sont correctement codées (c'est que j'ai demandé à Henrik de faire, notamment). Les autres, par contre, sont exprimées en taille fixe.

Concernant la corvée fastidieuse de préparation des images, je voulais seulement dire qu'il est hors de question pour moi de faire des versions différentes au niveau des illustrations entre le doc qui doit être converti en PDF et le doc qui doit être converti en epub, d'où la nécessité que le convertisseur gère certains choses.

Enfin, après étude intensive de la question, je m'aperçois que les choses sont plus compliquées que le pensais pour les pourcentages :

* Pour les images rectangulaires en long supérieures à 200x300, il faut utiliser max-width="100%" et heigth="100%".

* Pour les images rectangulaires en largeur supérieures à une certaine taille (==> pas encore bien testé laquelle, peut-être supérieur à 250px), il faut mettre seulement width="100%", sans préciser la hauteur, ou alors, si on veut que l'image n'occupe pas toute la largeur, choisir un pourcentage de largeur correspondant à l'effet visuel désiré, par exemple 80%, 70%, etc

* Pour les petites images, c'est plus compliqué. En effet, comme tu l'avais expliqué, les % sont exprimés par rapport à l'écran de visualisation, lequel varie : il n'est donc pas conseillé de mettre une largeur et une hauteur en %, car les résultats peuvent être imprévisibles...
J'aurai tendance à dire que le mieux est de laisser la taille fixe, car, s'agissant d'images petites, elles s'afficheront toujours en entier sur l'écran. Si on veut mettre des %, je pense qu'il vaut mieux ne fixer que la hauteur ou la largeur, selon que l'image est rectangulaire en long ou en large, et le faire manuellement pour juger du résultat, qui est parfois mieux, parfois moins bien selon l'image.

Il faut donc que j'essaye d'expliquer à Henrik (en anglais qui n'est pas mon fort) ce qu'il faut faire pour W2X, car mon premier message n'était pas assez précis :
1. max-width="100%" et heigth="100%" pour les images rectangulaires en long sup à 200x300
2. width="100%" ou width en pourcentage calculé en faisant le rapport largeur image visible dans le doc/largeur feuille (je ne sais pas quelle est la meilleure solution) pour images rectangulaires en large d'une largeur sup à 250px
3. Largeur et hauteur fixes comme maintenant pour les autres images

Nota : pour la cas n°2, c'est à dire pour la calcul du pourcentage en largeur, j'attends l'avis d'un expert qui est en train de faire de nombreux epubs illustrés pour ELG et qui a développé pour ce faire des algorithmes persos de calcul pour les images.

[roger64]

Bonjour

Une sortie parrallèle PDF - EPUB est-elle nécessaire ?

Elle imposera une contrainte dans la conception des images. Il est logique de s’assurer d’abord qu’elle est vraiment nécessaire.

Cela me parait contestable pour les raisons suivantes.

Le PDF et l’EPUB ont des caractéristiques différentes.
Un document PDF est
- produit pour une dimension d’écran fixe :
- est prévu pour pouvoir être zoomé
Un EPUB est
- produit pour une dimension d’écran variable
- contrairement au texte qui peut afficher trois tailles (S,M,L) les images ne sont pas prévues pour être zoomées

Le choix d’une taille d’image commune risque de donner, suivant le poids des images, soit une image de qualité médiocre pour le PDF soit un affichage pas très fluide pour l’EPUB.

Si j’avais à produire un véritable livre illustré, il me semble que j’aurais tendance à utiliser deux jeux d’images.

Si elle est nécessaire, à quelles conditions?

Reprenons depuis le début : avec W2X, nous savons qu’il faut faire un choix entre les images réelles ou les images relatives provenant d’OpenOffice. C’est l’un ou l’autre.

Comme l’on veut mettre des pourcentages sur le fichier xhtml, il me parait biscornu de chercher à faire du pourcentage CSS relatif sur du pourcentage OpenOffice relatif. En effet le premier pourcentage est toujours un chiffre compris entre 0 et 100 alors que le second peut aller bien au-delà de 100 (en cas de magnification).

Avec des images de taille moyenne, c’est des coups à se prendre les pieds dans le tapis et avoir des bugs à n’en plus finir. Je ne recommanderai pas une telle solution.

En conclusion

1. Des images réelles.

Il me semble qu’il vaut bien mieux équiper l’odt d’images avec leurs dimensions réelles (pas relatives). Et cela, quelle que soit l’image, grosse, petite....

2. Un fichier odt de qualité

De plus, si l’on veut un fonctionnement automatique de conversion vers l’EPUB, sans bricolage ultérieur dans le CSS, il faudra que la qualité du fichier odt soit exemplaire: images bien centrées, aux bonnes dimensions. Garbage in, garbage out.

3. une méthode de calcul simple.

A ce moment là, à partir des dimensions réelles de l’image (largeur, hauteur) et de celles de la page du modèle (qui n’est pas forcément la taille de l’écran), il est facile pour W2X de calculer les deux pourcentages. J'ai pu vérifier qu'il est remarquablement précis.

C’est ces deux pourcentages là qu’il devrait inscrire sur le fichier xhtml en lieu et place de ses dimensions physiques.

Pas de souci pour le PDF dans ce cas-là, il sera également parfait et identique à l’EPUB pour la visualisation des images.

[roger64]

Bonjour

Une sortie parrallèle PDF - EPUB est-elle nécessaire ?

Elle imposera une contrainte dans la conception des images. Il est logique de s’assurer d’abord qu’elle est nécessaire.

Cela me parait contestable pour les raisons suivantes.

Le PDF et l’EPUB ont des caractéristiques différentes.
Un document PDF est
- produit pour une dimension d’écran fixe :
- est prévu pour pouvoir être zoomé
Un EPUB est
- produit pour une dimension d’écran variable
- contrairement au texte qui peut afficher trois tailles (S,M,L) les images ne sont pas prévues pour être zoomées

Le choix d’une taille d’image commune risque de donner, suivant le poids des images, soit une image de qualité médiocre pour le PDF soit un affichage pas très fluide pour l’EPUB.

Si j’avais à produire un véritable livre illustré, il me semble que j’aurais tendance à utiliser deux jeux d’images.

Si elle est nécessaire, à quelles conditions?

Reprenons depuis le début : avec W2X, nous savons qu’il faut faire un choix entre les images réelles ou les images relatives provenant d’OpenOffice. C’est l’un ou l’autre.

Comme l’on veut mettre des pourcentages sur le fichier xhtml, il me parait biscornu de chercher à faire du pourcentage CSS relatif sur du pourcentage OpenOffice relatif. En effet le premier pourcentage est toujours un chiffre compris entre 0 et 100 alors que le second peut aller bien au-delà de 100 (en cas de magnification).

Avec des images de taille moyenne, c’est des coups à se prendre les pieds dans le tapis et avoir des bugs à n’en plus finir. Je ne recommanderai pas une telle solution. Il vaut mieux ne pas se faire de nœuds au cerveau.

En conclusion

1. Des images réelles.

Il me semble qu’il vaut bien mieux équiper l’odt d’images avec leurs dimensions réelles (pas relatives). Et cela, quelle que soit l’image, grosse, petite....

2. Un fichier odt de qualité

De plus, si l’on veut un fonctionnement automatique de conversion vers l’EPUB, sans bricolage ultérieur dans le CSS, il faudra que la qualité du fichier odt soit exemplaire: images bien centrées, aux bonnes dimensions. Garbage in, garbage out.

3. Une méthode de calcul simple.

A ce moment là, à partir des dimensions réelles de l’image (largeur, hauteur) et de celles de la page du modèle (qui n’est pas forcément la taille de l’écran), il est facile pour W2X de calculer les deux pourcentages.

C’est ces deux pourcentages là qu’il devrait inscrire sur le fichier xhtml en lieu et place de ses dimensions physiques.

Pas de souci pour le PDF dans ce cas-là, il sera également parfait et identique à l’EPUB pour la visualisation des images.

[Coolmicro]

Concernant ton avis sur les 2 jeux d'images pour epub et PDF, c'est possible pour un artisan comme toi, mais certainement pas pour ceux qui ont une production plus importante, qui peuvent être amenés à mettre à jour leur doc avec des corrections, etc: cela devient une perte de temps. Bref, 2 conceptions... qui dépendent des objectifs et des méthodes de travail.

Par ailleurs, le débat sur la question des tailles exprimées en pourcentages, ne peut concernait que le cas où images réelles est décoché dans W2X (quand c'est réel, cela ne peut pas être en pourcentage, évidemment).

Donc, ceux qui veulent mettre les images réelles,qui seront donc par définition en taille fixe et non adaptable à l'écran, le font, et peuvent utiliser W2X tel que. Personnellement, ce type d'ebook ne m'intéresse pas, mais chacun voit midi à sa porte.

Pour ceux qui veulent utiliser les %, pour adapter les images aux différents écrans, ta méthode de calcul est fausse, tu n'as pas fait suffisamment de tests. J'ai essayé d'expliquer en détail dans le précédent post pourquoi le raisonnement que je faisais auparavant, qui était le même que toi, était faux, ce que j'ai pu vérifier par l'expérimentation sur différents écrans et différentes résolutions. C'est simple : W2X ne sachant pas quelle sera la résolution de l'écran du lecteur de l'epub, résolution qui peut prendre toute valeur selon la taille de la fenêtre de ADE par exemple sur un PC, W2X ne peut pas calculer un pourcentage pour la largeur et la hauteur en même temps (bref, la diagonale résultat de la taille de la page dans l'ODT, souvent du A4, ne doit pas intervenir). Tout au plus, W2X peut supposer que:
1. La taille de l'écran de lecture sera plutôt rectangulaire dans le sens de la hauteur (disons que cela correspond à 95% des cas)
2. La résolution horizontale sera au minimum de 240 (résolution des PDA ou de certains téléphones bas de gamme), ce qui explique la barre de 250px que je proposais pour la largeur dans mon post précédent.

Nota : quand je vois les difficultés que j'ai pour expliquer ce point de vue en français (point de vue résultat de l'expérience, d'heures de test sur téléphone, tablettes et liseuses, PC avec ADE, il ne s'agit pas d'une opinion), je ne sais vraiment pas comment je vais faire pour être clair en anglais...