Espaces fines

Jump to navigation Jump to search

S’il te plait, Verdy_p, pour faciliter le débat, reste aussi concis que possible et évite les digressions, on y gagnera vraiment en clarté.

Question : désormais tu préfères ne plus mettre d’espace du tout ???

En tous cas, merci de ne plus faire de modifications d’espace tant que le débat n’aura pas été réglé. Ce n’est pas à coup de révocations que le débat va être réglé…

Pols12 (talk)15:22, 1 December 2019

Je n'ai pas voulu supprimer ces espaces. Si ça a eu lieu à un endroit c'est un problème d'interface car ils y étaient bien quand j'ai saisi ça (filtrage par l'interface de traduction?).

Verdy p (talk)01:44, 2 December 2019
 

Cinq personnes (en comptant l’autre discussion) se sont prononcées en faveur d’NBSP, il serait temps d’en prendre acte et de passer à autre chose.

Thibaut (talk)11:23, 2 December 2019

Au cas où, +1 aussi. Vigneron a bien résumé mon opinion.

Ash Crow (talk)15:19, 2 December 2019

Idem (je n'ai rien contre les espaces fines, mais une espace insécable est largement préférable à pas d'espace du tout).

Jules78120 (talk)19:14, 2 December 2019

Mai il y a bien une espace ! Bel et bien pris en charge par MacOS depuis une douzaine d'années (pratiquement depuis son introduction dans Unicode 4.0). Et utilisé sur MacOS depuis bien longtemps (avant même le web) par tous les pros de la typographie et de la PAO (qui travaillent depuis bien plus longtemps sur Mac que sur PC) avant même le développement du web, ils ont été nombreux à demander cette prise en charge qui est arrivée au même moment que son unification (à tord) aussi avec le séparateur en mongol. et MacOS prend en charge aussi le mongol (pour l'instant encore avec NNBSP mais cela va changer en mars prochain avec un nouveau caractère et Apple a aussi déjà fait une mise à jour bêta pour ça de ses OS (il ne supprimera pas NBNBSP en mongol mais l'utilisera en mode de compatibilité sans rien retirer de la fine insécable, qui reste encore standard comme séparateur de groupes de chiffres dans les nombres en format français et ISO, où l'espace insécable NBSP est totalement indésirable) et figure aussi dans les bibliothèques CLDR et les formateurs de nombres en français de MacOS et de Java (inclus aussi dans MacOS et iOS).

Verdy p (talk)19:58, 2 December 2019

Pour ce qui concerne macOS, on parle ici de Safari qui n'affiche clairement pas d'espace (prouvé plusieurs fois dans la discussion précédente), pas des autres applications ou navigateurs.

Merci de ne pas changer de sujet.

Thibaut (talk)20:11, 2 December 2019

You do not have permission to edit this page, for the following reason:

The action you have requested is limited to users in the group: Users.


You can view and copy the source of this page.

Return to Thread:Portal talk:Fr/Espaces fines/reply (18).

Voici le résultat sur Safari 13.0.3 (macOS), si j'en crois le résultat pour la même commande sur Firefox, Safari semble ignorer complément l'espace fine insécable qui est censée être entre 120 et 000.

Thibaut (talk)20:55, 2 December 2019

Non Safari ne l'ignore pas puisqu'il affiche bien "202f" comme 4e caractère, il choisit seulement de l'afficher comme un glyphe vide (choix de design d'Apple dans la police que tu utilises). Ce qui confirme ce que je dis: c'est son design et conforme à ce qu'Apple fait depuis longtemps aussi dans la présentation des nombres. Le caractère est bien présent, mais il n'y a pas d'anomalie d'affichage, aucun "tofu".

Note bien que dans ta console Freifox, les résultats sont affichés dans une police de type "monospace" (à chasse fixe) qui figure le NNBSP sous forme d'une espace simple et non d'une espace vide (les deux sont possibles, bien qu'à mon avis la fine est plus adaptée à ce cas). Si tu passes la console en police proportionnelle tu peux voir une différence suivant les préférences du navigateur pour les deux styles génériques "serif" ou "sans-serif", selon les polices choisies (si tu prends une police système Apple, en sans-serif, le NNBSP disparaît et c'est normal et cohérent avec les glyphes des ponctuations). Dans tous les cas c'est une question de préférence: si tu aimes les polices UI d'Apple, ne rien voir est normal car tu ne vois rien non plus dans l'UI d'Apple pour les grands nombres et il n'uy a non plus aucune espace ajoutée autour des ponctuation déjà "élargies" de ces polices, donc aucune anomalie là non plus, mais tu ne fais pas de la APO ou de la typographie. Tu as le choix dans ton navigateur (dans Safari, comme Firefox ,ou Chrome, ou Edge qui va aussi arriver, ou Opera) !

Et dans d'autres polices comme Times New Roman, Segoe UI et plein d'autres, le caractère est bien distingué.

Critique l'UI d'Apple si tu veux, mais c'est ce qu'Apple recommande. De même il a mappé NNBSP (pas seulement NBSP) sur le clavier français tout en sachant que ce peut ne pas être utilisé pour les UIO d'applis MacOS/iOS, mais que c'est bien utilisé dans les contenus en ligne et la PAO. Hors de Javascript tu peux aussi voir ce que retourne les API d'internationalisation des nombres de MacOS: là aussi il y a bien NNBSP et non NBSP (Apple ne dévie donc pas des normes de codage, son choix est purement typographique dans ses polices système).

Apple a du faire ça pour "compacter" les nombres sur les mobiles (on peut noter qu'il choisit des chiffres plus larges, en supposant qu'il n'y a jamais besoin de les compter, il a fait le même choix avec les ponctuations qui incluent un "gap" qu'Apple juge suffisant pour qu'avec la même police la fine puisse être annulée. On peut critiquer le choix d'Apple mais c'est un choix propriétaire pour ses polices UI (qui ne sont pas destinées au rendu web où il y a plein d'autres choix que la police "système". Et c'est aussi cohérent avec son choix d'interface pour la présentation des formulaires de ses applications.

Ces polices système ne sont pas destinées au web, à la typographie fine, à la PAO. Dans le Finder de fichiers, MacOS choisit de ne pas afficher les grands nombres mais il les arrondit pour ne pas avoir à afficher les groupements de 3 chiffres. La PAO, et les logiciels tiers comme MS Office ou Libre Office utilisent des polices qui font clairement la différence et les polices "système" (pas adaptées à toutes les langues mais à des orthographes simplifiées, y compris en Arabe ou hébreu) ne sont pas utilisées sauf si on les demande.

Note: les polices web par défaut sont normalement avec "Serif" dans le texte d'un navigateur. Pour l'UI le design original d'Apple et cohérent avec son interface est de ne pas afficher les NNBSP (ce qui est une erreur fondamentale pour l'écriture mongole, ce qu'Apple a fini par reconnaître). Attends le printemps prochain, Apple va changer ça dans ses mises à jour de MacOS et iOS et rétablir ce qu'il faisait au début quand NNBSP a été encodé, mais pour il mettra un "flag" de compatibilité pour les applis spécialement dédiées à MacOS, pas pour le web (à moins d'utiliser un "feature" OpenType spécifique activable en Javascript pour émuler le comportement des versions récentes boguées de MacOS et iOS avec ses polices système).

Verdy p (talk)21:41, 2 December 2019

As-tu une source concernant cette mise à jour de mars ?

Thibaut (talk)13:26, 9 December 2019