Unicode

[Olivier RANDIER <orandier@xxxxxxxxxxx>]

J'ai jeté un oeil sur les tableaux de Patrick Andries. Je partage l'avis
général sur la qualité du travail accompli. Bravo, quel courage !
Maintenant, je partage aussi les réserves de Lacroux sur les connotations
idéologiques des choix d'Unicode et sur sa terminologie, que la traduction
française tente d'améliorer.

Puisque JiPé fait son timide, je vais m'y coller un peu.
Quelques remarques d'ordre général, d'abord :
* L'orientation « tout caractère » pose des problèmes majeurs, on l'a déjà
dit. En fait, une orientation « tout glyphe » en pose d'autres. Il aurait
sans doute été plus rationnel de combiner les deux approches à un peu de
bon sens, qui, visiblement, a manqué cruellement. D'un autre côté, si l'on
prône une approche « tout caractère », il faudrait être cohérent avec. Il y
a dans Unicode plein de choses qui ne sont pas des caractères (parfois même
pas des glyphes), et la terminologie se contente souvent d'en décrire
l'aspect visuel (donc le glyphe).
Prenons pour exemple la lettre A. Cette lettre a pour homoglyphe l'alpha
majuscule (A) et le A cyrillique. Du point de vue caractère, il est évident
qu'on a besoin de les distinguer, puisque la bas de casse du A est le a,
alors celle de l'alpha majuscule est l'alpha bas de casse, différent de
notre a. Du point de vue glyphe, pas contre, il est évident que c'est le
même signe.
Cela aboutit à multiplier les redondances dans les fontes. Cela aboutit
aussi à quelques définitions surréalistes.

* Majuscules/minuscules : Lacroux l'a fait remarquer, petite majuscule est
un non-sens. Je reste persuadé qu'il aurait mieux valu s'en tenir à
capitales/bas de casse, même si le dernier terme n'est pas très parlant
pour la plupart.
On remercie quand même les traducteurs de nous avoir épargner les _small
letter_ (petites lettres) de la version anglaise ! C'est déjà un gros
progrès.
L'orientation caractère d'Unicode a conduit à ignorer les petites caps dans
Unicode, alors même qu'on y trouve les chiffres petites capitales et des
caractères API petites majuscules (sic). Mais, du point de vue pratique, il
est beaucoup plus difficile de programmer un changement de fonte qu'une
translittération. Intégrer les petites caps faciliterait le travail des
concepteurs de logiciels et des utilisateurs. Problème similaire pour les
chiffres bas de casse.

* Intégration de dingbats et autres signes fantaisie. En totale
contradiction avec l'approche caractère, on trouve dans le codage des
fontes complètes de dingbats, avec toutes les variantes. Par exemple,
prévoir une case à cocher est pratique pour les formulaires. Mais une case
à cocher reste une case à cocher, que son ombre portée soit en haut ou en
bas ! Si l'on commence à vouloir intégrer toutes les fontes de
pictogrammes, vignettes, zigouigouis communicants et autres, il va falloir
enlever des langues complètes d'Unicode...

Olivier RANDIER -- Experluette		mailto:orandier@xxxxxxxxxxx
	http://technopole.le-village.com/Experluette/index.html
Experluette : typographie et technologie de composition. L'Hypercasse
(projet de base de données typographique), l'Outil (ouvroir de typographie
illustrative).