Re[2]: [typo] Unicode et autres - police expert

[Thomas Linard <thomas.linard@xxxxxxx>]

Bonjour Thierry Bouche <thierry.bouche@xxxxxxxxxxxxxxx>,

Le 2003-02-17 11:09:18, vous avez écrit :

TB> Si on reprend tout avec la définition « un caractère, c'est
TB> ce qui constitue un fichier RTF », alors tout devient beaucoup plus
TB> clair.  (cf. « il a fallu inclure les dingbats parce que de nombreux
TB> documents les utilisaient comme des caractères » donc la notion
TB> unicodienne de caractère a préexisté à unicode : elle a été définie par
TB> les traitements de texte. Si _x_ docs utilisent les fleurons de Caslon
TB> en disant « sélectionner la police Caslon Ornaments, imprimer
TB> 123454321 », alors les fleurons 1, 2, 3, 4, 5 de Caslon Ornaments sont
TB> des caractères.)

Qui a jamais prétendu qu'Unicode était comme un jardin à la française ?
ou comme un lieu saint interdit aux infidèles ? Unicode a une théorie,
valable pour tous ceux qui feront l'effort de s'y adapter, et une
pratique, valable pour les fossiles (en d'autres termes, mon point 1 et
mon point 2).

TB> TL> Pourtant, cette distinction a une valeur opératoire. Ne nous interdisons pas
TB> TL> de comparer des techniques différentes et prenons l'exemple d'InDesign 2
TB> TL> et d'une police OpenType, Adobe Caflisch Script Pro. En utilisant cette
TB> TL> police sous un InDesign bien réglé, on va rapidement générer des
TB> TL> dizaines de ligatures. Pourtant, aucune ne va gêner le correcteur
TB> TL> orthographique et grammatical ou le moteur de césure & justification, ni
TB> TL> rendre impossible la recherche et le remplacement automatique de mots.
TB> TL> Et ceci grâce à une distinction entre caractères et glyphes, rendue
TB> TL> possible par Unicode + OpenType.
TB> 
TB> unicode n'a rien à voir avec ça. Disons que chez adobe, il existe une
TB> version opératoire du paradigme caractère/glyphe : un glyphe est une
TB> classe d'oeils qui peuvent être définis dans une police ; un caractère
TB> est une classe de glyphes. on exprime ces relations d'équivalence de
TB> façon très simple (adobe glyph list -- du point de vue d'adobe, un glyphe
TB> est avant tout un _nom_, un caractère un numéro, un oeil une chaîne de
TB> commande CFF) : a, a.swash et a.final sont trois glyphes associés au
TB> même caractère a. Dès lors, la chaîne de caractères « akapa » pourra
TB> être imprimée à l'aide de la chaîne de glyphes « {a.swash}kap{a.final} »
TB> du moment que le programme utilisé a le bon modèle caractère/glyphe et
TB> la bonne façon d'analyser les noms de glyphes.

Pas exactement. L'AGL n'est gardée que pour des raisons de compatibilité
(eux aussi !). Voici ce que disait Read Roberts d'Adobe en novembre sur
la liste OpenType :

« The AGL is relevant only to name-keyed fonts. It is not relevant to
CID -keyed fonts.

TrueType and OpenType/TTF fonts are not required to carry glyph
names, and can indeed use a format 3 post table.

[...]

The purpose of the AGL is to state rules for applications that need
to search text in the case where the Unicode cmap info is not
available (as can happen in some cases when  PDF's are made from a
PostScript printer file), or when the glyph in question has no
corresponding Unicode character. In these cases, the only clue about
a glyph's semantics can be the glyph name. At the moment, I suspect
that this usage is limited to Acrobat and a few other Adobe apps,
when dealing with PDF  and PostScript files .  We hope others will
also use these rules in the future.  However, searchability on the
Web of PDF documents is a significant usage for many document
producers.

Most PDF production environments will do the right thing by glyphs
with a correct Unicode value, whether the AGL is used or not.  The
AGL naming rules are most important for glyph variants that have the
same semantics as a another glyph which does have corresponding
Unicode character, such as one.oldstyle. Fonts which have such glyph
variants, whether TTF or CFF-based, should provide names covered by
the AGL naming rules in order to enable the same PDF searching
functionality.

The AGL is obviously not the best way to make documents searchable.
We would much rather see that all documents which use typographic
layout features  keep a representation of the underlying text as
(Unicode characters + layout features), so that the AGL rules would
be come unnecessary. However, that happy state is clearly a long way
off. »

En clair : InDesign sait gérer tous les glyphes de Palatino Linotype,
qui n'a pas été conçue en référence à l'AGL.

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

Non, je parlais bien d'Unicode : il aurait été bien plus accommodant à
la logique de TeX de faire un codage d'où aucun glyphe n'aurait été
exclu.

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

« Unicode n'est pas adapté à mon logiciel favori » a légèrement moins de
poids qu'une affirmation comme « Unicode est un mauvais standard », non ?

J'espère pour vous en tout cas que Donald E. Knuth * est un athée
militant, sinon, quelle déception !

-- 
Cordialement,
 Thomas Linard


* Créateur de TeX.