[2] I.1.3 Support multilingue (b)

[Olivier RANDIER <orandier@xxxxxxxxxxx>]

b) WorldScript et équivalents

Jusqu'ici, le support multilingue des logiciels de P.A.O. tient de la pure
escroquerie.
En effet, depuis MacOS 7.1 (ça fait quand même un moment), les ressources
et les API permettant la composition multilingue sont intégrées au système,
et donc disponibles pour les développeurs. Or Adobe et Quark ont refusé de
les intégrer à leurs produits pour vendre leurs propres solutions à un prix
prohibitif. Résultat, WorldScript, une des technologies les plus
prometteuses d'Apple, périclite, alors que rien n'existe pour le moment
pour le remplacer efficacement. Quand on compare à ce qui s'est passé dans
d'autres domaines, avec QuickTime ou QuickDraw 3D, qui sont devenus des
standards multiplateformes grâce au soutien des éditeurs (et pour le plus
grand bénéfice des utilisateurs), il y a de quoi se bouffer les ongles de
rage.
Je peux admettre qu'on fasse payer un petit sus (petit, j'ai dit, pas 2000
balles par langue !), sous formes de modules optionnels de langues, pour le
développement des vérificateurs orthographiques, des algorithmes et
dictionnaires de césure spécifiques à chaque langue, mais il est, par
contre, inacceptable de ne pouvoir disposer, dans des logiciels de ce prix,
de fonctionnalités existants dans... SimpleText !
De même, je peux admettre des XTensions spéciales pour gérer les langues
idéographiques sur 2 octets (CJK), mais pas de devoir désactiver mon
système d'écriture cyrillique pour pouvoir composer du Russe sur XPress
(non Passport), à l'aide de ressources maison...
Donc, on doit pouvoir, au minimum, utiliser les ressources du système pour
composer au moins dans toutes les langues latines, grecques et cyrilliques
(tout ce qui se compose bêtement de gauche à droite). Pour les systèmes
d'écriture un peu plus complexes (ligatures contextuelles de l'arabe et des
langues indiennes, langues idéographiques...), on peut admettre que
certains problèmes de développement amène un léger surcoût (encore que).
Des modules additionnels optionnels pourront apporter dictionnaires et
algorithmes évolués nécessaires dans un cadre de production, mais, en aucun
cas, le logiciel "lite" ne devrait interdire de recourir aux ressources du
système pour composer trois lignes de japonais.
Donc :
-- Support intégral de WorldScript (ou équivalent),
-- Au minimum, dictionnaires et algorithmes et tout ce qui va bien pour
toutes les langues latines, le grec et le cyrillique,
-- Éventuellement, modules additionnels optionnels (qui peuvent être de
tierce partie) pour les langues complexes.

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.
De ce côté-là, WorldScript me semble insurpassable. Ce que je ne veux pas,
en tout cas, c'est devoir saisir des codes abscons à la Windows, genre
alt-197 ou pire #A6B7 (les codes hexa d'Unicode), pour obtenir un bête
alpha. Je ne veux pas non plus qu'on me balance tout ce qui sort de
l'ordinaire dans une table des symboles, parce qu'un tableau de 65 000
signes, ça rentre pas dans mon 17" !
Ce que je veux, c'est pouvoir continuer à faire ce que je fais à l'heure
actuelle, c'est-à-dire sélectionner la langue dans un menu, ce qui remappe
mon clavier, change la fonte de façon appropriée, modifie les critères de
tri, les séparateurs décimaux et de milliers, etc. Et les ressources ad hoc
doivent rester facilement éditables (elles pourraient même l'être plus),
pour que je puisse bidouiller mon clavier transliterré si les ressources
adaptées à mon Azerty français ne sont pas fournies. Bref, WorldScript
marche, et bien, je ne vois pas de raison d'en changer. Si en plus ça reste
compatible avec PopChar, c'est top !

Par contre, une chose qui serait importante dans ce contexte, ce serait de
pouvoir baliser les langues dans le texte, afin de pouvoir gérer les appels
aux dictionnaires, les C&J, etc., en fonction d'ycelles.

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).