IndexMatic 2 | Foire aux questions [màj]
April 19, 2012 | IndexMatic | fr | en
IndexMatic 2 s'affirme sans conteste comme l'un des scripts d'indexation les plus sophistiqués entre les mains des éditeurs, auteurs, maquettistes, utilisateurs d'InDesign CS3, CS4 et CS5+. Il existe cent façons de l'exploiter, de le paramétrer, d'affiner les stratégies de recherche et d'extraction… Et, peu à peu, de nombreux utilisateurs découvrent que ce qui leur semblait inaccessible au début se révèle à la portée du produit. Cette page se propose de muscler leur courbe d'apprentissage à travers une sélection concrète de questions/réponses.
1/ Généralités
Guide d'utilisation
Numéro de version
Compatibilité CS5.5
Mémorisation des préférences
IndexBrutal vs IndexMatic
2/ Portée, contexte et options de recherche
Empêcher l'indexation de l'index !
Extraction automatique de vocabulaire
Concordances et Page Rank
« Mot Entier » et Regex
Texte conditionnel
Cibler plusieurs styles de caractères
Espaces et mots entiers
Mode automatique vs requêtes explicites
3/ Requêtes simples
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
Utilisation du métacaractère "\w"
Extraction de données XML
Espaces spéciales
4/ Requêtes avancées
Insertion d'intertitres (A, B, C…)
Ponctuation
Concordances et redondance
Statistiques sur les lettres
Utilisation isolée du symbole "$"
5/ Sortie
Sortie XML
Index multiples
6/ Limitations et problèmes connus
Erreur système -982 / Verdana
Conservation des enrichissements typographiques
Alphabets non latins
Barre de progression inerte / Indexation de tableaux
Effet retard ?
Styles de caractères « indirects »
Mots interdits ?
Erreur : « Incorrectement formé » (extrait InDesign)
1/ Généralités
Guide d'utilisation
• IndexMatic est facile à tester mais paraît beaucoup plus difficile à apprivoiser en profondeur. Où trouver un bon tutoriel expliquant pas à pas ses fonctionnalités avancées ?
[TOUTES VERSIONS] La seule référence complète est le manuel d'utilisation (PDF), disponible à la fois en anglais et en français. Ce dernier a été conçu pour guider l'utilisateur depuis la prise en main jusqu'aux opérations les plus raffinées impliquant l'interpréteur de requêtes et les expressions régulières, sans omettre de nombreuses précisions techniques liées à la procédure d'analyse des documents InDesign par IndexMatic.
D'autres exemples concrets et études de cas case seront peu à peu abordés dans cette FAQ — qui s'alimentera je l'espère de vos commentaires !
Numéro de version
• Comment connaître la version d'IndexMatic en cours d'utilisation ?
[TOUTES VERSIONS] Le numéro majeur de version s'affiche dans la barre de titre de la boîte de dialogue principale, typiquement : « IndexMatic PRO | 2.0 » (version pro) ou « IndexMatic TRY | 2.0 » (version d'essai). Par ailleurs, le numéro complet de version est indiqué en bas à droite de la boîte de dialogue principale. Par exemple : « 2.026 ».
Compatibilité CS5.5
• Nous avions acquis une licence d'IndexMatic PRO et, ces jours-ci, nous effectuons une mise à niveau d'InDesign vers CS5.5. Le script est-il réutilisable ?
[TOUTES VERSIONS] IndexMatic2 fonctionne sous InDesign CS3, CS4, CS5 et CS5.5. (Sous CS3, quelques rares fonctionnalités sont entravées.) Pour « installer » le script avec une nouvelle mouture d'InDesign, placez tout simplement le fichier IndexMaticPro.jsx (ou IndexMaticTry.jsx) dans le dossier Script Panels correspondant à ladite version d'InDesign.
Rappel. — La façon la plus simple de localiser le dossier Scripts Panel est de démarrer InDesign, d'ouvrir le panneau Scripts (Fenêtre > Utilitaires > Scripts), d'effectuer un clic droit sur l'élément « Utilisateur » ou « Application », puis de cliquer sur « Révéler dans le Finder / Explorateur ».
Mémorisation des préférences
• Y a-t-il un moyen de conserver-restaurer les dernières options choisies dans le dialogue d'IndexMatic ? C'est un peu frustrant de recommencer tout le paramétrage à chaque fois que je relance le script.
[VERSION TRY] La mémorisation des paramètres pendant votre session InDesign est seulement implémentée dans la version PRO d'IndexMatic.
IndexBrutal vs IndexMatic
• J'ai exploité pendant des années votre script « IndexBrutal ». Puis-je réutiliser dans IndexMatic les mêmes listes de mots, telles que je les avais préparées pour IndexBrutal ?
[TOUTES VERSIONS] Toutes les fonctionnalités d'IndexBrutal sont présentes dans IndexMatic2 — et bien davantage ! — mais vous ne pourrez pas réutiliser les requêtes IndexBrutal telles quelles si des opérateurs syntaxiques étaient sollicités. En effet, IndexMatic s'appuie sur une syntaxe différente pour gérer la sensibilité à la casse, la réécriture des termes et l'option « Mot entier ». Au minimum, vous aurez à appliquer les conversions suivantes :
| Syntaxe IndexBrutal | Syntaxe IndexMatic2 |
|---|---|
| chat|félin | chat=>félin |
| >thérap | thérap/W |
| !marguerite | marguerite/I |
| !Urssaf | Urssaf/i |
2/ Portée, contexte et options de recherche
Empêcher l'indexation de l'index !
• Dans la mesure où je place l'index généré à la fin du livre soumis à l'indexation, je ne souhaite pas qu'IndexMatic analyse les pages portant l'index lui-même ! Comment indiquer au script qu'il devra ignorer cette section ?
[TOUTES VERSIONS] Il y aurait maintes façons d'opérer. Je recommande l'une des deux suivantes :
(a) Dans le panneau Portée, sélectionnez Étendue > Pages... et saisissez explicitement l'intervalle de pages que vous souhaitez indexer, en excluant les pages correspondant à l'index. Par ex. : 1-250 si l'index démarre en page 251.
(b) Une autre stratégie consiste à aménager tout le contenu indexable sur un calque dédié — appelons-le « Indexable » — en prenant soin de placer l'index (ou autres éléments hors de propos) sur un autre calque. De cette façon, vous n'aurez plus à spécifier l'étendue d'indexation, il vous suffira de choisir le calque « Indexable » dans la liste Calque(s) du panneau Scope.
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 ?
[VERSION PRO] 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. Dans le panneau Portée, rubrique Document(s), choisissez « Livre ». Dans le panneau Options par défaut, fixez le Page Rank à 3 ou 4 (ce sont habituellement des valeurs adéquates). Cliquez alors sur le bouton Occurrences..., qui ouvre une petite boîte de dialogue dédiée. Décochez la case « Afficher les statistiques » et cliquez sur le bouton Démarrer. Vous obtenez alors une liste de mots, facile à nettoyer et à personnaliser, qui constituera un bon point de départ pour l'indexation en mode « Liste de requêtes ».
Concordances et Page Rank
• Étant donné une expression régulière comme /Steve|Bill/, qui produit deux termes — "Steve" et "Bill" — le Page Rank s'applique-t-il à chaque terme ou en considération du nombre total d'expressions capturées par page ?
[TOUTES VERSIONS] Le filtre Page Rank 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 Page Rank à 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 Page Rank 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 Page Rank est largement satisfait.)
« 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.
[TOUTES VERSIONS] 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 le panneau Options par défaut (ainsi, le flag est globalement désactivé).
OU
(b) Ajoutez le flag W à la fin du motif :
/\\index\{([^}]+)\}/W => $1
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 ?
[TOUTES VERSIONS] 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.
Cibler plusieurs styles de caractères
• Les données que nous devons indexer sont formatées ainsi : "Name/Reference". Le premier élément (Name) possède le style de caractère "Product Name" alors que le second élément (/Reference) possède le style de caractère "Product Ref". Lorsque nous sélectionnons le style "Product Name" dans IndexMatic et que nous lançons la requête /[a-z]+\/[0-9]+/i, le script ne renvoie aucun résultat. Comment procéder ? Est-il alors possible de produire les lignes d'index sous la forme : "Name (Reference): numéros de page" ?
[TOUTES VERSIONS] IndexMatic ne peut pas cibler directement un motif de texte distribué sur plusieurs styles de caractères (sauf à ne spécifier aucun style). Cependant, une solution simple consiste à rassembler les différents styles sollicités au sein d'un groupe de styles. Vous pourrez alors sélectionner ce groupe dans la rubrique Styles de la boîte de dialogue — les groupes de styles sont listés sous la forme: [nom_du_groupe] *. Voici en détail comment procéder dans votre cas :
1. Dans InDesign, ajoutez un groupe de styles de caractère — disons "Product" — puis déplacez les deux styles désirés — "Product Name" et "Product Reference" — dans le groupe nouvellement créé.
2. Démarrez IndexMatic. Dans la liste des Styles de caractère, choisissez : [Product] *.
3. Envoyez la requête : /([a-z]+)\/([0-9]+)/i => $1 ($2).
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 » ?
[TOUTES VERSIONS] 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)))/
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 ?
[TOUTES VERSIONS] 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 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+/
3/ Requêtes simples
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 À or É. Comment procéder ?
[TOUTES VERSIONS] 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.)
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 ?
[TOUTES VERSIONS] 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 (sujet homonyme), tandis que la seconde crée parallèlement le sujet « France » (à partir des occurrences de « Paris »).
Une autre approche consisterait à présenter « Paris » comme une sous-entrée du sujet « France » :
Paris => France > $0
La requête ci-dessus est plus avisée, en ce qu'elle prépare l'adjonction d'autres membres dans le sujet « 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 le sujet « France » en ajoutant une référence croisée (notez la double barre oblique au début de la requête) :
// Paris => Voir France
Au final, votre liste de requêtes complète pourrait alors ressembler à ceci :
// Bordeaux => Voir France
// Paris => Voir France
/Paris|Bordeaux/ => France > $0
• 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 un autre sujet nommé "PARIS". Comment faire ?
[TOUTES VERSIONS] La syntaxe des références croisées permet de placer un renvoi au sein de n'importe quel sujet ou membre (existant ou virtuel). Il suffit de mettre en forme le faux terme (cf. manuel, page 20) selon la syntaxe d'un membre :
// FRANCE > Paris => Voir PARIS.
Considérons maintenant la liste de requêtes suivante :
...
FRANCE
PARIS
// FRANCE > Paris => Voir PARIS.
...
Elle aura pour effet de produire un index de la forme :
…
FRANCE: folios
Paris: Voir PARIS
…
PARIS: folios
…
Gestion des pluriels
• Est-il possible d'indexer, à partir d'une liste de mots au singulier, à la fois le singulier et le pluriel ?
[TOUTES VERSIONS] 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 concurrentes au sein des requêtes.
Pour indexer des formes au singulier et au pluriel — ou même d'autres alternatives — sous la même entrée d'index, il convient d'ajuster vos requêtes pour qu'elles capturent ces variantes 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.
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 ?
[TOUTES VERSIONS] 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.
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" ?
[TOUTES VERSIONS] 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\.)[^ ]+/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 Occurrences...), il ne vous restera qu'à établir et affiner votre liste de requêtes de façon à capturer les noms et les URLs des sites.
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éfaut, quelle alternative suggérez-vous ?
[TOUTES VERSIONS] La taille maximum d'une clé, dans une requête IndexMatic, est fixée à 172 caractères depuis la version 2.025. Cela permet de fabriquer des expressions régulières complexes, mais pas au point d'inclure des centaines d'alternatives. La seule solution est donc d'utiliser une traditionnelle Liste de requêtes :
Jean => Auteurs > $0
Bernard => Auteurs > $0
Caroline => Auteurs > $0
...
Toutefois, rien ne vous interdit d'optimiser la liste par regroupement de termes alternatifs, sous réserve de ne pas aboutir à des clés de recherche de plusieurs kilomètres. Voici une approche possible, basée sur des regroupements 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
...
Utilisation du métacaractère "\w"
• Quelle est la portée exacte du métacaractère \w ?
[TOUTES VERSIONS] Le métacaractère\w s'ajuste automatiquement à l'alphabet : 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 cases correspondantes sont cochées (panneau Alphabet). Je vous renvoie au manuel d'utilisation pour une vue plus détaillée de ces options.
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 cochez les cases « 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_].
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>..."
[TOUTES VERSIONS] 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
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 ?
[TOUTES VERSIONS] Il suffit de forger une classe de caractères correspondant aux espaces désirées : [~<~|] (syntaxe GREP) ou [\u2009\u200A] (rangs Unicode). Reportez-vous au tableau, page 22, du manuel d'utilisation.
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 indiquez expressément.
4/ Requêtes avancées
Insertion d'intertitres (A, B, C…)
• Je souhaite insérer des intertitres A, B, C, etc., au sein de mon index. (Il s'agit purement de mise en forme.) Dois-je ajouter ces lignes manuellement ? Si tel est le cas, y a-t-il un moyen de spécifier ces intertitres directement dans ma liste de requêtes de façon que je n'ai pas à resaisir cette information à chaque fois que je reconstruis l'index ?
[TOUTES VERSIONS] La version actuelle d'IndexMatic n'offre pas la possibilité d'ajouter des titres « externes », à moins d'exploiter le mécanisme des références croisées sous la forme :
// Mon Sujet Titre => voir aussi...
Cependant, dans la syntaxe ci-dessus, la portion "voir aussi…" (située à droite de l'opérateur =>) ne peut pas rester vide ni se contenter de caractères d'espace. Par conséquent, le script ne peut pas produire de simples titres tels que A, B, C… sans élément connexe. (Nous tenterons de résoudre cette limitation dans la prochaine version d'IndexMatic.)
Pour le moment, la seule technique de contournement qui m'apparaît consiste à utiliser un caractère postiche — par exemple un point — pour former les requêtes suivantes :
// A => .
// B => .
etc.
Dès lors vous pourrez créer une règle de style Grep visant à appliquer la nuance [Sans] au motif \t\. (i.e. TABULATION + POINT).
Par ailleurs, dans le cas particulier où votre index est basé sur des expressions régulières produisant seulement des SUJETS de premier niveau, par exemple :
/\w{3,}/
il vous reste toujours l'option d'extraire la première lettre en tant que SUJET et de déplacer les entrées d'index comme MEMBRES dudit sujet :
/(\w)\w{2,}/ => $1 > $0
Il suffit alors de choisir l'option "Maj > Auto" dans la rubrique Casse du panneau de sortie. Ce faisant, vous obtiendrez un index de la forme suivante :
A
{Entrées commençant par A}
B
{Entrées commençant par B}
etc.
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 ?
[TOUTES VERSIONS] Le métacaractère Unicode \p{P} permet de capturer tout signe de ponctuation. D'autres raffinements sont disponibles. Pour une vue complète des propriétés Unicode implémentées dans IndexMatic, reportez-vous au manuel, page 22.
Concordances 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 ?
[TOUTES VERSIONS] Sachant qu'IndexMatic 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 me 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+).
À l'attention des lecteurs francophones. — Un développement plus étoffé a été consacré aux problèmes de concordance et de redondance dans le fil de commentaires de l'article « IndexMatic2 et les expressions régulières » publié chez Indigrep.com. Vous y trouverez notamment une solution pour indexer « Premier ministre » séparément de « ministre ». ACCÈS DIRECT AU COMMENTAIRE
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 « Occurrences ». Quelle requête envoyer ?
[VERSION PRO]
1. Utilisez l'expression suivante :
/[\p{Ll}\p{Lu}\p{Lt}]/IW
2. Dans la rubrique Casse, sélectionnez « [À l'identique] ».
3. Cliquez sur le bouton Occurrences...
Note. — Le métacaractère \p n'est pas affecté par l'alphabet courant : on peut l'utiliser en toute circonstance pour extraire des caractères à partir de propriétés Unicode.
Utilisation isolée 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 ?
[TOUTES VERSIONS] 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 sujet (1er niveau) et les URLs trouvées en tant que membres (2e niveau) :
/motif1/ => $ > $0
/motif2/ => $ > $0
etc.
5/ 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 ?
[VERSION PRO] 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.
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 ?
[TOUTES VERSIONS] 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 et faire de nouveaux réglages pour l'index des PERSONNAGES, etc. L'Éditeur de requêtes permet de basculer rapidement d'une liste de requêtes à une autre si vous travailler avec des fichiers autonomes sauvegardés sur disque (ce qui est recommandé, dans tous les cas de figures).
Cela étant dit, si chaque index repose exclusivement sur des termes de premier niveau, vous pourriez envisager de créer une seule liste de requêtes avec pour sujets principaux VILLES, PERSONNAGES, etc., et en traitant comme des membres respectifs 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...
6/ Limitations et problèmes connus
Erreur système [-982] / Verdana
• Lorsque je tente d'exécuter IndexMatic sur InDesign CS5 / Mac (Lion), je récolte un message d'erreur JavaScript mentionnant une "Erreur système [-982]".
[TOUTES VERSIONS] Ce message d'erreur est lié à l'absence ou à la corruption d'une police de caractères. Assurez-vous que la fonte Verdana est correctement installée sur votre système.
Conservation des enrichissements typographiques
• 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.
[TOUTES VERSIONS] Hélas, le script ne gère pas cet aspect — ce qui constitue, j'en conviens, une limitation importante. Fondamentalement, 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.
Notons qu'une telle fonctionnalité n'est pas aussi simple qu'il y paraît, car la même expression (ou le même motif de texte) peut 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 du même SUJET ? Dans ce contexte, comment décompter les occurrences, le Page Rank, etc. ? La réponse n'a rien d'univoque.
Alphabets non latins
• IndexMatic ne fonctionne pas correctement avec des textes écrits en russe. Envisagez-vous la prise en charge de l'alphabet cyrillique ?
[TOUTES VERSIONS] IndexMatic peut adresser tout caractère Unicode du plan multilingue de base (Basic Multinlingual Plane) mais en effet il n'offre pas de moyen pratique de cibler et de trier des lexiques basés sur l'alphabet cyrillique. Pour l'instant, seuls les alphabets latins sont pleinement pris en charge à cet égard. Nous étudions la possibilité de faire évoluer cela dans une future version.
Barre de progression inerte / Indexation de tableaux
• La barre de progression d'IndexMatic semble se figer complètement quand j'indexe un gros document contenant un certain nombre de tableaux.
[TOUTES VERSIONS] Les tableaux InDesign reposent sur une structure interne particulièrement lourde qui n'offre guère de compromis. Cela explique que l'indexation des tableaux puisse se révéler très lente, avec pour effet d'immobiliser la barre de progression. Soyez patient(s) !
Effet retard ?
• J'ai d'abord cru qu'IndexMatic avait planté. Puis, après une bonne période d'inactivité, l'index final est soudain apparu ! Comment savoir si le script est encore en train de travailler ?
[TOUTES VERSIONS] Ce problème a été rapporté par des utilisateurs Mac. Il semble que la barre de progression puisse « disparaître » (ou en donner l'impression) alors que le processus d'indexation est encore en cours. Il est probable que la barre de progression se trouve en réalité masquée par un autre élément du système, mais bien entendu ce n'est pas le comportement désiré ! Nous essayons d'en savoir plus sur ce problème.
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 ?
[TOUTES VERSIONS] IndexMatic en effet n'analyse pas les « styles indirects ». Il considère uniquement les styles de caractère ou de paragraphe expressément appliqués — peu importe les enrichissements q $2, $1`ue le texte subit par ailleurs.
Comme l'a suggéré Laurent Tournier, une solution de secours consiste à utiliser un script d'appoint capable de convertir les formatages indirects en styles réels. Différents outils ont été présentés dans ce billet d'InDesign Secrets (en anglais) : « Free Scripts Help Fix Word Formatting ».
Mots interdits ?
• Existe-t-il un moyen d'empêcher l'indexation des mots-outils (« le », « est », « un », etc.) lorsqu'on opère en mode Automatique ?
[TOUTES VERSIONS] On peut filtrer les mots courts par l'intermédiaire du paramètre “Taille mini.” du panneau Mode de recherche. Cependant, IndexMatic ne possède pas de liste préétablie de mots interdits (comme le propose Wordalizer). Nous pourrions ajouter cette fonctionnalité dans une future version.
Erreur : « Incorrectement formé » (extrait InDesign)
• J'obtiens parfois une erreur lors de l'export de mon index sous la forme d'un extrait InDesign. Il semble que ce problème résulte spécialement de la présence du caractère '&' dans ma clé de recherche. Lorsque je produis l'index sous forme de texte brut, tout fonctionne normalement ; mais quand je génère un extrait InDesign je récolte l'erreur suivante : « Incorrectement formé ». Y a-t-il à faire un traitement particulier pour le caractère '&' ?
[VERSION PRO] Il s'agit d'un bug incontestable. Après quelques investigations, nous avons en effet constaté que trois caractères à part exigent un encodage spécial pour garantir la validité du flux IDML : &, < et > (comme en XHTML). Par suite, le bug signalé se produira sitôt que l'un de ces trois caractères intervient dans l'index final. Bien entendu, cette erreur sera corrigée dès la prochaine mise à jour d'IndexMatic. D'ici là, contactez-nous à support [at] indiscripts {dot} com si vous avez besoin d'un patch provisoire sur ce problème spécifique.
Comments
Bon, je découvre (…sans aucune surprise à vrai dire…!!) que je ne voyais que 5% des possibilités de ce script…
Bref, à lire dès que j'ai deux heures devant moi…
I am trying to test this program but appears an OS error [-982] in both version, Pro and Try.
Mac, Lion 10.7.2, Indesign CS5.5 / 7.5.2
Thank you
Hi Maria,
Thanks for your feedback. Does the error occur before the script dialog appears?
Please, send me —marc {at} indiscripts {dot} com— a screenshot of the error message and if possible your sample document exported as IDML.
I will investigate as soon as possible.
Thanks,
Marc
I posted the required.
Hi,
The message appears inmediately after clicking the script. Any Indexmatic window or aditional activity is showed. Simply nothing happens.
Thanks.
Maria
[NOTE]
The issue mentioned above is solved. If you encounter the “OS error [-982]”, make sure that the Verdana font file is *properly* installed in your system.
Special thanks to Dominique Chiron (http://doopix.com), who gave me helpful details about “OS Error Codes” in Lion.
Marc
This looks amazing...but...does it have any way to hyperlink the page numbers to the page in the generated index?
Hi daneyul,
About hyperlinks, please see this comment:
http://www.indiscripts.com/post/201...
@+
Marc
Darn, guess I'll need to keep using the native ID a while longer. :<
Thanks for the quick reply!
Hi... Thanks for these FAQs. Sometime i also feel difficulties..specially with space But really here you gave the solutions in a very easy & cool manner. I am a developer and Now whenever i fell any trouble than will post again here.
Sincerely..
Hi Marc,
one additional comment / the reason for my yesterday’s question: I was not able to use my query list of approx. 1000 entrie in the try version, it was cut to ca 550 entries. Thx Jan
Bonjour,
merci pour tous ces scripts très utiles.
J'ai toutefois un problème avec la version test d'indexmatic sous CS3 : le texte contenu dans des tableaux imbriqués dans d'autres tableaux n'est pas indexé. Ce type de configuration n'est peut-être pas très orthodoxe, mais en l'occurrence c'est le résultat d'une mise en page automatisée sur laquelle je n'ai aucun contrôle. Est-ce-que ce problème est limité à CS3 ou à la version test? Sinon est-il prévu d'y remédier ?
Bonjour Claude,
Merci pour votre commentaire.
En effet, IndexMatic ne considère que le contenu des tableaux de premier niveau et ignore tout tableau imbriqué. Cette limitation est documentée dans le manuel (page 6) et concerne aussi bien la version TRY que la version PRO.
> Est-il prévu d'y remédier ?
Cela ne dépend que de ma capacité à concevoir un algorithme plus puissant, capable de traverser les tableaux sans induire des temps d'exécution exponentiels ! Hélas, pas de solution en vue pour le moment.
N. B. — La limitation d'IndexMatic est due à l'inefficacité caractéristique d'InDesign en matière d'adressage des cellules. Durant le parcours d'un tableau, le script sollicite intensément l'application afin de détecter les cellules vides, d'extraire le texte, d'identifier les pages associées, etc., mais InDesign répond à chacune de ces commandes avec une lenteur endémique. Pour prendre en charge les tableaux imbriqués, il faudrait en quelque sorte « boucler sur elle-même » la routine d'IndexMatic (i.e. la rendre récursive), ce qui provoquerait une dégradation vertigineuse des performances.
Cela étant, il existe peut-être une approche complètement différente du problème. Le tout est de la trouver.
@+
Marc
Merci pour cette réponse documentée.
La chose m'avait échappée dans le manuel, pourtant très bien fait.
Je vais creuser de mon côté pour résoudre mon problème. Une exploration sur 2 niveaux me suffirait.
I am trying to produce an index based on a character style sheet using an InDesign book file. When I try to select the relevant character style sheet in the Indexmatic dialogue box, many of the character style sheet names (including the one I need to use!) are listing as 'NaN'.
If I try again with just one document open, all the names of the character style sheets are displaying correctly?
I would be most grateful for any advice on why is this happening and how to resolve it.
Many thanks
Marie
Hi Marie,
Thanks for your feedback. It seems like something goes wrong while the script attempts to extract the common styles from the book chapters.
I'd need more detail to study this bug:
1) What version of ID? What OS?
2) When you run IndexMatic having the book file open in the Book Panel but *no document open* in ID workspace, does the script dialog display correct information in the Scope panel? In particular, does the 'Document(s)' listbox display the right number of documents available in the book?
3) Does the 'NaN' error you mention also occur in the Paragraph styles list?
4) Is there something special to notice about your styles (special characters in names, imported styles, etc.)?
Thanks for your patience. I'll try to fix this ASAP. Feel free to email me further detail or samples if needed: marc [at] indiscripts {dot} com
Regards,
Marc
Bonjour,
je souhaiterais indexer une liste de noms présents dans un document, mais je rencontre quelques difficultés dans la syntaxe à adopter pour une requête personnalisée.
Le document se présente ainsi dans un style de paragraphe dédié :
Prénom (saut de ligne forcé)
Nom
Je voudrais un résultat dans l'ordre inverse et sans saut de ligne; Nom Prénom.
Comment indexer le prénom "jusqu'au saut de ligne", puis le nom et les remettre dans l'ordre inverse afin que la recherche se fasse par le nom et non le prénom ?
Merci.
Bonjour Fabrice,
Merci pour cette question, elle va me permettre de préciser le cas épineux du SAUT DE LIGNE FORCÉ, sur lequel le guide d'utilisation fait cruellement silence.
Tout d'abord, le SAUT DE LIGNE FORCÉ (U+000A) est traité par défaut comme un caractère « blanc » depuis IndexMatic 2.025 (alors qu'il était considéré comme un caractère de saut dans les versions antérieures). Cela signifie que ce caractère est pris comme une espace lorsque l'option ESPACE GÉNÉRIQUE est activée — sinon il serait capturé tel quel et converti en saut de ligne dans l'index résultant. [Ce n'est pas le cas du saut de ligne simple, lequel marque la fin d'un paragraphe, donc d'un segment d'indexation, et se soustrait par conséquent à toute possibilité de capture via une requête IndexMatic.]
Dans les situations courantes d'indexation, le fait d'assimiler le SAUT DE LIGNE FORCÉ à une simple espace est le comportement recherché par les utilisateurs. Cela permet d'adresser plus simplement des expressions composées même si elles sont parasitées dans la composition par un saut « manuel » dépourvu de valeur sémantique.
Cependant, dans l'exemple que vous exposez, la valeur séparatrice du SAUT DE LIGNE FORCÉ importe !
On peut capturer spécifiquement ce caractère grâce au raccourci \n (ou \u000A). Un des problèmes identifiés — sur lequel nous travaillons ! — est que cet élément interfère quelquefois avec l'option MOT ENTIER (irruption d'espaces additionnelles dans l'index, typiquement). C'est pourquoi je vous recommande de désactiver l'option MOT ENTIER (flag \W) lorsque votre cible est suffisamment fine pour s'en affranchir.
Passons maintenant aux travaux pratiques. Pour indexer la forme :
<MOT><SAUT DE LIGNE FORCÉ>
<MOT>
l'approche la plus immédiate est d'envoyer la requête :
/\w+\n\w+/
Mais, dans le cas qui vous occupe, considérant que chaque prénom ou nom peut contenir des espaces internes, il faudra plutôt envisager ceci :
/[\w ]+\n[\w ]+/
Libre à vous d'affiner ce motif si nécessaire. Par exemple, utilisez le méta-caractère \m pour imposer une majuscule comme lettre initiale du nom et du prénom :
/\m[\w ]+\n\m[\w ]+/
[N'oubliez pas qu'à ce stade, le SAUT DE LIGNE FORCÉ est converti en saut de ligne dans l'index résultant.]
Reste maintenant à réorganiser les éléments dans l'ordre « Nom Prénom » et à absorber le saut de ligne. Heureusement, l'opérateur de réécriture d'IndexMatic vient à notre secours :
/(\m[\w ]+)\n(\m[\w ]+)/W => $2 $1
Dans la requête ci-dessus, $2 représente la seconde parenthèse capturante (le Nom), tandis que $1 attrape le contenu de la première (le Prénom).
Notez au passage la présence du flag /W, comme suggéré plus haut.
Voilà. J'espère que vous y voyez maintenant un peu plus clair ;-) Dites-moi si cette solution résout votre problème.
@+,
Marc
C'est plus clair en effet et ça fonctionne (me reste à le tester sur un document long) ! Merci beaucoup.
Hello,
Off topic I think, but there was not a place complain...
I was very impressed by the program possibilities, so I decided to buy. Unfortunately the form gives error message suggesting I have the wrong NIP number. I swear the number is right number. What to do?
Hi janusz,
> Unfortunately the form gives error message suggesting I have the
> wrong NIP number. I swear the number is right number. What to do?
Well, I really don't know, sorry :(
When you purchase a product on Indiscripts.com, the operations related to the payment are entirely performed through PayPal [although you don't need to create a PayPal account to purchase with your Credit Card.]
The whole payment processing is hidden to our server and all we can do from this place is to check whether a payment is complete, or not.
So, I suggest you contact PayPal and/or your card issuer to clarify this problem. (I even don't know how NIP numbers do work behind the scene!)
Sorry not to be more helpful.
Regards,
Marc
NOTE. — About Indiscripts' Terms of Sale and payment processing, please refer to this page: http://www.indiscripts.com/pages/cg...
Bonjour
je vous remercie pour ce script étonnant la vitesse peut varier de fulgurante à très longue suivant ce qu'il doit analyser (j'ai un book avec énormément de tableaux longs. Avoir coché l'option tableau implique un temps d'attente sur le livre semblable a celui que certains moteurs de rendu d'image de synthèse.. on peut aller boire un café, faire ses course, se brosser les dents, faire sont lit.. mais le travail est finalement produit, ce qui est une excellente chose. Par contre, en lisant ce post: http://www.indiscripts.com/post/201... , je me demande ou en est le biscuit car en effet, obtenir des numéros de page cliquables lors de l'export de l'extrait en comblerait plus d'un.
Merci pour votre travail
PM
Concernant l'analyse des tableaux, ci ceux-ci sont provisoirement 'transformés en texte'. Alors tout est fulgurant. Reste à les retrouver à leur états originels
Merci Piem pour ce retour très sympathique :)
En effet, le processus d'indexation des tableaux est étonamment « lourd », en raison des boucles de contrôle qui sont exigées par l'agorithme et de la faiblesse inhérente à InDesign dans ce domaine. C'est un aspect que j'évoque dans le manuel d'utilisation et dans la présente FAQ. On va faire le maximum pour améliorer cela dans les prochaines màj d'IndexMatic.
> Concernant l'analyse des tableaux, si ceux-ci sont provisoirement
> 'transformés en texte'. Alors tout est fulgurant.
Ce serait une solution envisageable dans les cas extrêmes — en travaillant sur un document temporaire — encore faut-il s'assurer que la conversion des tableaux en texte ne bouleverse pas la pagination, ce qui n'est pas une mince affaire !
> […] en lisant ce post : http://www.indiscripts.com/post/201...
> je me demande ou en est le biscuit car en effet, obtenir des
> numéros de page cliquables lors de l'export de l'extrait
> en comblerait plus d'un.
Merci de me le rappeler. Je vais faire remonter cet item sur ma « todo list ». Ah ! Si seulement les journées avaient 48 h ;-)
@+,
Marc
oui :)
Je n'ai pas le gène des maths/logique/code, cependant
j'imagine les choses ainsi:
nb: quand je dis 'on' bien sur je parle du script :)
si la page comporte un ou des tableaux on crée sur cette page un layer provisoire (par exemple tbcsv*)
, bien sur on ignore l'analyse des tableaux, alors on (se contente de) copy & paste les entités de tables sur le calque tbcsv*, ensuite on explose en texte (peu importe les options tab ou virgule ou autre, tout fera l'affaire)
(a ce moment la pagination est anecdotique, tant que les tableaux se trouvent à leur bons numéros de page - le texte en excès étant tout de même analysé)
on récupère les infos , on supprime le layer tbcsv* et on passe au suivant.
Peut-être y a t-il des difficulté de sélection lorsque le tableau est en partie ou totalement verrouillé.. je ne sais pas
Quoi qu'il en soit je suis déjà heureux de gagner du temps grâce à ce script.
Merci encore
Bonjour Piem,
> si la page comporte un ou des tableaux on crée sur cette page
> un layer provisoire […] ensuite on explose en texte […]
> a ce moment la pagination est anecdotique, tant que […]
> les tableaux se trouvent à leur bons numéros de page…
Sachez que lors de la conception d'IndexMatic ce type de stratégie a été sérieusement étudiée et pesée. Mais elle se heurte à une série d'obstacles dont je vous donne les deux plus rédhibitoires :
1) La production de contenus temporaires sur un calque de réception dédié aux tableaux « explosés » induit un temps additionnel qui peut se révéler dévastateur sur des documents longs (ou sur un livre entier) lorsque le nombre de pages concernées par cette opération s'accroît. Toute modification, même provisoire, de gros documents de travail, implique des temps de rafraîchissement coûteux pour InDesign, dont IndexMatic pâtirait — outre que le script a pour règle d'or de ne pas « toucher » aux documents cibles.
2) La conversion des tableaux en texte ne résout aucunement le cas épineux des tableaux multipages. Techniquement, un tableau ancré en page 1 et qui se déploie sur plusieurs pages via des blocs chaînés n'est pas « vu » par InDesign comme appartenant à ces différentes pages. Il est vu seulement comme un élément de la page 1. Par conséquent, lors de l'explosion de ce tableau en texte, le problème se pose de conserver la pagination réelle de façon à ce qu'IndexMatic retourne les bons folios pour tout fragment de texte indexé. Or, vous devez savoir que c'est précisément cette question — déterminer la page réelle où apparaît telle cellule d'un tableau — qui consomme du temps de calcul dans IndexMatic !
Le jour béni où les développeurs d'InDesign nous donneront un moyen de récupérer efficacement la PAGE où apparaît une cellule donnée d'un tableau donné, le temps de travail d'IndexMatic sera considérablement raccourci — mais pas pour CS3, CS4 et CS5 !
Cela étant, je ne désespère pas de trouver moi-même une autre solution algorithmique... Qui vivra verra ;-)
@+,
Marc
Les tableaux multi-pages posent un gros problème. Je comprend
Après tout, l’utilisateur, s'il est ordonné, peut préparer le terrain lui même et cacher le layer contenant les véritables tableaux
Merci d'avoir été si clair :)
PM
Je suis têtu, sans doute mon côté breton:
J'insiste:)
Pourtant lorsque vous copiez/collez des tableaux chainés sur plusieurs pages, vous ne vous retrouvez plus avec 1 tableau multipage mais avec 1 tableau (ou au moins un) par page et qui sont tout à fait indépendants. il n'y a plus de chainage.. L'explosion en texte ne pose plus de souci puisque ce que vous avez copié/collé n'est que ce que la page contenait.(me trompe-je?)
j'ai par exemple un tableau de disjoncteurs reparti sur 5 ou six pages.. ça le fait
Je ne suis pas sûr d'avoir parfaitement saisi votre idée, mais je vais creuser cela à tête reposée. (Après tout, j'ai du sang breton moi aussi ;-)
@+
Marc
Je ne veux pas polluer trop longtemps votre fil avec des questions auxquelles vous avec déjà dû réfléchir et je m'excuse auprès des lecteurs et autres spécialistes d'Indesign
Vous avez laissé ouverte la porte à des approches différentes, je vais parler avec mes mots qui ne sont pas 'techniques' :)
copier/coller des cadres de texte contenant des flux de tableau(x) (avec l’outil de sélection V) n'est pas copier le tableau en entier (ce qui d'ailleurs me semble impossible sans être obligé entrer dans le tableau lui même avec l'outil texte puis de tout sélectionner..etc).
Donc, lorsque vous sélectionnez (V) 1 (ou +) cadre contenant le tableau
Le flux ( le chainage) des pages précédentes et suivantes est ignoré, le résultat collé est un nouveau tableau, réduit à ce qui se trouvait visuellement sur la page. Le cas échéant et suivant votre sélection, on peut conserver le chainage présent sur la page.. mais c'est tout, rien ne va ni ne vient au-delà.
En ce sens, un tableau réparti sur 6 pages, une fois copié/collé, devient 6 tableaux indépendants (1 par page).
Indesign peut éclater un tableau en csv en un éclair
C'est sur ce point que je voulais attirer votre attention.
Le copier-coller d'InDesign possède en effet des propriétés remarquables, du fait de sa capacité à conserver la « photographie » d'une page par-delà la rupture qui s'opère dans le chaînage des blocs prélevés. Et — vous avez raison de le souligner — c'est un point singulièrement spectaculaire dans le cas des tableaux car, lorsqu'un bloc-texte chaîné contient seulement la « séquelle » d'un tableau initié dans un autre bloc, il est VIDE de tout contenu du strict point de vue de la structure objet. (Tout tableau InDesign est « ancré » via un caractère spécial, U+0016, situé dans le bloc d'origine. Notez d'ailleurs qu'il suffit de copier ce caractère pour récupérer et coller le tableau tout entier à un autre emplacement.) Mais le copier-coller du bloc séquellaire s'affranchit totalement de ces considérations et parvient à répliquer l'extrait de tableau, comme par magie, dans un objet neuf et autonome.
Je comprends mieux votre suggestion désormais, même si elle présente encore pas mal de difficultés techniques que je vais vous épargner. Quoi qu'il en soit, c'est de toute évidence une piste à creuser.
Merci de votre excellente contribution.
Marc
Hello again its me (Jannusz with the billing problem).
I'm just after the long talk with PayPal guys. They checked everything and gave me authoritative judge: From your side everything is correct. Probably the script on the page: http://www.indiscripts.com/store/ix...
checking the VAT ID number is wrong, giving the message:
"Ooops! The VAT ID Number is not valid or doesn't match your country."
So what to do?
Maybe I'll send you money from PayPal to you account directly?
Best regards
Janusz
PS Nobody from Poland ever bought the Indexmatic?
Hi janusz
> Probably the script […] checking the VAT ID number is wrong,
> giving the message: "Ooops! The VAT ID Number is not valid or
> doesn't match your country."
> […]
> PS Nobody from Poland ever bought the Indexmatic?
Most of the time our “VAT checker” works fine—and we already have (many!) customers in Poland who successfully supplied their VAT ID.
However, the script depends on the availability of the UE's VAT Number Validation Service (VIES), which might—rarely—fail.
Note: a Poland VAT ID always starts by 'PL' and is followed by one block of 10 digits. Could you please make sure that this field is correct and try again?
If this still does not work, please contact me privately at:
support [at] indiscripts {dot} com.
Regards,
Marc