Re: [typo] Unicode et autres - police expert

[Thierry Bouche <thierry.bouche@xxxxxxxxxxxxxxx>]

Le lundi 17 février 2003 à 00:12:38, Thomas Linard écrivit :


TL> Certes, certes, fond et forme, c'est un peu trop rapide comme définition.
TL> Et, bien sûr, nous ne sommes pas dans un monde néo-platonicien où les
TL> plus sages d'entre nous pourraient contempler les entités Caractères :
TL> quand on creuse un peu, la distinction entre caractères et glyphes
TL> apparaît artificielle.

disons que telle qu'elle est posée par unicode, comme un de ses mythes
fondateurs, elle est non seulement artificielle, elle est différente de
la façon dont ils s'en servent. Olivier et d'autres se sont mis à
critiquer unicode à partir de ces définitions alors qu'elles sont sans
importance. Si on reprend tout avec la définition « un caractère, c'est
ce qui constitue un fichier RTF », alors tout devient beaucoup plus
clair.  (cf. « il a fallu inclure les dingbats parce que de nombreux
documents les utilisaient comme des caractères » donc la notion
unicodienne de caractère a préexisté à unicode : elle a été définie par
les traitements de texte. Si _x_ docs utilisent les fleurons de Caslon
en disant « sélectionner la police Caslon Ornaments, imprimer
123454321 », alors les fleurons 1, 2, 3, 4, 5 de Caslon Ornaments sont
des caractères.)

TL> Après tout, la seule chose qui existe vraiment,
TL> c'est les glyphes.

Même pas. De toute façon, la notion de glyphe est aussi mal définie (en
fait, elle est uniquement introduite pour servir de repoussoir et bien
montrer qu'on ne saurait faire un codage de glyphes -- ah ah !)

Si on s'amuse à introduire Tex dans ce jeu-là, on pourrait penser que
les vieux utilisateurs de Tex savent de toute éternité ce qu'est un
texte balisé, un texte source faisant usage de caractères pour décrire
une version typographiée, etc. On s'attend donc à ce que les
utilisateurs de tex poussent des cris d'orfraie à l'idée qu'on banalise
leurs outils en les pervertissant. Pas partageux, les texards, en somme.

TL> Pourtant, cette distinction a une valeur opératoire. Ne nous interdisons pas
TL> de comparer des techniques différentes et prenons l'exemple d'InDesign 2
TL> et d'une police OpenType, Adobe Caflisch Script Pro. En utilisant cette
TL> police sous un InDesign bien réglé, on va rapidement générer des
TL> dizaines de ligatures. Pourtant, aucune ne va gêner le correcteur
TL> orthographique et grammatical ou le moteur de césure & justification, ni
TL> rendre impossible la recherche et le remplacement automatique de mots.
TL> Et ceci grâce à une distinction entre caractères et glyphes, rendue
TL> possible par Unicode + OpenType.

unicode n'a rien à voir avec ça. Disons que chez adobe, il existe une
version opératoire du paradigme caractère/glyphe : un glyphe est une
classe d'oeils qui peuvent être définis dans une police ; un caractère
est une classe de glyphes. on exprime ces relations d'équivalence de
façon très simple (adobe glyph list -- du point de vue d'adobe, un glyphe
est avant tout un _nom_, un caractère un numéro, un oeil une chaîne de
commande CFF) : a, a.swash et a.final sont trois glyphes associés au
même caractère a. Dès lors, la chaîne de caractères « akapa » pourra
être imprimée à l'aide de la chaîne de glyphes « {a.swash}kap{a.final} »
du moment que le programme utilisé a le bon modèle caractère/glyphe et
la bonne façon d'analyser les noms de glyphes.

Ce que je suis en train de dire, c'est que le bon modèle, c'est de
définir une liste (ouverte) de glyphes et une relation d'équivalence
entre eux. Si on cherche à définir le caractère ex nihilo, on sombre
dans toutes les aberrations que l'on est forcé de constater. La _bonne_
raison pour laquelle on pourrait préférer se libérer des glyphes, ce
serait justement si l'on était capables de faire directement de la
sémantique, sans référence à l'imprimé, mais nous n'en sommes
visiblement pas là.

TL> Presque tous les logiciels de mise en
TL> page pourraient bénéficier d'une telle approche. Sauf TeX et dérivés, et
TL> c'est là le hic. TeX a son propre système, et peut-être a-t-il eu besoin
TL> d'un codage étendu de glyphes, mais pas d'un codage qui choisit
TL> d'exclure des glyphes selon des critères relevant d'une logique qui lui
TL> est étrangère. D'où une insatisfaction des utilisateurs de TeX,

la logique source en clair, éditable, vérifiable, constitué de
caractères (avec la contrainte supplémentaire : uniquement ascii !)
existe depuis toujours en tex. S'il y a un conflit entre tex et ce que
vous décrivez, c'est pas avec unicode, c'est avec opentype (format de
métriques différent, séparation de ce qui se fait dans le programme et
dans la police différent aussi).

TL>  et des
TL> titres comme « Unicode et typographie, un amour impossible » : Unicode
TL> suppose « un protocole de niveau supérieur » (dixit Patrick Andries).

mmh, les questions posées par yannis portent justement sur le
dénominateur commun unicode : que peuvent les protocoles supérieurs
s'ils s'appuient sur des fondations bancales ?

TL> Non qu'avec un effort d'adaptation TeX ne puisse utiliser les glyphes
TL> contenus dans des polices OpenType ou AAT, mais je peux concevoir que ce
TL> n'est pas la solution idéale. Cela relativise quand même pas mal de
TL> critiques à l'encontre d'Unicode formulées par des utilisateurs de TeX.

je ne vois pas ce qui relativise ! j'ai dû rater un développement de
l'argutie !



 Thierry Bouche