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