Re: [typo] chiffres anciens et e supérieur

[Thierry Bouche <thierry.bouche@xxxxxxxxxxxxxxx>]

Le dimanche 6 juillet 2003 à 23:53:45, Thomas Linard écrivit :


TB>> j'espère que « beaucoup simplifié le code » !?

TL> - sub est un raccourci pour substitute
TL> - three est le nom PostScript du chiffre trois
TL> - d est le nom PostScript du d bas de casse
TL> - le fait de marquer d par ' indique que c'est seulement ce glyphe qui
TL>   est concerné par la substitution
TL> - dsuperior est le nom PostScript traditionnel du d supérieur

jusque là, j'avais intuité bon.

TL> Donc la phrase peut être traduite par :
TL> « Quand on a la suite « 3d », remplacer le d par un d supérieur. »

c'est précisément ça qui me gêne : l'abréviation de third est 3rd plutôt
que 3d, on ?


TB>> TL>  Ça peux bien sûr changer si la police s'améliore.

d'ailleurs, ça aussi, ça me gêne : ça veut dire qu'un texte fait par
quelqu'un qui a la version x d'une police sera vu différemment par
quelqu'un ayant la version x+1. Et que la modification en question peut
casser la marche éditoriale de celui qui l'a produit !

Pour les abréviations, je suis à peu près sûr d'avoir vu des éditeurs
américains préférer « 21st. » à « 21^st ». Si les _st_ de la première
version décollent tous seuls (en laissant le point au sol, qui n'a plus
de raison d'être !) il y a de quoi mécontenter pas mal de monde. (J.-F.
Roberts dira si mon exemple est complètement idiot, je suppose.)


TB>> damn. Mais est-il bien raisonnable que ce genre de joyeusetés soit
TB>> pris en charge par la police ??

TL> Unicode ne se conçoit pas sans protocole de niveau supérieur : une fois
TL> qu'on a décidé d'exclure des glyphes du codage Unicode, il est bon
TL> d'avoir un standard pour atteindre facilement ces glyphes.

c'est évident.

TL> Les technologies qui ont émergé (OpenType, AAT, Graphite) se fondent
TL> beaucoup sur la police plutôt que sur le logiciel de composition.

c'est étonnant : j'ai compris qu'il y avait certaines choses qui sont
appliquées autoritairement dans un contexte langue+script, et d'autres
qui doivent être demandées par l'utilisateur. Je trouve qu'il y a de
plus en plus de choses pour lesquelles il y a trop d'interfaces et trop
d'options différentes (exemple typique : exposants/supérieures *
programme/police): un système de saisie évolué fait des
substitutions ou des corrections dans le dos de l'utilisateur, du coup,
ce que voit la police n'est pas forcément ce qu'on a saisi. Si la police
modifie à nouveau la saisie de son propre chef, ça va pas être de la
tarte à contrôler ! En fait, le caractère Unicode qui tend à avoir le
plus la cote, c'est « graphème joiner », qui va être la seule façon
invisible de casser ces automatismes, et bonjour le respect du texte
source...


TB>> À la limite, si je tape 1er dans word,
TB>> il va me mettre _er_ en exposant, et si une police OT pouvait
TB>> intercepter ça et le remettre en supérieures, pourquoi pas, mais
TB>> visiblement c'est pas ça qu'est prévu !

TL>     sub one e' r by esuperior;
TL>     sub one esuperior r' by rsuperior;

TL> La preuve que c'est possible et prévu... mais Adobe et Microsoft ne
TL> l'ont pas encore fait.

Ce que je voulais dire, c'est que dans ce cas, le flot de caractères
serait plutôt : one, e exposant (même police mais corps différent et
parangonnage), r exposant ; je ne suis pas certain que ces substitutions
s'appliquent quand les corps sont différents (ce qui m'inquiéterait à
nouveau un peu...).




 Thierry Bouche