Espaces fines insécables entre les guillemets

Bonjour,

Le Lexique des règles typographiques en usage à l'Imprimerie nationale ([1]) et l'OQLF recommandent tous les deux l'usage de l'espace insécable (U+00A0) entre les guillemets et non l'espace fine insécable (U+202F).

C'est aussi le caractère utilisé par MediaWiki dans le rendu d'une page quand des espaces normales (U+0020) sont utilisées entre guillemets ([2]).

Je pense qu'il vaut mieux se conformer aux sources de référence et à l'usage (cf. MediaWiki).

Cordialement.

Ces règles sont vieilles et dataient d'avant l'encodage tardif de la fine en Unicode.

La fine a toujours été en usage dans l'imprimerie et bien distincte de l'espace insécable, elle est largemetn dicumentée dans l'imprimerie comme étant de taille entre 1/4 et 1/6 de cadratin (et non 1/2 cadratin comme l'espace normale ou l'espace insécable NBSP) : en typographie anglaise c'est plutôt 1/6, et en typographie française c'est par tradition 1/5.

C'est très bien documenté et largement discuté dans Unicode, et cela a été longtemps réclamé. Avant la fine insécable, on devait utiliser un style CSS et la fine sécable mais qu'on devait éviter en texte brut à cause justement de l'absence de style.

J'ai longtemps travaillé dans la presse et l'édition pour des logiciels de gestion de contenu, la fine est hautement recommandée, et même imposée aux opérateurs qui saisissent les petites annonces et les journalistes dans absolument TOUS les quotiens, annuaires et guides de France (régionaux ou nationaux) de plein de maisons comme Hachette, Larousse, tous les quotidiens régionaux de France (y compris parisiens), Pages Jaunes qui étaient TOUS nos clients.

Le traitement automatique du texte pour le prétirage en pré-presse va même remplacer et mettre les fines (chez certains éditeurs), qui sont utilisées partout autour des ponctuations et comme séparateur de groupes de chiffres (dont les numéros de téléphone et pas que les annuaires mais aussi comme les guide type Gault&Millau, et la presse magazine, et même la presse spécialisée professionelle qui a aussi des éditeurs dont les groupes sont situés à Paris ou dans les Hauts-de-Seine).

La règle est bien connue et pas qu'en France car c'était demandé aussi par nos clients presse en Belgique, Suisse, Canada, Luxembourg, Liban, et pas qu'en zone francophone car on la trouve aussi en Espagne et Italie. Même au Royaume-Uni.

Franchement la méconnaissance... NBSP (U+00A0) n'est plus recommandé QUE comme repli au cas ou NNBSP (U+202F) ne peut pas être utilisé pour des raisons techniques (ce qui n'est plus justifié depuis, le caractère étant bien supporté par les moteurs de rendu (dont tous les moteurs pour l'édition) même si les polices de caractères utilisés n'ont pas ce caractère, car il est synthétisé et n'a besoin d'aucun glyphe: s'il est absent d'une police le moteur utilise lui-même la moitié de la métrique de l'espace, donc 1/4 de quadratin et c'est dans les clous acceptables; s'il est présent dans une police, sa métrique (entre 1/4 et 1/6 de cadratin) est utilisée (mais c'est rarement le cas sauf cas particulier de polices aux métriques très spéciales comme les polices décoratives ou destinées au titrage).

Les sources que j'ai cité plus haut datent bien d'après l'encodage de l'espace fine dans Unicode.

Avez-vous des sources pour soutenir vos propos ?

Dans toutes les sources que j'ai pu consulter, l'espace fine insécable est uniquement recommandée devant le point-virgule, le point d’exclamation et le point d’interrogation.

« le caractère étant bien supporté par les moteurs de rendu »

Non, le caractère est malheureusement invisible sur Safari sur iOS (ce qui constitue une grande partie du lectorat sur Wikipédia).

De même l'OQLF indique clairement :

Ce tableau tient compte des limites des logiciels courants de traitement de texte, qui ne comportent pas l’espace fine (espace insécable réduite), à la différence des logiciels d’éditique et des logiciels professionnels de mise en pages.

Le tableau de l'OQLF est maintenant obsolète puisque les logiciels courants de traitement de texte comme aussi les navigateurs web comprennent et prennent en charge la fine. On revient aux règles de l'éditique qui sont applicables partout (sauf dans de très vieux contextes comme les anciens terminaux à police de chasse fixe uniquement, mais même eux font maintenant la substitution des espaces précis pour les remplacer par NBSP ou SPACE, ou des répétitions d'un de ces deux caractères si nécessaire : il n'est plus nécessaire que NNBSP soit présent dans les polices, et c'est le cas aussi dans les polices asiatiques: le moteur de rendu fait la prise en charge le plus adaptée de toutes les espaces codifiées et standardisées dans Unicode/ISO/CEI 10646, et c'est effectif maintenant depuis plus d'une décennie sur le web, et depuis toujours dans l'éditique professionnelle avant même l'apparition du web).

On donc des fines parfaitement supportées, on doit les utiliser. Il est juste regrettable que la fine ait tardé autant à être encodée dans Unicode/IEC 10646. D'aillurs la fine a toujorus existé aussi dans l'éditique anglophone, mais elle était jugée non nécessaire car traditionellement elle était un peu plus fine (1/6 cadratin) que la fine francophone (1/4 cadratin) et les polices de caractères de base avaient iuntégré une "approche" dans les signes de ponctuation: la fine a alors été supprimée dans les années 1960 pour les machines à écrire (de là vient aussi la convention anglophone des deux espaces après le point entre deux phrases d'un paragraphe, car l'éditique recommandait une espace plus importante en anglais (dont les mots sont plus courts et où il y a plus d'espaces séparateurs de mots qu'en français où la mise en page était plus lisible en anglais avec ce double espacement, mais pas nécessaire en français, allemand, néerlandais, italien, espagnol, portugais, grec, hébreu, arabe: ce double espacement en pratique ne persiste plus qu'aux USA, mais vient de la dactylographie qui s'y est développée plus vite qu'ailleurs et a résisté bien plus longtemps, mais où aussi l'éditique progressionnelle avait bien plsu de liberté de mise en page : la règle dactylographique est bannie depuis toujous au New York Times, mais encore imposée dans le Financial Times, et la presse magazine aux USA a toujours fait ce qu'elle voulait; pour les annuaires avant la libéralisation, AT&T n'utilisait pas du tout cette règle, mais d'autres éditeur d'annuaires et guides ont fait d'autre choix; chaque éditeur définissant ses propres règles de style; pour les journaux officiels américains au niveau fédéral ou de chaque Etat ou juridiction, il n' y a jamais eu les mêmes règles, chacun faisant ce qui lui plaisait et changeant d'avis selon les législatures, notamment au plan fédéral ou suivant les ministères, mais ça fait longtemps que ces journaux officiels sont diffusés par voie électronique vers leurs abonnés juristes, en forme ASCII uniquement sans aucune mise en page; pour les journaux officiels des villes et municipalités, il n'y avait jamais de règle, la typographie dépendant de l'éditeur privé choisi localement).

L'OQLF indique plus loin : « Si l’on dispose de l’espace fine, il est conseillé de l’utiliser devant le point-virgule, le point d’exclamation et le point d’interrogation. », exactement ce qui est indiqué sur https://unicode.org/udhr/n/notes_fra.html

Pas que là. Je sais de quoi je parle ayant justement travaillé avec à peu près tous les professionnels de l'édition en France (aussi au Canada), ils demandaient tous la même chose ; y compris avec les guillemets. La référence que tu donnes de l'OQLF est antérieure à l'encodage de la fine en Unicode, mais l'éditique a la fine utilisée depuis longtemps, représentée en SGML, et même avant l'HTML et le web et que finalement elle soit ajoutée à l'Unicode (quand un autre usage a été ajouté aussi pour les langues asiatiques, mais le comité Unicode ne voulait pas en entendre parler avant, jugeant que c'était inutile pour l'éditique qui utilisait SGML ou les langages et feuille de style pour la mise en forme, pour marquer les caractères "insécables", et donc en utilisant la fine sécable déjà codée. L'Unicode s'appuyait en fait sur l'absence d'usage dans les textes bruts (sans mise en forme), qui ont malheureusement hérité des mauvaises pratiques de l'ASCII et des anciens jeux de caractères. Unicode était plus timide à l'époque et avait un certain conservatisme, même poru des prtaiques qui n'étaient nécessaires que par les limitations des anciens systèmes dactylographiques, très largement développés pour les langues européennes. L'Unicode a eu de nombreuses demandes pendant des années pour l'ajout de NNBSP, et encore aujourd'hui ce caractère est mal connu (et même Microsoft dans Windows le "cache" dans son outil "Charmap" où il n'est accessible dans aucune catégorie, et n'apparait que si on choisit une police qui le mappe directement (rare et en fait inutile), et choisissant d'afficher "tous les caractères" en mode Unicode, et il faut le chercher alors à sa position U+202F. L'outil "Charmap" a de nombreux bogues de classification jamais corrigés depuis longtemps malgré tous les signalements. Avec ça il n'a pas facilité la vie de ceux qui voulaient l'utiliser. Il aura fallu que ce soient les moteurs de rendu qui le prennent en charge (puisqu'il a été informellement décidé qu'il était vain d'attendre qu'il soit "mappé" dans les polices alors que le comportement attendu était pourtant bien documenté. Les pratiques de l'éditique professionnelle n'ont jamais changé. Et même l'imprimerie nationale (avec qui on travaillait) nous demandait explicitement de traiter les NNBSP pour la mise en page et même de l'afficher explicitement sous forme balisée dans les outils de saisie: on utilisant une balise "[FINE]" entre crochets et en gras et rouge, traitée comme un seul caractère à la saisie, et ce "caractère" était saisi avec la simple touche [F2] du clavier PC. Et on peut facilement s'en convaincre: il suffit de regarder les rendus PDF générés par les textes publiés par l'Inprimerie nationale, et dans le JORF: les guillemets ont bien une fine à l'intérieur, et non une espace insécable (c'est encore plus visible avec la justification du texte puisque la fine n'est PAS justifiée et conserve sa taille, mais l'espace insécable l'est et peut s'élargir comme l'espace normale!)

Personnellement, je m’en moque que l’espace soit fine ou non.

Par contre je ne trouve pas normal que le changement soit fait de manière massive alors qu’il n’y a pas consensus.

Et ça me fatigue de devoir relire des tas de modifications juste pour une espace qui perd un quart de pixel de large. Faire le changement au passage, quand il y a un autre changement à faire, d’accord. Mais ne faire que ce changement là, c’est faire perdre du temps en relecture à tous les traducteurs de Translatewiki.net

Faire perdre du temps ? Tu sembles oublier qu'on a beaucoup de retard sur les relectures. Le plus gros du temps c'est moi qui le passe à faire remonter les statistiques car on a des tonnes de fautes oubliées. Maintenant cela se fait sur l'interface de relecture elle-même. S'il y a des problèmes d'interprétation c'est que la doc est incomplète sur certains messages. De plus ces messages sont eux-mêmes parfois changés dans la version anglaise et on les voit de façon isolée hors contexte qui n'est pas précisé. Fatalement si on modifie de façon synchrone cela va réapparaître à l'interface des rares qui suivent, ce n'est pas pour "tous" les traducteurs. J'ai vu des arguments assez suspects comme le fait que NNBSP ne serait pas pris en charge sur MacOS et iOS, alors que c'est dans les docs même de MacOS et iOS depuis des années. Apple a commis un bogue sur certaines versions anciennes de MacOS lors d'une mise à jour malheureuse quand il a modifié simultanément la prise en charge intrinsèque des espaces dans son moteur et supprimé les mappings de ses polices : c'était cohérent pour les nouvelles versions de MacOS (et n'a pas fait disparaître ces espaces), mais le problème est arivé sur les anciennes versions de MacOS et iOS quand le moteur n'a pas été modifié mais de nouvelles versions des polices sans les mappings ont été chargées : ces polices n'auraient pas du avoir ces mappings supprimés. Cela a été corrigé et ne concerne que les polices Apple boguées qui ont été corrigées à nouveau pour restaurer ces mappings afiun de restaurer la compatibilité. Et cela n'a jamais concerné les autres polices non système. C'est bien une anomalie temporaire avec les anciennes versions (qui étaient correctes à l'origine) mais il n'y a pas eru de changemetn de recommandations (car les NNBSP sont restées nécessaires notamment pour les fines insécables des séparateurs de groupes de chiffres dans les nombres qui avaient disparu; Apple l'a corrigé mais certains rares utilisateurs ont remis des versions incorrectes de ces polices Apple, en fait une seule police était concernée par l'anomalie).On ne peut pas se baser sur ces anomalies transitoires de certains OS et les manipulations hasardeuses des utilisateurs sur leur appareil. Les fines sont standards en faire partout des espaces normales est incorrect et non conforme pour tous les autres utilisateurs qui sont l'immense majorité, y compris les utilisateurs de MacOS et iOS d'appareils assez récents (concernant iOS, les appareils sont nécessazirement anciens et leur batterie à bout de course, il reste les vieilles versions de MacOS où il n'y a pas de raison de ne pas installer les polices corrigées (pas de problème de place). Alors c'est un problème pour 0,000001% des utilisateurs, la très grande majorité voit ce qui est attendu et décrit dans les standards, décrits dans les docs d'Apple, documentés dans les forums Apple, et cohérent avec ce qui est présent dans les bibliothèques communes (CLDR par exemple) utilisées dans des tas de logiciels (y compris d'Apple). Enfin quant à dire que "j'ignore" les commentaires, ce n'est pas vrai mais les commentaire ne sont pas là où il faut quand on doit travailler sur des centaines de message dans l'interface de traduction car on ne les voit pas du tout (on ne voit que les commentaires de dans la page de doc "/qqq". Cela peut aboutir à quelques lignes avec désaccord mais ce n'est rien à côté des centaines de lignes sur lesquelles il y a des corrections tout à fait appropriées. Les désaccords viennent de l'absence de contexte (et de défaut de documentation).

Non, tout est à jour et c’est la police par défaut qui est utilisée (qui ne peut pas être changée sur iOS de toute façon).

Safari est le deuxième navigateur en termes de parts de marché, ça ne concerne donc pas que « 0,000001% des utilisateurs ».

Merci de cesser les arguments fallacieux.

Il suffit pourtant de regarder les nombreux forums de support pour Apple, c'est un bogue connu et admis par Apple et décrit aussi comme tel dans les discussions du standard Unicode. Tout marchait bien avant MacOS 8, corrigé ensuite avec des notes d'Apple. Et sinon le bogue concerne certaines versions d'iOS anciennes aussi. C'est Apple qui s'est planté et ne formate plus les nombres correctement à cause de ça. NNBSP est là depuis longtemps et s'il est invisible sur certains appareils c'est une minorité pas à jour avec les correctifs mais ça ne rend rien d'illisible et il est même préférable de ne rien voir que de voir une espace trop grande. Quant au fait de ne pas pouvoir changer de police c'est faux dans un navigateur même sur mobile.

Sinon encore une fois tu choisis le ton agressif avec un terme comme "fallacieux", plein de mauvaises intentions.

> NBSP (U+00A0) n'est plus recommandé QUE comme repli au cas ou NNBSP (U+202F) ne peut pas être utilisé pour des raisons techniques

> c'est un bogue connu et admis par Apple

On est donc bien dans le cas des limitations techniques (que ce soit une limite inhérente à une architecture, un navigateur ou une mauvaise configuration par défaut ne change pas grand chose). Et les super-logiciels dont tu parles remplaceront automatiquement ces espaces par des espaces fines^^.