Re: [XP] langages scientifique, substitution automatique

[Olivier RANDIER <orandier@xxxxxxxxxxx>]

>At 19:44 + 0200 17/10/99, Olivier RANDIER wrote :
>>>>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,
>>
>Le monsieur parlait de logiciel (ou de plug-in) de composition, pas de
>polices de caractères.

Je sais, je sais. Je disais ça par rapport à des enfilades précédentes
concernant les fontes de chimie.

>>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.
>>
>C'est l'idée, sauf qu'il me semble que tu es emporté par ton enthousiasme
>et que tu en veux _trop_.
>
>Décrit comme tu le fais, ce moteur devient une usine à gaz, un monstre
>impossible à maîtriser. Si on avait déjà un bête et brave moteur de
>substitution gérant quelques cas particuliers (y compris les substitutions
>contextuelles), ce serait déjà pas mal.
>
>>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.
>>
>Ça, ça me semble l'exemple typique : tu vas rendre tout trop compliqué pour
>l'utilisateur (et je n'imagine même pas le casse-tête que va constituer
>l'écriture de l'interface !)

Mais non, c'est très simple. T'as une case de recherche et une case de
remplacement/substitution. Dans la première, tu rentre ta série (ici les
caps [A, B, C, ..., Z]), dans la deuxième, la série de remplacement (ici
également les caps [A, B, C, ..., Z]). En dessous, tu choisis la fonte de
départ et celle d'arrivée (comme actuellement). Tu rajoutes une condition
(si après tag de fin de ligne/si pas après) et le tour est joué. Pour un
programmeur, c'est pas bien sorcier.
Si vous me donnez trois jours, je vous fais une maquette de l'interface
comme je la rêve.
Deux idées fondamentales ici :
-- pouvoir remplacer/substituer des séries de caractères d'un coup. Par
exemple, les chiffres par les elzéviriens de l'expert :
dans ta première case, tu sélectionne la série des chiffres (en
sélectionnant dans la table de la police, qui pourrait s'afficher à la
PopChar), dans la deuxième, celle de la police expert (de la même façon).
J'utilise une XTension (ChangeCase, 70 500 octets tout mouillé) qui permet
de remplacer les caps par les bas de case (et lycée de Versailles). Pour
obtenir également les caps accentuées, il suffit de rentrer la série
correcte (àÀáÁâÂ...), c'est le même principe, et c'est con comme la lune.
On pourrait résoudre une partie du problème des métafontes de cette façon
(mais pas ce qui concerne le crénage).

-- une interface simple de condition. Ça n'est pas très compliqué non plus,
c'est comme les critères de la recherche de MacOS, juste un peu plus évolué.

>>Ou encore remplacer tous les v isolés en italique par des nu.
>>
>Admettons, mais est-ce qu'un script qui commanderait un
>« chercher-remplacer » efficace n'irait pas tout aussi bien ?

Oui, c'est pas un très bon exemple.

>On peut faire des scripts avec XPress ! Personne ne le fait jamais, parce
>qu'AppleScript est aussi chiant à programmer que lent à s'exécuter, mais
>bon, c'est même ahurissant le nombre de commandes disponibles dans XPress
>(mal documentées, comme si Quark en avait honte, mais c'est un autre
>problème).

Y paraît que pour bien profiter d'AppleScript, il faut avoir une des
dernières versions de MacOS, où AppleScript s'exécute en code PPC natif.
Personnellement, je me fous comment ça marche. Si vous voulez faire ça avec
AppleScript (jamais eu le temps de me plonger dedans), pourquoi pas. Ça
n'empèche pas d'avoir une interface qui simplifie ça pour l'utilisateur. Je
sais faire des requêtes conditionnelles sous FileMaker, c'est pas pour
autant que je comprend Lingo. Dans FileMaker, tu construit ta requète en
cliquant sur des boutons "if", "not", etc. et le programme se charge de la
syntaxe.
Mais, à mon avis, AppleScript peut être bien par-dessus le moteur de
recherche (je vois plutôt ça pour gérer les séries de requêtes), mais
n'aidera pas pour la substitution en elle-même. Et puis AppleScript
n'existe pas sur PC...

>Donc, il y aurait nécessité de faire un « chercher-remplacer » intelligent,
>c'est-à-dire qui gère tout ce qu'il ne gère pas actuellement (y compris les
>attributs typographiques) et qui permette les séquences de commande,
>éventuellement les boucles, dans tous les cas les commandes conditionnées
>par des booléens (If... AND..., etc.) C'est lié à la substitution
>automatique (qui doit aussi gérer certains attributs typographiques :
>petites capitales, exposants, italiques et gras, etc.), mais ce n'est pas
>la même chose.

Si ton moteur comprend tout ça, il sera forcément capable de faire tout ce
que j'ai dit ! ;-)

>Et qu'on ne vienne pas me dire que c'est trop compliqué à programmer (sic)
>et que ce serait trop compliqué pour les utilisateurs. Des
>macros-commandes, c'est pas trop compliqué, non ?
>
>>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.
>>
>Moi non plus, je n'imagine pas ;-). Tu peux donner des exemples ? Parce que
>je n'en imagine aucun... :-).

L'as rin compris ! Je parlais du moteur de recherche/substitution, pas de
la fonction aléatoire que je ne citais qu'en passant.
Bon, pour la fonction aléatoire, imagine une série de fontes façon vieux
plomb fatigué avec les mêmes signes, mais "abimés" différemment dans chaque
fonte, tu pourrais remplacer aléatoirement chaque lettre par une variante
chaque fois différente. C'est ce que fait Beowulf (mais c'est intégré au
programme de la fonte). Ça peut servir pour plein de fontes à variantes non
contextuelles. C'est anecdotique, mais ça pourrait rendre quelques
services. On peut imaginer aussi de n'effectuer une substitution qu'une
fois sur n.

>>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).
>>
>Moi aussi, mais là on parle d'un moyen pour XPress de sauver sa peau (et
>pour Robert et ses collègues de ne pas être au chômage dans quelques mois ;-)

Un utilitaire puissant et efficace de gestion de l'interface fontes/Unicode
pourrait constituer une diversification intéressante pour Quark (regarde
Adobe et ATM). Comme ça, il pourrait réinvestir l'argent dans le
développement d'XPress ;->

>Jean-Denis ne va pas être content : imagine qu'on ait satisfaction
>sur la moitié de ce qu'on demande : quel programme fabuleux on aurait !)

Oh oui ! ;)))

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).