Register Guidelines E-Books Search Today's Posts Mark Forums Read

Go Back   MobileRead Forums > Non-English Discussions > Forum Français > E-Books

Notices

Reply
 
Thread Tools Search this Thread
Old 02-28-2011, 05:15 PM   #61
Coolmicro
Groupie
Coolmicro will become famous soon enoughCoolmicro will become famous soon enoughCoolmicro will become famous soon enoughCoolmicro will become famous soon enoughCoolmicro will become famous soon enoughCoolmicro will become famous soon enough
 
Coolmicro's Avatar
 
Posts: 195
Karma: 542
Join Date: Jul 2008
Device: Tablette android SmartQ T7 - Nook Touch - Pocketbook 602
Je me réponds à moi-même, pour me contredire et me préciser...

Suite à une discussion avec le spécialiste des epubs illustrés dont j'avais parlé, et à de nouveaux tests, je pense finalement qu'il faut uniquement utilisé les %, mais d'une certaine manière. En fait, il distingue 3 cas :
1 le cas général, qu'il appelle vignettes
2 le cas des images plein écran
3 les cas des images flottantes

1. Le cas général, c'est à dire tout ce qui n'est pas 2 ou 3, est défini uniquement par la largeur en %; on a donc un truc du genre:

Quote:
img.Img1 {width:x%;margin:0}
<img alt="toto.jpg" class="Img1" src="toto.jpg"/>
avec x = 100 * largeur image / (largeur page - marge gauche - marge droite)

Exemple pour une image de 10 cm de large dans une page A4 avec marges de 2,5 cm : x = 100*10/(21-2.5-2.5) = 62.50%
Faites le test : que l'image soit petite ou grande, cela fonctionne toujours bien (sauf évidemment le cas 2 ci-dessus)

2. La discussion est toujours en cours pour savoir quels sont les critères qui doivent déclencher automatiquement le plein écran, c'est à dire :

Quote:
img.ImgModeHeight {max-width:100%;height:100%;margin:0}
<img alt="toto.jpg" class="ImgModeHeight" src="toto.jpg"/>
Mon correspondant utilise pour le moment des conditions assez restrictives. Je propose pour ma part deux conditions cumulatives un peu moins restrictives; soit :
H : hauteur de l'image en cm
W1 : largeur de l'image en cm
W2 : largeur de la page en cm
H >= 1,33 * W1 (ce qui signifie rectangulaire en hauteur dans une proportion de 1,33)
et
W1>=33%*W2
Exemple: dans une page A4, une image large de 7cm et haute de 9,5cm est convertie automatiquement en plein écran.

3.
Quote:
img.Img1 {width:x%;margin:0;float:left}
<img alt="toto.jpg" class="Img1" src="toto.jpg"/>
avec x calculé de la même manière qu'au 1.

Lien vers l'ebook de Pierre Louÿs, "Bilitis", pour lequel j'ai utilisé les règles 1 et 2 ci-dessus : http://www.ebooksgratuits.com/epub/l...s_bilitis.epub

Last edited by Coolmicro; 02-28-2011 at 10:05 PM.
Coolmicro is offline   Reply With Quote
Old 02-28-2011, 10:52 PM   #62
roger64
Wizard
roger64 ought to be getting tired of karma fortunes by now.roger64 ought to be getting tired of karma fortunes by now.roger64 ought to be getting tired of karma fortunes by now.roger64 ought to be getting tired of karma fortunes by now.roger64 ought to be getting tired of karma fortunes by now.roger64 ought to be getting tired of karma fortunes by now.roger64 ought to be getting tired of karma fortunes by now.roger64 ought to be getting tired of karma fortunes by now.roger64 ought to be getting tired of karma fortunes by now.roger64 ought to be getting tired of karma fortunes by now.roger64 ought to be getting tired of karma fortunes by now.
 
Posts: 1,456
Karma: 846401
Join Date: Jan 2009
Device: KoboGlo
OK A toi de voir. Nos posts se sont croisés, je vais essayer d'étudier ça.

En ce qui me concerne, après notre discussion, je commence à avoir les idées plus nettes.
Je vois deux façons d'utiliser W2X, suivant ce que l'on veut produire :

- Un livre standard,
avec une page de couverture et des illustrations petites ou moyennes (voire en plein écran ?).

On utilisera l'export avec les images relatives.
C'est la solution confortable habituelle sans traitement d'images.
Les unités exprimées sur le CSS restent physiques (centimètres ou pixels). (% si possible ?)
Besoin
- Support spécifique pour la page de couverture (on en a déjà parlé)
- Déterminer la taille maximum de l'image moyenne supportée (largeur-hauteur).
- Les questions de CSS dont tu as parlé, les valeurs CSS en % etc.

- Un véritable livre illustré,
avec beaucoup d'illustrations dont des images pleine page séparées par des sauts de page.

On utilisera l'export avec les images réelles.
Ce type de livre suppose le recours préalable à un traitement d'image.
W2X exprime la taille de l'image en pourcentage sur le CSS (largeur, hauteur).
Besoin
Mettre au point la conversion en pourcentage sur le CSS.

Nota: Dans les deux cas, une intervention manuelle sur l'EPUB avec Sigil restera ponctuellement possible.

Proposition

Je crains de ne pas être d'une grande aide dans ces questions de CSS dont je ne puis juger l'opportunité par manque de compétence technique.

Compte tenu de tes remarques et de tes intérêts propres, en ce qui concerne notre correspondance vers le développeur, il me semble possible de se répartir la tâche:

- je te propose de prendre à ton compte la partie "export des images relatives"(sans oublier les remarques que tu aurais à faire par ailleurs).
- je peux me charger de la partie "export des images réelles", plus quelques petits point mineurs que j'ai relevés.

On verra bien avec lui ce qu'il est possible de faire, et selon quel échéancier.
Jeudi ou vendredi, je posterai mon texte anglais sur ce forum avant de le lui envoyer. Ensuite je serai absent une huitaine de jours à compter de dimanche.

Nota: déclencher l'affichage plein écran = to trigger a full screen display.

Last edited by roger64; 03-01-2011 at 03:59 AM. Reason: Proposition
roger64 is offline   Reply With Quote
 
Advertisement
Old 03-01-2011, 09:43 AM   #63
Coolmicro
Groupie
Coolmicro will become famous soon enoughCoolmicro will become famous soon enoughCoolmicro will become famous soon enoughCoolmicro will become famous soon enoughCoolmicro will become famous soon enoughCoolmicro will become famous soon enough
 
Coolmicro's Avatar
 
Posts: 195
Karma: 542
Join Date: Jul 2008
Device: Tablette android SmartQ T7 - Nook Touch - Pocketbook 602
Salut Roger,

J'ai déjà écrit à Henrik, ainsi qu'aux développeurs d'Atlantis pour leur faire les propositions développées ci-dessus. Dans le cas de W2X, j'ai précisé que cela concernait le cas où "Use original image size" n'était pas coché.

Cela dit, je ne suis pas du tout d'accord avec la distinction que tu fais ci-dessus. Tout au contraire, je pense que l'utilisation des images réelles est une erreur, et qu'il faut toujours utiliser des images relatives en % pour avoir un bon résultat, et donc pour un véritable livre illustré, puisque c'est justement dans ce cas qu'il est important que les images s'affichent correctement sur tous les médias, ce qui est impossible avec une image fixe. Pour t'en convaincre, il suffit d'étudier sur plusieurs médias (tablette, téléphone, liseuses, etc) les mises à jour de livres illustrés en epub qui ont été faites sur notre site ces derniers temps (Homère, Louÿs, Verne, Conan Doyle, Dumas, César, Daudet, Malot, Maupassant).

Par ailleurs, dans tous les cas, si on utilise un traitement préalable de l'image au niveau du traitement de texte, quel qu'il soit (à condition que ce dernier soit réfléchi en fonction de divers médias et non d'un seul type de liseuse), le résultat sera évidemment meilleur.

Il n'y a pas de taille maximum de l'image, il suffit que l'image soit inférieure à la taille de la page diminuée des marges, ce qui est évident dans OO...
Les images pleine page sont traitées automatiquement et de manière adéquate, sans qu'il soit nécessaire d'insérer un saut de page qui ne peut que causer des problèmes supplémentaires, selon les écrans.
L'utilisation du pourcentage en largeur - la cas général - est le meilleur moyen pour obtenir le truc le plus proche de ce que tu appelles "images réelles" : as-tu essayé, fait un test ???

Pour moi, la distinction entre un livre illustré "standard" et un livre "plus soigné" tiendra uniquement à une édition manuelle éventuelle pour modifier, affiner les pourcentages utilisés (cela lorsqu'il existera une méthode automatique pour avoir des images relatives exprimées en %)

Enfin, je te le répète, les dimensions ne peuvent pas être exprimées en % pour une image réelle. On ne peut jamais exprimer en pourcentage en même temps la largeur et la hauteur, puisque le pourcentage est relatif à l'écran du lecteur utilisé, aux caractéristiques, par définition, inconnues, et non à l'image elle même. Si on veut utiliser des pourcentages, il faut déterminer uniquement la largeur ou la hauteur (la largeur étant beaucoup plus naturelle, évidemment). La notion de pourcentage est antinomique avec la notion d'image réelle, une image réelle doit obligatoirement être exprimée en unités fixes (cm, px, etc). Tu fais une faute de raisonnement.

PS : Je n'ai pas "d'intérêts propres" autres que ceux de tout le monde : pouvoir faire facilement un ebook illustré lisible sur la majorité des médias.

Nota, le message envoyé à Henrik :
Quote:
Hello Henrik,

After hours of testing and discussions with a specialist of pictures in ebooks epub, I can now get yourself some specific proposals and achievable with OpenOffice. If "Use original image size" is not chosen in the export parameters, it is best to work with percentages.

There are three cases:

1. The general case ((anything that is not the case 2 or 3 ...) :

img.Img1 {width:x%;margin:0}
<img alt="toto.jpg" class="Img1" src="toto.jpg"/>

with x = 100 * PictureWidth / (PageWidth - LeftMargin - RightMargin)

(especially not to the height)
Example : A4 with margins 2,5 cm and width picture 10 cm : x = 100*10/(21-2.5-2.5) = 62.50%

2. Pictures automatically in full screen :

img.ImgModeHeight {max-width:100%;height:100%;margin:0}
<img alt="toto.jpg" class="ImgModeHeight" src="toto.jpg"/>

These are that I am proposing that the images are automatically in full screen :
H : picture height in cm
W1 : picture width in cm
W2 : lmage width in cm
H >= 1,33 * W1
and
W1>=33%*W2
Example: page A4, picture width 7cm and height 9,5cm ==> OK for automatically full screen

3. Float (left and right)

img.Img1 {width:x%;margin:0;float:left}
<img alt="toto.jpg" class="Img1" src="toto.jpg"/>

X ==> idem 1.

Last edited by Coolmicro; 03-01-2011 at 10:10 AM.
Coolmicro is offline   Reply With Quote
Old 03-01-2011, 11:32 AM   #64
roger64
Wizard
roger64 ought to be getting tired of karma fortunes by now.roger64 ought to be getting tired of karma fortunes by now.roger64 ought to be getting tired of karma fortunes by now.roger64 ought to be getting tired of karma fortunes by now.roger64 ought to be getting tired of karma fortunes by now.roger64 ought to be getting tired of karma fortunes by now.roger64 ought to be getting tired of karma fortunes by now.roger64 ought to be getting tired of karma fortunes by now.roger64 ought to be getting tired of karma fortunes by now.roger64 ought to be getting tired of karma fortunes by now.roger64 ought to be getting tired of karma fortunes by now.
 
Posts: 1,456
Karma: 846401
Join Date: Jan 2009
Device: KoboGlo
Bonjour

Merci de ton courrier et de tes explications.
Voici ce que je cherche à obtenir;

1. A partir des dimensions réelles de l'image et de son rapport avec la page du document source on peut calculer un pourcentage de hauteur et de largeur.

2. Il faut faire passer cette information dans le code CSS en faisant abstraction des données physiques.

3. Lorsque ce code est interprété dans une machine, le CSS adapte la taille de l'image visualisée en fonction de la taille de l'écran en appliquant ce pourcentage.

4. Je ne sais pas écrire ce code mais j'avais pensé y arriver en rajoutant l'argument "width=100%" en pensant qu'il serait prioritaire sur les données physiques mais ce n'est malheureusement pas si simple que ça.

Ceci dit,

Il est possible qu'il y ait un malentendu du au fait que l'on parle aussi dans OpenOffice de tailles relatives alors que ce n'est pas la même chose. N'oublions pas que l'on fait un export à partir d'OpenOffice.

Le fait que l'image soit magnifiée ou réduite dans OpenOffice, ce que l'on appelle aussi la taille relative indique comment l'auteur souhaite que son image soit visualisée par rapport à sa taille réelle. Cela rajoute donc un paramètre supplémentaire à la taille réelle. Il me semble logique de penser que cela rend le calcul du pourcentage plus délicat et je le pense toujours.

Ce n'est pas bien grave, les forums de discussion sont faits pour échanger des idées.

Merci de ta contribution très concrète au projet. Je vais écrire également au développeur pour demander une mise en application du pourcentage dans le CSS pour les images mais je me garderai bien de lui écrire du code...

Je lui avais déjà formulé ce souhait. On verra bien la réponse.

à +

PS: tout le monde a des intérêts propres et il n'y avait pas de sous-entendu de ma part. J'en retiens que tu me lis attentivement.

PS2. (appel au peuple) Jusqu'à présent, je suis le seul à avoir proposé des fichiers de test avec W2X, je me sens un peu seul... (/fin mode appel)

Last edited by roger64; 03-01-2011 at 11:41 AM.
roger64 is offline   Reply With Quote
Old 03-01-2011, 11:49 AM   #65
Coolmicro
Groupie
Coolmicro will become famous soon enoughCoolmicro will become famous soon enoughCoolmicro will become famous soon enoughCoolmicro will become famous soon enoughCoolmicro will become famous soon enoughCoolmicro will become famous soon enough
 
Coolmicro's Avatar
 
Posts: 195
Karma: 542
Join Date: Jul 2008
Device: Tablette android SmartQ T7 - Nook Touch - Pocketbook 602
Quote:
Originally Posted by roger64 View Post
1. A partir des dimensions réelles de l'image et de son rapport avec la page du document source on peut calculer un pourcentage de hauteur et de largeur.
2. Il faut faire passer cette information dans le code CSS en faisant abstraction des données physiques.
==> Impossible, c'est un non sens! puisque la diagonale de ta page OO sera toujours différente de la diagonale de l'écran de visualisation, laquelle est en plus inconnue, tu obtiendrais du n"importe quoi et ce serai une catastrophe pour W2X si Henrik partait dans cette voie. Encore une fois, on ne peut utiliser que le pourcentage en largeur (ou en hauteur, mais c'est moins bien), plus, évidemment, la diagonale intrinsèque de l'image, mais pour cet élément, il n'y a rien à faire de spécial.
Ce que je t'explique est du calcul très basique.

Quote:
Originally Posted by roger64 View Post
3. Lorsque ce code est interprété dans une machine, le CSS adapte la taille de l'image visualisée en fonction de la taille de l'écran en appliquant ce pourcentage.
On ne peut pas appliquer le pourcentage relatif à une diagonale, à une diagonale différente. On ne peut le faire que pour une largeur ou une longueur.


Quote:
Originally Posted by roger64 View Post
Le fait que l'image soit magnifiée ou réduite dans OpenOffice, ce que l'on appelle aussi la taille relative indique comment l'auteur souhaite que son image soit visualisée par rapport à sa taille réelle. Cela rajoute donc un paramètre supplémentaire à la taille réelle. Il me semble logique de penser que cela rend le calcul du pourcentage plus délicat et je le pense toujours.
Lorsque la case 'images réelles" est décochée dans l'export, c'est l'apparence de l'image dans OO qui est retenue pour l'export, c'est à dire l'image éventuellement rognée, agrandie ou rapetissée dans OO, voire déformée si on ne respecte pas volontairement l'échelle de l'image. Pour le moment, cette image éventuellement rognée, etc est exprimée en cm, et je pense qu'elle devrait être exprimée en pourcentage, en respectant les 3 règles ci-dessus énoncées.
Si on coche, c'est l'image d'origine, telle qu'elle a été insérée dans le doc OO, qui est utilisée, les traitements effectués dans OO ne sont plus pris en compte. L'image peut très bien être d'une dimension supérieure au A4 en réel, puis avoir été diminuée dans OO. C'est pourquoi je disais précédemment qu'on ne pouvait pas, par définition, appliquer un pourcentage quand la case est cochée...

Last edited by Coolmicro; 03-01-2011 at 11:55 AM.
Coolmicro is offline   Reply With Quote
Old 03-01-2011, 08:15 PM   #66
roger64
Wizard
roger64 ought to be getting tired of karma fortunes by now.roger64 ought to be getting tired of karma fortunes by now.roger64 ought to be getting tired of karma fortunes by now.roger64 ought to be getting tired of karma fortunes by now.roger64 ought to be getting tired of karma fortunes by now.roger64 ought to be getting tired of karma fortunes by now.roger64 ought to be getting tired of karma fortunes by now.roger64 ought to be getting tired of karma fortunes by now.roger64 ought to be getting tired of karma fortunes by now.roger64 ought to be getting tired of karma fortunes by now.roger64 ought to be getting tired of karma fortunes by now.
 
Posts: 1,456
Karma: 846401
Join Date: Jan 2009
Device: KoboGlo
Bonjour

Edition

Le petit dernier, intitulé Fleurs d'adultère et réalisé évidemment 100% avec W2X.
http://www.mobileread.com/forums/sho...08#post1423208

Typographie

La version 4.3 de l'extension checkbook a été publiée. Son auteur m'a indiqué avoir pris en compte une -petite- sélection d'éléments de la macro Word d'ELG (merci à eux). Il a par ailleurs ajouté d'autres perfectionnements de son cru. Elle fonctionne bien et je l'ai utilisée pour le livre ci-dessus. Vous la trouverez à son adresse originale.

W2X et les images

Je vois que tu puisé aux bonnes sources. Merci sincèrement pour ces toutes dernières informations que, honnêtement, je ne connaissais pas. Si deux dimensions ça ne va pas, si un pourcentage de diagonale, ça ne va pas non plus pour d'autres raisons, eh bien, il va falloir se montrer inventifs et trouver autre chose!! -voir plus bas-. ;-)

W2X n'a jamais produit d'images "reflowables" ou relatives au sens absolu (%) du terme, qu'elles soient petites, moyennes ou plein écran.
Il nous offre le choix d'exporter
- soit des images de taille réelle
- soit des images de taille relative c'est à dire minorées ou majorées au seul sens OpenOffice du terme
et rien d'autre, d'où l'importance de s'occuper, entre autre, de la définition des images que j'avais soulignée.

W2X avec les images plein écran "reflowable"

Mais à bien y regarder, parce que je suis comme Saint Thomas, on peut lui donner très facilement cette capacité. J'avais commis précédemment une manip fautive parce que je ne suis pas un Dieu du CSS. Voici la V3 :
- les trois images plein écran sont bien "reflowable", il me semble
- le PDF et l'EPUB sont identiques (mais la page du PDF est fixe)
- il m'a suffi, pour chaque image plein écran de remplacer un tout petit bout de code avec Sigill (voir photos Avant et Après ici bas)
http://www.w3schools.com/css/pr_dim_max-width.asp

Ce n'est que du JPG. Ainsi, ces images sont "reflowables" mais dans des proportions modérées et non indéfinies comme ce serait le cas s'il s'agissait de SVG. Il serait intéressant de connaître la fourchette optimale à utiliser pour les tailles d'image destinées à être affichées en plein écran.

Enfin, qu'en penses-tu ? Tu verras qu'à force d'avoir tort et d'émettre des "non-sens", je finirai par avoir raison.

Seuil de déclenchement

En ce qui concerne les images de taille relative avec W2X, j'ai observé, à partir d'une certaine taille d'image disons moyenne, qu'il existe un seuil déclenchant une sorte d'affichage par défaut sur le tiers de l'écran environ et qui n'a rien à voir avec la taille souhaitée. Je n'ai pas encore déterminé avec précision la valeur de ce seuil et ne connais pas non plus son origine : W2X, ADE, Sony ?

L'existence de ce seuil pourrait être utilisée pour déclencher l'affichage d'une image en plein écran (avec les options % que j'ai choisies plus haut).

Ce phénomène que je n'avais pas compris m'avait incité à utiliser des images de taille réelle, pour lesquelles il ne se produit pas.

Utilité des sauts de page manuels

Si tu es finalement d'accord avec moi sur l'opportunité d'un traitement d'images préalable (en cas de véritable document illustré), tu contestes l'opportunité de sauts de page manuels pour encadrer les images pleine page, ce qui me surprend.

Il me semble que W2X, peut-être au contraire d'autres logiciels, interprète ces sauts de page très correctement comme un nouveau "chapitre" et donc, qu'il n'y a aucune raison pour que ça accroche. Au contraire, plus l'EPUB est divisé, plus il est fluide, non? Il me semble qu'il vaut mieux appeler les images une par une que par paquets. Si cela pose un problème à une liseuse, c'est la liseuse qui a un problème me semble t-il...parce que qu'il s'agit bien d'une fonctionnalité élémentaire. Même ma vieille PRS-505 ne tousse pas, au contraire, je ne vois plus tourner la boule d'attente.

Enfin, ce n'est que ma logique...

PS: Ne t'inquiètes pas pour Henrik. Il est suffisamment qualifié pour ne pas s'engager dans une voie technique absurde ou sans issue. Ce qu'il a réalisé jusqu'à présent le prouve, me semble t-il.
Attached Thumbnails
Click image for larger version

Name:	avant.png
Views:	121
Size:	61.6 KB
ID:	67651   Click image for larger version

Name:	après.png
Views:	115
Size:	62.1 KB
ID:	67652  
Attached Files
File Type: epub W2X et les images V3.epub (436.7 KB, 97 views)
File Type: pdf W2X et les images V3.pdf (352.7 KB, 133 views)

Last edited by roger64; 03-02-2011 at 09:44 AM. Reason: reflowable: oui
roger64 is offline   Reply With Quote
Old 03-02-2011, 09:57 AM   #67
Coolmicro
Groupie
Coolmicro will become famous soon enoughCoolmicro will become famous soon enoughCoolmicro will become famous soon enoughCoolmicro will become famous soon enoughCoolmicro will become famous soon enoughCoolmicro will become famous soon enough
 
Coolmicro's Avatar
 
Posts: 195
Karma: 542
Join Date: Jul 2008
Device: Tablette android SmartQ T7 - Nook Touch - Pocketbook 602
J'ai étudié ta version 3.
Pour les 3 grands images, elles sont effectivement en plein écran redimensionnables : j'ai regardé le code de l'epub, j'ai vu qu'il y a max-width 100% height 100%, bref que tu as appliqué manuellement ce que je recommande : on ne peut donc qu'être d'accord.
Pour les autres images, elles ne se redimensionnent pas. Tant qu'elles sont petites comme c'est le cas dans ton test, pas de problème. Si elles étaient plus grandes, alors, il serait préférable de les mettre en pourcentage de largeur, comme je le propose, ce qui est également très rapide.
Bref, je ne vois rien de nouveau si ce n'est la confirmation de ce que je disais précédemment.
Par ailleurs, méfiance avec Sigil, tu as vu qu'il cause des problèmes, comme la disparition des exposants, bref qu'il agit sur le code, ce qui n'est pas conseillé pour un test. Maintenant, j'édite manuellement mes fichiers pour les tests. Si tu ne connais pas le code, tu peux utiliser un logiciel comme Kompozer pour éditer les fichiers xhtml.

Pas compris tes seuils de déclenchement, et honnêtement, cela m'est égal, j'évite de toute façon ce problème en mettant tout en pourcentage selon les règles précédemment exposées.

Pour les sauts de page, je voulais seulement dire que cette fonctionnalité doit être gérée automatiquement par W2X, comme le fait d'ailleurs Atlantis, et non dans le document. La raison en est simple : je peux très bien avoir une image, mettons de 10x15, qui doit apparaître en plein écran dans l'epub, mais pas dans le doc, ni dans le PDF généré.
Coolmicro is offline   Reply With Quote
Old 03-02-2011, 11:57 PM   #68
roger64
Wizard
roger64 ought to be getting tired of karma fortunes by now.roger64 ought to be getting tired of karma fortunes by now.roger64 ought to be getting tired of karma fortunes by now.roger64 ought to be getting tired of karma fortunes by now.roger64 ought to be getting tired of karma fortunes by now.roger64 ought to be getting tired of karma fortunes by now.roger64 ought to be getting tired of karma fortunes by now.roger64 ought to be getting tired of karma fortunes by now.roger64 ought to be getting tired of karma fortunes by now.roger64 ought to be getting tired of karma fortunes by now.roger64 ought to be getting tired of karma fortunes by now.
 
Posts: 1,456
Karma: 846401
Join Date: Jan 2009
Device: KoboGlo
Bonjour

@Coolmicro

Sauts de page manuels.

Je te rassure pleinement: avec W2X tu as le choix:
- option "all explicit" cochée et les sauts de page sont traduits en chapitres et il n'y a aucun risque pour l'affichage.
- option non cochée et ils sont transcrits dans le texte (comme pour un certain logiciel selon ce que tu me dis)

Tu m'avais pourtant indiqué (mais tu as effacé ce commentaire...) que l'usage de sauts de page manuels dans le texte pouvait être mal interprété par certaines liseuses...

N'insistons pas. Cela te va comme ça?

Images plein écran reflowables

Bien, nous y sommes donc enfin arrivés grâce à ton aide!!

Avec W2X tu peux donc mettre partout en procédant de la même façon des images plein écran (ou pleine largeur) reflowables, et pas seulement sur la page de couverture comme pour certains logiciels.

Dès à présent, l'intervention sur le code de l'ensemble du livre avec Sigil est minimale et très facile (voir photos d'hier). Ce n'est sans doute pas aussi simple pour certains logiciels dont le corps du texte ne peut être visualisé avec Sigil.

Je n'ai aucun besoin de Kompozer pour cette opération minimale.

Réalisation d'un guide

Je constate que ton attitude a changé de façon paradoxale: au départ très favorables, tes commentaires sur W2X sont devenus systématiquement acides, accompagnés d'obscures mises en garde alors que les progrès de W2X sont non seulement de plus en plus évidents mais encore répondent à nos demandes précédentes.
- précision du support du texte (exposants, tableaux, cadres...)
- feuille de style unique
- éditeur de méta-données
- sauts de page manuels en tant que chapitres
- support de l'insertion d'images dans le texte
- images relatives reflowables (avec l'intervention a minima sur Sigil)

Il me semble que sur plusieurs de ces points, W2X l'emporte largement dès à présent, dans sa version alpha, sur certains autres logiciels comparables.

C'est pourquoi, contrairement à ce que je t'avais dit par MP, je viens de décider de publier vers la mi-avril un guide centré sur OpenOffice + W2X, que j'intitulerai "L'EPUB en pantoufles". Mais peut-être le rédigerai-je en anglais pour qu'il soit plus lu.

Quoi qu'il en soit, j'y ferai la part qui lui revient à tes contributions et tu seras le bienvenu (ainsi que les lecteurs de ce forum bien sûr) si tu souhaites t'y associer .

Last edited by roger64; 03-03-2011 at 01:37 AM.
roger64 is offline   Reply With Quote
Old 03-03-2011, 09:28 AM   #69
Coolmicro
Groupie
Coolmicro will become famous soon enoughCoolmicro will become famous soon enoughCoolmicro will become famous soon enoughCoolmicro will become famous soon enoughCoolmicro will become famous soon enoughCoolmicro will become famous soon enough
 
Coolmicro's Avatar
 
Posts: 195
Karma: 542
Join Date: Jul 2008
Device: Tablette android SmartQ T7 - Nook Touch - Pocketbook 602
Sauts de page manuels :
Je connais l''option, je ne parle pas de ça. Je dis seulement qu'à partir du moment où il y a une image pleine page, W2X devra faire le nécessaire au niveau de l'epub sans qu'il soit nécessaire d'expliciter le saut de page dans le doc (Atlantis le fait déjà).

Pour les images, W2X est pour le moment en retard sur un logiciel comme Atlantis, puisque ce dernier génère déjà automatiquement les images pleine page de la manière adéquate. Ce n'est que pour les petites images qu'on doit encore mettre la largeur en pourcentage au lieu des largeur et hauteur fixes. Peut-être - j'espère - que W2X sera un jour en avance, mais ce n'est pas encore le cas.

Le fait que l'intervention soit minimale ne change rien au fait que lorsque tu enregistres ton epub modifié dans Sigil, il change du code de manière incontrôlée et sur des points non modifiés comme par exemple pour les exposants (Henrik te l'a même expliqué). Donc, pour le moment, je continuerai à éviter l'édition d'epubs dans Sigil. Amuse-toi à passer tes epubs dans epubcheck avant Sigil, et après Sigil, tu verras que tu auras parfois des surprises.

Il n'y a pas à être acide ou à supporter un logiciel, il suffit d'être lucide, sans parti pris, objectif, et de lister de manière précise les avantages et défauts de chacun, et non d'un seul.
Pour le moment Atlantis est encore très supérieur à W2X sauf dans 2 cas :
1. Lorsqu'il y a des tableaux
2. Lorsqu'on veut éditer l'epub avec Sigil, qui "casse" les epubs issus d'Atlantis pour des raisons techniques que j'ai la flemme d'exposer
Par contre, j'ai peu d'espoirs sur une nouvelle évolution d'Atlantis malgré mes demandes (j'espère mon tromper), et j'ai beaucoup d'espoir pour W2X. Donc, je pense que W2X deviendra (futur, pas présent) la meilleure solution (mais, là aussi, je peux me tromper... tout dépend de ce que pourra/voudra faire Henrik)

Mes commentaires que tu estimes acides (à tort pour moi), visent en général plus ce que tu dis que W2X lui-même, car tu as tendance à affirmer des trucs que j'estime insuffisamment testés et vérifiés : dans une conversation privée, cela n'a aucune importance; mais sur un forum, en plus assez lu, c'est plus embêtant.

A part ça, tu fais tous les guides que tu veux, plus il y en a, mieux c'est. Par ailleurs, je t'avais dit que j'allais développer dans mon guide la question de la conversion des doc avec W2X, lorsque j'estimerai W2X au point, mais je n'ai jamais eu l'intention de développer le travail sur OpenOffice lui-même.

Last edited by Coolmicro; 03-03-2011 at 09:31 AM.
Coolmicro is offline   Reply With Quote
Old 03-03-2011, 04:58 PM   #70
roger64
Wizard
roger64 ought to be getting tired of karma fortunes by now.roger64 ought to be getting tired of karma fortunes by now.roger64 ought to be getting tired of karma fortunes by now.roger64 ought to be getting tired of karma fortunes by now.roger64 ought to be getting tired of karma fortunes by now.roger64 ought to be getting tired of karma fortunes by now.roger64 ought to be getting tired of karma fortunes by now.roger64 ought to be getting tired of karma fortunes by now.roger64 ought to be getting tired of karma fortunes by now.roger64 ought to be getting tired of karma fortunes by now.roger64 ought to be getting tired of karma fortunes by now.
 
Posts: 1,456
Karma: 846401
Join Date: Jan 2009
Device: KoboGlo
@Coolmicro

J'ai ouvert ce fil pour échanger des informations sur une solution (Fine Reader, OpenOffice, Writer2Epub) que je pratiquais.

Depuis mon premier post, j'ai le sentiment d'avoir sensiblement progressé et partagé ce progrès sur deux points :
- Typographie: "découverte", perfectionnement et mise en œuvre d'extensions pour OpenOffice.
- Conversion EPUB: "découverte", perfectionnement et expérimentation de W2X en remplacement de Writer2Epub.

Je n'ai jamais cherché à faire de ce fil un comparatif avec Atlantis dont j'évitais soigneusement de prononcer le nom. Mais, tu ne peux t'empêcher de glisser des commentaires à son sujet. Comme toujours dans ce que tu dis, il y a à boire et à manger, et il faut trier, et beaucoup trier.

Tu cites mes "erreurs". Je ne suis évidemment pas infaillible et les reconnais volontiers.
C'est ce qui nous différencie. Tu penses t'imposer avec des jugements tranchants et sans appel. Malheureusement, il s'avère qu'il sont parsemés d'informations biaisées ou accompagnés d'erreurs d'interprétation non avouées, et comme tu le dis à juste titre, sur un forum c'est plus embêtant. A la longue, je me sens contraint de réagir. Deux exemples seulement, pour ne pas être trop long.

Une information biaisée

Il ne faudra pas aller bien loin...et pourtant ça partait vraiment bien

Je te cite:
.../...Il n'y a pas à être acide ou à supporter un logiciel, il suffit d'être lucide, sans parti pris, objectif, et de lister de manière précise les avantages et défauts de chacun, et non d'un seul.
Pour le moment Atlantis est encore très supérieur à W2X sauf dans 2 cas :
1. Lorsqu'il y a des tableaux
2. Lorsqu'on veut éditer l'epub avec Sigil, qui "casse" les epubs issus d'Atlantis pour des raisons techniques que j'ai la flemme d'exposer

Fin de citation.

Voici typiquement une information biaisée, bien emballée mais biaisée.

1. Les tableaux.
Une absence de commentaire révélatrice. Surtout pas de commentaire. Alors, je vais en faire.
"Mon logiciel est très supérieur mais il salope les tableaux".
En somme ce qu'Atlantis produit, c'est un peu comme la Venus de Milo... l'esthétique est parfaite mais il manque un bras....Oui, monsieur, on a le menu mais y a pas de dessert. Faut vivre avec, je suppose ?
Cite-moi une lacune irréparable équivalente pour W2X qui est pourtant selon toi très inférieur...

2. Sigil
A te lire, on a l'impression que le coupable finalement c'est Sigil (qui commet d'ailleurs comme tu n'as pas manqué de le signaler un peu avant, des agressions "incontrôlées" sur le code, agressions régulièrement dénoncées par epubcheck et Amnesty International). Et les raisins sont trop verts. Valloric, si tu nous lis, bonjour!

Et pourtant, le seul responsable de cette situation c'est bien Atlantis, avec sa façon très particulière de gérer l'html et qui fait que l'on ne peut accéder au texte depuis Sigil. C'est un défaut de conception grave et chronique pour un logiciel censé être "trés supérieur", et je comprends que tu aies "la flemme" de l'exposer.

Le fait de ne pas pouvoir modifier facilement le code constitue une entrave fondamentale pour l'utilisateur qui se retrouve pieds et poings liés, content, pas content, à manger la pâtée qu'on lui a donné.

"Trés supérieur"!! oh, Marius, quelle blague tu nous sors avec ton air si sérieux !!

Des erreurs d'interprétation jamais reconnues

Lorsque j'avais décidé d'exporter des images réelles avec W2X, tu avais qualifié cette solution de conceptuellement fautive et ajouté qu'il ne pouvait être question d'exporter que des images relatives si l'on voulait que les images sur l'EPUB soient retaillables.

Tu commettais là une confusion et c'est moi qui avais raison: on peut effectivement exporter avec W2X des images, qu'elles soient réelles ou relatives, puisque ces adjectifs ne qualifient que ce qui sort d'OpenOffice: les deux sont exportées avec des dimensions physiques, qu'elles soient réelles ou interprétées.

Ce n'est que lorsqu'on a modifié le code CSS directement sur l'EPUB en remplaçant ces valeurs physiques par des valeurs en %, que ces mêmes images deviennent retaillables et j'ai fini (erreur pour la V2, solution pour la V3, je ne suis pas très doué) par obtenir l'effet retaillable souhaité en modifiant une seule malheureuse ligne de code par image. Vrai ou faux?

Cette solution -enfantine- n'est possible cependant que lorsqu'on peut modifier le code.

Ah! que n'ai-je entendu de ta part à ce sujet...Je n'aurai pas la cruauté de te citer.

Tu raisonnais en fait, je le vois maintenant, comme un client ligoté d'Atlantis pour lequel une solution si basique n'est pas applicable pour les raisons citées plus haut "et que j'ai la flemme d'exposer".

Eh bien, vive la liberté... Allez, porte-toi bien, merci quand même très sincèrement de faire vivre ce fil. Bien le bonjour à la Vénus de Milo si tu la croises.

Last edited by roger64; 03-03-2011 at 08:24 PM.
roger64 is offline   Reply With Quote
Old 03-03-2011, 08:37 PM   #71
Coolmicro
Groupie
Coolmicro will become famous soon enoughCoolmicro will become famous soon enoughCoolmicro will become famous soon enoughCoolmicro will become famous soon enoughCoolmicro will become famous soon enoughCoolmicro will become famous soon enough
 
Coolmicro's Avatar
 
Posts: 195
Karma: 542
Join Date: Jul 2008
Device: Tablette android SmartQ T7 - Nook Touch - Pocketbook 602
Là, j'hallucine vraiment en te lisant. Je réponds une dernière fois et je laisse tomber...
Tout d'abord, je te rappelle que tu n'es pas propriétaire d'un sujet. Tu crées un sujet sur un forum pour expliquer comment tu produis des epubs, je pense que c'est pour que des gens viennent discuter avec toi de tes méthodes et des leurs, non ?
Par ailleurs, parler d'un logiciel en soi, sans le comparer aux autres solutions, c'est être une autruche contente de soi.
Sur tel forum que tu connais et que je ne nommerai pas, on célèbre Calibre comme supérieur à toutes les autre solutions, en refusant soigneusement de comparer Calibre à W2X ou Atlantis.
Toi tu célèbres W2X en refusant de le comparer à Atlantis.
Pourtant, depuis le temps, il devrait être évident que c'est en comparant les avantages et inconvénients de chaque logiciel, en poussant les développeurs à incorporer telle ou telle idée d'un autre logiciel, que les choses progressent.

Où as-tu vu qu'Atlantis est "mon logiciel" ? C'est uniquement la solution que j'utilise majoritairement (mais non exclusivement), pour le moment.
* Pour les ebooks sans tableaux - ce qui constitue la majorité des livres publiés par ELG, j'utilise actuellement Atlantis parce qu'ils propose des fonctionnalités (images plein écran, marges et espacement en em) qui ne sont pas encore dans W2X qui vient à peine d'incorporer la feuille de style unique. C'est en cela que je dit qu'il est supérieur, pour le moment. La situation sera complètement différente dès que W2X aura évolué et j'ai dit X fois que pour une version alpha, il est déjà super.
* Je critique en fait sévèrement Atlantis puisque s'il est complètement cassé lors d'une édition avec Sigil, c'est dû à un défaut de conception intrinsèque à Atlantis qui ne conserve pas les balises H1, H2, H3 et nomme n'importe comment les styles. Cela fait un moment que je le dis (http://www.mobileread.com/forums/sho...5&postcount=21) En plus les développeurs ne semblent pas vouloir évoluer sur ce point.
* Par ailleurs je fonde de grands espoirs sur W2X, car, même si des fonctionnalités manquent encore, l'axe du développement me semble meilleur.

Je pense donc être beaucoup plus lucide que toi qui te complais à supporter telle solution contre telle autre. Je n'ai pour ma part aucune envie de jouer au supporter de foot en informatique.

Quant à Sigil, je disais de t'en méfier quand tu édites des ebooks faits avec W2X, je ne parlais pas d'Atlantis : je te rappelle que le bug signalé à Henrik concernant les exposants, était dû à Sigil, c'est lui même qui te l'a dit, et que j'était partisan de combiner Sigil avec W2X jusqu'à ce que je m'aperçoive que Sigil faisait des conneries.

Bon maintenant je te laisse en tête à tête avec ton sujet, je te reviendrai pas t'embêter.
Coolmicro is offline   Reply With Quote
Old 03-03-2011, 09:45 PM   #72
roger64
Wizard
roger64 ought to be getting tired of karma fortunes by now.roger64 ought to be getting tired of karma fortunes by now.roger64 ought to be getting tired of karma fortunes by now.roger64 ought to be getting tired of karma fortunes by now.roger64 ought to be getting tired of karma fortunes by now.roger64 ought to be getting tired of karma fortunes by now.roger64 ought to be getting tired of karma fortunes by now.roger64 ought to be getting tired of karma fortunes by now.roger64 ought to be getting tired of karma fortunes by now.roger64 ought to be getting tired of karma fortunes by now.roger64 ought to be getting tired of karma fortunes by now.
 
Posts: 1,456
Karma: 846401
Join Date: Jan 2009
Device: KoboGlo
Bonjour

Ah, je vois, la vérité ne peut se dire que dans un sens... de préférence de haut en bas. Il est vrai que les discussions comparatives sur qui lave plus blanc sont finalement stériles, mais enfin tu l'as voulu. Je remarque que tu n'as toujours pas reconnu t'être trompé comme je l'indiquais plus haut (voir paragraphe: des erreurs d'interprétation jamais reconnues).

Exposants et Sigil

A propos de ce que raconte Coolmicro, comme ça fait trois fois qu'il ressort cette histoire sur ce forum, je voudrais mettre les choses au clair : il y avait sur un fichier de test que j'ai réalisé un et un seul exposant, un orphelin vous dis-je, et il a été transformé en caractère normal (1er), peut-être à la suite d'une intervention avec Sigil sans qu'une autre cause ne puisse être exclue.

Le développeur n'a jamais incriminé formellement Sigil. Il a suggéré "Sigil ?" avec un point d'interrogation, ce qui n'est quand même pas la même chose...

J'ai refait aujourd'hui un test avec un livre qui contient des centaines d'exposants. J'ai modifié les images avec Sigil, les méta-données : les exposants sont toujours là, hirondelles perchées sur leur branche.

Mais quand cette bricole vous est racontée par Coolmicro, puis répétée trois fois, cela devient une tout autre histoire. Ce malheureux exposant que le hasard a fait choir, va se transformer en cause célèbre internationale sur les "agressions incontrôlées" de Sigil et servira jusqu'à la fin des temps. Comment ne pas conclure que cette histoire est gonflée hors de toute proportion, dans un esprit malicieux?

Ne prenez pas ce que je vous dis pour argent comptant, vérifiez par vous même. Le livre a été publié sur MobileRead et s'appele Tableaux vivants. Sigil fonctionne pour Windows, Mac et Linux et est opensource.

On se demande parfois comment naissent les rumeurs, je commence à avoir ma petite idée...

Nouvelle version

Voici la V4, avec un tableau à la fin.

Toutes les images sont en pourcentage
- les grandes en "height:100%;max-width:100%;"
- les petites en "width:..%;" (le pourcentage varie)

Délai de l'intervention chirurgicale complémentaires avec Sigil destiné à mettre les %: comptez vingt à trente secondes par image pour une personne âgée.

Notez que l'image insérée est maintenant aussi redimensionable. Voir photos jointes.

P.S. - Assez parlé : que quelqu'un nous montre enfin en quoi, Atlantis est "très supérieur"
Cela ne manquera pas d'être instructif et Saint Thomas y croira.
Attached Thumbnails
Click image for larger version

Name:	avant.png
Views:	118
Size:	22.7 KB
ID:	67771   Click image for larger version

Name:	après.png
Views:	113
Size:	21.9 KB
ID:	67772  
Attached Files
File Type: epub W2X et les images V4.epub (437.9 KB, 101 views)

Last edited by roger64; 03-04-2011 at 06:17 AM. Reason: Sigil
roger64 is offline   Reply With Quote
Old 03-05-2011, 06:09 AM   #73
roger64
Wizard
roger64 ought to be getting tired of karma fortunes by now.roger64 ought to be getting tired of karma fortunes by now.roger64 ought to be getting tired of karma fortunes by now.roger64 ought to be getting tired of karma fortunes by now.roger64 ought to be getting tired of karma fortunes by now.roger64 ought to be getting tired of karma fortunes by now.roger64 ought to be getting tired of karma fortunes by now.roger64 ought to be getting tired of karma fortunes by now.roger64 ought to be getting tired of karma fortunes by now.roger64 ought to be getting tired of karma fortunes by now.roger64 ought to be getting tired of karma fortunes by now.
 
Posts: 1,456
Karma: 846401
Join Date: Jan 2009
Device: KoboGlo
A propos des résolutions d’images pour l’EPUB : "to flag a dead horse"


Je voudrais citer un livre blanc d’Adobe que je viens de trouver et que vous pourrez télécharger ici http://terabook.net/how-to-optimize-...or-ebooks.html sous le titre: eBooks: Optimizing images for the EPUB file format

Ce guide est destiné aux utilisateurs de InDesign mais il contient des remarques d’ordre général qui recoupent exactement ce que j’avais trouvé de façon empirique (le bon sens est également partagé) et écrit dans ce post. http://www.mobileread.com/forums/sho...6&postcount=54 Vous pouvez vérifier...

Je me suis permis de vous en traduire un petit extrait. Je vous encourage à lire le document en entier. Il donne des suggestions concrètes pour préparer ses images avant de les insérer dans l'odt (ou le doc).

1. A propos de la taille des images plein écran

The final image size for the cover should be around 600x800 pixels so that
the cover looks good on a variety of eBook readers.

La taille finale de la page de couverture devrait avoisiner 600 x 800 pixels pour que la couverture puisse être correctement affichée sur différents lecteurs d’eBooks.

2. Exporter des images à taille réelle

Exporting original images
If you prefer to optimize the images yourself, choose Original from the Copy Images menu, and InDesign will export the original images to the EPUB file. With this option selected, all the other image export options are not available.
When optimizing images for the EPUB file format, it’s best to create one eBook that works well across a variety of reading devices. Keep in mind that there is an abundance of eBook readers available on the market today. They vary in screen size and resolution. For example, the iPhone has a 3.5-inch display with a resolution of 163 ppi, whereas the Amazon Kindle has a 6-inch display with a resolution of 167 ppi, and the Amazon Kindle DX has a 9.7-inch display with a resolution of 150 ppi. Figuring out how to handle images depending on the end device is a challenge. And as the eBook reader market continues to grow, there will be newer models with even more advanced technology and impressive features.


Exporter les images d'origine
Si vous préférez optimiser les images vous-même, choisissez l’option «Original» dans le menu «Copy Image» et InDesign exportera les images d'origine vers le fichier EPUB. Lorsque cette option est sélectionnées, les autres options d’export d’images ne sont plus disponibles.
Pour optimiser les images pour le format EPUB, il vaut mieux créer un eBook qui fonctionne bien sur divers appareils de lecture. Souvenez-vous qu’il y a une pléthore de lecteurs deBook disponibles sur le marché aujourd’hui. Ils ont des dimensions d’écran et des résolutions diférentes.
Par exemple l’iPhone a un affichage de 3,5 pouces et une résolution de 163 ppi, alors que le Kindle d’Amazon a un affichage de 6 pouces avec une résolution de 167 ppi, et que le Kindle DX d’Amazon a un affichage de 9.7 pouces avec une résolution de 150 ppi.
Trouver comment gérer les images en fonction de l’appareil final est difficile. Et comme le marché des eBook continue à grandir, nous verrons apparaître des modèles nouveaux disposant d’une technologie plus avancée et de caractéristiques remarquables.

3. Séparer le contenu d’une image plein écran dans la structure du livre.

Manage the cover with a book file.
The EPUB file format does not define page structure, so all content flows together in one continuous linear stream. This can be problematic for an eBook cover, because text from the following page can potentially run into the cover image. To avoid this problem, create a separate InDesign document for the cover image.


Gérer la couverture d’un livre.
Le format de fichier EPUB ne définit pas la structure des pages. Tout le contenu défile de façon linéaire et continue. Ceci peut poser un problème pour une couverture d’EPUB, parce que le texte de la page précédente peut potentiellement interférer avec l’image de couverture. Pour éviter ce problème, créez un document InDesign séparé pour l’image de couverture.

Commentaire:

Comme je l’ai déjà indiqué, puis répété, si l'on encadre chaque image plein écran de sauts de page manuels puis que l'on choisisse avec W2X l’option «all explicit», l'image sera mise dans un chapitre séparé de la structure de l’EPUB. L'affichage sera fluidifié et les risques d'interférence écartés. Le résultat n'a pas l'air désastreux, même sur un iPad. http://www.mobileread.com/forums/sho...1&postcount=18

Si un logiciel exporte une image pleine page sans l'isoler de cette façon dans la structure du document, il fait courir le risque des problèmes d’interférence indiqués ci-dessus, sans parler des inconvénients d'une moindre fluidité de l'affichage.

Ce n'est quand même pas difficile à comprendre, mais il n'y a pire sourd que celui qui ne veut pas entendre.

Last edited by roger64; 03-05-2011 at 09:42 AM.
roger64 is offline   Reply With Quote
Old 03-05-2011, 11:00 AM   #74
Coolmicro
Groupie
Coolmicro will become famous soon enoughCoolmicro will become famous soon enoughCoolmicro will become famous soon enoughCoolmicro will become famous soon enoughCoolmicro will become famous soon enoughCoolmicro will become famous soon enough
 
Coolmicro's Avatar
 
Posts: 195
Karma: 542
Join Date: Jul 2008
Device: Tablette android SmartQ T7 - Nook Touch - Pocketbook 602
Extrait d'un email que j'avais envoyé à Henrik :
Quote:
Hello Henrik,
I forgot to say one thing.
For pictures automatically in full screen (case 2), Writer2xhtml must generate automatically a separate file xhtml with only the picture in full screen. It's important.
Best regards
Coolmicro
J'ai toujours été d'accord pour dire que l'image plein écran doit être dans un fichier xhtml séparé, c'est déjà connu de nombre de gens et les recommandations d'Adobe ne sont pas nouvelles Je pense simplement que cela doit être fait automatiquement par W2X à partir du moment où une image est en plein écran, et non par un saut de page explicite dans le doc.

Si tu lisais ce qui est écrit parfois, ce serait bien.

Last edited by Coolmicro; 03-05-2011 at 11:06 AM.
Coolmicro is offline   Reply With Quote
Old 03-05-2011, 08:31 PM   #75
roger64
Wizard
roger64 ought to be getting tired of karma fortunes by now.roger64 ought to be getting tired of karma fortunes by now.roger64 ought to be getting tired of karma fortunes by now.roger64 ought to be getting tired of karma fortunes by now.roger64 ought to be getting tired of karma fortunes by now.roger64 ought to be getting tired of karma fortunes by now.roger64 ought to be getting tired of karma fortunes by now.roger64 ought to be getting tired of karma fortunes by now.roger64 ought to be getting tired of karma fortunes by now.roger64 ought to be getting tired of karma fortunes by now.roger64 ought to be getting tired of karma fortunes by now.
 
Posts: 1,456
Karma: 846401
Join Date: Jan 2009
Device: KoboGlo
Technique: LibreOffice, un excellent cru

J'ai maintenant installé LibreOffice 3.3.1 fr. Il en vaut la peine:
- plus rapide
- tout le support langue française dans le pack d'installation
- meillleur support des formats exogènes
- un outliner très pratique* intégré dans le navigateur
- inclusion automatique des insécables à la française

Je n'ai pas encore eu le temps de faire le tour du propriétaire mais ce que j'ai vu me satisfait déjà grandement.

Images plein écran

Pour les images plein écran que vous insérez dans LibreOffice, vous pourrez retenir les options suivantes (mais chacun fait comme il veut):

- forme avoisinant le 3 x 4
- résolution avoisinant 600 x 800 pixels
- JPG pour les photos (ou GIF), PNG pour les logos et dessins (comme le Tux)
- alignement centré
- ancrage au paragraphe (pas à la page)
- laisser les couleurs sur les images (pas de fausses économies)
- option max-width:100%; conseillée, ou height:100%;max-width:100%;
Pour les autres images, pour des questions de cohérence, on peut vérifier que la résolution reste dans les 150-200 ppi mais ça n'a rien de forcé.

Divers

@Coolmicro

Bonjour, je te croyais mort...

Profite en, je pars pour quelques jours... Puisque souhaites faire un comparatif, peux-tu nous poster un -petit- EPUB de démonstration made in Atlantis? ce sera sincèrement très instructif plutôt que de te contenter d'en parler. Tu dois bien en avoir un au fin fond de l'un de tes disques durs.

Saut de page

Oui, si c'est automatique ce sera vraiment bien.

En attendant, insérer un saut de page dans LibreOffice suffit, dans la mesure bien sûr où il est correctement interprété par la suite...

* Je me rappele le temps où j'en utilisais un avec Word 4 pour Macintosh en 1993...

Last edited by roger64; 03-06-2011 at 05:44 AM.
roger64 is offline   Reply With Quote
Reply

Thread Tools Search this Thread
Search this Thread:

Advanced Search

Forum Jump

Similar Threads
Thread Thread Starter Forum Replies Last Post
Créer des epub à partir d'une syntaxe wiki (chaîne d'édition vers PDF (LaTeX), xHTML farvardin Software 1 04-03-2011 01:49 PM
Problème avec conversion de *.pdf avec calibre panzer Assistance 2 08-24-2010 04:49 AM
Comment créer un tableau centré dans un Ebook avec sigil ? agronomia Software 7 05-06-2010 07:26 AM
Créer des documents ePub Thomas_ Software 3 04-17-2010 08:36 AM
Comment créer une recette avec calibre ? KLAO Software 1 02-04-2010 10:17 AM


All times are GMT -4. The time now is 03:41 PM.


MobileRead.com is a privately owned, operated and funded community.