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
- Re: [typo] IKEA, (continued)
- Re: [typo] IKEA, Pierre Marchand (19/09/2006)
- Re: [typo] pas IKEA, Thierry Bouche (20/09/2006)
- Re: [typo] pas IKEA, Pierre Marchand (01/10/2006)
- Re: [typo] pas IKEA, Thierry Bouche <=
- Message not available
- Re: [typo] IKEA, Anne Guilleaume (19/09/2006)
Re: [typo] IKEA, Blue Cox (19/09/2006)
- Re: [typo] IKEA, Thibaud Sallé (19/09/2006)
- Re: [typo] IKEA, Alain Joly (20/09/2006)
- Re: [typo] IKEA, Thibaud Sallé (20/09/2006)
Re: [typo] IKEA, philpask (19/09/2006)
- Re: [typo] IKEA, Alain Joly (19/09/2006)