Re: [XP] langages scientifique, substitution automatique

[Olivier RANDIER <orandier@xxxxxxxxxxx>]

>>Is there anything for chemistry, etc?

On a dit un peu vite qu'il n'existait pas de polices de chimie. Dans mon
catalogue Linotype, je viens de remarquer un groupe de 5 polices appelées
Universal Chemical Pi. Je pense que ça peut en intéresser certains. Il
semble y avoir aussi quelques trucs dans Maths et Technical, chez Agfa.

>>Will people usually want _all_ the
>>contextual substitutions in say, a discretionary ligature feature?
>>
>Évidemment pas : je veux des ligatures « ffi », pas de ligature « st » et
>« ct » : c'est un cas banal...
>
>Je veux disposer du jeu de ligatures spéciales (et codées n'importe
>comment ;-)) inventée par le dessinateur de telle jolie police, très
>décorative et un peu absurde - au hasard : quelqu'un qui vectorise un
>AvantGarde complet, avec le jeu de ligatures qu'avait prévu son concepteur
>H. Lubalin -, mais seulement dans la titraille, pas dans le texte courant.
>Tout cela demande évidemment une énorme souplesse et que l'utilisateur ait
>le dernier mot, à l'inverse d'un programme « dictateur ».

Dans mon idée, il faudrait un véritable moteur de substitution, qui
pourrait être le même que le moteur de recherche. On enregistre une série
de requêtes, qu'on peut lier à une (méta)fonte ou à une feuille de style.
Ces requêtes sont ensuite exécutées récursivement et dynamiquement, en
toute transparence.
Ce serait d'ailleurs aussi une amélioration pour le moteur de recherche :
au lieu de faire recherche après recherche, on enregistre une série de
requêtes qu'on exécute d'un seul coup. Bien sûr, on doit pouvoir
enregistrer ces requêtes dans des fichiers séparées, pour pouvoir les
réutiliser (utile pour nettoyer les textes d'un client qui fait toujours
les mêmes erreurs de saisie).
Il faut pouvoir dire au programme de substituer ffi en expert à f-f-i en
standard, mais aussi un e alternate à la place d'un e final, mais seulement
en fin de ligne, par exemple. Ou bien d'utiliser les swash caps de la
troisième série de Poetica en début de ligne et celle de la première série
pour le reste. Ou encore les chiffres elzéviriens avec corrections
d'approche dans le texte et les chiffres capitales semi-cadratinés dans les
tableaux.
Ou encore remplacer tous les v isolés en italique par des nu.
Ou les lettres bas de casse après un chiffre par des lettres supérieures en
expert (1er, 2e -> 1^er, 2^e).
Ou substituer un glyphe composé dans l'éditeur _ad-hoc_ à une combinaison
bidouillée dans le texte.
Et tutti quanti.
Donc il faut pouvoir TOUT contrôler. Avec un petit popup à la PopChar dans
l'interface, ça le ferait bien. Et on doit pouvoir appliquer des
modifications de style (parangonnage, corrections d'approche, etc.) lors de
ces substitutions. À l'occasion (fontes calligraphiques ou à formes
multiples, comme Beowulf), un paramètre aléatoire serait utile aussi.
C'est très important. Je n'imagine même pas le nombre de casse-têtes qui
pourraient être résolus avec un tel système.

>>But it would certainly be interesting (and
>>hard) to define a general, user controllable automatic substitution feature
>>as mentioned on p.48 that could do these sorts of things.
>>
>Pourquoi « difficile » ? Pourquoi est-ce plus difficile qu'avec le « fi »
>et « fl » déjà présents dans XPress ?

Oui, on comprend le problème dans le cadre du codage standard, mais avec
une métafonte, il n'y a pas de raison qu'on ne puisse pas faire de même
pour tout. Mais il faut que ça puisse se faire en fonction de la
fonte/feuille de style et non pour tout le document, comme c'est le cas
actuellement.

>Autre problème : la césure. Une ligature « en dur » (dans la police) n'est
>pas césurable par définition. Ça pose problème avec « ff », et bien entendu
>avec des tas d'autres ligatures qui peuvent avoir été inventées par un
>dessinateur et qui ne sont pas standards. À noter : ce problème de
>substitution se pose aussi avec les césures en allemand, puisque « ck »
>devient « k [k » - exemple du code de l'IN : « Drucken » devient « druk
>[ken », je crois que InDesign gère ça, d'ailleurs !

À ce propos, ces particularités de l'allemand vont peut-être disparaître.
Il y a une réforme de l'orthographe en cours, qui ferait disparaître le ß
et ces césures acrobatiques. Probablement parce qu'il se sont rendus compte
que l'informatique avait du mal à gérer ça. J'avais trouvé une page
là-dessus (en allemand), mais je ne sais pas si j'ai gardé l'U.R.L. Si ça
en intéresse, je peux la rechercher.

>Dernier problème, noté par Robert : la restitution du texte, dans une autre
>police ou à l'exportation (vers un fichier Word, par exemple, ou du HTML,
>ou autre). Les ligatures _doivent_ être réversibles, et seule une police
>virtuelle le permet sans trop de manipulations.

Je dirais plus : il faut pouvoir contrôler cette réversibilité. Je veux
bien qu'à l'export en texte on me substitue f-f-i à ffi, mais pas que mes
nu redeviennent des v italiques ! Donc ça doit être un attribut de la
requête (genre une case à cocher).
Encore une fois, XPress sait le faire avec fi et fl, il n'y a pas de raison
qu'avec une métafonte ce ne soit pas possible.
Et ça résoud également le problème des césures.

>>  It *is* easy to see what characters are present in a font,
>>
>Non, ça ne l'est pas ! Il est facile de voir que « V » est présent dans une
>police Expert, mais rien ne dit _facilement_ qu'il s'agit en fait d'une
>ligature « ff » !

Dans Unicode, il y a une donnée pour ça : la décomposition. C'est-à-dire
qu'Unicode sait que ffi se décompose en f-f-i. Une métafonte doit intégrer
ces données. Une fonte Unicode contiendra déjà ces informations ; pour des
fontes au codage non standard, il faudra pouvoir les intégrer soi-même.

>>  It seems more useful to have a tool that could build a profile of each
>>font and compare them in a way meaningful to the user -- ligatures present,
>>true smallcaps, whatever -- and can build a permanent database of the
>>information for future recall, for later comparisons, or for grouping fonts
>>in user-defined buckets as in ATR.

En gros, oui. C'est ce que j'évoquais quand je disais qu'il manque une
interface entre les fontes et Unicode. Mais je trouverais dommage de
limiter ce système à un logiciel. Pour moi ce doit être une fonctionnalité
intégrable au système (comme Suitcase, ATM et ATR).

>C'est aussi une solution. En fait, l'essentiel pour moi est qu'une fois
>tout ce tintouin informatique achevé (ou corrigé et mis à jour s'il y a
>lieu), le reste soit transparent pour l'utilisateur.
>
>>I think  Apple's new FontSync even
>>proposes to go this far, even down to comparing at the glyph level. Has
>>anyone heard about this, and what do you think?
>>
>Quelqu'un a des précisions là-dessus ?

Ça m'intéresserait aussi grandement.

Olivier RANDIER -- Experluette		mailto:orandier@xxxxxxxxxxx
	http://technopole.le-village.com/Experluette/index.html
Experluette : typographie et technologie de composition. L'Hypercasse
(projet de base de données typographique), l'Outil (ouvroir de typographie
illustrative).