Re: [2] I.1.3 Support multilingue (b)

[Michel Bujardet <mickie@xxxxxxxxxxxx>]

>Bon, je ne suis pas un fanatique de WorldScript, je sais qu'il existe un
>système équivalent sous Fenêtres? (mais nettement moins bien, à ce que j'en
>sais) et qu'il est prévu quelque chose dans OpenType (Uniscribe), je serais
>d'ailleurs très intéressé à échanger des informations sur ces systèmes, si
>certains en ont l'expérience ici.
>L'important, dans tout ça, c'est qu'on ait une interface correcte entre
>Unicode et le clavier.

Windows 95/98 a en effet un système équivalent à WorldScript qui fonctionne
plutôt bien. Encore qu'il ne soit pas possible, comme sur Mac, de créer des
claviers. Probablement parce que Windows supporte plus que les polices 8
bits habituelles.

Le support multilanguage comporte un nombre impressionnant de langues avec
les systèmes d'écritures romain, cyrillique et grec. Avec les claviers
idoines. Les polices natives du système sont multilingues, Unicode 16 bits
(pratiquement, avec quelques limitations). Lorsqu'elles sont utilisées par
les applications, elles présentent les scripts appropriés : Ouest,
Baltique, Est-européen, Cyrillique, Grec en 8 bits, avec support des
imprimantes et de la pluspart des applications anciennes. On peut aussi
utiliser les polices aux standards code-page habituels, CP-1250, 1251, etc.
qui sont alors reconnues par le système de la même manière. Et qui
fonctionnent avec toutes les applications, y compris les plus anciennes.
C'est là qu'est le problème : des applications plus modernes
fonctionneraient probablement parfaitement avec des polices Unicode, mais
les systèmes doivent rester compatibles avec les applications existantes.

Tout cela est fort bien fait, et j'avoue que vu du côté du développeur de
polices de caractères, semble fonctionner impeccablement.

Les claviers sont très intelligemment intégrés aux applications. Par
exemple, dans un même document où l'on aurait entré du français, du russe
et du grec dans différents paragraphes, le clavier correspondant est
automatiquement activé lorsqu'on parcours le texte avec le curseur.

J'imagine qu'Apple devrait proposer quelque chose du même genre dans le
cadre de son support Unicode. Cela étant, cela risque de changer quelque
peu la donne du côté du support des claviers. Si un système de polices
Unicode est utilisé, avec des scripts qui présentent aux applications et
aux imprimantes des pages restant compatibles avec les encodages 8 bits
actuels, le clavier devra devenir plus intelligent. Par exemple, le clavier
russe devra comporter l'information correspondant au script nécessaire
(Cyrillique), et chaque touche devra générer non pas simplement un code
ascii, mais une requête pour un glyphe Unicode, que le système ira chercher
selon le cas dans la page Unicode appropriée, ou dans le jeu de caractères
en encodage Apple 8 bit actuel. Du moins, si Apple envisage de conserver le
support des polices WorldScript actuelles, ce qui semble vraisemblable.

D'une manière générale, ce qu'ont fait les gens de Windows semble plus ou
moins inévitable, si Apple veut supporter des polices 16 bits sans pour
autant jeter aux orties tout ce qui a été fait en polices 8 bits. Et cela
comprend pas mal d'applications.

Il est intéressant en tous cas de voir que tes préoccupations recoupent
exactement ce que semblent avoir rencontrés les gens de Windows. Unicode
seul ne resoud pas tout, loin s'en faut. Les claviers non plus. Et le
système d'écriture doit de plus en plus incorporer des règles
d'intelligence...

Enorme tâche !