lp-l10n-fr team mailing list archive

[Nicolas Delvaux <nicolas.delvaux@xxxxxxx>]

Salut !


> Bonne lecture !

Tu devrais écrire des livres tu sais ^^

Bien, je pense avoir compris.
À priori il faudrait donc employer des nnbsp partout et remonter les
bugs de rendu éventuels vers le moteur de rendu incriminé.

Comme tu l'as peut-être vu, j'ai soumis un patch pour rajouter un tag
« [thinsp] » et, en guise de nnbsp, un tag « [nbthin] » (oui, j'ai pensé
qu'il y aurait trop de risques de confusions entre « [nbsp] » et
« [nnbsp] »).
Après réflexion, même si « [fine] » aurait été mieux pour nous, il faut
être cohérent : Launchpad est intégralement en anglais (et ce n'est pas
près de changer à priori) donc bon, notre « [fine] » aurait été un peu
hors sujet.
Déjà que les mots anglais que l'on emploi au milieu d'une conversation
française sont un peu destroy... Et bien idem dans l'autre sens
(AMHA). ;-)

Et sinon, concernant l'emploi de nnbsp, j'ai trouvé plusieurs versions
différentes.
Par exemple, regarde les références de cette page :
http://traduc.org/gnomefr/Typographie

Certains veulent des espaces insécables « simple » entre les guillemets,
d'autres ne veulent une nnbsp que devant un point-virgule...
En pratique j'ai l'impression qu'il n'y a pas vraiment de règle ferme et
définitive.
Mais on pourrait par exemple décréter que, dans le groupe lp-l10n-fr, on
utilise exclusivement des nnbsp (donc, peut-être, des [nbthin] ;-)) sous
le prétexte que c'est plus simple... et que je trouve ça plus joli. 

Ça vous va tous le monde ?
(bien entendu il faudra attendre que le tag nécessaire arrive dans
Launchpad)


Bonne soirée,
Nicolas


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

Attachment: face-wink.png
Description: PNG image