[K2] I.1.3 Support multilingue (a)

[Olivier RANDIER <orandier@xxxxxxxxxxx>]

a) Unicode

On a déjà évoqué à plusieurs reprises Unicode et les simplifications qu'il
pourrait apporter à certains aspects de notre travail (translittérations,
substitutions de glyphes, etc). C'est dans le cadre du support multilingue
que ses avantages seront le plus évident.
Pour ma part, ma position est claire : même si Unicode est encore loin
d'être parfait (air connu), je n'échangerais pas un baril d'Unicode contre
deux barils d'ISO-Latin, fût-il neuf (9) ;-(
Notre futur logiciel de mise en pages idéal devra fonctionner en Unicode
natif, point barre.
Quitte à prévoir des "appauvrissements" à l'export et des conversions à
l'import.
Il faut faire tomber le bastion 8 bits (et je ne parle même pas du 7 bits).
Pas de quartier ! Monjoie ! Saint-(Jean)-Denis ! ;)

Ceci étant posé, Unicode ne résoud pas tout. Unicode est une norme qui ne
régit que les caractères (on s'en est assez plaint). Il reste à définir
l'interfaçage avec, d'une part les codes saisis au clavier et, d'autre
part, les divers systèmes de glyphes (c'est-à-dire les fontes).
Certes, cela n'est pas réellement du ressort de l'éditeur de logiciel, mais
il est difficile d'ignorer complètement le problème, et comme en plus on a
chez nous quelqu'un qui s'occupe d'un gestionnaire de fontes (ATM), autant
en profiter. On ne peut évidemment qu'effleurer le problème, mais je crois
qu'il y a quelques petites choses qui mérite d'être dites.
Concernant l'interfaçage Unicode/clavier, WorldScript me semble un bon
modèle de fonctionnement, comme je l'évoque dans la partie b. Toutefois, il
date d'avant Unicode, donc du 8 bits. Dans le cadre d'Unicode, la sélection
d'une langue devrait pointer non sur une fonte correspondante, mais vers le
sous-ensemble approprié d'Unicode.
Ce qui nous amène au gros morceau, l'interfaçage caractère/glyphe. Il me
semble, si j'ai bien tout compris, qu'on est train d'essayer, via les
"codepages", de morceler Unicode en fragments 8 bits, pour y faire coller
les fontes actuelles. C'est débile.
Certes, il y a bien des sous-ensembles logiques dans Unicode, mais, sauf
coup de chance, très peu d'entre eux rentreront dans 8 bits. Celui qui nous
concerne le plus, le latin (ou roman) comprend au moins 800 signes
(probablement beaucoup plus). La démarche devrait être plutôt de rassembler
des fontes pour correspondre à ces sous-ensembles.
Ce rôle pourrait, me semble-t-il, être dévolu au gestionnaire de fontes. On
pourrait ainsi rassembler des fontes au standard Mac-latin, Adobe expert,
Mac-CE, Adobe OSF, etc., pour constituer une "métafonte" (hi, hi !) qui
contiendrait enfin à peu près ce dont on a besoin. Objet qui serait
manipulé d'un seul tenant dans le logiciel de mise en pages. À nous alors
les substitutions automatiques (Unicode sait composer/décomposer un
digramme ou un trigramme).
Pour combler les manques d'Unicode (au hasard les petites caps), on
pourrait aussi affecter une série de glyphes à un caractère Unicode, afin
de gérer les glyphes alternatifs (fonte alternate). Avec une convention
bien gérée, ça devrait permettre de sélectionner un texte, de choisir
"petites caps" afin qu'il aille chercher le signe affecté à la position x
du caractère Unicode, alors que pour avoir les alternate, on irait chercher
la position y (s'il n'y a rien, on laisse le signe standard). Idem pour les
différentes casses de chiffres...
Combien de glyphes maxi pour un même caractère ? Ben, je verrais bien 256,
pour pouvoir utiliser des fontes genre fontes d'esperluettes (ou d'Euros)
en restant Unicodement correct...
Accessoirement, si un système de ce genre se mettait en place comme
standard, ça pourrait inciter les concepteurs d'Unicode à libérer un peu de
place en virant les 12 astérisques, les 25 versions de cases à cocher ou de
flèches qui n'ont rien à y faire...
Inversement, un même glyphe doit pouvoir être affecté à plusieurs
caractères, ça éviterait du travail inutile aux concepteurs de fontes,
merci pour eux.
Bien entendu, une partie du travail devrait pouvoir être fait
automatiquement, au moins pour les codages standard, mais on doit pouvoir
bidouiller ces propres tables de correspondances (comme pour les exemples
cités précédemment).
Ceci, combiné à la possibilité offerte par OpenType de conjuguer des
glyphes pour en créer de nouveaux, devrait permettre de résoudre pas mal de
nos problèmes actuels (fontes CE inexistantes, etc.).

P.S. : Et ce serait une bonne idée d'embaucher Günther Blashek, ce
bienfaiteur de l'humanité, pour qu'il nous concocte le PopChar
Unicode/WorldScript du prochain millénaire...

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