"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. _______________________________________________ Mailing list: https://launchpad.net/~lp-l10n-fr Post to : lp-l10n-fr@lists.launchpad.net Unsubscribe : https://launchpad.net/~lp-l10n-fr More help : https://help.launchpad.net/ListHelp
