Archive Liste Typographie
Message : Re: [typo] pas IKEA

(Thierry Bouche) - Lundi 02 Octobre 2006
Navigation par date [ Précédent    Index    Suivant ]
Navigation par sujet [ Précédent    Index    Suivant ]

Subject:    Re: [typo] pas IKEA
Date:    Mon, 2 Oct 2006 11:58:04 +0200
From:    Thierry Bouche <thierry.bouche@xxxxxxxxxxxxxxx>

Bonjour Pierre,

P> J'ai mis du temps à comprendre ce que vous entendiez par « purement
P> graphique », j'imagine que c'est la composition par juxtaposition de
P> boîtes que vous souhaitez voir remise en question.

oui. En fait tout le modèle actuel, en particulier en finir avec la
notion de fonte.

P> Dans ce cas, cela revient à vouloir faire un calligraphe du programme
P> de composition.

plus ou moins, mais c'est l'idée. Il n'y a que deux raisons tangibles,
aujourd'hui, de tenir aux fontes :
 1. les « hints » (dont la « nécessité » est surtout une conséquence
 d'insuffisance technologique et matérielle qui ne va pas durer
 longtemps ; sans parler d'autres raisons nettement plus douteuses).
 2. conserver un lien assez fort entre texte composé et texte « source ».

(1) est généralement considéré comme en fin de vie. On peut dire qu'une
large part d'Opentype est destinée précisément à améliorer (2) par
rapport à Truetype ou Type 1. Bon, mais j'oublie probablement la
troisième (et plus importante) :
 3. « on sait faire ».

P> Ce n'est pas rien et je me demande si l'effort à fournir pour sortir de
P> l'ère du caractère mobile se justifie. Car finalement, manque-t-il à sa
P> mission de nous donner à lire ?

Pour ce qui nous concerne, non ; et puis, comme me le disait un jour
quelqu'un, on peut toujours tout faire avec une palette de caractères
sous illustrator. Notre problème à nous, c'est juste qu'on n'est pas
prêts pour faire à la fois de la typographie et du document électronique
: soit on fait de la typo comme à l'époque de Gutenberg en plaçant un
par un des glyphes pris dans une casse, et le texte est complètement
perdu ; soit on stocke le texte, et alors il faut des tas de gadgets
dans la police pour qu'elle affiche des choses un peu plus drôles, et il
devient très difficile de faire des modifs à la main sans altérer le
Sens (donc s'en prendre à la Démocratie !). Pour voir cette dualité,
imaginez que vous envoyez à un abonné aveugle le PDF du programme du
prochain concert de musique ancienne, avec police et mise en page
adaptée aux instruments d'époque : aucune raison de sacrifier la
typo parce qu'un seul ne la verra pas ; mais ce serait fâcheux de rendre
le texte incompréhensible à cause de ça si on ne le voit pas.

De nos jours, comment traite-t-on ce problème ? à plusieurs niveaux :
pour les cas simples, la police contient une table de correspondance,
dite ToUnicode, qui dit que tel glyphe de telle police « vaut » tel
caractère unicode. Mais il y a les ligatures, les formes spéciales,
etc. : ça marche encore si on a une cible unicode (lig. ff -> f+f) mais
plus du tout si ce qui se trouve dans la police n'a de sens que dans son
contexte (penser aux demi-formes liées de l'anglaise de Didot !) ; dans
ce cas on fait ce que je suggère de faire systématiquement : on met dans
le PDF deux flux parallèles, un de caractères unicode, l'autre de
glyphes.

Ces problèmes s'aggravent avec les langues ou les traditions écrites où
les rapports entre glyphe et caractère sont sont encore plus sauvages
que ça (mais, si on y pense un peu sérieusement, on se rend assez vite
compte qu'une solution générale à ce genre de problème ouvrirait pour
nous des perspectives que nous n'imaginons même pas aujourd'hui parce
que nous sommes pris dans ce paradigme des fontes). Il faut une infinité
de glyphes pour composer proprement l'arabe, alors qu'il faut un nombre
de caractères assez réduit : d'une certaine façon, si j'en crois un
exposé entendu cet été, le volant graphique de la calligraphie
traditionnelle est toujours complètement hors de portée de
l'informatique. Idéalement, on justifie par les noirs uniquement : il
n'y a pas d'espace intermot (les mots sont déterminés par l'emploi de
forme initiales ou finales, pas de blanc du tout), on justifie donc en
utilisant des variantes de glyphes, et on ajuste in fine la longueur de
certains fûts horizontaux. Ça n'est possible que si le programme calcule
à la volée la forme ad hoc dudit fût (ce qui, aujourd'hui, impose de
brancher des choses qui sont des glyphes de fonte sur des éléments
purement graphiques, ou de torturer le dessin des polices pour qu'il
puisse contenir des lignes droites horizontales).

Bref, je dis seulement que l'idée que la lettre "a" soit à la fois la
commande « imprimer le glyphe n° a de telle police » et le caractère a
est certes une simplification pratique, mais qui impose beaucoup de
limitations.


-- 
Cordialement,
 Thierry