Thread history

From User talk:Verdy p
Viewing a history listing
Jump to navigation Jump to search
Time User Activity Comment
20:58, 8 December 2019 Trial (talk | contribs) New reply created (Reply to Espaces fines insécables entre les guillemets)
15:44, 2 December 2019 Verdy p (talk | contribs) New reply created (Reply to Espaces fines insécables entre les guillemets)
14:28, 2 December 2019 Thibaut120094 (talk | contribs) Comment text edited  
14:26, 2 December 2019 Thibaut120094 (talk | contribs) New reply created (Reply to Espaces fines insécables entre les guillemets)
13:59, 2 December 2019 Verdy p (talk | contribs) New reply created (Reply to Espaces fines insécables entre les guillemets)
00:47, 10 October 2019 Pols12 (talk | contribs) New reply created (Reply to Espaces fines insécables entre les guillemets)
18:07, 14 September 2019 Verdy p (talk | contribs) New reply created (Reply to Espaces fines insécables entre les guillemets)
13:14, 14 September 2019 Thibaut120094 (talk | contribs) Comment text edited  
13:03, 14 September 2019 Thibaut120094 (talk | contribs) New reply created (Reply to Espaces fines insécables entre les guillemets)
12:58, 14 September 2019 Verdy p (talk | contribs) New reply created (Reply to Espaces fines insécables entre les guillemets)
12:47, 14 September 2019 Thibaut120094 (talk | contribs) Comment text edited  
12:47, 14 September 2019 Thibaut120094 (talk | contribs) New reply created (Reply to Espaces fines insécables entre les guillemets)
12:28, 14 September 2019 Verdy p (talk | contribs) New reply created (Reply to Espaces fines insécables entre les guillemets)
12:08, 14 September 2019 Thibaut120094 (talk | contribs) Comment text edited  
12:01, 14 September 2019 Thibaut120094 (talk | contribs) Comment text edited  
12:00, 14 September 2019 Thibaut120094 (talk | contribs) Comment text edited  
11:53, 14 September 2019 Thibaut120094 (talk | contribs) New thread created  

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.

Thibaut120094 (talk)11:53, 14 September 2019

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).

Verdy p (talk)12:28, 14 September 2019

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).

Thibaut120094 (talk)12:47, 14 September 2019
 

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).

Verdy p (talk)12:58, 14 September 2019

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

Thibaut120094 (talk)13:03, 14 September 2019

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!)

Verdy p (talk)18:07, 14 September 2019

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

Pols12 (talk)00:47, 10 October 2019