[ALGO. DE COMPO. DANS LES POLICES] [long] langage de composition

[Fekete Jean Daniel 0251858208 <Jean-Daniel.Fekete@xxxxxx>]

Après avoir écrit qu'il valait mieux penser à passer d'une séquence de
caractères (UNICODE par exemple) à une à une séquence de glyphes
positionnés que de codifier les glyphes, je propose de commencer un
fil de discussion sur ce thème.

Pour résumer, l'idée que je voudrais poursuivre est la suivante :
inclure dans la police de caractère le ou les algorithmes destinés à
composer avec cette police.

Par exemple, la police de l'anglaise de Didot contiendrait un
algorithme qui composerait les caractères du mot "azuré" avec la liste
des glyphes suivant : l'attaque du "a", suivi d'une descendant
verticale liée au "z", suivi du premier jambage du "u", suivi du
second jambage du "u" lié au premier jambage du "r", suivi du "é"
final.  Dans ce cas particulier, aucune correction d'approche n'est
nécessaire.  Dans le cas général, les glyphes peuvent être déplacés
pour être convenablement composés, pour le crénage en particulier.

À mon avis, l'algorithme doit être stocké sous une forme pratiquement
exécutable par un interprète PostScript (ça ne veut pas dire écrit en
PostScript) pour que la composition puisse se faire au moment de
l'impression s'il le faut.  Il doit être très compact pour ne pas trop
« alourdir » les polices.  Je suggère donc une machine virtuelle
adaptée à la tâche particulière, comme pour TrueType ou Java.

J'imagine le scénario que pourrait utiliser un système de traitement
de texte : lors de la sélection de la police, le système charge les
tables liées à la police, dans lesquelles un ou des algorithmes sont
définis.  Il sélectionne l'algorithme adapté au mode de composition
courant (suivant la langue, le niveau de décoration typographique, et
d'autres attributs dont on pourrait discuter).  Il utilise
l'algorithme pour sélectionner les glyphes et les placer à l'écran
interactivement.  Lors de l'impression, le système a le choix entre
envoyer la liste des glyphes placés à l'imprimante (PostScript
traditionnel) ou envoyer les caractères et les algorithmes (version
imprimable ET rééditable).

Apple a déjà bien travaillé sur les fonctionnalités nécessaires à
cette composition dans QuickDraw GX.  Il n'est donc pas indispensable
de réinventer la roue, on peut réutiliser leur interface.  En
revanche, les algorithmes utilisés par GX sont implémentés en
assembleur 68000 et Power PC, ce qui ne les rend pas indépendant de la
plateforme d'exécution.  De plus, ils reposent sur la bibliothèque
graphique QuickDraw.

Si la liste typographie est intéressée, j'enverrai l'interface
proposée par Apple et on pourra commencer une discussion technique.
De mon point de vue, trois choses sont intéressantes :

1) quel type de langage veut-on utiliser pour décrire les algorithmes
2) les attributs définis par GX pour sélectionner les algorithmes nous
   conviennent-ils ?
3) peut-on définir des algorithmes utilisables dans la majorité des
   polices (occidentales pour commencer) en mode de composition
   standard, et pour lesquelles des tables suffiraient à décrire les
   spécificités ?  Un algorithme comme celui de TeX rentre dans ce
   cadre, bien qu'il pose des problèmes en WYSIWYG car il remet en
   cause les coupures de lignes du paragraphe entier à chaque
   modification du paragraphe.  Il utilise bien des tables (stockées
   dans les fichiers tfm ou vf) pour décrire la composition.

J'attend impatiemment des commentaires ou question.

  Jean-Daniel Fekete
  Ecole des Mines de Nantes
  La Chantrerie, 4 rue Alfred Kastler, 44070 Nantes Cedex 03, France
  Voice: +33-2-51-85-82-08 / Fax: +33-2-51-85-82-49
  E-mail: Jean-Daniel.Fekete@xxxxxx