Espaces fines pour ePub sous iBook/iPad

Neurotron

Membre enregistré
24 Avril 2009
4
0
Bonjour à tous,

Je galère pour arriver à trouver un code qui génère l'équivalent d'une espace fine insécable pour des fichiers ePub sous iBook/iPad.
Le code   (NARROW NO-BREAK SPACE) ne fonctionne pas (ça affiche un carré) et le   ne me satisfait pas (je sais, je suis ch…t) !
Le pire c'est que j'aimerais que ça passe sur toute les liseuses (Kobo, Sony, etc.) Est-ce que quelqu'un a une solution acceptable puisqu'il semble que rien ne soit prévu en standard ? Ou suis-je contraint à la médiocrité typographique qui pullule jusque dans les ePub distribués par Apple dans son iPad ?

Merci
 
Bonjour, vous pouvez essayer de corriger la misère typographique avec les codes suivants :
(les espaces après le & sont à supprimer)
L’interprétation de ces espaces est plus ou moins bien faite selon le navigateur internet ou le lecteur d’ePub employé…

& nbsp; ou & #160; (espace insécable)
& thinsp; ou & #8201; (espace fine)
& #8239; (espace fine insécable)
& ensp; ou & #8194; (espace demi-cadratin)
& emsp; ou & #8195; (espace cadratin)

Bonne journée.
 
Dernière édition:
Merci pour vos réponses.

@ sylko : j'ai besoin d'une solution qui passe partout.
@ alex.virginia :
& #8239; (espace fine insécable) = NARROW NO-BREAK SPACE
Malheureusement ça ne marche pas sur iBook d'Apple… C'est étrange qu'une société qui a été le fer de lance de la PAO ne prenne pas en compte un minimim de typo.
J'ai mis des   partout, à mon grand désespoir. Boooouuuuu que c'est laid ! :(
 
Vous pouvez, si vraiment cette situation vous rend morose, mettre en place une feuille de style réduisant le corps (font-size) ou l’approche (letter-spacing) de votre espace insécable devant les points virgules et autres points d’exclamation…
Lorsque la gestion de la typographie sera enfin devenue adulte en html quelque soit l’environnement système ou logiciel, un rechercher-remplacer rétablira la bonne marche de votre développement.
Pour rappel, les compositeurs au plomb ne sont pas les derniers à “bricoler” leurs caractères mobiles à coup de lime et de marteau et cela fait cinq siècles que cela dure.
 
C'est étrange qu'une société qui a été le fer de lance de la PAO ne prenne pas en compte un minimim de typo.
C'est typique des logiciels développés par et pour des américains, ce n'est qu'après une diffusion mondiale massive et qu'après de nombreux retours utilisateurs qu'on s'aperçoit qu'il existe d'autres langues que l'US-english…

:D
 
Vous pouvez, si vraiment cette situation vous rend morose, mettre en place une feuille de style réduisant le corps (font-size) ou l’approche (letter-spacing) de votre espace insécable devant les points virgules et autres points d’exclamation…

Désolé de déterrer un sujet qui date un peu mais l'info à ce sujet étant importante...

Ce bricolage est l'une des plus mauvaises pratiques imaginables pour la problématique d'espaces. Pour cause, elle est susceptible de foutre l'insécable en l'air sur la majorité des solutions de lecture EPUB (qui tournent avec le Reader Mobile Adobe, ce qui inclut 90 % des apps tablettes et à peu près toutes les liseuses EPUB).

Mauvaise pratique pour plusieurs raisons :

1. L'insécable n'est pas "stretched" (étiré au delà de la taille du cadratin) par ARM et Kindle, au contraire de l'espace normale. Autrement dit, quand l'espace mot est vraiment important, on aura déjà l'impression que l'insécable est fine. On obtiendra donc une fine de fine.

2. La dernière mise à jour d'ARM est une catastrophe. En utilisant cette technique, on en vient en réalité à indiquer que le moteur ne doit plus prendre en compte l'insécable puisqu'il est contenu entre deux balises (typiquement "span"). Or, ARM coupe avant la balise en fin de ligne. Résultat : le signe de ponctuation début de ligne suivante...

3. La règle tacite dans le domaine veut que l'on prévoie le fichier pour iBooks et ARM. Il n'y a pas le choix, EPUB est un standard, le lecteur peut prendre le fichier sur iBooks et le lire sur sa liseuse. Ne pas prévoir juste pour iBooks donc. Là, par exemple, ça ne marcherait pas avec letter-spacing, qu'ARM ne supporte pas.

4. Tant qu'à faire, vu la médiocrité des algos de césure, autant les désactiver et aligner le texte à gauche si l'on a pas envie de s'embêter. Je rappelle que la coupure du mot en fin de ligne est systématiquement fausse sur iBooks s'il est précédé d'une apostrophe typo. Ne pas avoir de coupures pourries, c'est bien plus important que les espaces fines si vous voulez mon humble avis.

5. Cette technique alourdit le marquage pour quasiment que dalle (voir points précédents), ce qui va devoir être interprété par les solutions de lecture. Croyez-moi, il y a certains modèles de liseuses en vente qui galèrent à cause de ce genre de choses. Résultat : une latence susceptible de ruiner le confort de lecture. Ça n'a pas l'air de grand-chose mais ça a plus d'impact que des images par exemple.

6. Si soin typo doit être apporté(améliorations donc), la bonne pratique est de ne pas passer par du marquage HTML mais par CSS et JavaScript uniquement. Par exemple, JavaScript sera pris en compte sur iBooks, Readium, etc. Mais pas sur les liseuses et apps ARM. On est sur de l'amélioration progressive, pas sur de la dégradation.

En tout cas, quand je télécharge un fichier et que la technique est utilisée, je nettoie systématiquement vu les ennuis que ça peut apporter côté lecteur. Et croyez bien que ça m'ennuie tout autant que vous puisque mon travail consiste à faire de l'epub toute la journée. :zen:
 
Alors là, me voilà sidéré. Quand je pense aux capacités et aux innombrables variantes qu'on peut prêter à l'informatique, quand je pense que les liseuses et les fichiers ePub représentent une part non négligeable de l'avenir de l'édition du livre, et que j'apprends par ces lignes que les langages actuellement en cours n'ont même pas été prévus pour gérer les espaces et autres particularités typo de façon exhaustive… Serait-ce encore un coup des anglophones , ou de commerciaux qui ont considéré qu'il n'était pas nécessaire de consulter des imprimeurs avant de développer leur système « complet et infaillible » (et là je pense à une expérience personnelle de développement de site par un prestataire qui n'a jamais consulté le futur utilisateur que j'étais et nous a livré un outil ultra-pauvre et quasiment inexploitable en croyant avoir tout compris à notre métier sur la base de ses à-prioris et des opinions du commercial qui lui a acheté)

EDIT
Remarquez, dans l'édition papier, ce n'est pas toujours mieux, j'ai une connaissace qui a fait éditer son roman : aucune espace devant les points d'exclamation sur l'ensemble du bouquin.
Il était un peu furax envers son éditrice quand il a vu le résultat imprimé.
Enfin, je ne connais pas le détail de l'histoire, mais voilà, ça existe, et après c'est imprimé, distribué au Furet du Nord sur un présentoir, etc. Et pourtant je suis loin de saisir toutes les subtilités de l'édition de livre, je ne vois que les erreurs les plus grossières.
 
Dernière édition:
2. La dernière mise à jour d'ARM est une catastrophe. En utilisant cette technique, on en vient en réalité à indiquer que le moteur ne doit plus prendre en compte l'insécable puisqu'il est contenu entre deux balises (typiquement "span"). Or, ARM coupe avant la balise en fin de ligne. Résultat : le signe de ponctuation début de ligne suivante...

C'est un vrai calvaire ce comportement ! Même résultat avec les exposants…
Ils en ont des exposants les anglophones tout de même !
 
Merci Jiminy pour cette synthèse tout à fait exacte !
Le problème réside essentiellement dans le standard ePub lui-même. Ca évoluera probablement, mais pour l'instant je conseille aussi à tous mes stagiaires de tout faire en fer à gauche sans césure, sinon c'est la galère.
Et vivent les autres solutions de digital publishing, comme le PDF (il ne faut pas l'enterrer trop vite, celui-là), le DPS, Aquafadas, et autres... qui respectent vraiment notre travail de mise en page et de typographie...

Désolé de déterrer un sujet qui date un peu mais l'info à ce sujet étant importante...

Ce bricolage est l'une des plus mauvaises pratiques imaginables pour la problématique d'espaces. Pour cause, elle est susceptible de foutre l'insécable en l'air sur la majorité des solutions de lecture EPUB (qui tournent avec le Reader Mobile Adobe, ce qui inclut 90 % des apps tablettes et à peu près toutes les liseuses EPUB).

Mauvaise pratique pour plusieurs raisons :

1. L'insécable n'est pas "stretched" (étiré au delà de la taille du cadratin) par ARM et Kindle, au contraire de l'espace normale. Autrement dit, quand l'espace mot est vraiment important, on aura déjà l'impression que l'insécable est fine. On obtiendra donc une fine de fine.

2. La dernière mise à jour d'ARM est une catastrophe. En utilisant cette technique, on en vient en réalité à indiquer que le moteur ne doit plus prendre en compte l'insécable puisqu'il est contenu entre deux balises (typiquement "span"). Or, ARM coupe avant la balise en fin de ligne. Résultat : le signe de ponctuation début de ligne suivante...

3. La règle tacite dans le domaine veut que l'on prévoie le fichier pour iBooks et ARM. Il n'y a pas le choix, EPUB est un standard, le lecteur peut prendre le fichier sur iBooks et le lire sur sa liseuse. Ne pas prévoir juste pour iBooks donc. Là, par exemple, ça ne marcherait pas avec letter-spacing, qu'ARM ne supporte pas.

4. Tant qu'à faire, vu la médiocrité des algos de césure, autant les désactiver et aligner le texte à gauche si l'on a pas envie de s'embêter. Je rappelle que la coupure du mot en fin de ligne est systématiquement fausse sur iBooks s'il est précédé d'une apostrophe typo. Ne pas avoir de coupures pourries, c'est bien plus important que les espaces fines si vous voulez mon humble avis.

5. Cette technique alourdit le marquage pour quasiment que dalle (voir points précédents), ce qui va devoir être interprété par les solutions de lecture. Croyez-moi, il y a certains modèles de liseuses en vente qui galèrent à cause de ce genre de choses. Résultat : une latence susceptible de ruiner le confort de lecture. Ça n'a pas l'air de grand-chose mais ça a plus d'impact que des images par exemple.

6. Si soin typo doit être apporté(améliorations donc), la bonne pratique est de ne pas passer par du marquage HTML mais par CSS et JavaScript uniquement. Par exemple, JavaScript sera pris en compte sur iBooks, Readium, etc. Mais pas sur les liseuses et apps ARM. On est sur de l'amélioration progressive, pas sur de la dégradation.

En tout cas, quand je télécharge un fichier et que la technique est utilisée, je nettoie systématiquement vu les ennuis que ça peut apporter côté lecteur. Et croyez bien que ça m'ennuie tout autant que vous puisque mon travail consiste à faire de l'epub toute la journée. :zen: