Une extension de TeX incluant UNICODE et des filtres du type Lex

Cahiers

enberg

GUT GUT GUT

m UNE EXTENSION DE TEX INCLUANT UNICODE ET DES FILTRES DU TYPE LEX

P YannisHaralambous, JohnPlaice Cahiers GUTenberg, n20 (1995), p. 55-79.

<http://cahiers.gutenberg.eu.org/fitem?id=CG_1995___20_55_0>

© Association GUTenberg, 1995, tous droits réservés.

L’accès aux articles desCahiers GUTenberg (http://cahiers.gutenberg.eu.org/),

implique l’accord avec les conditions générales

d’utilisation (http://cahiers.gutenberg.eu.org/legal.html).

Toute utilisation commerciale ou impression systématique est constitutive d’une infraction pénale. Toute copie ou impression de ce fichier doit contenir la présente mention de copyright.

W , une extension de TEX incluant UNICODE et des filtres de type Lex

Yannis HARALAMBOUS^aet John PLAICE^b

Traduction franc¸aise d’Eric PICHERAL(CRI Rennes)

a187, rue Nationale ^bDe´partement d’Informatique 59800 Lille, France Universite´ Laval, Ste-Foy [email protected] Que´bec, Canada G1K 7P4

[email protected]

Re´sume´.Wcomprend un certain nombre d’extensions de TEX qui am ´eliorent ses possibilit ´es de traitement multilingue. On peut avoir plusieurs jeux de caract `eres en entr ´ee comme en sortie, et un nombre quelconque de codages internes. On peut d ´efinir des automates `a ´etats finis en utilisant une syntaxe `a la<sup>flex</sup>pour passer d’un codage `a l’autre.

Dans cet article, on pr ´esente `a la fois une introduction technique et quelques applications trait ´ees par l’impl ´ementation actuelle deW. Ces applications concernent des probl `emes de composition que TEX (et par cons ´equent aucun autre syst `eme connu des auteurs) ne sait r ´esoudre. Elles sont vari ´ees, depuis le traitement des fontes calligraphiques (Adobe Poetica) jusqu’ `a la simple composition du n ´earlandais, du portugais ou du turc, en passant par l’arabe avec ses voyelles, ou encore un cr ´enage correct du cambodgien.

On mentionne quelques probl `emes queWne sait pas r ´esoudre et qui sont des d ´efis pour de futures versions deW^.

Abstract. Wconsists of a series of extensions to TEX that improve its multilingual capabili- ties. It allows multiple input and output character sets, and will allow any number of internal encodings. Finite state automata can be defined, using a^flex-like syntax, to pass from one coding to another.

In this paper both a technical introduction and a few applications of the current implemen- tation ofWare given. The applications concern typesetting problems that cannot be solved by TEX (consequently, by no other typesetting system known to the authors). They cover a wide range, going from calligraphic script fonts (Adobe Poetica), to plain Dutch/Portuguese/Turkish typesetting, to vowelized Arabic, fully diacriticized scholarly Greek, or decently kerned Khmer.

A few problemsW^cannotsolve are mentioned, as challenges for futureW^versions.

Au d ´epart, l’id ´ee de base deWconsiste `a s ´eparer les trois principaux composants d’un syst `eme de composition :

Interface utilisateur — E´change d’information — Typographie

Ces composants ne sont pas clairement s ´epar ´es dans TEX, et cela cr ´ee de nombreux probl `emes quand il s’agit de traiter d’autres langues que l’anglais. Voici un exemple de

cette situation, signal ´ee dans [14] : pour composer le caract `ere cyrillique<sup>c</sup>en utilisant les macros et les polices de l’AMS (Soci ´et ´e Math ´ematique Am ´ericaine) [1], il faut saisir les codesASCIIts. La saisie detsfait partie de l’interface utilisateur de TEX. On ob- tient<sup>c</sup>gr ˆace au composant typographique de TEX. On n ´eglige le composant ´echange d’information : un texte cod ´e en KOI-8 ou enISO8859-5 ne peut ˆetre trait ´e directement en utilisant ce sch ´ema : il faut utiliser un pr ´e-traitement ou bien des caract `eres actifs pour la translit ´eration AMS. Mais l’algorithme de c ´esure — qui dans le cas de l’anglais d ´ecom- posera la ligature «» en «^f-i» — peut s ´eparer^cen^t-s, ce qui est inacceptable. Cela survient parce que la c ´esure (qui est un processus appartenant clairement au composant typographique de TEX) est activ ´ee alors que les donn ´ees sont encore cod ´ees de la m ˆeme fac¸on que dans l’interface utilisateur :^cn’est pas encore reconnu comme une entit ´e in- divisible, TEX ne connaıˆt que la paire de codes^ASCIIts^.

Avec W, on ´evite ce probl `eme ; de plus, on peut utiliser n’importe quel codage d’ ´echange pour saisir le texte, ce qui est possible parce que des processus s ´epar ´es convertissent les flux d’information entre les trois composants : dans l’interface utili- sateur, on peut tr `es bien taper les caract `erestsqui seront convertis en un caract `ere

ISO10646/UNICODEde code0x0446⁽CYRILLIC SMALL LETTER TSE). Un texte cod ´e se- lon un codage d’ ´echange quelconque, qu’il soit 8 ou 16 bits, sera aussi converti enISO

10646/UNICODE. Enfin, avant de passer la main au composant typographique deW, les caract `eresISO10646/UNICODEseront traduits selon les positions correspondantes des polices de sortie, et alors seulementWactivera l’algorithme de c ´esure.

Cet article comprend deux parties : la premi `ere, qui ´emane de [13], est une introduc- tion technique `aW; la deuxi `eme, provenant de [8], d ´ecrit quelques applications simples, principalement dans le domaine de la composition multilingue.

1. Une introduction `a W

1.1. Codages et recodages

Si on fait abstraction des probl `emes li ´es `a la mise en page, la composition peut ˆetre perc¸ue comme un processus qui convertit une chaıˆne de caract `eres en une chaıˆne de glyphes. Ce processus peut ˆetre tr `es simple ou tr `es complexe. Le cas le plus simple est sans doute l’anglais ou`, dans la plupart des cas, le codage d’entr ´ee comme le codage des polices en sortie est l’ASCII; aucune conversion n’est ici n ´ecessaire. `A l’oppos ´e, on pourrait imaginer une transcription latine de l’arabe qui produise un texte en arabe avec toutes ses voyelles et ligatures ; ici il faudra interpr ´eter la translit ´eration, puis d ´eterminer le trac ´e correct de chaque consonne, et enfin choisir les ligatures et placer les voyelles

— le processus est bien plus complexe.

TEX suppose qu’il y a deux codages de base : le codage d’entr ´ee et le codage interne, chacun d’entre eux utilisant un maximum de 8 bits. La conversion du codage d’entr ´ee vers le codage interne se fait par le biais du tableauxord. Un caract `ere en entr ´ee est lu et converti selon le tableauxord. Le codage de sortie est le m ˆeme que le codage

interne, `a la diff ´erence pr `es que plusieurs caract `eres peuvent se combiner pour former une ligature.

Supposons que l’on travaille dans un environnement h ´et ´erog `ene et que l’on rec¸oive r ´eguli `erement des fichiers utilisant des codages diff ´erents. Dans ce cas, on se heurte `a un probl `eme, car la conversion du codage d’entr ´ee vers le codage interne est faite en dur dans le code de TEX. Pour changer le codage d’entr ´ee, il faut modifier le code de TEX, ce qui est difficilement acceptable.

Alors comment contourner ce probl `eme ? La premi `ere possibilit ´e consiste `a utiliser un pr ´eprocesseur, avant d’appeler TEX. On peut aussi utiliser des caract `eres actifs. Au d ´ebut de chaque fichier, certains caract `eres sont d ´efinis comme ´etant des macros. Mais cette m ´ethode est peu fiable, car d’autres macros peuvent consid ´erer que ces caract `eres sont des lettres ordinaires.

Il serait bien plus int ´eressant d’avoir une commande d ´eclarant que le codage d’entr ´ee a ´et ´e modifi ´e, et de permettre `a TEX de changer de processus de conversion `a la vol ´ee, en gardant le m ˆeme codage interne.

Il serait sans doute relativement facile d’adapter TEX pour qu’il puisse rapidement basculer d’un codage de caract `eres sur un octet `a un autre. Mais il existe aujourd’hui plusieurs jeux de caract `eres multi-octets : JIS, Shift-JIS et EUC au Japon, GB en Chine et KSC en Cor ´ee. Certains sont de longueur fixe, d’autres ont des codes `a ´etat de lon- gueur variable. Le plan de base deISO10646-1.2 (Unicode-1.1) ´etant maintenant d ´efini, on dispose d’un jeu de caract `eres 16 bits qui peut ˆetre utilis ´e pour traiter la plupart des langues dans le monde. Pourtant, pour des raisons de compatibilit ´e, on rencontre sou- vent des fichiers en format UTF, dans lesquels on peut stocker jusqu’ `a 32 bits avec un codage de longueur variable (1-6 octets), mais les octetsASCIIy restent des octetsAS-

CII. En d’autres termes, le processus de conversion du codage d’entr ´ee vers le codage interne n’est pas vraiment simple.

Pour compliquer encore les choses, la nature du codage interne n’est pas ´evidente du tout. Doit-il ˆetre fixe, auquel cas la seule solution raisonnable est l’ISO10646/UNICODE, ou bien variable ? Si le codage interne est fixe, dans la plupart des cas, une conversion du codage interne vers le codage police devra aussi ˆetre effectu ´ee. Certaines polices japonaises sont par exemple cod ´ees en interne suivant l’unification Han, le principe qui sous-tendISO10646/UNICODE. Le codage interne devrait plut ˆot suivre les nombres de Kuten ou l’un des codages du JIS. Si c’est la m ˆeme chose pour le codage d’entr ´ee, une double conversion, pas toujours simple ni n ´ecessaire, doit ˆetre alors r ´ealis ´ee.

Pour rendre l’affaire encore plus difficile, l’ ´editeur peut tr `es bien ne pas disposer des fontes n ´ecessaires pour une langue particuli `ere. Une translit ´eration est alors indispen- sable, mais elle est compl `etement ind ´ependante du codage des caract `eres ; apr `es tout, on peut utiliser la m ˆeme translit ´eration de caract `eres latins vers le cyrillique, que l’on uti- liseISO646 ouISO10646/UNICODE. Et la translit ´eration n’a rien `a voir avec le codage des polices. En fait, on voudrait utiliser les m ˆemes fontes arabes, qu’on effectue la sai- sie en utilisant une translit ´eration latine enISO8859-1, ou arabe enISO8859-6 ouISO

10646/UNICODE. En plus, l’ordre des caract `eres dans un flux d’entr ´ee peut ne pas cor- respondre `a l’ordre dans lequel les caract `eres doivent ˆetre plac ´es sur le papier ou l’ ´ecran.

Par exemple, [4], de nombreuses voyelles cambodgiennes sont scind ´ees en deux : une partie est plac ´ee `a gauche d’un groupe consonantique, l’autre `a droite. Des probl `emes similaires ont surgi avec le cingalais et les autres ´ecritures du sous-continent indien [7].

Finalement, on doit r ´ealiser que des messages d’erreur et les traces doivent ˆetre affi- ch ´es et qu’ils n’utiliseront pas forc ´ement le m ˆeme jeu de caract `eres que celui du codage d’entr ´ee ou du codage interne.

1.2. Translite´ration et analyse contextuelle

Il semble clair que le seul codage interne viable soit le codage police. Pourtant, il n’y a aucune raison pour que la conversion du codage d’entr ´ee vers le codage interne se fasse en une seule ´etape. De toute ´evidence, on peut toujours l’effectuer et, si les polices sont assez grandes, on peut toujours faire toute l’analyse au niveau ligature dans la police. Mais ce choix nous emp ˆeche de s ´eparer des t ˆaches distinctes comme — par exemple pour l’arabe — la conversion initiale de tout le texte enISO10646/UNICODE, puis la translit ´eration, ensuite le calcul de la forme appropri ´ee de chaque lettre, et seulement alors l’activation du m ´ecanisme de ligature des polices.

En fait, nous proposons d’autoriser l’ ´ecriture d’un nombre quelconque de filtres, et la possibilit ´e que la sortie d’un filtre devienne l’entr ´ee d’un autre filtre, comme pour les pipes d’Unix.

1.3. Processus de translation deW

DansW, ces filtres sont appel ´es Processus de Translation deW⁽WTPs). ChaqueW^TP est d ´efini par l’utilisateur dans un fichier.otp: avec une syntaxe rappelant celle du g ´e- n ´erateur d’analyseur lexicalflex, les utilisateurs peuvent d ´efinir des automates `a ´etats finis de Mealy pour transformer les flux de caract `eres en de nouveaux flux de caract `eres.

Ces tables de traduction utilisateur ne sont pas directement lues par W^{. Mais} des repr ´esentations plus compactes (fichiers.ctp) sont produites par le programme otptoctp. La lecture d’un fichier.ctpse fait par l’interm ´ediaire d’une primitiveW^(voir ci-dessous).

Voici la syntaxe du fichier de translation :

in: ⁿ;

out: ⁿ;

tables: ^T

states: ^S

aliases: ^A

expressions: ^E

ou`n repr ´esente un nombre quelconque. Les nombres peuvent ˆetre repr ´esent ´es en no- tation d ´ecimale, octale `a laWEB⁽@'...) ou hexad ´ecimale (@"...), ou encore ˆetre des ca- ract `eresISO646 affichables inclus entre un accent grave et une apostrophe.

Le premier (resp. deuxi `eme) nombre sp ´ecifie le nombre d’octets dans un caract `ere en entr ´ee (resp. sortie), le d ´efaut ´etant de un dans les deux cas. Ces valeurs sont n ´eces- saires pour pr ´eciser quel processus de translation utiliser pour faire la conversion depuis ou vers un jeu de caract `eres qui utilise plus d’un octet par caract `ere.

Ces tables sont r ´eguli `erement utilis ´ees dans les conversions de jeu de caract `eres, quand on ne peut pas sp ´ecifier facilement des approches algorithmiques. Voici la syntaxe d’une tableT :

id[ⁿ] = {n; n; : : : ; n};

LesWTP, comme dansflex, autorisent un nombre donn ´e d’ ´etats. Chaque expres- sion est valide seulement dans un ´etat donn ´e. L’utilisateur peut sp ´ecifier des change- ments d’ ´etats. Les ´etats sont souvent utilis ´es pour l’analyse contextuelle. La syntaxe pour un ensembleS d’ ´etats est :

id, ^id, ^{: : :}, ^id;

Les expressions sont des paires motif-action. Les motifs sont ´ecrits comme des ex- pressions r ´eguli `eres simples, et on peut en d ´efinir des alias. La syntaxe d’un aliasA est : id = ^L;

ou`L est un motif.

Si on utilise un seul ´etat, alors une expressionE est compos ´ee d’un motif et d’une action :

L => ^R;

et la syntaxe d’un motif est :

L ::= n

j n–n intervalle

j . ^joker

j LL concat ´enation

j L{^{n; m}} occurrences

j (^L | ^{: : :} | ^L) ^choix

j ^ (^L | ^{: : :} | ^L) choix n ´egatif

j {^id} abr ´eviation ;

alors que la syntaxe simplifi ´ee pour une action est : R ::= string

j n

j nn

j n($^,n)

j n(+n^,n)

j #(^R)

j id[^R]

j RopR arithm ´etique ;

Les motifs sont appliqu ´es `a l’entr ´ee. Quand il y a correspondance entre un motif et le flux d’entr ´ee, l’action en partie droite est ex ´ecut ´ee. Unechaıˆne est simplement

´emise en sortie. Le\n correspond au n^e caract `ere correspondant et le\$ correspond au dernier caract `ere appari ´e.\* correspond `a toute la chaıˆne appari ´ee et\^(*,n) correspond

`a l’ensemble de la chaıˆne moins lesn derniers caract `eres. La recherche dans la table se fait en utilisant des crochets. Toutes les expressions doivent ˆetre pr ´ec ´ed ´ees d’un #.

Voici un exemple de translation du codage chinois GB 2312-80 vers ISO

10646/UNICODE: in: 1;

out: 2;

tables: tabgb[8795] = {...};

expressions:

(@"00-@"A0) => \1;

(@"A1-@"FF)(@"A1-@"FF) =>

#(tabgb[(\1-@"A0)*@"64 + (\2-@"A0)]);

.. => @"FFFD;

ou` nous utilisons0xfffd (replacement character)comme caract `ere d’erreur.

Et voici une translit ´eration courante dans les ´ecritures indiennes : {consonante}{1,6} {voyelle} => \$ \(*-1);

La voyelle en fin d’expression est mise avant le flux de consonnes.

La syntaxe compl `ete des expressions est plus compliqu ´ee, car il y peut y avoir plu- sieurs ´etats de traitements. En outre, on peut empiler des valeurs sur la pile d’entr ´ee.

Voici la syntaxe compl `ete :

<e´tat> L => ^R <= ^{R <}nouvel_e´tat>

e´tat signifie que si l’WTP est dans cet ´etat, alors cette paire motif-action peut ˆetre utilis ´ee.

nouvel_e´tat d ´esigne le nouvel ´etat si cette paire motif-action est choisie.

Et voici un exemple d’analyse contextuelle de l’arabe :

<MEDIAL>{QUADRIFORM}{NOT_ARABIC_OR_UNI}

=> #(\1 + @"DD00)

<= \2

<pop:>

;

Quand on est dans l’ ´etatMEDIAL(au milieu d’un mot) et qu’une lettre qui a quatre formes possibles est suivie d’une lettre non arabe, on obtient en sortie la lettre `a quatre formes plus la valeur@"DD00. La lettre non arabe est replac ´ee sur la pile d’entr ´ee. L’ ´etat courant est alors d ´epil ´e et l’WTP revient `a l’ ´etat pr ´ec ´edent, quel qu’il soit.

1.4. Chargement desW^TP

Le chargement d’unWTP est similaire `a celui d’une police. L’instruction est simple- ment :

notpⁿnouveau_nom = nom_de_fichier

Le fichier.ctp nouveau_nom.ctpest lu et stock ´e dans la m ´emoireotp info^{, si-} milaire `a la m ´emoirefont info. Une valeur est affect ´ee `a la s ´equence de commande

\nouveau_nom, comme pour les fontes. On peut ensuite faire r ´ef ´erence `a cetWTP par l’interm ´ediaire de cette valeur ou bien gr ˆace `a la commande nouvellement d ´efinie.

1.5. Codage d’entre´e

A la lecture d’un fichier d’origine inconnue, utilisant un jeu de caract `eres inconnu, il` faut trouver un m ´ecanisme pour d ´eterminer le jeu de caract `eres. Il y a deux possibilit ´es.

On peut utiliser un jeu par d ´efaut, ou bien trouver un moyen de reconnaıˆtre rapidement de quel jeu il s’agit.

Heureusement, l’ISO646 est un sous-ensemble de la plupart des jeux de caract `eres.

Le jeuISO10646/UNICODE, dans ses versions 16 et 32 bits, a le m ˆeme codage queISO

646 pour les 128 premiers caract `eres. Le seul jeu largement r ´epandu qui ne r ´eponde pas

`a ce crit `ere est l’EBCDICd’IBM.

Aussi fournissons-nous le moyen de d ´etecter automatiquement la famille du jeu de caract `eres. Il suffit que l’utilisateur place un commentaire au tout d ´ebut de chaque fi- chier : le caract `ere%est suffisant pour distinguer chacune de ces familles. Un fichier qui utilise une extension 8 bits de l’ISO646 commence avec le code caract `ere0x25<sup>; un fi-</sup> chier avec des caract `eres 16 bits commence par0x00 0x25¹. Enfin, un fichier utilisant le codageEBCDICcommence par0x6c^.

S’il n’y a pas de caract `ere %, alors on suppose qu’il s’agit du codage d’entr ´ee par d ´efaut (ISO646).

Une fois queWsait comment lire les lettres de base latines, il est possible dede´clarer quelle traduction l’entr ´ee doit subir. Ceci est fait en utilisant la commande

\InputTranslation Par exemple,

\InputTranslation 1

d ´eclare que tout le flux d’entr ´ee, commenc¸ant imm ´ediatementapre`s le caract `ere « retour chariot » `a la fin de cette ligne, devra ˆetre trait ´e par le processusW^TP.

Il est aussi possible de changer de jeu de caract `eres `a l’int ´erieur d’un fichier. Ce pro- cessus est plus difficile `a r ´ealiser, car il n’est pas toujours ´evident de savoirexactement ou` la modification doit prendre effet. Supposons que nous passions d’un jeu de carac- t `eres 8 bits `a un jeu 16 bits. Il est important de savoir quel est ledernier caract `ere 8 bits et quel est lepremier caract `ere 16 bits.

On peut r ´esoudre cette question en choisissant un caract `ere particulier pour marquer le changement. Pourtant, pour simplifier les choses, nous supposons que toutes les mo- difications de traduction en entr ´ee ont lieuimme´diatement apre`s le caract `ere « retour chariot » `a la fin de la ligne dans laquelle\InputTranslation^apparaıˆt.

1Un fichier avec des caract `eres 32 bits devrait commencer par<sup>0x00 0x00 0x00 0x25</sup>, mais la version actuelle de Wne traite pas les caract `eres 32 bits.

1.6. Translite´ration

Une fois que les caract `eres ont ´et ´e lus, le plus souvent suivant un certain jeu de ca- ract `eres universel commeISO10646/UNICODE, l’analyse contextuelle peut avoir lieu, in- d ´ependamment du jeu de caract `eres de d ´epart. Cette analyse peut n ´ecessiter plusieurs filtres, chacun d’entre eux ´etant similaire au processus de traduction auquel l’entr ´ee a

´et ´e soumise.

Puisque le nombre de filtres que nous pouvons vouloir utiliser est arbitrairement grand, il y a deux commandes pour sp ´ecifier des filtres :

\NumberInputFiltersⁿ

d ´eclare que lesn premiers filtres sont actifs. La sortie du i^e filtre devient l’entr ´ee pour lei+ 1^e filtre, pouri < n.

\InputFilter^{m i}

d ´eclare que lem^e filtre est lei^e W^TP.

Les s ´equences de caract `eres compos ´ees successivement des codes caract `eres 5, 10, 11 et 12 traversent lesnprocessus de traduction. Cela signifie que le r ´esultat du dernier processus de traduction sera le codage fonte en sortie ; c’est sur ce codage que sera appliqu ´e l’algorithme de c ´esure.

Notre exemple sur l’arabe se pr ´esentera comme suit :

\otp\trans = ISO646toISO10646

\otp\translit = TeXArabicToUnicode

\otp\fourform = UnicodeToContUnicode

\otp\genoutput = ContUnicodeToTeXArabicOut

\InputFilter 0 \translit

\InputFilter 1 \fourform

\InputFilter 2 \genoutput

\NumberInputFilters 3

Le traducteur TeXArabicToUnicodes ´electionne la translit ´eration latine et fait la conversion en arabe. Comme pour UnicodeToContUnicode, il effectue l’ana- lyse contextuelle pour l’arabe, c’est- `a-dire qu’il prend l’arabe en entr ´ee (en ISO

10646/UNICODE) et, en utilisant une zone priv ´ee, d ´etermine laquelle des quatre formes (isol ´ee, initiale, m ´ediale ou finale) doit prendre chaque consonne. Finalement, ContUnicodeToTeXArabicd ´etermine quel emplacement dans la police correspond

`a chaque caract `ere. E´videmment rien n’emp ˆeche la police d’avoir aussi son propre m ´e- canisme sophistiqu ´e de ligatures.

1.7. Codages de sortie et codages spe´ciaux

TEX ne se borne pas `a produire des fichiers.dvi. Il cr ´ee aussi des fichiers.aux<sup>,</sup> .loget bien d’autres, qui peuvent `a leur tour ˆetre relus par TEX. Il est donc important que le m ´ecanisme de sortie soit aussi g ´en ´eral que celui d’entr ´ee. Pour cela, nous

introduisons les op ´erations duales :

\OutputTranslation

\OutputFilter

\NumberOutputFilters

avec ´evidemment les arguments appropri ´es.

De fac¸on similaire, TEX peut ´ecrire dans ses fichiers.dvides commandes sp ´eci- fiques `a un pilote de p ´eriph ´erique, en utilisant des commandes\special. Comme les arguments de\specialsont eux-m ˆemes des chaıˆnes, il semble judicieux d’autoriser aussi les commandes suivantes :

\SpecialTranslation

\SpecialFilter

\NumberSpecialFilters 1.8. Fontes de grande taille

TEX limite la taille des fontes `a un maximum de 256 caract `eres. Pourtant, le be- soin en fontes de plus grande taille se fait souvent sentir. Un total de 256 caract `eres est ´evidement insuffisant pour les langues utilisant des id ´eogrammes. Mais la m ˆeme remarque s’applique aux ´ecritures alphab ´etiques comme le latin, le grec ou le cyrillique ; pour chacune d’entre elles,ISO10646/UNICODEpr ´evoit plus que 256 caract `eres. Cepen- dant nombre de ces caract `eres ´etant des combinaisons de base « caract `ere+signe dia- critique », le nombre r ´eel de glyphes de base est donc plus r ´eduit. En fait, pour chacun de ces trois alphabets, une seule fonte de 256 caract `eres suffit pour les glyphes de base.

Nous avons donc d ´ecid ´e, dans une premi `ere ´etape, d’offrir le moyen de traiter des fontes virtuelles de grande taille (16 bits), dont les glyphes de base tiendront en fait dans une fonte `a 8 bits. Ceci n’est ´evidemment qu’une premi `ere ´etape, mais elle pr ´esente l’avantage de permettre le traitement de fontes de grande taille, y compris leurs m ´eca- nismes de ligature, sans avoir `a r ´eecrire tous les pilotes de sortie.

En plus des changements `a TEX, il faudra aussi modifierdvicopy^etvptovf^{, qui} deviennent respectivementxdvicopy^etxvptovf. Les fichiers .tfm^,.vp^et.vf sont remplac ´es par les fichiers.xfm^,.xvp^etxvfrespectivement. Les nouveaux pro- grammes peuvent bien suˆr toujours lire les anciens fichiers.

1.9. Fichiers.xfm

Les fichiers.xfmsont similaires aux fichiers.tfm, `a la diff ´erence pr `es que la plupart des valeurs utilisent 16 ou 32 bits, et ont donc doubl ´e de taille. L’en-t ˆete comprend 13 mots de quatre octets. Pour distinguer les fichiers.tfm^et.xfm, le premier mot est enti `erement mis `a z ´ero. Les douze mots suivants contiennent les valeurs delf, lh, bc,

ec, nw, nh, nd, ni, nl, nk, ne et np. Toutes ces valeurs doivent ˆetre positives ou nulles et inf ´erieures `a 2³¹. D ´esormais, chaque valeur dechar_info est d ´efinie comme suit :

width index 16 bits height index 8 bits depth index 8 bits italic index 14 bits

tag 2 bits

remainder 16 bits

Chaquelig_kern_command est de la forme : op byte 16 bits

skip byte 16 bits next char 16 bits remainder 16 bits

Finalement ces extensions prennent deux fois plus de place.

1.10. Fichiers.xvp

Les fichiers.xvpsont simplement des fichiers.vpldans lesquels toutes les res- trictions dues au codage des caract `eres sur 8 bits ont ´et ´e lev ´ees. Sinon, tout le reste est identique.

1.11. Modifications mineures

Comme les changements mentionn ´es ci-dessus ont n ´ecessit ´e un examen appro- fondi de tout le code de TEX, nous en avons profit ´e pour supprimer toutes les restrictions dues `a un codage sur un seul octet. Par exemple, on peut utiliser maintenat plus de 256 registres (de chaque sorte). De m ˆeme, on peut avoir plus de 256 fontes simultan ´ement.

2. Applications de W

2.1. Ne´arlandais, portugais, turc : un traitement facile

Ces trois langues (et peut- ˆetre d’autres ?) ont au moins une chose en commun : elles ont besoin de fontes ayant une table de ligatures l ´eg `erement diff ´erente de celle du codage de Cork. La composition du hollandais utilise la fameuse ligature « ij » (qu’on trouve par exemple dans le nom de personnes connues comme Dijkstra, van Herwijnen, Eijkhout, van Dijk, ou encore celui de la ville de Nijmegen ou du lac IJselmeer) ; cette ligature apparaıˆt dans le codage de Cork (comme dans ISO 10646/UNICODE), mais jusqu’ `a maintenant, il n’existait pas de moyens tranparents `a l’utilisateur pour l’obtenir.

AvecWil suffit de placer une macro appelant un filtreWTP sp ´ecifique dans l’expansion de la macro qui bascule en hollandais ; en syntaxeW(d ´ecrite dans la section 1.3), on

peut ´ecrire cetWTP tr `es simplement :

in: 1 out: 2

expressions:

`I'`J' => @"0132;

`i'`j' => @"0133;

. => \1;

ou`0x0132<sup>et</sup>0x0133sont les caract `eres « IJ » (LATIN CAPITAL LIGATURE IJ) et « ij » (LATIN SMALL LIGATURE IJ) enISO10646/UNICODE.

Le portugais et le turc n’utilisent pas les ligatures « fi », ... « ffl » (en turc la raison est ´evidente : l’alphabet turc utilisant les deux lettres « i » et « ı », il serait impossible de savoir si « fi » repr ´esente « f » + « i » ou « f » + « ı »). C’est un probl `eme majeur pour TEX, car la seule solution qui permettrait de conserver une saisie naturelle serait d’utiliser une nouvelle fonte ; et d ´efinir un ensemble complet de fontes (virtuelle ou r ´eelle), pour

´eviter seulement 5 ligatures, pr ´esente plus d’inconv ´enients que d’avantages.W^{r ´esoud} facilement ce probl `eme ; bien suˆr il est impossible de d ´esactiver une ligature, puisqu’elle arrive `a la toute derni `ere ´etape, `a savoir `a l’int ´erieur de la fonte. Nous devons donc tricher d’une fac¸on ou d’une autre ; le plus naturel consiste `a placer un caract `ere invisible entre le « f » et le « i » ; dansISO10646/UNICODE, il y a pr ´ecis ´ement un tel caract `ere, dont le code est0x200b⁽ZERO WIDTH SPACE) ; on peut r ´ealiser cette op ´eration avec une ligne W^{TP du type}`f'`i' => "f" @"200b "i"pour chaque ligature. Ce caract `ere devra ensuite ˆetre mis en correspondance avec le caract `ere « compound mark » de la table de Cork, qui a ´et ´e d ´efini pour cet usage.

Une meilleure m ´ethode consisterait `a d ´efinir un second « f » dans la table de la police de sortie, qui ne formerait pas de ligature avec « f », « i » ou « l ». Cela donnerait la pos- sibilit ´e `a la police d’appliquer un cr ´enage entre les deux lettres, et de compenser l’effet de la ligature manquante (apr `es tout, si une police est dessin ´ee pour utiliser une ligature entre « f » et « i », une paire « fi » sans ligature paraıˆtrait assez ´etrange et pourrait n ´eces- siter une modification).

2.2. Poetica d’Adobe

Poetica est une famille de polices scriptes chancelli `eres, dessin ´ee par Robert Slim- bach et commercialis ´ee par Adobe Systems Inc. D’apr `es la publicit ´e d’Adobe, «La police Poetica a e´te´ conc¸ue d’apre`s les cursives manuscrites diplomatiques produites durant la Renaissance italienne. E´le´gante et simple, l’e´criture diplomatique est reconnue comme e´tant a` la base des polices italiques et elle marque le point de de´part de la calligraphie mo- derne. Robert Slimbach a capte´ la vitalite´ et la graˆce de ce style d’e´criture dans Poetica.

Les caracte´ristiques de l’e´criture diplomatique comprennent l’usage fre´quent de lettres aux formes fleuries, de ligatures et de caracte`res variables permettant d’embellir des ma- nuscrits qui sinon auraient un aspect un peu rigide. Pour capter la varie´te´ de formes et

Figure 1 – Exemple du caract `ere Poetica

la richesse de cette e´criture, Slimbach a cre´e´ des alphabets supple´mentaires et des jeux de caracte`res en concevant Poetica de main de maıˆtre, qui contient un ensemble varie´

de ces formes de lettres. »

Techniquement, Poetica comprend 21 polices PostScript : Chancery I–IV, Expert, Small Caps, Small Caps Alternate, Lowercase Alternates I–II, Lowercase Beginnings I–

II, Lowercase Endings I–II, Ligatures, Swash Caps I–IV, Initial Swash Caps, Ampersands, Ornaments. Alternate, Beginnings, Endings et Ligatures sont particuli `erement int ´eres- santes pour nous, carWpeut automatiquement choisir des caract `eres dans ces polices.

L’utilisateur saisit simplement son texte, en marquant ´eventuellement le changement d’alphabet par un symbole. UnWTP convertit l’entr ´ee en caract `eres d’une police 16 bits virtuelle, qui contient les caract `eres de tous les composants de Poetica. En utilisant plu- sieursWTP et en les modifiant `a la vol ´ee, l’utilisateur pourra choisir le nombre de ligatures qu’il veut obtenir en sortie. Cela permettra aussi d’aller plus loin qu’Adobe, en d ´efinissant le cr ´enage entre des paires de caract `eres de diff ´erentes polices de Poetica.

Voir fig. 1 pour un ´echantillon de texte compos ´e en Poetica.

2.3. A` propos du grec, ancien et moderne (mais ancien plus que moderne)

2.3.1. Signes diacritiques ou cre´nage ?

Les personnes instruites connaissent en g ´en ´eral les lettres grecques. Au coll `ege d ´ej `a, ayant utilis ´e pour les angles, pour l’acc ´el ´eration et³ pour calculer la surface d’un cercle de rayon donn ´e, nous sommes familiaris ´es avec toutes ces lettres, comme avec l’alphabet latin. Mais pour ´ecrire en grec, en particulier en grec ancien, il ne faut pas seulement des lettres. On utilise deux types de signes diacritiques, les accents (aigu, grave et circonflexe), et les esprits (rude et doux) qui sont plac ´es sur les voyelles et sur la consonne rho.

Chaque mot poss `ede au plus un accent<sup>2</sup>, et 99.9 % des mots grecs ont effective- mentun accent. Chaque mot commenc¸ant par une voyelle a exactement un esprit<sup>3</sup>. Il y a donc en grec beaucoup plus d’accentuation que dans tout autre langue `a alphabet latin,

`a l’exception ´evidente du vi ˆetnamien.

Comment TEX traite-t-il les signes diacritiques grecs ? En suivant l’approche tradi- tionnelle comme le fait la primitive\accent, nous n’aurions eu pratiquementaucune c ´esure (ce qui aurait entraıˆn ´e de d ´esastreux sur/sous remplissages de ligne, car le grec peut facilement avoir des mots de grande longueur tels que²torinolaruggologikìc), aucun cr ´enage, et une saisie tr `es malcommode, avec une ou deux macros `a chaque mot.

La premi `ere approche, dont Silvio Levy est l’auteur [11], consiste `a utiliser les liga- tures de TEX (les plus « b ˆetes » d’abord, puis les plus « intelligentes »), pour obtenir les lettres accentu ´ees comme combinaison de codes repr ´esentants les esprits (>^et<^{), les} accents (`<sup>,</sup>'et =) et les lettres elles-m ˆemes. De cette fac¸on, on ´ecrit>`hpour obtenir

£. Cette approche r ´esolvait le probl `eme de la c ´esure et de la difficult ´e de la saisie.

N ´eanmoins, cette approche ne r ´esoud pas le probl `eme du cr ´enage. Prenons le cas fr ´equent de l’article<sup>tä</sup>(lettre tau suivie de la lettre omicron) ; dans presque toutes les polices, il existe une instruction de cr ´enage entre ces deux lettres, `a cause bien suˆr des caract ´eristiques invariantes de leur dessin. Supposons maintenant que omicron soit ac- centu ´e, et qu’on ´ecrivet`opour obtenir tau suivi de omicron avec accent grave. Ce que TEX voit est un « t » suivi d’un accent grave. Aucun cr ´enage ne peut ˆetre d ´efini entre ces deux caract `eres, car nous n’avons aucune id ´ee de ce qui peut suivre l’accent grave (un iota par exemple, et en g ´en ´eral il n’y a pas de cr ´enage entre tau et iota). Quand la lettre omicron arrive, il est trop tard ; TEX a d ´ej`a oubli ´e qu’un tau pr ´ec ´edait l’accent grave.

Pour r ´esoudre ce probl `eme on pourrait ´ecrire les signes diacritiques apre`s les voyelles (« notation post-positive »). Mais cela entre en contradiction avec les caract ´eris- tiques visuelles des signes diacritiques associ ´es aux majuscules, puisqu’ils sont plac ´es

`a gauche de ces derni `eres : ^—Earpeut difficilement utiliser la translit ´erationE>'ar^{. Et} apr `es tout, TEX devrait pouvoir composer le grec correctement, quelle que soit la fac¸on dont sont saisis les lettres et les signes diacritiques.

Wr ´esoud ce probl `eme en utilisant une suite appropri ´ee de processus de traduction (WTP), une notion expliqu ´ee en section 1.3 : `a titre d’exemple, consid ´erons le mot^êar:

1. Supposons que l’utilisateur d ´esire saisir son texte enASCII7 bits ; il tapera>'ear^, ce qui est d ´ej `a de l’ISO-646, de sorte qu’aucune traduction en entr ´ee n’est n ´eces- saire. Il pourrait aussi utiliser un codage entr ´ee commeISO-8859-7 ou^elot; l’uti- lisateur pourra alors aussi bien taper^>'åáòque^>Ûáò.⁴. Le premierWTP transfor- mera ces codes vers les codes 16 bits appropri ´es d’ISO10646/UNICODE:0x1f14

2Un accent est parfois d ´eplac ´e d’un mot vers le pr ´ec ´edent :^{Šnjrwpìctic}au lieu de^{Šnjrwpoc,tÐc}, de sorte que, typographiquement, un mot peut avoir plus d’un accent.

3Avec une exception : les lettres^rrsont souvent ´ecrites^üû, quand elles sont `a l’int ´erieur d’un mot :<sup>poüûÀ</sup>. 4La raison de la complication absurde qui force `a taper^>'åou^>Ûpour obtenir^êest que le codage du « grec mo- derne » a choisi la facilit ´e en n’utilisant qu’un seul accent, comme si la langue grecque ´etait n ´ee en 1982, ann ´ee de la r ´eforme h ˆative de l’orthographe d ´ecid ´ee pour des raisons politiques.

pour^ê(GREEK SMALL LETTER EPSILON WITH PSILI AND OXIA),0x03b1^poura(GREEK

SMALL LETTER ALPHA) et0x03c1^pourr(GREEK SMALL LETTER RHO).

2. Une fois qu’Wconnaıˆt les caract `eres qu’il manipule (le codage interne par d ´efaut d’West pr ´ecis ´ementISO10646/UNICODE), il fera la c ´esure en utilisant des motifs 16 bits.

3. Finalement, unWTP appropri ´e enverra les codes grecsISO10646/UNICODE`a une fonte 16 bits virtuelle (voir page 69 la raison pour laquelle nous avons besoin de 16 bits), construite `a partir d’une ou de plusieurs fontes 8 bits. Cette fonte contient des instructions de cr ´enage, appliqu ´ees d’une mani `ere simple, puisque nous nous occupons de trois codes seulement : <<sup>ê</sup>>, <<sup>a</sup>> et <<sup>r</sup>>. Aucun code auxiliaire n’in- terf `ere plus.

4. xdvicopy⁵d ´e-virtualisera le fichierdviet produira un nouveau fichierdvi^utili- sant exclusivement des polices 8 bits, compatibles avec tout pilotedvi^{digne de} ce nom.

En s ´eparant les t ˆaches, la c ´esure devient plus naturelle (pour TEX, il faut utiliser des motifs incluant les codes auxiliaires'^,`, = etc.). Au passage, on a r ´esolu un probl `eme suppl ´ementaire : les primitives\lefthyphenmin^et\righthyphenmins’appliquent aux caract `eres decatcode 12. Pour obtenir la c ´esure entre des groupes comportant des codes auxiliaires, nous devons d ´eclarer ces codes comme des « caract `eres de type lettre ». Par exemple, le mot^êar, qu’on ´ecrit>'ear: Pour autoriser la c ´esure, les codes

>^et'doivent ˆetre consid ´er ´es comme des lettres (\lccode significative) ; mais ceci signifie que pour TEX,^êara 5 lettres au lieu de 3, et en cons ´equence, m ˆeme si nous de- mandons\lefthyphenmin=3, le mot sera encore coup ´e comme^ê-ar!!Wr ´esoud ce probl `eme en coupantapre`s la fin de la traduction (dans ce cas>^{’e ou>'åou>Û!ê).}

2.4. Dactyles, sponde´es et fontes 16 bits

Les ´editions savantes de textes grecs sont l ´eg `erement plus compliqu ´ees que les ´edi- tions ordinaires<sup>6</sup>, l’un des ajouts ´etant untroisie`me niveau de diacritiques : la longueur des syllabes.

On lit dans [2], p. 254 : «La poe´sie grecque a e´te´ compose´e sur un principe entie`re- ment diffe´rent de celui employe´ en anglais. Elle n’e´tait pas construite en disposant les syllabes accentue´es en motifs, ni avec un syste`me de rimes. Les poe`tes grecs utilisaient un certain nombre de me´triques diffe´rentes qui consistaient toutes en un certain arrange- ment fixe desyllabes longues et courtes». Les syllabes longues et courtes sont mar- qu ´ees par les signes diacritiquesmacron et bre`ve. Ces diacritiques sont plac ´ees entre la lettre et le signe diacritique normal, s’il existe (sauf dans le cas de lettres majuscules,

5Dans le nom de ce programme, qui est une version ´etendue du^dvicopyde Peter Breitenlohner, « x » signifie

« extended » et non pas « X-Window ».

6Apr `es tout, les ´erudits ´etudient les textes grecs depuis plus de 2000 ans

auquel cas elles sont plac ´ees apr `es et au-dessus de la lettre alors que les diacritiques normales sont plac ´ees `a leur gauche).⁷

Les fameux deux premiers vers de l’Odyss ´ee

—Andra moi ênnepe, MoÜsa polÔtropon, çc mˆla poll€

plˆgqjh âpeÈ TroÐhc Éerän ptolÐejron êperse;

forment des hexam `etres. Ils comprennent six pieds : quatre dactyles ou spond ´ees, un dactyle et un spond ´ee ou un troch ´ee (voir `a nouveau [2] pour plus de d ´etails). On pourrait

´ecrire le texte sans accents ni esprits pour rendre la m ´etrique plus apparente : Andra moi ennepe, Mousa polutropon, oc mala polla

plagqjh epei Troihc ieron ptoliejron eperse

ou d ´ecider de mettre tous les types de signes diacritiques :

— Andra moi —ennepe, Mo=usa pol'utropon, Ãoc m'ala poll`a pl'agqjh >epe`i Tro'ihc <ier`on ptol'iejron —eperse

Apr `es avoir d ´epens ´e une fortune pour acqu ´erir la machinerie qui se trouve entre le clavier et l’ ´ecran, on pourrait s’atttendre `a ce que la c ´esure et le cr ´enage entre les lettres restent les m ˆemes, malgr ´e le nombre toujours croissant de signes diacritiques. En fait, ce n’est pas possible avec TEX : il existe exactement 345 combinaisons possibles entre les lettres grecques et les accents, esprits, longueur de syllabe et iota en indice ; TEX peut g ´erer un maximum de 256 caract `eres dans une police. AussiWest-il n ´ecessaire pour la c ´esure de textes grecs, chaque fois que des longueurs de syllabe sont compos ´ees.

Dans ce cas, les choses ne se passent pas aussi facilement que dans la section pr ´e- c ´edente : bien que 345 soit un petit nombre par rapport `a 65536 (= 2¹⁶), l’ISO a d ´ecid ´e qu’il n’y avait pas assez de place pour toutes les combinaisons d’accents, d’esprits et de longueur de syllabe.⁸

Chaque fois queISO10646/UNICODEdevient insuffisant pour nos besoins, nous uti- lisons lazone prive´e. Comme dans la s ´erie t ´el ´e The Twilight Zone, tout peut arriver dans cette zone priv ´ee. Dans le cas d’Wtoutes les op ´erations restent internes, de sorte que nous avons toute libert ´e pour d ´efinir des caract `eres : enISO10646/UNICODE, la zone pri- v ´ee est compos ´ee des caract `eres0xe000^`a0xfffd(du groupe 0, qui est la partie 16 bits deISO10646/UNICODE), soit un total de 8190 positions.

Wtraitera l’entr ´ee comme dans la section pr ´ec ´edente, mais les lettres avec macron et br `eve occuperont des positions internes dans la zone priv ´ee. Le reste du traitement sera exactement le m ˆeme. Comme pour la translit ´eration de l’entr ´ee, on peut prendre ˆ et¯pour noter macron et br `eve (apr `es avoir chang ´e leurcatcode pour ´eviter toute inter-

7Ces signes diacritiques suppl ´ementaires sont aussi utilis ´es avec un autre objectif : en prose, plac ´es apr `es l’une des lettres alpha, iota ou upsilon, ils indiquent s’il faut prononcer cette derni `ere longue ou courte (cette fois nous parlons de lettreset pas desyllabes).

8N ´eanmoins, ils ont introduit les lettres alpha, iota et upsilon avec macron et br `eve, en minuscules et majuscules, pro- bablement pour les raisons expos ´ees dans la note pr ´ec ´edente. Pourtant, la combinaison de diacritiques doit ˆetre utilis ´ee pour coder des lettres avec macron/br `eveetdes diacritiques suppl ´ementaires.

f ´erence avec les op ´erateurs math ´ematiques), ou n’importe quelle combinaison de codes 7 ou 8 bits.

2.5. Un reˆve quipeut devenir re´alite´

Comme le premier auteur l’a declar ´e d ´ej `a `a Cork en 1990, son r ˆeve ´etait — et de- meure — de dessiner une fonte grecque inspir ´ee du fameux « Grecs du Roi » de Claude Garamont, grav ´e en 1544-46 pour le roi Franc¸oisI. Ce caract `ere a ´et ´e conc¸u d’apr `es un manuscrit de^{—Aggeloc Berg kioc}, un Cr ´etois, calligraphe et lecteur de grec `a la cour franc¸aise, au d ´ebut duXVIsi `ecle. Il comprend 1327 caract `eres diff ´erents, la plupart d’entre eux ´etant des ligatures de deux lettres ou plus (parfois des mots entiers). On peut lire dans [12] que «cette police est la pie`ce la plus pre´cieuse de la collection [de l’Imprimerie Nationale franc¸aise] », et ce n’est suˆrement pas le moindre des honneurs ! West la plateforme id ´eale pour composer avec cette police, puisque seul unW^{TP sup-} pl ´ementaire sera n ´ecessaire pour introduire les ligatures dans le texte grec ordinaire de l’entr ´ee.

2.6. L’arabe, ou « l’art de se´parer les taˆches ».

2.6.1. L’arabe ordinaire, rapide, net et e´le´gant.

La composition en arabe est un bon compromis entre les techniques de composi- tion occidentales (nombre fini de caract `eres, r ´ep ´et ´es `a l’infini) et la calligraphie arabe (nombre infini de ligatures arbitrairement complexes). Nous pouvons subdiviser les li- gatures arabes en deux cat ´egories : (a) celles qui sont obligatoires : liaison de lettres (

ª

+

¢

^!

¤«

) et la ligature sp ´eciale l ¯am-al¯ıf (

Ÿ

⁺

,

^!

¾

), et (b) celles qui sont optionnelles, utilis ´ees pour des raisons esth ´etiques.

La deuxi `eme cat ´egorie de ligatures correspond `a nos bons vieux « fi », « fl », etc.

Elles d ´ependent du dessin de la police et du degr ´e de qualit ´e artistique du document.

Nous avons fait une classification approfondie des ligatures esth ´etiques de la casse ´egyp- tienne [3], republi ´ee dans [6]. Voici un exemple du processus de ligature du mot

¡mÍ

^,

en suivant les traditions typographiques ´egyptiennes :

— ” — (lettres disjointes) ;

— –mH(ligatures obligatoires seulement, lettres reli ´ees) ;

— –mÆÀ(ligature esth ´etique entre les deux premi `eres lettres) ;

— –^to(ligatures esth ´etiques entre les trois premi `eres lettres) ;

Pour produire toutes les ligatures possibles (plus de 1500) de deux, trois ou quatre lettres, il a fallu trois tableaux de 256 caract `eres. Chaque ligature est construite par su- perposition de petits ´el ´ements. Une fois que TEX sait quels caract `eres prendre, et dans

quelle fonte, il lui suffit alors de les superposer (aucun d ´eplacement n’est n ´ecessaire).

Le probl `eme est de reconnaıˆtre l’existence d’une ligature et de d ´ecouvrir quels sont les caract `eres n ´ecessaires. Ce processus d ´epend fortement des fontes. Une fonte diff ´e- rente — par exemple en style Kuffic ou Nastaliq — peut avoir un ensemble de ligatures compl `etement diff ´erent, ou aucune ligature (comme la police de base, dans laquelle sont

´ecrits les deux mots

µr` , @y

, et qui est largement utilis ´ee en composition ´elec- tronique gr ˆace `a sa lisibilit ´e) ; n ´eanmoins, les ligatures obligatoire restent exactement les m ˆemes, quelle que soit la fonte utilis ´ee.

Jusqu’ `a maintenant, il existe trois solutions au probl `eme des ligatures arabes obliga- toires :

— La premi `ere, par K. Lagally [10], consiste `a utiliser des macros TEX pour d ´etecter et appliquer les ligatures obligatoires (dans notre terminologie : « faire l’analyse contextuelle »). Ce processus est malcommode et long. Il d ´epend beaucoup du codage de la fonte et les macros utilis ´ees peuvent interf ´erer avec d’autres macros TEX. Tout compte fait, ce n’est pas la fac¸on naturelle de traiter un ph ´enom `ene qui est une caract ´eristique fondamentale de l’ ´ecriture arabe.

— La deuxi `eme, par le premier auteur [5], consiste `a utiliser les ligatures propres `a TEX (coupl ´ees avec TEX--XET, la version bidirectionnelle de TEX) ; sur le fond, ce processus est plus naturel, puisque l’analyse contextuelle est faite « dans les cou- lisses », au plus bas niveau, `a savoir celui des fontes lui-m ˆeme. Il ne d ´epend pas du codage de la police, puisque chaque fonte peut utiliser son propre jeu de liga- tures. L’inconv ´enient r ´eside dans le nombre de ligatures n ´ecessaire pour r ´ealiser la t ˆache : environ 7000 ! La situation devient dramatique quand on veut utiliser une douzaine de polices arabes sur la m ˆeme page : TEX chargera 7000 ligatures pro- bablement strictement identiques pour chaque police. Vous aurez besoin de bien plus qu’un BigTEX pour cela.

— La troisi `eme, ´egalement par le premier auteur [5], utilise un pr ´eprocesseur. L’in- t ´er ˆet en est que l’analyse contextuelle est r ´ealis ´ee par un utilitaire d ´edi ´e `a cette t ˆache, avec plusieurs fonctionalit ´es suppl ´ementaires (par exemple l’ajout de jonc- tions de longueur variable, aussi appel ´ees « keshideh ») ; c’est une m ´ethode rapide qui utilise tr `es peu de m ´emoire. Cette m ´ethode pr ´esente malheureusement les inconv ´enients classiques des pr ´eprocesseurs traitant un document avant TEX : un fichier peut en inclure un autre (\input), depuis un endroit quelconque de votre r ´eseau, et vous ne pouvez pas savoir `a l’avance quels fichiers seront lus, et donc devront ˆetre pr ´etrait ´es ; les directives du pr ´eprocesseur peuvent interf ´erer avec les macros TEX ; il n’y a pas d’imbrication entre elles, ce qui peut facilement entraıˆner des erreurs par rapport aux op ´erations de groupage de TEX, etc.

Aucune de ces m ´ethodes ne peut ˆetre appliqu ´ee `a une production `a grande ´echelle d’arabe dans la vie r ´eelle : dans tous les cas, l’ ´ecriture arabe est trait ´ee comme un

« puzzle `a r ´esoudre » et, in ´evitablement, les performances de TEX en ressentent.

Nous utilisons desWTP pour fournir une solution naturelle au probl `eme ; consid ´erons

`a nouveau l’exemple du mot–^to:

— D’abord,

¡mÍ

^{est lu par}W, en translit ´eration latine (tHml^{) ou enISO8859-6, ou} en ASMO, ou en codage Macintosh arabe, ou en un quelconque codage d’entr ´ee arabe acceptable.

— Le premierWTP convertit cette entr ´ee en codesISO10646/UNICODEpour lettres arabes : 0x062a ^(, ARABIC LETTER TEH), 0x062d ^(, ARABIC LETTER HAH), 0x0645^(—,ARABIC LETTER MEEM),0x0644^(”,ARABIC LETTER LAM) ;

— ISO10646/UNICODE´etant une fac¸onlogique de coder les lettres arabes, et pas une fac¸on graphique, il n’y a pas d’information sur leur forme contextuelle (isol ´ee, ini- tiale, m ´ediale, finale). Le deuxi `emeWTP envoit ces codes `a la zone priv ´ee, ou` nous avons (de fac¸on interne) r ´eserv ´e des positions pour la combinaison de caract `eres arabes et de formes contextuelles. Une fois que c’est fait,Wconnaıˆt la forme de chaque caract `ere.

— Le troisi `emeWTP traduit simplement ces codes dans un codage police TEX stan- dard 16 bits (c’est une op ´eration mineure : la zone priv ´ee ´etant situ ´ee `a la fin du tableau 16 bits, nous d ´eplac¸ons tout le bloc au d ´ebut du tableau).

— Si la fonte n’a pas de ligatures esth ´etiques, c’est fini : Wva envoyer les r ´esultats du dernierWTP au fichierdvi, et produire

¡mÍ

. D’un autre c ˆot ´e, s’il y a encore des ligatures esth ´etiques — comme dans–^to— alors elles seront ins ´er ´ees dans la fonte, en tant que ligatures intelligentes (“smart ligatures”). Puisque les tables des fontes peuvent contenir jusqu’ `a 65536 caract `eres, on a toute la place n ´ecessaire pour mettre les petites parties caract `eres `a combiner.⁹

Ce que nous avons r ´ealis ´e consiste `a ce que le processus fondamental d’analyse contextuelle soit trait ´e par une machinerie en arri `ere-plan (exactement comme TEX fait la c ´esure et divise les paragraphes en lignes), et que les raffinements esth ´e- tiques ´eventuels soient exclusivement g ´er ´es par les fontes (par analogie avec les fontes romaines qui ont plus de ligatures que celles pour machine `a ´ecrire, etc).

2.6.2. L’arabe voyellise´ (les choses deviennent plus difficiles)

Dans l’arabe contemporain ordinaire, on ´ecrit seulement les consonnes et les voyelles longues ; le lecteur doit deviner les voyelles courtes, en utilisant le contexte (les m ˆemes consonnes avec des voyelles courtes diff ´erentes peuvent ˆetre comprises comme verbe, comme nom ou adjectif etc.). Quand il est essentiel de sp ´ecifier des voyelles courtes, on ajoute de petits signes diacritiques au-dessus ou au-dessous des lettres.

A c ˆot ´e des voyelles courtes, il y a aussi des diacritiques pour les consonnes doubles,` pour indiquer l’absence de voyelle, et pour le coup de glotte (comme dans « Oh-oh ») : en comptant toutes les combinaisons, nous arrivons `a 14 signes. Ces diacritiques peuvent

9Si ces ligatures esth ´etiques sont utilis ´ees dans plusieurs polices, on pourrait rencontrer le m ˆeme probl `eme de sur- charge de la m ´emoire fonte deW; dans ce cas, on peut toujours ´ecrire un quatri `emeWTP, qui ferait syst ´ematiquement l’analyse « esth ´etique » ind ´ependamment des codes d’analyse contextuelle.

rendre la vie difficile `a TEX, car ils doivent ˆetre cod ´es entre les consonnes, et interviennent ainsi dans l’algorithme d’analyse contextuelle : supposons par exemple que TEX doive composer la lettrex, derni `ere lettre d’un mot, suivie d’un point. Apr `es la lecture du point, TEX sait que la lettre doit ˆetre sous forme finale (l’une des 7000 ligatures doit ˆetre<<sup>x sous</sup> forme m ´ediale> + <.><sup>!</sup><x sous forme finale><.>). Supposons maintenant que la lettre soit imm ´ediatement suivie d’une voyelle courte, qui dans notre cas est forc ´ement plac ´ee entre la lettrex et le point. Les ligatures intelligentes de TEX ne peuvent revenir deux positions en arri `ere ; quand TEX d ´ecouvre le point apr `es la voyelle courte, il est trop tard pour convertir lex m ´edial en un x final.

Heureusement, lesWTP sont suffisamment ing ´enieux pour d ´eterminer la forme des lettres, quelles que soient les diacritiques qui les entourent (ce qui est exactement l’at- titude d’un typographe humain, qui compose d’abord les lettres, puis ajoute les diacri- tiques correspondantes).

N ´eanmoins, lesWTP ne sont pas parfaits, et il y a des probl `emes impossibles `a r ´e- soudre m ˆeme avec lesWTP les plus efficaces : le positionnement des diacritiques par exemple. Nous savons tous que TEX (et par cons ´equentW, qui n’est rien de plus qu’une humble extension de TEX) place tous les ´el ´ements sur la page en utilisant des boıˆtes. Mal- heureusement, le positionnement des diacritiques n ´ecessite plus d’informations que les seules hauteur, largeur, profondeur et correction d’italique d’un caract `ere ; dans certains cas, un v ´eritable examen de la forme du caract `ere lui-m ˆeme et des caract `eres adjacents est n ´ecessaire (pensez aux ligatures construites verticalement `a partir de quatre lettres, chacune ayant sa propre diacritique).

Ce probl `eme peut facilement ˆetre r ´esolu pour une fonte sans ligature (esth ´etique) : en comptant toutes les lettres possibles (sans oublier le farsi, l’ourdou, le pashto, le sindhi, le kirghiz, l’ouigoure et d’autres langues utilisant des variantes des lettres arabes), dans toutes les formes possibles, on peut arriver `a un nombre ne d ´epassant pas 1000 glyphes. En combinant ces glyphes avec les 14 signes diacritiques, on atteint moins de 14 000 positions, un chiffre bien en-dessous de la limite de 65 536 caract `eres. Puisque la zone priv ´ee deISO10646/UNICODEn’est pas assez grande pour g ´erer autant de ca- ract `eres, nous utiliserons unWTP suppl ´ementaire pour envoyer des combinaisons de

<consonnes ou voyelles longues analys ´ees contextuellement>^et<diacritique>^{vers des} codes du codage fonte en sortie. L’avantage de cette m ´ethode est de permettre de pla- cer individuellement chaque diacritique (en comptant une minute pour trouver la position id ´eale d’un signe diacritique, la fonte peut ˆetre termin ´ee en quatre semaines de travail r ´egulier), mais on peut utiliser des m ´ethodes QDTEXVPL pour placer automatiquement les diacritiques, puis faire les corrections n ´ecessaires.

Malheureusement le nombre de positions n ´ecessaires dans les fontes croıˆt de fa- c¸on astronomique quand nous consid ´erons des ligatures de 2 ou 3 lettres. Un des futurs d ´efis du projetWsera d’analyser les caract `eres manuscrits arabes et de trouver les pa- ram `etres n ´ecessaires pour d ´eterminer le positionnement des diacritiques, exactement comme D.E. Knuth l’a fait pour la composition math ´ematique. Il faut noter que malgr ´e l’immense complexit ´e de cette t ˆache, nous restons dans le strict domaine de latypo-

graphie arabe, qui n’est apr `es tout rien de plus qu’une version re´duite et simplifie´e de la calligraphie arabe.

2.7. Langues a` plusieurs syste`mes d’e´criture (« savez-vouslire le vietnamien ? ») Les Occidentaux comme les Arabes ont eu l’habitude — pas vraiment d ´emocratique

— d’imposer leur alphabet aux nations dont ils faisaient la conqu ˆete (de fac¸on militaire, religieuse, culturelle ou technologique). Aussi arrive-t-il que nous puissions lire le vi ˆetna- mien (mais sans le comprendre) tout comme n’importe quel Arabe peut lire le malais et le sindhi, et ne pas en comprendre un mot (sauf peut- ˆetre quelques mots arabes qui ont accompagn ´e l’alphabet dans ses voyages).

Dans certains cas, plusieurs ´ecritures sont rest ´ees en usage pour la m ˆeme langue et des efforts sont faits pour ´eclaircir et standardiser les ´equivalences entre les lettres de ces diff ´erentes ´ecritures, en vue de fournir un algorithme efficace de translit ´eration.

Le premier auteur a travaill ´e sur deux cas qui concernent l’ ´ecriture arabe : le berb `ere et le comorien.

2.8. Le berbe`re : une langue a` trois syste`mes d’e´criture et deux directions d’e´criture

La langue berb `ere (les Berb `eres l’appellent le « tamazight ») peut ˆetre ´ecrite en arabe, en latin ou en ´ecriture native (« tifinagh »). Le premier auteur a d ´evelopp ´e, sous la di- rection de Salem Chaker, directeur du d ´epartement d’ ´etudes berb `eres de l’Institut Na- tional de Langues Orientales `a Paris, une police tifinagh en^METAFONT. Voici un petit exemple de texte berb `ere, ´ecrit en tifinagh, de gauche `a droite.

Tifina†, d_tira timzwura n Imazi†n. L‰ant di tmurt_nŠ† dat tira n ta›rabt d_tla„init. NŠulfant_dd dat imir n ugl‰id Ma- sinisn. Imazi†n n imir_n, ttarun_tnt †f i…ra, dgg ifran, †f igdurn, maca tig g ti †f i…kwan : ttarun fl‰_asn ism n umt- tin, d wi_t_ilan, d wayn yxdm di tudrt_is akkn ur t ttttun ina„farn.

Le m ˆeme texte en tifinagh, mais de droite `a gauche :

tad †Šn_trumt id tna‰L .n†izamI n aruwzmit arit_d ,†anifiT

-aM di‰lgu n rimi tad dd_tnafluŠN .tini„alt_d tbar›at n arit

f† ,narfi ggd ,ar…i f† tnt_nuratt ,n_rimi n n†izamI .nsinis

-tmu n msi nsa_‰lf nuratt : nawk…i f† it g git acam ,nrudgi

nutttt t ru nkka si_trdut id mdxy nyaw d ,nali_t_iw d ,nit

.nraf„ani

et en ´ecriture arabe :

" ,rÿ ÿi\ V, ˜¼_V=um\ ^#ü .$ÿ ÿ—~am " ,=í`zÿ ÿmi\ ,ri\_ ,•aÿ ÿnifi\

.$ÿ ÿsiniOa di¹` " rim V, í_^ÿ ÿ#afu¼ .^ÿ ÿiniû\_ ^,rša\

aÿÿa ,"=`dg – ,",rf í ,,=” – ^ÿÿn\_"`=a ,"_rÿÿim " $—~am

$,` ,"û_V_` ,$ÿÿiÃ` " ÿÿs $ÿÿO,_í "`=a : ",w” ÿÿ– tÛi\

."=aÿÿfan "uÿÿàV =` $ÿÿ¶, P_V=u\ dx

Le codage de ces fontes est conc¸u de sorte qu’on puisse traiter la m ˆeme entr ´ee TEX en translit ´eration latine, en tifinagh de gauche `a droite, de droite `a gauche ou en arabe.

Il suffit de changer une macro au commencement du traitement. R ´ealiser cette fonc- tionnalit ´e a ´et ´e plus ou moins simple pour le latin et le tifinagh, mais pas autant pour l’arabe. Malheureusement, cette police pr ´esente tous les probl `emes des fontes arabes ordinaires : il faut plus de 7 500 ligatures pour faire l’analyse contextuelle, et elle est sur- charg ´ee : il n’y a plus la place d’ajouter un seul caract `ere, un inconv ´enient pour une langue qui est encore en train d’ ˆetre standardis ´ee.

Une autre source de difficult ´es r ´eside dans le fait que les ´equivalences entre l’ ´ecriture latine, tifinagh et arabe ne sont pas imm ´ediates. Certaines voyelles courtes sont ´ecrites dans le texte latin, mais pas dans celui en arabe ou en tifinagh. De plus, les consonnes doubles sont ´ecrites explicitement en latin et tifinagh, mais comme une consonne simple en arabe. Et peut- ˆetre le probl `eme le plus difficile `a r ´esoudre est de faire en sorte que chaque ´ecrivain berb `ere se sente « chez lui », quelle que soit l’ ´ecriture qu’il utilise : il ne doit pas avoir l’impression qu’une ´ecriture est privil ´egi ´ee par rapport aux deux autres !

Finalement, le dernier probl `eme (qui n’est pas le moindre quand il se pose dans le monde de la production) est que nous avons besoin d’une police arabe sp ´eciale pour le berb `ere, `a cause de la diff ´erence de translit ´eration en entr ´ee : par exemple, alors qu’avec la translit ´eration arabe ordinaire nous utilisons « v » pour

–

et « sh » pour

^

, en berb `ere nous sommes oblig ´es d’utiliser « g » pour le premier et « c » pour le dernier. Il y a deux lettres suppl ´ementaires utilis ´ees pour le berb `ere en ´ecriture arabe :et^“; ces lettres sont aussi utilis ´ees en sindhi et pachtou, de sorte que les glyphesexistent d ´ej `a dans le syst `eme TEX standard arabe ; mais en berb `ere, ils doivent ˆetre transform ´es par transli- t ´eration en « j » et « z », `a cause des ´equivalences avec l’alphabet latin. Ceci nous force

`a utiliser un sch ´ema de translit ´eration diff ´erent de celui pr ´evu pour l’arabe ordinaire, et donc — en raison de l’incapacit ´e de TEX `a s ´eparer clairement les codages entr ´ee et sortie

— d’utiliser une fonte de sortie TEX cod ´ee diff ´eremment. Supposez que vous soyez en train de composer un livre `a la fois en berb `ere et en arabe ; vous aurez besoin de deux polices graphiquement identiques pour chaque style, corps, graisse et famille, chacune d’entre elle ayant plus de 7 000 ligatures. Et nous ne parlons que de fontes sans ligatures esth ´etiques !

W r ´esoud ce probl `eme en utilisant les m ˆemes fontes en sortie pour l’arabe ordi- naire et le berb `ere. Nous devons simplement remplacer le premierWTP de la chaıˆne

de traduction : celui qui convertit l’entr ´ee brute en codesISO10646/UNICODE. Les lin- guistes berb `eres sont libres d’inventer/introduire de nouveaux caract `eres ou signes dia- critiques ; pour peu qu’ils soient inclus dans le tableauISO10646/UNICODE, il nous suffit de changer l ´eg `erement le premierWTP (et si ces signes ne sont pas encore dansISO

10646/UNICODE, nous utiliserons la zone priv ´ee).

2.9. Le comorien : e´criture latine africaine ou arabe

La situation est similaire dans les petites ıˆles des Comores, entre Madagascar et le continent africain. Les alphabets latin (avec quelques adjonctions venant de langues afri- caines) et arabe sont utilis ´es. `A cause des nombreux sons qu’il faut diff ´erencier, on utilise des diacritiques accompagnant des lettres arabes. Ces diacritiques ressemblent aux dia- critiques arabes (pour des raisons pratiques) mais elles ne sont pas utilis ´ees de la m ˆeme fac¸on ; en fait, elles font partie des lettres, exactement comme les points font partie des lettres de l’arabe ordinaire.

Une fois encore, la situation peut facilement ˆetre g ´er ´ee par unWTP. Alors que les pro- positions d’insertion dansISO10646/UNICODEne sont pas encores claires (la proposition faite par Ahmed-Chamanga, de l’Institut des Langues Orientales `a Paris, circule mainte- nant entre minist `eres et institutions ´educatives et religieuses), les Comoriens peuvent d ´ej `a utiliserWpour faire la composition et faire progresser le sch ´ema de translit ´eration `a la vol ´ee.

2.10. Le cambodgien

Comme not ´e dans [4], l’ ´ecriture cambodgienne utilise des groupes consonantiques, des consonnes souscrites, des voyelles et des signes diacritiques. A l’int ´erieur d’un` groupe, TEX doit d ´eplacer les diff ´erents composants pour les positionner correctement.

Il en r ´esulte que TEX doit utiliser des commandes\kernentre chaque composant d’un groupe. Aussi n’y a-t-il plus de cr ´enage : supposons que les caract `eres^Bet^kdoivent ˆetre cr ´en ´es ; et supposons que la consonne^Best (logiquement) suivie de la consonne souscrite ^€, qui est (graphiquement) plac ´ee sous cette lettre : ^B€k. Pour TEX,^kne suit plus imm ´ediatement^B, et ainsi il n’y aura aucun cr ´enage entre ces lettres ; n ´eanmoins, graphiquement elles sont toujours adjacentes, et doivent donc ˆetre ´eventuellement cr ´e- n ´ees.

Wutilise une m ´ethode marteau-pilon pour r ´esoudre ce probl `eme : nous d ´efinissons une « grande » fonte cambodgienne (virtuelle), contenanttous les groupes actuellement connus. Comme nous l’avons d ´ej `a mentionn ´e dans [4], `a peu pr `es 4 000 codes devraient suffire. On peut ´evidemment encore utiliser les m ´ethodes traditionnelles de TEX pour former des groupes consonantiques exceptionnels, non contenus dans cette police.

Comme en arabe, nous venons `a bout de la complexit ´e du cambodgien en s ´eparant les t ˆaches. Un premierWTP enverra la m ´ethode d’entr ´ee que l’utilisateur a choisie vers les codes cambodgiens d’ISO10646/UNICODE(en r ´ealit ´e) il n’existe encore aucun code cambodgienISO10646/UNICODE, mais le premier auteur a soumis une proposition de