Plaçons-nous dans la situation classique où l'éditeur vous soumettrait une liste de termes à indexer sous la forme suivante (le caractère → indiquant un renvoi) :

Instructions d'indexation remises par le client.

J'ai réduit le volume réaliste d'une telle liste, mais elle rend assez compte des paramètres auxquels vous aurez affaire en pratique. Avant toute chose, vous devez remplacer les schémas “A → B” (instructions de renvoi) par leur équivalent IndexMatic :

   // A => B

ce qui ne sera qu'une formalité pour votre éditeur de texte.

Conversion des renvois en références croisées IndexMatic.

Concernant les requêtes effectives, un fait immédiat devrait alors vous sauter aux yeux. Dans la quasi-totalité des cas, une virgule divise la ligne en deux parties. La partie préfixe constitue alors, presque toujours, une clé suffisante pour identifier sans ambiguïté cet élément dans le document — sous réserve qu'il n'entre pas en collision avec des homographes.

Par exemple, on admettra que la forme Aaron induit le terme “Aaron, Jeff (1936-2001)”, de même que Alió-Barràs pour “Alió-Barràs, Karl (1961)”, et ainsi de suite :

Mise en évidence des composants-clés (avant la virgule).

On note toutefois trois petites exceptions :

   Diophantos von Alexandria (ca. 250 n. Chr.)
   Russell (1855)
   Voltaire (Arouet, François-Marie) (1694-1778)

Dans les deux premiers cas, aucune virgule n'apparaît, ce qui nous empêche d'extraire une clé pertinente. Dans le dernier cas, la virgule intervient seulement après la parenthèse ouvrante — “Voltaire (Arouet,…” — ce qui tend à produire une clé trop longue (on espérait Voltaire tout seul).

Mais on remarque qu'en ces trois circonstances, c'est la parenthèse ouvrante (précédée d'un caractère d'espacement) qui joue alors le rôle de séparateur. De sorte que la réunion des deux options (PARENTHÈSE ou VIRGULE) produit un critère révélant toujours la fin de la clé de recherche. En syntaxe regex, le motif séparateur qui nous intéresse s'exprime donc :

   (\s\(|,)

(traduisez : « espace quelconque suivie de parenthèse ouvrante, ou virgule ».) Si l'on applique mentalement ce séparateur à la liste d'origine, on voit apparaître (en bleu ci-dessous) toutes les CLÉS que notre liste de requêtes devrait finalement rechercher dans le document InDesign.

En bleu, nos véritables clés de recherche.

Gardez en tête notre fil rouge : traquer dans le document uniquement les éléments en bleu mais, pour chaque concordance, associer la ligne complète telle que l'a rédigée le client. Prenez par exemple l'expression “Alió-Barràs, Karl (1961)”. Nous voudrions que notre système la digère comme ceci :

   /Alió-Barràs/Ih => Alió-Barràs, Karl (1961)

(afin d'améliorer mon expression régulière, j'ai ajouté au passage les options de sensibilité à la casse et de tiret générique, d'où les flags /Ih.)


Maintenant que notre objectif est clair, toute la question est de mettre en œuvre ce procédé en triturant le moins possible la liste existante. Tel est précisément l'objet des directives ~format ou ~split.

Bien que ~split fonctionne souvent sans accroc quand il s'agit de séparer des éléments de la ligne d'entrée, je vais employer ~format car elle donne un contrôle étendu des motifs et permettra ici de négliger la syntaxe particulière des références croisées.

Manuel IndexMatic³: directive ~format

Le premier argument à passer à ~format est une expression régulière (dialecte ExtendScript) qui analysera n'importe quelle ligne entrante. L'idée est d'attirer les portions qui nous intéressent dans des parenthèses capturantes, puis de les réagencer afin de produire la requête effective, celle qui sera reçue par l'interpréteur IndexMatic.

En l'occurrence, nous voulons capturer tous les caractères situés AVANT le motif séparateur (\s\(|,) puisqu'ils interceptent notre clé de recherche. Mais nous voulons capturer ce préfixe sous une double contrainte :

    1. D'une part, via un quantificateur « non gourmand » qui garantisse une correspondance minimale ;

    2. D'autre part, en rejetant systématiquement le caractère barre oblique (/), de façon à ignorer totalement les formes //... qui introduisent les commentaires ou les références croisées.

La conjugaison de tous nos critères débouche sur l'expression :

   /^([^\/]+?)(\s\(|,)/

décomposable comme suit :

Explication de la regex passée à la directive ~format.

Seul le premier élément capturé nous intéresse. Dans le schéma sortant d'une directive, il est symbolisé par ^1, alors que la ligne complète à l'état initial est symbolisée par ^0. La requête que nous voulons produire ressemble donc à /^1/=>^0, à quoi nous allons ajouter quelques flags de sécurité pour gérer la casse, l'espace et le tiret générique, soit finalement /^1/Ish=>^0.

En résulte la directive complète que nous allons insérer au tout début de la liste (notez le séparateur :: entre la regex et le schéma sortant) :

   //~ format /^([^\/]+?)(\s\(|,)/ :: /^1/Ish => ^0

Peut-être passerez-vous du temps avant de parvenir à cette instruction — qu'il faut évidemment adapter au formatage et à la ponctuation de votre propre fichier — mais retenez qu'une fois cet effort accompli, la liste fonctionne instantanément comme une authentique Liste de requêtes IndexMatic sans qu'il n'y ait plus rien à y retoucher. Cela signifie qu'elle agira sur toutes les lignes qui la suivent (à moins de tomber sur une ligne blanche ou une directive d'arrêt), peu importe qu'il y ait 100, 500, 1000 ou 5000 échantillons à traiter.

Note. — Nous nous sommes même offert le luxe de tolérer des références croisées parmi les lignes entrantes. Cette petite astuce tient au fait que lorsque la directive ~format ne détecte aucune concordance dans une ligne, elle la conserve telle quelle et passe à la suivante.

Voici donc la liste de requêtes prête à être chargée dans IndexMatic³:

// Liste de requêtes IndexMatic3
// ---

//~ format /^([^\/]+?)(\s\(|,)/ :: /^1/Ish => ^0
Aaron, Jeff (1936-2001)
Alió-Barràs, Karl (1961)
// Ambroise => d’Ambroise
// Arouet => Voltaire
Béraud, Paul (père ~) (1705)
Bertholon de Lazare, Jacques (†1800)
Böhr, Walter (1906-1985)
Calmant, ? (†1840?)
Cochrane, Billy (1898-1938)
Dalla Volpi, Danilo (1925-1995)
d’Ambroise, Lucien (1967)
Diophantos von Alexandria (ca. 250 n. Chr.)
Ehner, Mike (1959)
Fermat, Pierre de (1607-1665)
Frézier, Amédée-François (1682-1773)
Guretzky-Cornitz, Bernhard von (1838-1873)
// Henry => Russ
Jänisch, Carl Ferdinand von (1813-1872)
Krebb, Daniel (1947)
La Croix de Castries, Charles E. Gabriel de (1727-1801)
Laplace, Pierre-Simon (1749-1827)
// Linde => van der Linde
Łuczak, Mario (1939-2009)
McKay, Brendan Damian McKay (1951)
Newton, Isaac (1643-1727)
O’Connor, Joseph (1939)
Parejo Casañas, Francesco N. (?) (1890-1983)
Rabelais, François (ca. 1494 [1483?]; †1553)
Russ, William Henry (1833-1866)
Russell (1855)
Schoumoff, Ilja (Stepanowitsch) (1819-1881)
Talleyrand-Perigord, Charles-Maurice de (1754-1838)
Ukers, William Harrison (1873-1945)
van der Linde, Antonius (1833-1897)
Vandermonde, Alexandre-Théophile (1735-1796)
Voltaire (Arouet, François-Marie) (1694-1778)
Witcomb, H. (1846)
Ximénès, Augustin-Louis, marquis de (1728-1817)
//~
 
// Fin de la directive
// Ajout possible de requêtes spécialisées

Il n'existe sans doute aucune situation où ~format chapeauterait toutes les requêtes de votre futur index. Des expressions régulières plus fines restent nécessaires pour départager les homonymes, regrouper les variantes orthographiques et/ou optimiser les clés de recherche. Cependant, le mécanisme des directives est un formidable outil de « traitement par lot » dès lors que la très grande majorité des termes à indexer présente une structure prévisible et (relativement) homogène.