lp-l10n-fr team mailing list archive

[verdy_p <verdy_p@xxxxxxxxxx>]

"Nicolas Delvaux" 
> ps : Laissons les THINSP de côté pour le moment, ils me semblent avoir
> moins d'importance.

Bonne lecture !

Ce n'est pas si simple: THINSP est présent dans Unicode et ISO/IEC 10646 depuis TRES longtemps, ce qui explique 
qu'ile soit si largement supporté dans nombre de polices même sur des systèmes déjà très anciens (comme Windows 95 
qui en disposait déjà dans ses premières polices TrueType par défaut pour le web comme Arial et Times New Roman).

THINSP était là à la demande des imprimeurs (qui de leur côté ne se souciaient guère du fait que ce caractère était 
sécable ou non, puisque concernant la mise en page, il n'était pas encore envisagé que celle-ci puisse varier en 
fonction du moteur de rendu utilisé, et de fait ils contrôlait la totalité de la mise en page, ce qui n'est pas le 
cas sur le web pour des raisons d'accessibilité et de tailles d'écran différentes.)

NNBSP est un ajout encore récent dans Unicode 4.1 (postérieur à la conception des polices souvent utilisées), afin 
d'apporter une version insécable de THINSP. Les polices sont supposées "mapper" ce caractère exactement de la même 
façon que THINSP, mais nombre de polices l'oublient car NNBSP n'est finalement utilisée pratiquement qu'en français, 
et les typographes concepteurs de polices ne connaissent que la typographie anglophone usuelle.

Mais cet ajout n'est même pas nécessaire au HTML qui possède d'autres moyens pour contrôler l'insécabilité, 
notamment grace à à la propriété de style CSS "white-space: nowrap", ou bien grâce à l'ancienne balise texte 
insécable qu'on trouvait sur certaines implémentations de HTML4 et qui a été dépréciée on ne sait pas trop 
pourquoi, alors que les documents devraient éviter dans le corps du texte l'usage de l'attribut HTML style, au 
profit plutôt d'un balisage par classe et l'utilisation de balises sémantiques.

Les typographes anglophones (y compris les plus connus comme ceux qui travaillaient pour Monotype ou Adobe) 
méconnaissaient la typographie traditionnelle anglaise qui faisait aussi référence à ces fines insécables anglaises 
(aujourd'hui oubliées depuis que les dactylographes anglophones on décidé de supprimer la fine insécable dans les 
nombres et autour des ponctuations, alors que les dactylographes francophones ont décider de forcer au minimum 
l'affichage d'une espace puisqu'il n'utilisent pas la virgule mais une fine pour séparer les milliers) ! Tout 
d'abord parce que leurs plus nombreux clients ont d'abord été tous anglophones !!!

Il y a une raison à cela : la fine insécable anglaise recommandait une valeur minimale de 1/8 em (pas pour séparer 
les groupes de chiffres puisqu'ils utilisent la virgule), alors que la fine française recommandait 1/6 em (pour 
obtenir une séparation suffisante des groupes de chiffres), les deux typographies traditionnelles indiquant aussi un 
maximum de 1/4 em.

Quand la dactylographie est arrivée (à chasse fixe), il était impossible de rester entre les deux bornes 
traditionelles :

- Les dactylographes anglophones ont donc décidé de supprimer leur fine autour des ponctuations (qui était de toute 
façon très peu visible et souvent incorporée dans la chasse des ponctuations dans les polices de caractères à chasse 
variable utilisées par les imprimeurs)

- Les dactylographes francophones ont en revanche fait le choix opposé avec leur fine pour s'asssurer qu'elle serait 
bien représentée. Le problème aujourd'hui est qu'on emploie des polices de caractères à chasse variable qui incluent 
maintenant le supplément de chasse intégré à droite des ponctuations anglaises (le point, la virgule, le point-
virgule). Et du coup l'espace insécable standard (d'une valeur de 1/4 em) est beaucoup TROP LARGE en français.

Ces règles **dactylographiques** avaient du sens au temps des machines à écrire et premières imprimantes et consoles 
de texte (à cause de la limitation technique à des polices de chasse fixe uniquement). Elles sont devenues 
totalement obsolètes depuis qu'on est revenu aux polices à chasse variable.

Et donc on a vu revenir les fines dans les documents anglophones soignés (cependant elles sont implicites dans les 
polices de caractères à chasse variable conçues pour des anglophones, sans qu'il soit nécessaire de les coder), et 
les fines anglaises sont donc d'un emploi rarissime.

Quand THINSP a été codé dans ISO 10646, on avait encore assez peu d'utilisation des polices TrueType à chasse 
variable : il a été oublié pourtant de le rendre insécable.

Les francophones râlaient depuis assez longtemps pour qu'une version insécable soit ajoutée (il a fallu de long 
débats aux sein des comités ISO qui jugeaient que l'insécabilité n'était pas un attribut nécessaire, mais il aura 
fallu qu'Unicode indique dans ses algorithmes et propriétés que THINSP était bel et bien sécable, pour satisfaire 
les rares usages anglophones et rester compatible avec les polices et moteurs de rendu existants). Ils ont obtenu 
NNBSP, mais toutes les polices de caractères déjà distribuées n'ont pas été mises à jour afin de mapper NNBSP avec 
le même "glyphe" et la même chasse que THINSP : l'effet produit alors, si le caractère n'était pas mappé était un 
affreux rectangle ou un point d'interrogation.

Si on peut commencer à utiliser NNBSP maintenant, ce n'est pas parce que les polices de caractères ont changé. C'est 
parce que les moteurs de rendus, pour HTML ou autres, font d'eux-même la substitution de NNBSP par THINSP quand le 
premier est absent d'une police mais le second y est mappé, afin de déterminer la largeur à appliquer conformément à 
la conception de la police ! Et ces mêmes moteurs de rendu respectent les propriétés d'insécabilité des caractères 
codés Unicode, pour leur calcul de la mise en page (donc la substitution de NNBSP par THINSP reste transparente et 
ne nuit pas à la mise en page).

C'est en ce sens que je citait THINSP : il est principalement destiné maintenant pour servir de substitution 
automatique par les moteurs de rendus, afin de rester compatible avec les anciennes polices toujours très largement 
utilisées et dans lesquelles NNBSP ne pouvait pas être présent (puisqu'il n'existait pas encore dans Unicode ou ISO 
10646 au moment où ces polices ont été conçues, et que nombre de typographes ont encore oublié de le mapper dans les 
versions ultérieures de leurs polices, leurs clients étant essentiellement anglophones et ne leur ayant pas signalé 
l'anomalie).

Ce petit rappel historique (assez sommaire) permet de comprendre certaines choses. Dans les faits l'histoire est 
encore plus compliquée à cause de la complexité des conventions typographiques utilisées au sein même de la même 
langue, et des conventions parfois contradictoires entre elles (une complexité qui a été masquée uniquement au temps 
de la dactylographie qui n'était qu'une ébauche très basique de typographie mais où ce genre de « détails », y 
compris l'insécabilité, était totalement non pris en compte).

Mais pourtant ça explique pourquoi les anglophones se sont mis à taper deux espaces après un point en fin de phrase 
(une convention dactylographique essayant d'imiter une fine anglaise après le point, suivie d'une espace normale 
justifiable)

----

Note:

THINSP et NNBSP sont tous les deux non « justifiables ». Ce qui veut dire qu'à moins qu'on utilise l'ajustement de 
chasse entre tous les caractères d'une ligne pour la justifier, seuls les espaces « justifiables » séparant les mots 
(qu’ils soient sécables ou non) sont réajustés en largeur pour remplir une ligne et aligner les mots sur les deux 
marges.

Si l’ajustement des seuls blancs séparateur produit des espacements trop importants rendant la lecture des lignes de 
texte difficile, généralement l’ajustement de l'approche entre tous les caractères de la ligne (sauf ceux qui sont 
ligaturés) pourra intervenir pour distribuer partout l’excès d’espacement entre les mots produit par la 
justification simple (et pourra donc augmenter la chasse par défaut de tous les glyphes, y compris les fines 
insécables françaises ou les vieilles fines traditionnelles anglaises, utilisées toutes les deux autour des 
ponctuations ou comme séparateurs de groupes de chiffres).

Et cet ajustement de chasse interviendra alors sur TOUS les caractères et espaces, qu'ils soient sécables ou non, 
justifiables ou non... SAUF ceux qui précisent une chasse ABSOLUE comme l’espace demi-cadratin 1/2 em (différent de 
l'espace normale qui est de taille relative, sécable et justifiable) ou l’espace quart de cadratin 1/4 em (différent 
lui aussi de la fine qui est aussi de taille relative, sécable, et non justifiable pr défaut sauf en cas de 
justification nécessitant l'interpolation des chasses relatives entre les glyphes) : ces espaces à chasse absolue 
sont codés en plus dans Unicode et ISO 10646 depuis longtemps à la demande des imprimeurs, mais sont pourtant eux 
aussi sécables !.

Avec tout ça il nous reste une terminologie délicate de toutes ces espaces :

- sécable ou non

- justifiable ou de chasse « fixe » (elle-même soit de chasse « ajustable », soit de chasse « absolue »)

Et ça permet de comprendre pourquoi il y en a tant de variantes codées dans Unicode/ISO 10646. NNBSP n'est qu'un de 
plus parmi eux pour satisfaire les francophones.

Les Asiatiques extrême-orientaux ont eu droit au codage des espaces à chasse fixe absolue, dont ceux de valeur 
plein-cadratin 1 em ou 2 em, utilisés notamment avec les écritures sinographique et coréenne hangûl, qui préfèrent 
très nettement les chasses fixes absolues et n’admettent pas qu’on modifie les approches entre les sinogrammes ou 
syllabes composées coréennes (pour des raisons de lisibilité de glyphes déjà complexes à analyser visuellement). En 
effet, dans ces écritures, TOUS les graphèmes sont sécables (même en milieu de mot car ils représentent presque sans 
exception des syllabes complètes, sans qu'il soit besoin de faire appel à un tiret de césure comme dans l'écriture 
latine) puisque la plupart des mots sont monosyllabiques et se transcrivent avec un seul sinogramme ou un seul 
graphème syllabique coréen, sans même aucune séparation par une espace entre les mots ; les espaces ne leur servent 
qu’à séparer les phrases ou les vers, mais doivent s'aligner avec la grille des sinogrammes et syllabes (toutes de 
valeur plein-cadratin) ; même leur ponctuation est élargie (comme le point ou la virgule) afin d'entrer dans la 
grille à chasse fixe absolue.

Cela va même plus loin pour eux car l'unité de largeur de leurs espaces est le « quad » (généralement un carré dans 
lequel s'inscrivent parfaitement tous les sinogrammes ou toutes les syllabes coréennes afin que leurs œils soient 
eux-aussi de taille fixe et pas seulement le corps et la chasse), alors que dans l’écriture latine, la largeur de 1 
cadratin ne correspond pas nécessairement à la hauteur de 1 cadratin, et peut varier donc avec l'interlignage, ce 
qui n’est pas admis dans l'écriture sinographique. Pour les Asiatiques, la largeur des espaces utilise l'unité 
principale qui est basé sur la hauteur du corps, contrairement cadratin horizontal.

----

Conclusion : (ouf !)

Tout n'est pas simple en typographie. OK laissons THINSP pour l'usage anglophone ou les substitutions automatiques 
par les moteurs de rendus devant prendre en charge la typographie française avec des polices très majoritairement 
conçues par (et trop souvent uniquement pour) les anglophones.

Mais le bon caractère pour nous est bien NNBSP et il a été codé sur la demande expresse et réitérée des typographes 
francophones qui ont eu bien du mal à convaincre les typographes anglophones pour qu'ils respectent leur demande et 
prennent en compte le besoin d'une fine réellement insécable.

Si vous utilisez des distributions récentes de Windows, Linux, or MacOSX, les polices fournies (et utilisées comme 
polices d'usage général par défaut) contiennent maintenant un mappage correct de NNBSP (ce n'est pas encore le cas 
dans des polices de style plus spécifique, alors que nombre de ces polices ont pourtant très souvent un THINSP, tout 
bonnement car elles n'ont pas été mises à jour depuis qu'elles ont été créées la première fois et sont encore 
livrées car elles sont souvent référencées dans de nombreux documents !).

La solution pour nous vient non pas des polices (dont il est impossible de les modifier et les distribuer sans 
violer un droit ou nécessiter une coûteuse licence), mais du moteur de rendu qu'il est facile de mettre à jour (ne 
serait-ce qu'avec les mises à jour de sécurité des navigateurs et des lecteurs de médias).

Bonne vacances !

Philippe.