IndexMatic³ | Foire aux questions [MÀJ]
January 22, 2024 | IndexMatic³ | fr | en
Avec ses centaines de fonctions interconnectées et sa documentation plantée devant vous comme une cathédrale gothique, IndexMatic³ vous inspirera sans doute cette question fatale : par où commencer ? Et l'on commence souvent par du concret, un problème précis à traiter maintenant ! L'objectif de cette page est de vous aiguiller vite et bien dans les replis du programme, à partir des questions les plus fréquemment soumises au support technique…
1/ Généralités
Apprentissage d'IndexMatic³
IndexMatic³ versus IndexMatic²
Tarif réduit de mise à niveau
Rétro-compatibilité avec la Creative Suite
Paiement par carte bancaire via PayPal
2/ Scope et options de recherche
Extraction automatique de vocabulaire
Concordances et PageRank
« Mot Entier » et Regex
Texte conditionnel
Espaces et mots entiers
Mode automatique vs requêtes explicites
3/ Requêtes élémentaires
Syntaxe des regex : le préfixe /
Lettres majuscules et diacritiques
Réécriture de terme / Sous-sujets / Références croisées
Gestion des pluriels
Requêtes et espaces
Sites Web, URLs
Taille d'une clé / Regroupement d'alternatives
Signification du métacaractère "\w"
Extraction de données XML
Espaces spéciales
Apostrophe générique
Consolider deux termes sous une seule référence
4/ Noms propres
Noms propres vs acronymes
Reformatage d'une liste de noms
Concordance et redondance
5/ Requêtes avancées
Signes de ponctuation
Statistiques sur les lettres
Utilisation du symbole "$"
Émojis
Diacritiques en arabe
6/ Sortie
Sortie XML
Inhiber le tri
Index multiples
Indication des entrées non trouvées
7/ Problèmes connus et dépannage
Conservation des enrichissements
Styles de caractères « indirects »
PDF importés
Écran noir !
Sélection de chapitres non restaurée !
InDesign ne répond plus
1/ Généralités
Apprentissage d'IndexMatic³
• IndexMatic³ est facile à tester mais paraît plus difficile à apprivoiser en profondeur. Où trouver un bon tutoriel expliquant pas à pas ses fonctionnalités avancées ?
La seule référence complète et officielle est le manuel d'utilisation (PDF, 110 pages), publié à la fois en français et en anglais. Ce dernier a été élaboré pour vous guider pas à pas depuis la prise en main de l'interface (boîte de dialogue, boutons, listes) jusqu'aux opérations plus raffinées impliquant l'ajustement du scope, l'interpréteur de requêtes et les expressions régulières, le contrôle des paramètres en sortie, sans omettre aucun des aspects techniques régissant l'analyse des documents InDesign par IndexMatic.
L'expertise IndexMatic³ ne réclame pas un temps d'apprentissage si terrible, mais essentiellement de la concentration. Lisez le manuel posément, graduellement, sans vous laisser happer par les notifications de votre smartphone ou des réseaux sociaux ! Les concepts vont se mettre en place peu à peu, vos tests et vos requêtes deviendront plus fructueux, plus sensés, plus performants. Vous viendrez bientôt à bout de tâches que vous ne songiez même pas à formuler au début de votre apprentissage.
→ Notre chaîne YouTube distille, par ailleurs, des tutoriels plus ciblés à l'attention des utilisateurs francophones.
D'autres exemples concrets et études de cas case seront peu à peu versés à la présente FAQ, au gré des questions qui parviendront au support technique: support[at]indiscripts{dot}com
.
→ Manuel d'utilisation IndexMatic³ (PDF)
IndexMatic³ versus IndexMatic²
• Je suis une aficionado d'IndexMatic² (voilà des années que j'offre à mes clients, surtout éditeurs, un service d'indexation sur mesure). Puis-je réutiliser dans iX³ les mêmes listes de mots ou schémas de requêtes que j'avais rédigées dans iX² ? Si oui, pourquoi passer à la nouvelle version ?
Toute tâche accomplie par IndexMatic² peut l'être par IndexMatic³ et la syntaxe fondamentale des requêtes n'a pas été altérée, seulement augmentée de nouveaux opérateurs gérant par exemple le tiret générique, les directives, les formateurs de rubrique, le flag d'admission des mots vides… Ainsi, les requêtes et listes iX² continueront de fonctionner normalement dans cet environnement, sous réserve que vos instructions ne contiennent pas de codes spéciaux aujourd'hui analysés comme des opérateurs syntaxiques. Pour un aperçu de ces innovations, reportez-vous aux sections récapitulatives Syntaxe des rubriques (mémento), Métacaractères et Directives.
Indiscripts n'a jamais eu pour politique de pousser ses clients à des dépenses factices, et encore moins captives ;-) Nos produits ne vous enchaînent pas à un abonnement fumeux et nos licences sont perpétuelles (du moins, tant qu'InDesign veut bien exécuter le code sous-jacent). Si vous aimez IndexMatic² et vous y sentez à l'aise, s'il répond à toutes vos attentes en matière d'indexation, il n'y a pas lieu d'en changer (d'ailleurs nous le conservons au catalogue, en l'état). Les raisons qui ont présidé à la refonte de ce produit ont été exprimées dans cette annonce parue début 2023 et se résument en trois mots : plus rapide, plus poussé, plus ergonomique. Vous lirez avec profit cette interview chez Swash qui en dit un peu plus long.
→ Migration d'IndexMatic² à IndexMatic³ (tableau)
Tarif réduit de mise à niveau
• J'utilise IndexMatic² Pro depuis des années, comment puis-je accéder au tarif réduit de mise à niveau ?
Les utilisateurs d'IndexMatic² Pro bénéficient d'un prix spécial leur permettant d'accéder à IndexMatic³ (Expert) avec 50 € de réduction sur la licence standard, de sorte qu'ils paient seulement la différence. Cette offre concerne également les licences multi-postes. La procédure est expliquée sur la page de mise à niveau d'IndexMatic.
En résumé, il vous suffit de remettre la main sur le « lien de téléchargement » associé à votre licence iX² (afin d'en déduire votre code remise). Si par mégarde vous avez perdu cette URL privée, n'hésitez pas à entrer en contact avec nous (support[at]indiscripts{dot}com
) : fournissez alors suffisamment d'éléments (numéro de facture, nom de société, adresse e-mail associée à la licence…) pour que l'on puisse identifier la commande d'origine.
→ Mise à niveau d'IndexMatic
Rétro-compatibilité avec la Creative Suite
• Je refuse de payer un abonnement à Adobe et travaille donc encore (pleinement satisfait !) sous InDesign CS6. IndexMatic³ supporte-t-il cet environnement ? (Projetez-vous de le rendre accessible depuis Affinity Publisher ?)
1. IndexMatic³ a été réécrit de fond en comble en tenant compte des fonctionnalités introduites dans les dernières versions d'InDesign CC (versions 9.x à 18.x), mais nous avons mis un point d'honneur à conserver une compatibilité descendante jusqu'à InDesign 6.x. Autrement dit, le programme fonctionne encore dans InDesign CS6, CS5 et CS4, sur plateformes macOS et Windows. C'est un atout majeur sur les solutions concurrentes et nous nous y tenons !
Note. - Bien sûr, du fait que certaines fonctionnalités (blocs masqués, notes de fin, etc.) n'existent pas dans d'anciennes versions d'InDesign, IndexMatic³ les occultera mécaniquement si vous l'exécutez dans ces contextes-là.
2. Bien que des solutions d'extensibilité soient à l'étude chez Serif Labs, il est difficile de prédire sous quel délai elles pourraient arriver à maturité. À l'heure où j'écris ces lignes, il n'y a aucune perspective solide permettant d'envisager l'extension d'IndexMatic³ à Affinity Publisher.
→ IndexMatic³ : configuration requise
Paiement par carte bancaire via PayPal
Je viens d'acheter ma licence IndexMatic³ et m'en réjouis. Un seul regret, je n'ai pas pu l'acheter avec ma CB pro. J'ai eu beau cliquer sur le bouton Mastercard, c'est resté bloqué sur PayPal…
Expérience vraiment frustrante : il arrive que PayPal refuse votre carte, ou même la modalité de paiement direct par carte, sans que personne (y compris chez les développeurs) ne puisse exactement déterminer les critères de ce rejet.
Le pays depuis lequel vous achetez le produit est parfois en cause, d'où un risque de quiproquo si vous utilisez un VPN. Selon d'autres sources, des problèmes analogues surviennent si votre carte de crédit, ou votre adresse e-mail, est par ailleurs liée à un compte PayPal actif auquel vous n'êtes pas actuellement connecté(e). De plus, des impératifs de sécurité font que PayPal fixe probablement des quotas (tout aussi opaques que les autres conditions) concernant le paiement par carte hors d'un compte PP.
Quelle que soit la raison du rejet, créer un compte PayPal et y ajouter votre carte de crédit comme source de financement peut évidemment résoudre le problème. Mais nous comprenons fort bien que cette approche est inacceptable si vous ne souhaitez tout simplement pas utiliser de compte PP !
Note. - Nous cherchons activement des solutions de paiement alternatives (pourvu qu'elles offrent le même niveau de sécurité que l'interface PayPal et qu'elles ne pénalisent pas le client).
Concrètement, si l'ombre d'une difficulté apparaît lors de votre transaction, n'hésitez surtout pas à nous contacter directement à legal[at]indiscripts{dot}com
. Nous mettrons alors en place une solution personnalisée de paiement, par virement bancaire.
→ Commander IndexMatic³ Expert
2/ Scope et options de recherche
Extraction automatique de vocabulaire
• Je dois établir l'index d'un livre mais je ne dispose pas d'une liste de mots prédéterminée. Y a-t-il un moyen d'extraire automatiquement le vocabulaire puis d'affiner la liste avant de lancer le processus d'indexation ?
IndexMatic³ propose un mode de recherche « Automatique » permettant de collecter sans effort les mots les plus représentatifs de votre/vos document(s). Ouvrez tout d'abord le livre dans InDesign et démarrez le script. Sélectionnez les chapitres à indexer dans la liste des documents cibles. Depuis le panneau Explorateur, fixez le PageRank à 3 ou 4 (ce sont habituellement des valeurs adéquates) et sélectionnez la langue adaptée dans la rubrique Mots vides. Faites alors un Ctrl Clic sur le bouton Termes, qui ouvre une petite boîte de dialogue dédiée. Passez tous les champs sur [Sans]
à l'exception du premier que vous maintenez sur l'option « Terme d'index ». Cliquez sur OK. Vous obtenez ainsi une liste de mots facile à collecter, nettoyer et personnaliser. Elle constituera un excellent point de départ pour une indexation en mode « Liste de requêtes ».
→ Personnalisation du rapport de termes ; Termes – Collecter les données
Concordances et PageRank
• Étant donné une expression régulière comme /Steve|Bill/
, qui produit deux termes — "Steve" et "Bill" — le PageRank s'applique-t-il à chaque terme ou en considération du nombre total d'expressions capturées par page ?
Le PageRank opère sur chaque terme séparément (i. e. chaque terme implicitement produit par la requête). Supposons que "Steve" figure trois fois en page 10 et deux fois en page 11, tandis que "Bill" figure deux fois en page 10 et trois fois en page 11 :
Page 10 : … Steve … Bill … Steve … Bill … Steve.
Page 11 : … Bill … Steve … Bill … Steve … Bill.
Alors, la requête :
/Steve|Bill/3
règle le PageRank à 3 et conduit au résultat suivant :
Bill: 11
Steve: 10
Par contraste, si la requête fournissait un terme explicite :
/Steve|Bill/3 => My Friends
alors IndexMatic³ compterait chaque expression trouvée dans le PageRank de "My Friends". Par conséquent, la requête ci-dessus produirait en sortie :
My Friends: 10-11
(Comme le nombre total d'occurrences est de 5 sur chaque page, le PageRank est largement satisfait.)
→ PageRank
« Mot Entier » et Regex
• Notre document de travail repose sur un balisage spécial :
"...\index{mot à indexer}..."
Souhaitant extraire chaque expression ainsi identifiée, nous avons essayé la requête:
/\\index\{([^}]+)\}/ => $1
, mais cela ne fonctionne pas.
Ne perdez jamais de vue le contexte dans lequel les concordances se manifestent. Votre syntaxe, \index{mot à indexer}, semble s'imbriquer dans le texte sans aucune séparation. Donc, il vous faut vraisemblablement désactiver l'option « Mot entier ». Essayez l'une de ces solutions :
(a) Décochez l'option « Mot entier » dans Explorateur > Options (ainsi, le flag est globalement désactivé).
OU
(b) Ajoutez le flag W
à la fin du motif :
/\\index\{([^}]+)\}/W => $1
→ Mot entier
Texte conditionnel
• Notre rapport annuel est établi en plusieurs langues qui cohabitent dans le même document InDesign via des « textes conditionnels » (plutôt que des calques linguistiques). IndexMatic³ est-il capable de cibler chaque condition séparément, afin de produire un index pour chaque langue ?
En matière de texte conditionnel, la politique d'IndexMatic³ consiste à inspecter le contenu disponible dans l'état actuel du document au moment où vous lancez le script. Ainsi, il suffit d'activer la condition qui correspond à la langue à indexer et vous obtiendrez les résultats escomptés.
→ Contenu hors-page, éléments ignorés
Espaces et mots entiers
• Je souhaite indexer des expressions contenant des espaces, telles que "a priori" ou "cordon bleu". Faut-il désactiver l'option « Mot entier » ?
Non. Le rôle de l'option « Mot entier » est de s'assurer qu'une concordance n'est ni précédée ni suivie d'un caractère appartenant à l'alphabet actif. Cela n'interdit en rien la présence d'espaces — ou même de n'importe quel autre caractère non alphabétique — dans la clé de recherche.
Ainsi, lorsque l'option « Mot entier » est active (par défaut), une requête telle que a priori
trouvera toute occurrence de la locution "a priori", mais ignorera des concordances fragmentaires comme dans "ma priorité".
En général, désactiver « Mot entier » est utile lorsqu'une unité lexicale partielle apparaît dans de multiples expressions qui renvoient sans ambiguïté au même sujet, par exemple: modern/W => modernité
Sous réserve que la sous-chaîne modern ne se manifeste que dans des mots relatifs à la modernité, la clé :
modern/W
se révèle beaucoup plus performante qu'une expression régulière du genre :
/modern(e|(i(sme|té|ser)))/
→ Mot entier
Mode automatique vs requêtes explicites
• J'ai tenté d'établir un index basé sur un style de caractère et me suis aperçu qu'IndexMatic³ ne prenait en compte que des mots simples, pas des expressions complexes comme “Premier ministre”, y compris lorsque ces expressions (avec espaces) se voient appliquer globalement le style de caractère voulu. Y a-t-il une possibilité de capturer les plages entièrement soumises à un style ?
Vous avez probalement utilisé le mode de recherche Automatique, lequel n'est pas adapté à votre exemple. En mode automatique, IndexMatic³ se borne à capturer des mots au sens de « séquence de lettres de l'alphabet actif ». Pour obtenir des résultats plus étendus, vous devez sélectionner le mode Requête simple (ou Liste de requêtes) afin d'envoyer vos propres commandes à l'interpréteur. Voici quelques requêtes usuelles qu'on peut appliquer lors d'un filtrage selon un style de caractère :
Pour capturer entièrement les plages stylées :
/.+/
Pour capturer les expressions formées de lettres et d'espace(s) :
/[\w ]+/
Pour capturer les mots (sans espace) :
/\w+/
→ Comment créer un index à partir d'un style ?
3/ Requêtes élémentaires
Syntaxe des regex : le préfixe /
• J'essaie de trouver une expression régulière : tout entre accolades. Ma requête est \{.+?\}
et le script ne trouve rien. Où est mon erreur ?
N'oubliez pas le caractère /
(barre oblique) au début d'une requête regex (car IndexMatic³ gère à la fois les expressions « littérales » et « régulières »).
Ainsi votre requête complète sera : /\{.+?\}
Note. - L'ajout d'une barre oblique finale est facultatif : /\{.+?\}/
; cela revient strictement au même tant que d'autres opérateurs n'entrent pas en ligne de compte (flags, spécification de rubrique sortante…)
→ Introduction aux expressions régulières
Lettres majuscules et diacritiques
• La requête /[A-Z]\w+/I
détecte tous les mots commençant par une majuscule non accentuée, mais je souhaiterais également capturer les autres majuscules telles que À
ou É
. Comment procéder ?
Utilisez \m
plutôt que [A-Z]
. L'ensemble [A-Z]
ne voit que les majuscules Ascii, alors que le métacaractère \m
, spécifique à IndexMatic³, détecte toute lettre majuscule de l'alphabet courant, diacritiques inclus. (Symétriquement, le métacaractère \l
concorde avec toute lettre minuscule de l'alphabet courant.)
→ Métacaractères ; Opérateurs issus de la syntaxe Grep
Réécriture de terme / Sous-sujets / Références croisées
• Je souhaiterais intégrer à l'index des termes qui n'apparaissent pas réellement dans les pages (par ex. indexer sous le terme "France" les pages qui mentionnent "Paris"). Comment procéder ?
Tirez parti de l'opérateur de réécriture (=>
). Toute occurrence du nom « Paris » dans le document peut être réécrite « France » dans l'index, grâce à la requête :
Paris => France
Il va de soi que vous pouvez aussi produire les deux termes, en utilisant deux requêtes :
Paris
Paris => France
La première ligne indexe « Paris » en tant que tel (terme implicite, homonyme de la clé), tandis que la seconde crée parallèlement la rubrique « France » (à partir des occurrences de « Paris »).
Une autre approche consisterait à présenter « Paris » comme une sous-rubrique de « France » :
Paris => France > $0
La requête ci-dessus est plus avisée, en ce qu'elle prépare l'adjonction d'autres éléments dans la rubrique « France », comme :
Bordeaux => France > $0
Une façon plus compacte d'exprimer tout cela est :
/Paris|Bordeaux/ => France > $0
L'index résultant ressemblera à ceci :
France
Bordeaux: folios
Paris: folios
Par ailleurs, si vous souhaitez que « Paris » apparaisse également au premier niveau de l'index, il est aisé de rediriger le lecteur vers la rubrique « France » en ajoutant une référence croisée (notez la double barre oblique au début de la requête) :
// Paris => France
Au final, votre liste de requêtes complète pourrait alors ressembler à ceci :
// Bordeaux => France
// Paris => France
/Paris|Bordeaux/ => France > $0
→ Références croisées
• Dans le sujet "FRANCE", j'aimerais aménager une sous-entrée, "Paris", qui n'indique aucun numéro de page mais renvoie le lecteur vers une autre rubrique nommée "PARIS". Comment faire ?
La syntaxe des références croisées permet de placer un renvoi au sein de n'importe quelle rubrique ou sous-rubrique, peu importe que cette dernière figure ou non parmi les éléments effectivement recherchés. Il suffit de mettre en forme la référence comme suit :
// FRANCE > Paris => PARIS
Considérons maintenant la liste de requêtes :
...
FRANCE
PARIS
// FRANCE > Paris => PARIS
...
Elle aura pour effet de produire un index de la forme :
…
FRANCE: folios
Paris: Voir PARIS
…
PARIS: folios
…
→ Références croisées ; Mentions «Voir» et «Voir aussi»
Gestion des pluriels
• Est-il possible d'indexer, à partir d'une liste de mots au singulier, à la fois le singulier et le pluriel ?
1. IndexMatic³ est incapable de « calculer » tout seul les formes plurielles des expressions fournies, c'est pourquoi il est nécessaire de spécifier les formes alternatives au sein de vos requêtes.
Pour indexer des formes au singulier et au pluriel — ou même d'autres variantes — sous la même entrée d'index, il convient d'ajuster vos requêtes pour qu'elles capturent ces formes via une expression régulière. Voici un exemple canonique (pluriel en ‘s’) :
/chats?/ => chat
qui peut aussi s'exprimer plus symboliquement :
/(chat)s?/ => $1
Du coup, si vous avez à traiter plusieurs mots reposant sur la même transformation au pluriel, il est facile et très économique de « factoriser les clés » comme suit :
/(chat|chien|serpent)s?/ => $1
Bien entendu, vous devrez traiter de façon plus chirurgicale les pluriels spéciaux :
/cheva(?:l|ux)/ => cheval
/hiboux?/ => hibou
/œil|yeux/ => œil
etc.
Note. - En mode Liste de requêtes, activez le bouton Synthèse automatique du terme pour vous éviter de fournir explicitement le terme des expressions régulières simples : la requête /chats?/
sera automatiquement comprise comme renvoyant au terme « chat », de même que /év[éè]nement/
pour « événement ».
2. Mais il y a encore plus fort ! Vous pouvez transformer une liste de mots simples, supposés au singulier, de sorte qu'elle produise systématiquement le modèle de requête étendu. Partons de la liste suivante :
chat chien serpent lapin bison . . .
On admettra que tous les éléments ainsi référencés possèdent un pluriel simple de la forme <singulier>+s
. On peut alors exploiter la directive ~format
pour opérer la transformation en une seule ligne, sans avoir à modifier la liste de mots :
//~format :: /^0s?/ => ^0
chat
chien
serpent
lapin
bison
. . .
Cette structure détectera aussi bien les occurrences au singulier qu'au pluriel tout en leur assignant une seule entrée d'index (la forme au singulier).
→ Directive format
Requêtes et espaces
• Nous devons indexer la chaîne " EUR" (avec espace initiale), mais la requête " EUR" semble être interprétée comme "EUR" sans espace. Pourquoi ?
Lorsqu'une clé est basée sur un simple vocable (absence de barre oblique initiale), les espaces initiales sont automatiquement ignorées. De même, les espaces finales sont ignorées en l'absence de barre oblique finale. Examinons les requêtes suivantes :
exemple
exemple/w
exemple => Mots > $0
Dans chacune, le vocable retenu est "exemple" (sans espace).
Pour forcer IndexMatic³ à prendre en compte les espaces initiales et/ou finales, délimitez la clé par des barres obliques :
/ EUR/
Notez que l'expression est alors analysée comme une expression régulière, ce qui reste sans effet indésirable tant que vous n'utilisez pas d'opérateurs spécifiques aux motifs d'expressions régulières.
→ Espace générique
Sites Web, URLs
• Est-il possible d'indexer tous les sites Web mentionnés dans mon document et de présenter les entrées d'index sous la forme : "nom [url], numéros de pages" ?
Cela dépend avant tout de la façon dont ces éléments sont identifiés dans le document.
Si un style de caractère dédié est attribué au nom des sites et/ou à leur adresse, il n'est pas difficile de capturer ces entités en sélectionnant le filtre Style et en appliquant une requête générique telle que : /.+/
Si les données ne sont pas « stylées », vous devez établir vous-même la liste des noms à inspecter, car le script ne peut pas savoir a priori en quoi consiste le nom d'un site Web !
Dans le cas où vous auriez seulement à collecter les URLs, utilisez une requête comme :
/(http:\/\/|www\.)\S+/I
(ou plus sophistiquée si besoin). Cette technique peut d'ailleurs s'envisager comme une étape préparatoire à l'identification des sites et de leurs noms. Une fois les URLs connues et rassemblées (bouton Termes), il ne vous restera qu'à établir et affiner votre liste de requêtes de façon à capturer les noms et les URLs des sites.
→ Introduction aux expressions régulières
Taille d'une clé / Regroupement d'alternatives
• Je trouve très pratique de pouvoir cibler un ensemble d'entrées de second niveau avec des requêtes du genre :
/Jean|Bernard|Caroline/=>Auteurs>$0
. Mais, combien de termes peut-on inscrire dans cette expression? J'ai plusieurs centaines d'éléments analogues. La requête peut-elle supporter une telle quantité ?
Désormais, la taille maximum d'une regex IndexMatic³ n'est plus plafonnée, si bien qu'elle dépend seulement de ce que le système (en l'espèce, ExtendScript) peut tolérer. Nous n'avons pas testé tous les environnements possibles, mais il est probable qu'au-delà d'un millier de caractères l'interpréteur va commencer à tirer la langue. Cela permet toutefois de fabriquer des expressions régulières très complexes. Si vous deviez « dépasser les bornes », une solution simple reste bien sûr d'utiliser une liste de requêtes :
Jean => Auteurs > $0
Bernard => Auteurs > $0
Caroline => Auteurs > $0
...
Note. - Et une encore meilleure solution consiste à insérer une directive ~format
au-dessus de la liste nue “Jean¶Bernard¶Caroline...” :
//~format :: ^0 => Auteurs > $0
Toutefois, rien ne vous interdit d'optimiser la liste par regroupement de termes alternatifs. Voici une approche possible, basée sur des agrégats alphabétiques :
// A...
/Alfred|Adèle|Alban|André|Arnaud|Anna/ => Auteurs > $0
// B...
/Baptiste|Béatrice|Benjamin|Bernard|Berthe/ => Auteurs > $0
// C...
/Céleste|Charles|Caroline|Constance|Carlos/ => Auteurs > $0
...
Remarquez toutefois que selon nos tests, le moteur d'expressions régulières perd peu à peu en vélocité lorsque le motif implique un grand nombre d'alternatives, au point qu'il devient plus efficace de lancer des requêtes séparées remplissant exactement la même fonction !
→ Alternatives
Signification du métacaractère "\w"
• Quelle est la portée exacte du métacaractère \w
?
Le métacaractère \w
s'ajuste automatiquement à l'alphabet, c'est-à-dire qu'il capture tout caractère disponible dans l'alphabet sélectionné, ainsi que le trait d'union, les chiffres, les apostrophes et/ou le tiret bas si les options correspondantes sont cochées (rubrique Alphabet).
Soulignons que le comportement du symbole \w
est propre à IndexMatic. Dans une pure expression régulière JavaScript, \w
capture uniquement un caractère alphanumérique ou le tiret bas. En conséquence, si vous avez besoin d'utiliser \w
au sens du JavaScript, sélectionnez l'alphabet ASCII et activez les commutateurs « Inclure les chiffres » et « Inclure le tiret bas ». À défaut, vous pouvez aussi travailler avec la classe de caractères équivalente : [a-zA-Z0-9_]
.
→ Alphabet
Extraction de données XML
• IndexMatic³ est-il capable d'analyser une syntaxe comme :
"...<index>New Orleans</index>..." ?
Peut-il également extraire un attribut XML ? Par exemple :
"...<index entry="New Orleans, LA">New Orleans</index>..."
Pour extraire le contenu de l'élément <index>, utilisez la requête :
/<index>([ \w]+)<\/index>/ => $1
Et pour récupérer l'attribut :
/<index entry="([ \w,]+)">/ => $1
Notez qu'une requête beaucoup plus élaborée (incluse dans votre liste de favoris sous l'intitulé “XML Tags”) permet de capturer les motifs plus génériques de la forme <tag>...</tag>
, produisant alors le rubricage “tag > contenu” :
/<([a-z][a-z0-9-]*)>([^<]+)<\/\1>/iW => $1 > $2
→ Gestion des requêtes favorites
Espaces spéciales
• À tel emplacement de mon expression régulière, je souhaite spécifier une espace fine OU ultra-fine plutôt que « l'espace générique » d'IndexMatic³. Est-ce possible ?
Il suffit de forger une classe de caractères correspondant aux espaces désirées :
[~<~|]
(syntaxe GREP) ou [\u2009\u200A]
(rangs Unicode).
Note. — Que l'option « Espace générique » soit active ou inactive, IndexMatic³ prend toujours en compte les caractères spéciaux que vous lui fournissez expressément.
→ Métacaractères issus de la syntaxe Grep ; Réglage fin des espaces génériques
Apostrophe générique
• Comment effectuer une recherche simple sur un texte contenant indifféremment l'apostrophe dactylographique ' U+0027
et l'apostrophe typographique ’ U+2019
?
IndexMatic³ ne fournit pas nativement de fonctionnalité apostrophe générique mais il est très facile de rédiger vos requêtes comme si c'était le cas : utilisez simplement la classe spéciale [']
dans vos expressions régulières. L'interpréteur comprend ce code comme [’']
, capturant par conséquent les deux formes concurrentes de l'apostrophe.
Note. - Depuis une liste de requêtes, il est alors possible de forcer en sortie la forme privilégiée en activant la Synthèse automatique du terme.
→ Opérateurs issus de la syntaxe Grep
Consolider deux termes sous une seule référence
• Je souhaiterais unifier les deux termes suivants :
1) Brahma
2) Mahabrahma
et produire dans l'index la mise en forme :
Brahma Voir Mahabrahma
Mahabrahma 279, 293-295, etc.
Comment procéder ?
Requête pour unifier les deux éléments :
/Mahabrahma|Brahma/wI => Mahabrahma
(utilisant les flags mot entier /w
et sensibilité à la casse /I
).
Quant à la référence croisée :
// Brahma => Mahabrahma
→ Références croisées
4/ Noms propres
Noms propres vs acronymes
• Je suis généalogiste et mes livres contiennent de nombreux patronymes. J'ai essayé d'utiliser la requête « Acronymes » (depuis la liste de favoris). Le résultat me donne de nombreuses abréviations sans noms de famille. (Les gens utilisaient couramment des initiales au lieu de prénoms dans les années 1800.) Mais lorsque je récolte ces abréviations, le nom de famille n'apparaît pas dans l'index. Que faire ?
La gestion des noms propres dépend principalement de la façon dont votre document InDesign est structuré au départ. Les requêtes favorites intégrées fournissent uniquement des modèles illustrant quelques possibilités d'utilisation des expressions régulières IndexMatic³. Mais il est généralement nécessaire d'ajuster ces commandes en fonction du texte réel trouvé dans le document, son organisation particulière.
Tout d'abord, supposons qu'un style de caractère dédié soit appliqué aux noms cibles. Il est alors extrêmement simple de récupérer tous ces noms quel que soit leur formatage particulier (à l'aide de la requête /.+/
). Et à partir de l'ensemble collecté, tel qu'il sera extrait par la fonction Termes, vous pouvez ensuite étudier les différents modèles obtenus — par ex. « Jean Dupont », « J. Dupont », « J. K. Dupont », « J. de Dupont »… — suite à quoi vous déciderez comment ajuster ces modèles pour l'index final.
— Il y a des cas où vous souhaiterez réinvestir tous les termes issus de /.+/
sous forme d'une nouvelle liste de requêtes littérales, parce que certaines règles de réécriture CLÉ => TERME
seront rendues nécessaires pour remplir vos objectifs de présentation. Par exemple, il faudra ajouter à l'index toutes les dates de naissance et ces informations ne sont pas accessibles dans le document InDesign (elles proviennent d'une base de données externe).
— Dans d'autres situations, toute la matière requise est bel et bien disponible dans les termes issus de /.+/
, mais vous devez distinguer des motifs comme « Jean Dupont », i.e. /\m\w+ \m\w+/
et « J. Dupont », i.e. /\m\. \m\w+/
. Si bien que votre requête universelle /.+/
doit finalement se spécialiser en sous-motifs plus fins prenant en charge les transformations que vous voulez appliquer — ce qui implique à nouveau une liste de requêtes, mais cette fois pilotée par des expressions régulières.
La requête étiquetée « Acronymes » n'est qu'un composant parmi d'autres pouvant s'appliquer à cette structure. Il capture aussi bien des séquences en majuscules (« ABCD ») que des chaînes de la forme « A.B.C.D. », « A. B. C. D. », « A B C D » ou toute autre combinaison mixte :
/\m(?:\.?\ ?\m)+\.?/Is
Mais c'est manifestement insuffisant pour extraire des noms de famille. Peut-être qu'il n'y aurait pas grand-chose à changer pour que cela fonctionne. Essayons ceci :
/\m(?:\.?\ ?\m)*\l+/Is
J'imagine que c'est beaucoup plus proche de vos objectifs. Le point essentiel que je voulais souligner dans cette discussion, c'est que le texte source et vos propres contraintes déterminent entièrement la façon de procéder. Il n'y a pas de réponse absolue qui serait indifférente aux réalités structurelles de votre document.
→ IndexMatic³ : vue d'ensemble ; Métacaractères
Reformatage d'une liste de noms
• J'ai une liste de plusieurs centaines de noms classés par ordre alphabétique : «Arrabas, Jacques¶Burton, Robert W.¶Dupont de Boismont, Hyppolite¶etc. Comment l'utiliser comme liste de requêtes ?
Dans la plupart des situations faisant intervenir des noms propres, la question centrale est la suivante : sous quelle forme se trouve l'élément clé que je cherche dans le document ? Et secondairement, quelle entrée d'index lui associer ?
La partie spécifique (la CLÉ) est habituellement le nom de famille. En dehors des ouvrages de généalogie qui exigent des requêtes plus minutieuses, il suffit en général d'identifier un nom de famille pour produire l'entrée d'index. Grosso modo,, on cherche donc à détecter des concordances sensibles à la casse telles que “Arrabas”, “Burton”, “Dupont de Boismont”, pour finalement leur associer dans l'index un terme complet incluant alors, d'une façon ou d'une autre, le prénom de la personne.
(Et si ce scénario général se heurte à des exceptions, on les traitera séparément, au cas par cas.)
Considérons maintenant la liste fournie au départ :
Arrabas, Jacques
Burton, Robert W.
Dupont de Boismont, Hyppolite
. . .
Ce que nous voulons, c'est prendre la partie située avant la virgule comme clé de recherche (seule, sensible à la casse), puis produire un terme absolument identique à la ligne d'entrée. Par exemple (première ligne) :
Arrabas/I => Arrabas, Jacques
Mais nous ne voulons pas opérer à la main cette transformation fastidieuse sur des centaines de lignes ! Alors nous gardons la liste telle quelle et la coiffons d'un chapeau magique : la directive format
:
//~format /[^,]+/ :: ^1/I => ^0 Arrabas, Jacques Burton, Robert W. Dupont de Boismont, Hyppolite . . . // ici des centaines de lignes "<nom>, <prénom>"
Note. - Remarquez qu'une directive split
aurait tout aussi bien fait le job. J'illustre seulement ici une autre façon de procéder.
Supposons maintenant que l'élément « Burton » ne soit pas correct, parce que le document mentionne à la fois « Robert W. Burton » et « Nadia Burton ». Fort bien ! Nous retirons cette ligne du champ d'application de la directive format
et nous créons une requête plus élaborée pour gérer ce cas particulier, mettons :
/(Nadia) Burton|Burton/I => Burton, {$1:Robert W.}
qui signifie : « Si ‘Nadia’ apparaît juste avant ‘Burton’ dans le texte, alors nous parlons de Nadia Burton ; sinon on admettra que, par défaut, il s'agit probablement de Robert W. Burton. »
Et finalement, notre liste de requêtes revêtira la forme suivante :
//~format /[^,]+/ :: ^1/I => ^0 Arrabas, Jacques Dupont de Boismont, Hyppolite . . . Zipf, George Kingsley // Cas spéciaux : /(Nadia) Burton|Burton/I => Burton, {$1:Robert W.} . . .
Notez qu'une simple ligne vide stoppe l'effet de la directive format
.
→ Directives ; Opérateur conditionnel ternaire
Concordance et redondance
• L'ouvrage dont je suis en train d'établir l'index possède des prénoms abrégés sous trois formes distinctes : "P. H. Nielsen", "L.-D. Nisipeanu", "G. Kasparov". Je récupère ces éléments depuis un style de caractère. J'utilise alors les trois requêtes suivantes :
// 1. Capture "P. H. Nielsen" etc.
/([A-Z]\. [A-Z]\. )([A-Z]\w+)/ => $2, $1
// 2. Capture "L.-D. Nisipeanu" etc.
/([A-Z]\.\-[A-Z]\. )([A-Z]\w+)/ => $2, $1
// 3. Capture "G. Kasparov" etc.
/([A-Z]\. )([A-Z]\w+)/ => $2, $1
Mais Nielsen sort dupliqué, à la fois sous la forme "Nielsen, H." et "Nielsen, P. H." Comment corriger cela ?
Sachant qu'ExtendScript ne supporte pas le lookbehind, il n'est pas possible d'empêcher la concordance partielle de "P. H. Nielsen" avec la troisième requête, concordance parasite puisque que l'expression complète est déjà repérée et correctement traitée par la première requête. Ce problème classique se pose à chaque fois que nous devons contrôler le contexte de démarrage d'une expression régulière. Par chance, dans le cas que vous nous soumettez, le problème peut être réglé en remplaçant les trois requêtes par une seule :
// Traite tous les cas d'un coup:
/([A-Z]\.(?:[ -][A-Z]\.)?) ([A-Z]\w+)/ => $2, $1
Cela fonctionne parce que l'opérateur ?
, en milieu de requête, est gourmand : il oblige le moteur à prendre "P. H." plutôt que "P." tout seul quand l'élément optionnel est présent. La meilleure stratégie, lorsqu'il faut capturer les variantes d'une même forme générale, est d'intégrer tous les cas de figures dans une même requête. L'utilisation de requêtes multiples tend à créer de la redondance dès lors que deux expressions régulières distinctes sont susceptibles de capturer la même chaîne, en tout ou partie.
Note. — Dans la regex ci-dessus, la syntaxe (?:
a pour fonction de déclarer une parenthèse non capturante. Cela permet de créer un groupe optionnel,
(?:[ -][A-Z]\.)?
sans risquer d'augmenter le numéro d'ordre des variables capturées. Ainsi, $2
désigne toujours la dernière portion du motif : ([A-Z]\w+)
.
→ Quantificateurs gourmands et frugaux ; Variables $
5/ Requêtes avancées
Signes de ponctuation
• Quelle est la façon la plus générique de cibler n'importe quel signe de ponctuation dans une expression régulière ?
Le métacaractère Unicode \p{P}
permet de capturer tout signe de ponctuation. D'autres raffinements sont disponibles :
→ Table des propriétés Unicode
Statistiques sur les lettres
• Je souhaite identifier toutes les lettres (et seulement les lettres) d'un document, y compris celles provenant d'alphabets non latins, puis afficher leur fréquence d'apparition grâce à la fonction « Termes ». Quelle requête envoyer ?
1. Utilisez l'expression suivante :
/\p{L}/IW!
Note. - Le flag spécial !
désactive localement le filtrage des mots vides (car par défaut, tous les mots d'une lettre sont considérés tels).
2. Faites un Ctrl Clic sur le bouton Termes.
3. Rendez visibles les champs Terme et Fréquence. Appliquez éventuellement un tri décroissant aux fréquences.
4. Cliquez sur OK.
Note. — Le métacaractère \p
n'est jamais affecté par l'alphabet courant : on peut l'utiliser en toute circonstance pour extraire des caractères à partir de propriétés Unicode.
→ Ajout de flags locaux ; Table des propriétés Unicode ; Mots vides
Utilisation du symbole "$"
• Nous testons différentes expressions régulières afin de déterminer laquelle est la plus apte à extraire des adresses Internet. IndexMatic³ peut-il indiquer en sortie quel motif de départ a produit tel ensemble de résultats ?
Dans le terme d'une requête, le symbole $
représente toujours la clé originale dans sa forme littérale. Par exemple :
/[a-z]{3}\d/ => $
regroupe dans un unique sujet, "[a-z]{3}\d", les pages contenant une séquence de trois lettres suivies d'un chiffre.
Par suite, on peut facilement garder trace de la correspondance entre une requête et les concordances trouvées. Dans le cas considéré, une solution consiste à produire chaque motif testé en tant que rubrique de 1er niveau et les URLs trouvées en tant que terme (rubrique finale) :
/motif1/ => $ > $0
/motif2/ => $ > $0
etc.
→ Variables $
Émojis
• Mon livre de recettes utilise des émojis (police EmojiOne) qui naviguent essentiellement entre 🍄 (U+1F344) et 🍿 (U+1F37F). J'utilise ces sortes de marqueurs pour catégoriser le mot qui suit immédiatement, donc mes requêtes reposent sur des motifs du genre /([🍄-🍿])(\w+)/=>$1>$2, etc. Mais IndexMatic³ ne semble pas trouver ces éléments, pourquoi ?
1. Les caractères Unicode reflétant les émojis se situent au-delà du plan multilingue de base (PMB), autrement dit, ils sollicitent des points de code supérieurs à U+FFFF. Ces derniers ne peuvent pas être intégrés à une classe de caractères, car ils sont alors identifiés aux paires de substitution UTF16 qui les composent. Par ex., [🍄-🍿] se réduit syntaxiquement à [\uD83C\uDF44-\uD83C\uDF7F]
, ce qui n'est évidemment pas la classe que l'on désire exprimer.
La solution est de systématiquement décrire un ensemble d'émojis au sein d'une structure alternative de la forme (a|b|c|...)
. Cela impose l'énumération exhaustive des caractères, mais c'est la seule façon de les communiquer au moteur d'expressions régulières.
Supposons que votre document utilise les émojis 🍅, 🍆, 🍇, 🍈, 🍉, 🍋, 🍐, 🍞 comme symboles de repérage ; alors vous rédigerez vos requêtes selon le modèle :
/(🍅|🍆|🍇|🍈|🍉|🍋|🍐|🍞)(\w+)/ => $1 > $2
2. Mais il existe une solution encore plus poussée. Si les émojis cibles possèdent des points de code consécutifs (comme dans votre exemple U+1F344 MUSHROOM — U+1F37F POPCORN
), vous pourrez généralement factoriser la première composante UTF16 (ici \uD83C
) et créer une regex très compacte de la forme (\uD83C[\uDF44-\uDF7F])
, laquelle couvre en réalité tous les symboles en rapport avec la cuisine. Il s'ensuit la requête experte :
/(\uD83C[\uDF44-\uDF7F])(\w+)/ => $1 > $2
Note. - Un bon réflexe est d'enregistrer votre découverte, /(\uD83C[\uDF44-\uDF7F])
, en tant que requête favorite « Emoji Cuisine ».
→ Points de code (Unicode) ; Gestion des requêtes favorites
Diacritiques en arabe
• En arabe, IndexMatic³ ne voit pas une centaine de mots de mon document qui contiennent un caractère Shadda. Comment régler ceci ?
Réponse courte : lorsque « Arabe » est sélectionné comme Alphabet, utilisez la classe [\w\p{Mn}]
au lieu de \w
si vous devez cibler des signes diacritiques spéciaux tels que la marque Shadda.
En détail. - U+0651 ARABIC SHADDA
ne fait pas partie du jeu de lettres arabes reconnues par IndexMatic³, ce qui explique pourquoi \w
ne le capture pas. Ma source pour définir les lettres dans différentes écritures est la spécification Unicode. Selon elle, U+0651
n'est pas une lettre (bien qu'elle appartienne au bloc arabe), mais une marque de non-espacement (Mn) héritant ses propriétés morphologiques du caractère précédent. Plus précisément, il s'agit d'un diacritique combinatoire utilisé avec l'écriture arabe et disponible principalement pour des textes en langues arabe et syriaque.
Grâce à votre message, je suis maintenant plus familier¹ du fait que des textes arabes peuvent nécessiter de tels caractères « non-lettres » afin que des éléments diacritiques soient correctement spécifiés et affichés.
¹ Fait méconnu chez un héritier de l'écriture latine :-/ En français, par exemple, les signes diacritiques habituels sont intégrés d'office dans l'ensemble des lettres Unicode, par exemple ‘É’ est un caractère simple (U+00C9 LATIN CAPITAL LETTER E WITH ACUTE). Il est vrai que nous pouvons également spécifier le glyphe ‘É’ par combinaison de la lettre E et de l'accent aigu (U+0301 COMBINING ACUTE ACCENT), donc une lettre nue et un signe de combinaison diacritique sont utilisables conjointement, mais la plupart d'entre nous ignorent cette option — qu'Unicode décrit comme une décomposition canonique (NFD).
Cela posé, devrions-nous ajouter les diacritiques combinatoires aux jeux de lettres alphabétiques ? Par défaut, nous ne le devrions certainement pas. Car, dans de nombreux systèmes d'écriture, ce n'est pas ce à quoi l'utilisateur s'attend. Une marque combinatoire n'est pas une lettre en soi, et elle pourrait se téléscoper avec des caractères arbitraires n'étant pas davantage des lettres. Cependant, le problème que vous me signalez montre que l'inclusion de ces marques pourrait devenir une option pertinente dans certains alphabets, et notamment pour la langue arabe !
Solution provisoire. - Techniquement, nous avons la possibilité d'utiliser la classe composite [\w\p{Mn}]
au lieu de \w
lorsqu'il s'agit de lettres arabes. De cette façon, un mot comme
الصّبي
traité par la requête /[\w\p{Mn}]+/
sera correctement identifié, alors que le motif /\w+/
l'aurait cassé en deux morceaux non conformes :
الص
بي
Mais je comprends maintenant qu'il serait bien plus commode de surcharger le métacaractère \w
de telle sorte qu'il puisse assimiler le Shadda. La solution que j'envisage est d'ajouter une option « Inclure les diacritiques combinatoires » aux sélecteurs disponibles dans le champ Alphabet (ceux qui permettent d'inclure sélectivement les chiffres, traits d'union, etc.). Pour l'heure, cette fonctionnalité est en attente.
→ Alphabets ; Propriétés Unicode
6/ Sortie
Sortie XML
• Je ne saisis pas le fonctionnement de l'option de sortie XML. Une fois que j'ai édité le fichier XML généré par IndexMatic³, comment réinjecter ces données dans InDesign de façon à produire un index ?
La sortie XML est totalement indépendante d'InDesign. Elle permet d'exprimer un index en langage XML, dans un fichier ad hoc, en vue de traitements ultérieurs (base de données, etc.). Cependant, le flux résultant n'est pas censé offrir une quelconque compatibilité avec la couche XML propre à InDesign.
→ Sortie XML
Inhiber le tri
Existe-t-il un moyen d'indexer sans trier les résultats (par ordre alphabétique ou autre) ?
Activez le commutateur « Conserver l'ordre original », dans l'Explorateur, en mode Liste de requêtes.
→ Conserver l'ordre original
Index multiples
• Mon objectif est de créer plusieurs index à partir du même livre (index des villes séparément de l'index des personnages). IndexMatic³ peut-il faire cela ?
1. Fondamentalement, IndexMatic³ ne peut gérer et constituer qu'un index à la fois. Vous devez d'abord configurer les options et les requêtes correspondant à l'index des VILLES, puis relancer le script afin de charger les paramètres contrôlant l'index des PERSONNAGES, etc. Il suffit de basculer d'une liste de requêtes à une autre, vos fichiers étant sauvegardés sur disque.
2. Cela étant dit, une autre solution consiste à créer une seule liste de requêtes avec pour rubriques principales VILLES, PERSONNAGES, etc., et en traitant comme des sous-rubriques les éléments de chaque index. Par exemple :
/Boston|Atlanta|Paris/ => VILLES > $0
/Jean|Bernard|Jules/ => PERSONNAGES > $0
Bien que cela conduise stricto sensu à un seul index, sa structure se rapproche assez de ce que vous recherchez et il est aisé d'en isoler les différentes parties :
PERSONNAGES
Bernard 5, 12-13, 20...
Jean 14, 18, 22...
Jules 17, 20-23...
VILLES
Atlanta 7, 9, 12-13...
Boston 15...
Paris 12-15, 17-22...
→ Emboîtement de rubriques ; Export et ré-import de paramètres
Indication des entrées non trouvées
• La précédente version d'IndexMatic offrait une option pour marquer dans l'index les termes « non trouvés » (en utilisant le caractère —). Cette fonction a-t-elle disparu ?
Rendez-vous dans Sortie > Destination > Fréquence et entrez 0
(zéro) comme valeur Minimum. Cela conduit IndexMatic³ à conserver en sortie les termes de fréquence nulle, c'est-à-dire sans concordance.
→ Entrées non trouvées
7/ Problèmes connus et dépannage
Conservation des enrichissements
• Y a-t-il un moyen de préserver la mise en forme du texte dans une entrée d'index ? Par exemple, les titres d'œuvres, les noms d'espèces, etc., sont typiquement composés en italique dans le texte source.
Non, IndexMatic³ reste un moteur de recherche « plein texte », il peut cibler tel ou tel style mais, en sortie, il ne conserve aucune trace des enrichissements appliqués au texte.
Notez qu'une même expression (ou le même motif de texte) pourrait se manifester dans différentes mises en forme au sein du document. Supposons qu'IndexMatic³ trouve le terme « New York Times » en italique sur la page 1, puis la même chaîne de caractère en romain sur la page 2... S'agit-il de la même rubrique ? Dans ce contexte, comment décompter les occurrences, le Page Rank, etc. ? La réponse est équivoque.
À noter cependant qu'IndexMatic³ vous offre un contrôle très granulaire des styles générés en sortie IDML ou InDesign. Cela permet de prérégler de nombreux attributs de formatage au niveau des termes, rubriques et sous-rubriques (H0
, H1
, H2
...), folios, séparateurs, etc. En pratique, beaucoup d'utilisateurs iX³ exploitent avec succès les styles Grep d'InDesign pour ajuster la typographie de certains éléments bien déterminés.
→ Styles prédéfinis en sortie
Styles de caractères « indirects »
• Lors d'une indexation basée sur des styles de caractère, IndexMatic³ ne trouve que les expressions explicitement soumises au style considéré, mais pas celles qui revêtent ce style sous l'effet d'un style imbriqué ou d'un style GREP. Pourquoi ?
IndexMatic³ en effet n'analyse pas les « styles indirects ». Il considère uniquement les styles de caractère ou de paragraphe formellement appliqués — peu importe les enrichissements que le texte possède par ailleurs.
Solution : utilisez un script de conversion des formatages indirects en styles réels. Différents outils ont été présentés dans ce billet de CreativePro (en anglais) : « Free Scripts Help Fix Word Formatting ».
→ Styles «remplacés»
PDF importés
• Certaines pages de nos catalogues de produits sont construites grâce à des fichiers PDF que j'importe directement dans InDesign. Mais lorsque j'utilise IndexMatic³ il ne détecte pas les codes articles inscrits dans ces pages.
En effet, IndexMatic³ ne « voit » pas le texte inscrit dans un PDF placé dans InDesign. Et d'ailleurs, InDesign lui-même ne voit pas ce texte et ne nous offre aucune fonction pour y accéder.
Pour le moment, il n'y a pas de réponse simple et directe à ce problème. À peu de choses près, un PDF importé se comporte comme une image. La couche scripting d'InDesign l'expose comme un objet graphique et son contenu intime nous reste inaccessible. Certes, l'encodage des PDFs permettrait en principe de récupérer le texte (c'est typiquement ce que font les visionneuses implémentées dans les navigateurs), mais une telle fonctionnalité est assez lourde à embarquer dans IndexMatic³. Cependant, nous y réfléchissons…
Écran noir !
• Alors que tout fonctionnait très bien jusqu'alors, ma console IndexMatic reste vide et ne semble plus répondre…
En raison d'un bug apparu avec InDesign 2024 (19.x), l'affichage de certaines couleurs n'est plus pris en charge dans l'interface utilisateur (ce qui conduisait à la sensation d'un écran vide alors qu'IndexMatic³ continuait de fonctionner normalement en arrière-fond).
Ce bug cosmétique a été corrigé (contourné) à partir de la version 3.23111. Téléchargez la nouvelle version du programme depuis votre lien privé !
→ MÀJ de compatibilité pour InDesign 2024
Sélection de chapitres non restaurée !
• L'option « Mémoriser les chapitres d'un livre » ne semble pas fonctionner. Quand je relance IndexMatic³, il ne préselectionne pas les chapitres sur lesquels je travaillais la fois d'avant.
Bug corrigé dans la version 3.24012. Téléchargez la nouvelle version du programme depuis votre lien privé !
→ Mémoriser les chapitres d'un livre
InDesign ne répond plus
• IndexMatic³ traitait mes expressions régulières à la vitesse de l'éclair, et soudain, après un ajustement anodin de ma liste de requêtes, la barre de progression s'immobilise et InDesign ne répond plus.
Dans cette situation très spécifique où InDesign ne répond plus alors que le CPU travaille encore à plein régime — et si vous ne pouvez pas forcer la fermeture du dialogue en maintenant appuyée la touche Échap — vous êtes alors en train d'expérimenter une boucle infinie du processeur ExtendScript d'expressions régulières.
Il ne s'agit pas à proprement parler d'un bug IndexMatic (bien qu'il se traduise par une paralysie du programme), mais d'un dysfonctionnement interne du système de script. Il existe en effet des bugs inhérents au traitement des regex par ExtendScript. Nul n'en possède la liste exhaustive, il est donc quasi impossible de les détecter et/ou de les neutraliser en amont.
Cependant, neuf fois sur dix, nous savons que cette catégorie de problèmes est liée à une erreur de « retour sur trace » — qui engendre alors cette maudite boucle infinie. Plus concrètement, nous savons que la plupart des crashs découlent de l'usage de quantificateurs emboîtés ou d'alternatives quantifiées, typiquement dans le modèle simplifié suivant :
/... (a|b|c)?/ => ...
Le point d'interrogation à la fin de l'expression régulière rend optionnelle la capture d'une des alternatives (a|b|c)
, et ce modèle d'apparence inoffensive peut déclencher une boucle critique (pour ExtendScript) du fait qu'il apparaît vers la fin de la requête, non suivi de contraintes supplémentaires forçant le processeur à prendre une décision.
Dans le cas particulier que nous venons d'évoquer, il est quelquefois salutaire de réécrire le motif d'une façon équivalente en exprimant le quantificateur ?
par une option vide:
/... (a|b|c|)/ => ...
D'une façon plus générale, tentez d'alléger la superposition de quantificateurs et d'éléments optionnels dans vos requêtes, facilitez la vie du processeur en imposant des conditions plus sévères aux bornes du motif. Des utilisateurs ont également remarqué que l'emploi de quantificateurs non gourmands plutôt que d'assertions de type lookahead pouvait ponctuellement résoudre certains problèmes complexes.
→ « The Hard Problem of Quantified Alternatives in ExtendScript » (EN) ; Requêtes avancées : quantificateurs
Une question à ajouter ? Un bug à signaler ?
Contactez-moi → support{at}indiscripts[dot]com