[Unicode] Distinction caractère/glyphe/graphème/typème/raton-lav eur

[orandier@xxxxxxxxxxxxxxxxxxx (Olivier RANDIER)]

...Suite du précédent message

Bon, développons un peu, en prenant deux exemples : la petite cap A, et la
ligature ffi, choisis à dessein parmi ce qui n'est, pour l'instant, pas
géré de façon conforme.

1/ Au niveau de la saisie, la ligature ffi n'a pas lieu d'exister, puisque
si elle existe dans la fonte, sa substitution doit être automatique et
systématique, ce qui peut donc être géré par le système. En ce qui concerne
le A petite cap, ça se discute plus, mais il me semble que c'est plus à
l'utilisateur de décider - après saisie - d'utiliser l'attribut petite cap.

2/ Au niveau du code texte, la ligature ffi constitue une gène, si elle
n'est pas identifiée en tant que représentation de la séquence de texte
f-f-i. C'est la raison pour laquelle les tenants d'Unicode ne souhaitent
pas intégrer les ligatures à la norme. Concernant la casse, une position
"caractère seulement" franchement intégriste a été défendue par certains,
même si Unicode reconnait, d'ors et déjà, la distinction caps/bas-de-casse.
Je rappelle simplement ici que, en Allemand, par exemple, les noms prennent
une capitale initiale, ce qui fait de la casse un attribut fortement
discriminant, orthographiquement parlant.

3/ Au niveau de l'enrichissement typographique, par contre, il est
indispensable, si l'on souhaite, à long terme, préserver la richesse
typographique de nos traditions - qui répond d'abord à des exigences
pratiques - que la ligature ffi puisse être systématiquement substituée,
que l'on puisse composer en petites caps par simple sélection d'un
attribut. Il importe également, et c'est là le point délicat, que l'on
puisse continuer à utiliser les outils précédemment décrits MEME après
l'enrichissement. Enfin, on doit pouvoir transmettre aisément ce texte avec
tous ses enrichissements, sous un format de fichier accessible à tous, même
en l'absence des fontes utilisées.

4/ Une fois le texte enrichi et transmis sous le format adéquat,
l'utilisateur lambda doit pouvoir l'afficher et l'imprimer en utilisant les
fontes qu'il a à sa disposition. Il faut donc que le système soit capable,
si les fontes en question ne comporte pas de ligatures, de décomposer la
ligature ffi en la séquence de glyphes f-f-i, et de calculer également des
caps du corps de la hauteur d'oeil des bas-de-casse, pour remplacer les
petites caps manquantes.

En fonction de tous ces critères, il semble raisonnable de ne pas inclure
les ligatures ni les petites caps dans Unicode, mais plutôt dans une norme
parallèle destinée aux fondeurs.
Oui, mais...
Mais ce qui paraît raisonnable n'est pas forcément pratique, ni,
simplement, humain. À l'heure actuelle, les ligatures fi et fl sont
incluses dans la norme ASCII Macintosh. Moyennant quoi, il a été aisé pour
les développeurs d'XPress d'inclure une option dans XPress permettant de
substituer automatiquement ces ligatures, sans handicaper les outils de
traitement du texte, ce qui prouve qu'on sait le faire. Si on dispose d'un
codage plus large, et contenant toutes les ligatures "systématiques", il
sera tout aussi facile de concevoir l'insertion automatique de balises
<ligature> n'altérant pas le sens du texte, tout en autorisant un
enrichissement correct. Par contre, si ces ligatures ne font pas partie
d'Unicode, étant donné que les probabilités de la disposition simultanée de
deux normes informatiques parallèles et capables de fonctionner ensemble
tendent vers... zéro :( , il y a fort à parier que les ligatures devront
continuer d'être hors normes, et nous de les saisir "à la main" <g>. Donc,
je pense que les ligatures doivent être incluses dans Unicode. On pourra
alors rêver de disposer dans XPress, voire au niveau même du système, d'une
option de ce genre (les × représentent des cases à cocher) :
× Usage des ligatures
× sans s long
× sans s long (sauf eszet)
× etc. ?

Concernant les petites caps, je suis, par contre, partisan de ne pas les
inclure, parce qu'il paraît plus simple de prévoir une balise <petites
caps> dans un format de texte enrichi, en laissant le soin au système soit
de les calculer - ce qui est faisable, en utilisant les axes "graisse" et
"corps" de Multiple Masters, soit de les sustituer - de la même façon qu'on
substitue la fonte italique au romain quand on utilise la balise
<italique>, plutôt que de prévoir un autre algorythme de substitution de
code aller/retour comme pour les ligatures. C'est au niveau de
l'environnement graphique et des fontes qu'il faut prévoir les combinaisons
balises/descriptifs de style nécessaires. C'est, à mon sens, l'un des
objectifs des fonctions typographiques avancées de QuickDraw GX qui seront,
si tout va bien, intégrées à Display PostScript.

À suivre...

Olivier Randier - Experluette