1) Le symbole du $

Le caractère $ en GREP signifie Fin de paragraphe et son emploi est donc réservé. Pour rechercher le symbole du dollar, il faut donc l’échapper : \$.

Je n’ai pas le souvenir d’un quelconque problème avec \$, seul ou associé à d’autres caractères. Jusqu’à ce qu’un comportement étrange soit signalé sur le forum Adobe InDesign Scripting et que le problème se produise chez moi.

Dans la chaîne de caractères ci-dessous, avec la regex \$\d+,\d+, impossible de sélectionner davantage que le premier nombre avec virgule précédé du symbole du dollar, alors qu’on est en droit d’attendre que toutes les séries soient trouvées  :

Le problème ne vient pas des tabulations. Comme on peut en juger ci-dessous, \$ ne sélectionne qu’un symbole du dollar par paragraphe :


Très intrigué, j’ai poursuivi les investigations. Sans plus de résultat satisfaisant, comme le montrent les captures d’écran ci-dessous.

Avec \$, non seulement la totalité des symboles ne sont pas trouvés, mais la sélection diffère selon la position du curseur (flèche rouge) au départ de la recherche.

Bref, \$ n’est pas le métacaractère le plus approprié pour sélectionner le symbole du dollar. Et cela, sous InDesign CS4, Mac et Windows. La situation est différente, mais pire avec InDesign CS3 puisque bien souvent aucun symbole du dollar n’est sélectionné.

Heureusement, une solution existe, suggérée sur le forum Adobe par l’expert Jongware : il suffit tout simplement de remplacer \$ par sa valeur Unicode, à savoir \x{0024}. James Fritz, en septembre 2009, l’avait déjà recommandée sur le site InDesignSecrets.com.

Pour éviter tout problème, ci-joint les valeurs Unicode des métacaractères GREP qui doivent être échappés (sauf lorsqu’ils sont insérés dans un jeu de caractères) pour prendre leur valeur littérale  :

2) N’importe quelle chaîne de caractères entre deux signes

Toujours sur le forum Adobe, section InDesign, une question relativement simple fut posée : comment sélectionner des données entre parenthèses situées à la fin d’un paragraphe ?

Après quelques tergiversations quant aux données contenues entre parenthèses, j’ai suggéré l’expression régulière suivante : \(.+\)$ : une parenthèse ouvrante suivie de n’importe quel caractère une ou plusieurs fois, suivi d’une parenthèse fermante et d’une fin de paragraphe. Certes, ce qui devait être sélectionné l’était, mais cette regex ne prenait pas en compte la présence, dans le même paragraphe, d’une chaîne semblable. Dans ce dernier cas, compte tenu de l’avidité du caractère spécial + (Zéro ou plusieurs fois), le résultat n’était plus celui escompté :

Jongware proposa justement \(.+?\)$, ce qui était tout à fait logique, car en décidant de limiter l’avidité de + par la correspondance la plus courte +?, seule la dernière parenthèse devait être sélectionnée. Or, tel n’est pas le cas. Dans le cas présent, comme le fit remarquer Peter Kahrel, la même chaîne était retournée.

Comment donc sélectionner notre motif ? Peter Kahrel proposa de recourir à un jeu de caractères négatif [^]. Effectivement, la regex \([^(]+\)$ retrouve bien et seulement la chaîne de caractères entre parenthèses située à la fin du paragraphe :
 

Le métacaractère $ (Fin de paragraphe) n’est pas en cause dans l’échec de l’expression régulière. La même anomalie survient avec n’importe quel caractère. 

3) Chaînes de caractères capturées et mise en forme

Dans un ancien billet, j’avais montré comment la permutation de motifs s’accommodait mal des attributs stylistiques de caractères. En définitive, le problème n’intervient pas simplement dans ce cas, mais dès qu’il y a « déplacement ». Les chaînes bougent mais pas leurs attributs de mise en forme.

En d’autres termes, dès lors que l’on fait subir une manipulation à des motifs, rappelés dans le champ Remplacer par à l’aide de la variable Trouvée (de type $1, $2, etc.), des problèmes de mise en forme apparaissent.

Dans le cas d’une permutation, autrement dit quand un motif A prend la place d’un motif B et inversement, il ne semble pas y avoir d’alternative.

Dans les autres cas (ajout ou retrait de caractères aux motifs capturés), on peut préserver la mise en forme respective desdits motifs en recourant à un lookaround. En guise d’exemple, prenons une phrase s’apparentant à une référence bibliographique, au début de laquelle nous voulons ajouter un « Prénom ».

Dans l’exemple ci-contre, nous avons recherché ^(.+) pour le remplacer par Prénom $1. On le voit dans le deuxième paragraphe, Prénom a « revêtu » trois couleurs différentes : le bleu du Nom, le noir de la virgule et de l’espace, et le rouge du deuxième mot.

 

Pour éviter cette anomalie, nous avons rédigé une regex quelque peu modifiée faisant intervenir un lookahead positif : ^(\u)(?=.+). En début de phrase, nous avons recherché une lettre capitale (à la condition d’être) suivie d’un ou de plusieurs caractères quelconques. La même formule de remplacement a été utilisée, à cette différence près que $1 capture (\u).

Nous aurions pu ajouter un « Prénom » après le « Nom » et conserver la mise en forme grâce à un lookbehind positif : (?<=^Nom)(,) que remplace $1 Prénom, :

Dans les deux cas, il faut obligatoirement capturer au moins un caractère, au risque de voir la manipulation échouer.

4) \u, \l et les ligatures

Dans son tutoriel vidéo sur GREP et InDesign, InDesign CS4: Learning GREP, paru sur linda.com, Michael Murphy relevait deux particularités concernant les caractères spéciaux \u et \l :

  • le métacaractère \u sélectionne non seulement n’importe quelle lettre capitale, mais aussi la lettre capitale + la lettre minuscule dans le cas d’une « ligature bicamérale » :



  • quant à \l, il sélectionne bien les lettres minuscules, mais aucun des deux caractères dans le cas des ligatures associant capitale et bas-de-casse :



De découvrir cela en direct me laissa dubitatif. N’avais-je pas écrit que, dans le cas des ligatures bicamérales, \u et \l ne sélectionnaient que les lettres correspondant à leur casse respective ? Après plusieurs essais sur InDesign CS3 et CS4, sous Mac et Windows, je notifiai cette particularité à l’intéressé. L’image parle d’elle même :



Oui mais, voilà. En vue de reproduire le surlignage de la vidéo, j’ai refais des essais avec un style de caractère. Et là, stupéfaction ! Les résultats sont identiques à ceux de Michael Murphy :



Tout s’explique. Dans le premier cas, je n’ai fait qu’une recherche simple. Or, si une ligature est par définition la fusion de deux caractères, chacun d’eux garde sa propre valeur Unicode ; InDesign a distingué dans la combinaison Th le T (U+0054) et le h (U+0068). Dans le second, j’ai fait un Rechercher/Remplacer avec application du style de caractère « surlignage ». Dans ce cas, InDesign « interprète » la ligature comme un caractère à part entière ; InDesign sélectionne donc Th, le T étant le premier « élément » indissociable du h.

Je m’en vais de ce pas avertir Michael Murphy ! Et n’hésitez pas à m’avertir si GREP vous joue des tours.



Nuages de mots (du billet) réalisé avec le script Wordalizer de Marc Autret. A découvrir de toute urgence sur InDiScripts.