Comments

#1 By Jean-Christophe d'urbanbike ( 04 December 2011 - 20:38 )

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…

#2 By Maria ( 15 December 2011 - 16:08 )

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

#3 By Marc ( 15 December 2011 - 17:32 )

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

#4 By Maria ( 15 December 2011 - 21:52 )

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

#5 By Marc ( 19 December 2011 - 19:17 )

[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

#6 By daneyul ( 19 December 2011 - 23:59 )

This looks amazing...but...does it have any way to hyperlink the page numbers to the page in the generated index?

#7 By Marc ( 20 December 2011 - 16:51 )

Hi daneyul,

About hyperlinks, please see this comment:
http://www.indiscripts.com/post/201...

@+
Marc

#8 By daneyul ( 20 December 2011 - 20:43 )

Darn, guess I'll need to keep using the native ID a while longer. :<

Thanks for the quick reply!

#9 By Jan Hugo ( 14 January 2012 - 21:30 )

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

#10 By Claude ( 18 January 2012 - 14:40 )

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 ?

#11 By Marc ( 19 January 2012 - 12:28 )

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

#12 By claude ( 19 January 2012 - 16:52 )

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.

#13 By Marie ( 18 February 2012 - 15:18 )

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

#14 By Marc ( 19 February 2012 - 02:44 )

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

#15 By Fabrice ( 26 March 2012 - 15:49 )

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.

#16 By Marc ( 27 March 2012 - 00:11 )

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

#17 By Fabrice ( 27 March 2012 - 11:02 )

C'est plus clair en effet et ça fonctionne (me reste à le tester sur un document long) ! Merci beaucoup.

#18 By janusz ( 27 March 2012 - 18:28 )

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?

#19 By Marc ( 27 March 2012 - 21:42 )

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

#20 By Piem ( 30 March 2012 - 08:36 )

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

#21 By Piem ( 30 March 2012 - 10:21 )

Concernant l'analyse des tableaux, ci ceux-ci sont provisoirement 'transformés en texte'. Alors tout est fulgurant. Reste à les retrouver à leur états originels

#22 By Marc ( 30 March 2012 - 16:48 )

Merci Piem pour ce retour très sympathique :)

En effet, le processus d'indexation des tableaux est étonnamment « lourd », en raison des boucles de contrôle qui sont exigées par l'algorithme 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

#23 By Piem ( 30 March 2012 - 17:37 )

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

#24 By Marc ( 31 March 2012 - 12:09 )

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

#25 By Piem ( 31 March 2012 - 14:44 )

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

#26 By Piem ( 31 March 2012 - 15:56 )

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

#27 By Marc ( 02 April 2012 - 05:53 )

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

#28 By Piem ( 02 April 2012 - 10:18 )

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.

#29 By Marc ( 02 April 2012 - 13:32 )

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

#30 By janusz ( 03 April 2012 - 13:33 )

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?

#31 By Marc ( 03 April 2012 - 15:26 )

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

#32 By Laszlo ( 19 May 2012 - 18:19 )

Hi Mark,

I have a task. There is an InDesign document full with names. They are discriminated by their character attributes from the rest of the text (e.g., bold-italics, italics etc.).
I can convert them into separate character styles (with find&replace), however, I cannot find any option to select in one query for example two or more character style in Indexmatic. I understand that I can do it in two steps but than I have to merge several hundreds of exactly the same word in the index.
Is it a real limitation or I simple missed something.

Thanks in beforehand

Laszlo

#33 By Marc ( 19 May 2012 - 23:09 )

@ Laszlo

> I cannot find any option to select in one query for example two or more
> character style in Indexmatic. […] Is it a real limitation or I simple
> missed something.

You are perfectly right in the sense that IndexMatic can only target a single character style—or character style group— at the same time.

From there, the trick is to create a STYLE GROUP based on the multiple styles you need to inspect. Then, in the Style panel, select the group and IndexMatic will do the job in one pass.

See also: Targeting several Character Styles

@+
Marc

#34 By newmedia ( 22 May 2012 - 22:55 )

I just upgraded to cs 6 .... is there a newer version of indexmatic pro ?

#35 By Marc ( 23 May 2012 - 13:41 )

@ newmedia

As soon as possible, I swear ;-)

[Do not worry: every IndexMatic's licensee will receive an email as soon as the update is ready.]

@+
Marc

#36 By Sq2 ( 01 August 2012 - 19:58 )

Hi Marc,
I just downloaded IndexMatic 2 to use for indexing in InDesign. I ran the program and I noticed the words I am trying to index are splitting up onto different lines if I use a TradeMark symbol (TM) or a Registered Trademark (®). For example, if I want to index the word "Black™ White® Red," the Index will come out to be:

Black 1
White 1
Red 1

Instead , I would like to read :
Black™ White® Red 1

I also noticed the same thing happens with an ampersand (&). Does the program not support special characters or symbols?

#37 By Marc ( 02 August 2012 - 20:18 )

Hi Sq2,

Thanks for your question. As many users have a similar request I think it's useful to shed more light on this topic.

1. IndexMatic can target and index almost any term or expression including 'exotic' characters such as © or ™ (U+2120). In fact, the script supports any available character of the Unicode Plane 0 used in a left-to-right context.

2. However, the basic features are based on a specific ALPHABET, as documented in the user's manual, page 9: http://www.indiscripts.com/blog/pub... In its maximum extent, this alphabet is supposed to address any Latin-based LETTER that you may find in a text, including diacritics and so on. But it does not include punctuation or symbols, because the purpose of the alphabet is to delineate 'words' in a natural context.

3. Thus, the alphabet is a specific set of characters which is implicitly referred to in the 'Automatic' query mode. It also determines the meaning of the metacharacters '\w' and '\W' in advanced query modes. In such circumstances, © or ™ are not seen as word letters. So when IndexMatic is requested to extract words and is parsing the expression “Black™ White® Red” it returns three words (Black, White, Red). In a sense, this is the very basic function of the script.

4. Now, to extract composite expressions not only based on regular letters, we need to be more specific and tell IndexMatic what kind of characters, or character patterns, we want to target. This is the purpose of advanced queries, as detailed in the user's manual, page 15 and following: www.indiscripts.com/blog/public/scripts/en_IndexMatic2-Manual.pdf#page=15

In your example, it's important to determine what must be considered a complete expression, and then to build a relevant query. Suppose your text contains the following passage:

    “The Black™ White® product is red.”

How to tell IndexMatic that “Black™ White®” is a single unit? Also, how to tell IndexMatic that “Black™ White® Red” is a single unit while “Black™ White® product” is not?

Of course you can easily include extra characters in a query, e.g.:

    /\w+[™®]?/

The above query means: find any sequence of (alphabet) letters that may optionally end with a ™ or a ® symbol. IndexMatic will then report:

    Black™
    is
    product
    The
    red
    White®

But the goal is not reached yet. You need to refine the query to extract matches like “Xxxxx™<SPACE>Yyyyy®”

In IndexMatic's syntax this can be formulated as follows:

    /\m\l+™ \m\l+®/

which becomes much more complicated! In addition, the above query won't find 'simple words' anymore…

5. To conclude: there is no obvious answer to the original question, because all depends on the intimate structure, the inner rules, of the expressions to be indexed.

When queries become really complex, it is usually better to change your approach and use style-driven requests—provided that the targeted expressions have a dedicated character style applied.

NB. — About the ampersand (&), all I have just explained apply the same way, except that a 'Known Issue' remains in the current version regarding InDesign snippets. See “Not Well Formed” error: http://www.indiscripts.com/post/201...

Regards,
Marc

#38 By McShaman ( 05 August 2012 - 05:07 )

I agree with daneyul, providing integration with InDesigns indexing tool would be ideal. I am looking for a solution similar to this but because IndexMatic does not insert index markers it means that the PDF at the end of the day does not link making it less accessible. I know that Marc has noted in the past about providing a script that will convert the page numbers to hyperlinks... However I cannot find such a script, and also it is not the most ideal solution because it dose not allow for dynamic updating when text reflows.

Dont get me wrong... Fantastic product... Almost exactly what our department has been looking for... except missing one important bit.

Keep up the good work

#39 By tamara ( 13 August 2012 - 09:14 )

Hi,
I just purchased IndexMaticPro. I have never written any type of query and after hours of trying to figure out how to do something that I am sure is easy, I surrender.

I have a long book document (150 different Indesign files CS6) that I need to index. I only need to index Proper Names (aka Title Case).

I'm just looking to generate a Last Name, First Name index. For example:
Smith, John 22, 146, 200

The files arrived to me with the index markers in place from Indesign but every time I tried to generate an index within Indesign, it crashed.

Can you please help?

Thanks in advance.

#40 By Marc ( 13 August 2012 - 20:17 )

Hi tamara,

Thanks for your message.

> The files arrived to me with the index markers in place from
> InDesign but every time I tried to generate an index
> within InDesign, it crashed.

Do you mean that the regular InDesign index feature crashed, or that IndexMatic crashed? In any case, I suppose that a 150-chapter book is really heavy to manage in memory. (In all honesty I never tested IndexMatic with such number of files in parallel. Not sure the script can address so much documents.)

Anyway, to target and retrieve proper names from your documents, you have in fact two approaches depending on the way documents are formatted.

First option is to base your queries on character styles, provided that the targeted data are 'styled.' This is with no doubt the best solution. Select the character style in the IndexMatic's Style panel then use a single query such as:

    /(\m\w+) (\m\w+)/ => $2, $1

to get expressions like "John Smith" outputted:

    Smith, John <page numbers>

The other option is to use a similar regex with no style selected. However, I'm afraid that /(\m\w+) (\m\w+)/ is not accurate enough to only retrieve Proper Names. There are probably in your text many other title-case expressions which are not proper names…

IndexMatic can help you to extract matches through the Hit Report feature. From that, you can cleanup raw data and build an explicit query list that specifically fits your needs.

I hope this helps you,

Regards,
Marc

#41 By Gilles ( 30 August 2012 - 18:46 )

Je viens d'acquérir IndexMaticPro : c'est un outil vraiment remarquable, merci beaucoup !
Mais comme on est jamais content ;-) j'ai une petite remarque :
Je pensais (naïvement) que l'index produit l'était également avec hyperliens et références croisées pour pouvoir être utilisé en numérique. Je n'ai pas trouvé comment faire cela et ne vois aucune mention dans le PDF d'aide. Du coup, cela devient pour moi une demande urgente : est-ce que ce développement est prévu ?
Bien cordialement,
Gilles

#42 By Marc ( 31 August 2012 - 13:01 )

Bonjour Gilles,

Merci pour votre commentaire élogieux.

> Je pensais (naïvement) que l'index produit l'était également
> avec hyperliens et références croisées pour pouvoir être
> utilisé en numérique.

Cette requête (légitime) revient en effet assez souvent de la part des utilisateurs d'iX². Pour l'instant, le script ne prend pas en charge cette fonctionnalité.

J'ai annoncé par le passé la mise à disposition d'un script « compagnon » s'occupant spécifiquement de transformer les folios en hyperliens. Ce serait un script à appeler séparément, après la génération de l'index. La routine en elle-même est en place depuis des années (dans mes « cartons »), mais je n'ai pas encore trouvé le temps de finaliser l'interface et d'opérer une mise à jour conforme aux dernières versions d'InDesign.

Comme vous pouvez aisément le deviner, tout est question de temps et de disponibilité. Je m'efforce de développer des scripts de qualité et c'est un processus qui paraît toujours extraordinairement long aux utilisateurs. Il y a des centaines de petits détails à vérifier avant de mettre un script en circulation, compte tenu du caractère très polymorphe des bugs potentiels selon les versions d'InDesign et les plateformes.

Je dois donc, une fois encore, solliciter votre patience.

Merci de votre compréhension.

Cordialement,
Marc

#43 By Matt ( 03 September 2012 - 21:09 )

Hey Marc,
I have a 400+ page doc which had been setup for print (setup across multiple docs using an InDesign CS6 'Book'), it also contains an Index supplied by a professional Indexer, this was provided as a Word file (no links, just text and the relevant page numbers). I'd like to convert these page numbers into live links across my book without having to rebuild the Index using InDesigns Indexing tool, as this will be a rather manual and time consuming. So the hard work has alerady been done, the index and correct page numbers are already there, just not linked.
Is there a script available to convert index page numbers into hyperlinks, across a book? I read on your website (here) that you were looking at creating/ completing such a script (approx one a year or so ago and were going to make it available on the Snippets page) but i have not been able to locate it.
Appreciate if you're able to help, i'm up against a tight deadline :(
Cheers, Matt

#44 By Gaëlle ( 25 September 2012 - 16:23 )

Bonjour,

Nous avons 5 index à créer pour un ouvrage d’environ 1 million de signes que nous montons sous Indesign CS5. Nous avons acquis IndexMatic Pro afin que notre graphiste puisse le mettre en œuvre ; nous avons décidé de passer par les styles de caractère en générant 5 index successivement, ce qui semble marcher, mais dans une certaine mesure seulement… Car nous avons besoin de demander au script certaines choses mais ni notre graphiste ni nous n’avons de compétence en Javascript ou en langage informatique. Comment résoudre les questions suivantes (à qui nous adresser ?) :

1) Index des auteurs : Comment obtenir un index trié sur le patronyme avec inversion nom prénom ? (Ex : « Bruno Castan » ou « Castan » dans le texte courant doit renvoyer à « Castan, Bruno » dans l’index) ?

2) Index des œuvres citées : Comment obtenir un renvoi vers le titre bibliographique (ex : « Le Syndrome de Gaspard » dans le titre courant doit renvoyer à « Syndrome de Gaspard (Le) » dans l’index) ?

3) Comment distinguer deux œuvres qui portent le même titre dans le texte courant mais ne sont pas du même auteur et doivent donc renvoyer à deux entrées d’index différentes (ex : « Cendrillon » dans le texte courant peut renvoyer à « Cendrillon de Charles Perrault » ou à « Cendrillon de Joël Pommerat ») ?

4) Index thématique et dramaturgique : Comment indiquer au script de considérer les barres obliques comme des caractères normaux (ex : « jeunesse/vieillesse » est un seul item d’index et non deux) ?

Merci par avance pour votre aide,

Gaëlle

#45 By Marc ( 26 September 2012 - 00:20 )

@Matt

Thanks for your comment and sorry for the delay.

> Is there a script available to convert index page numbers into
> hyperlinks, across a book?
> I read on your website (here) that you were looking at creating/
> completing such a script (…) but i have not been able to locate it.

Indeed, I've not posted this script yet. I need more time to finalize—sorry.

@+
Marc

#46 By Marc ( 26 September 2012 - 02:06 )

@Gaëlle

Bonjour et merci pour votre (copieuse) contribution ;-) J'ai numéroté les différents points que vous abordez afin de les traiter plus distinctement.

1 — INDEX DES AUTEURS
==========================================
Voilà une question qui, revenant fréquemment, mérite en effet une synthèse pratique. Un concept clé d'IndexMatic est la reconnaissance de « motifs » dans le texte. Mais, dans le cas des noms d'auteurs, on dispose rarement d'un motif général permettant un redécoupage a posteriori sous la forme « Nom, Prénom ». Cela tient au fait que certains noms (ou prénoms) sont individuellement formés de plusieurs mots (termes composés, particules…), ou bien qu'ils n'apparaissent pas sous une forme unique dans le document.

Ainsi « Bruno Castan » peut s'exprimer « B. Castan » dans une note bibliographique, ou encore « Monsieur Castan », « le professeur Castan », etc. Par conséquent, il est extrêmement rare qu'on puisse s'appuyer sur un motif aussi trivial que /(\w+) (\w+)/ pour extraire le prénom et le nom en vue de les réordonner dans l'index final. Il en résulte que vous devez fournir à IndexMatic des indications heuristiques. Cela conduit à produire l'index en trois étapes :

I — La première étape consiste à extraire TOUTES les expressions porteuses du style de caractères considéré, sans distinction de forme :

    • Lancez IndexMatic et sélectionnez votre style AUTEURS.
    • Sélectionnez le mode de recherche « Requête unique » et saisissez la requête globale :   /.+/
    • Cliquez sur le bouton « Occurrences… ». (Décochez les options statistiques et tri fréquentiel.)
    • Cliquez enfin sur « Démarrer ».

Vous récoltez alors la liste complète des auteurs, avec éventuellement des formes concurrentes pour la même personne.

II. — Il convient alors de traiter manuellement la liste précédente afin d'associer une clé unique à chaque auteur. Cette clé correspond à l'expression minimale que l'on doit trouver dans le document pour identifier une entrée. Par exemple, « Castan » peut apparaître comme la clé unique de l'entrée « Castan, Bruno » (pourvu que cet auteur n'ait pas d'homonyme dans le document). L'intérêt d'utiliser « Castan » comme clé est que Bruno Castan sera reconnu même aux pages où la déclinaison complète Prénom + Nom n'apparaît pas. Il suffit que la clé apparaisse pour que l'entrée soit détectée. L'opération de traitement des clés débouche alors sur une liste de requêtes ayant la forme CLÉ => ENTRÉE. Par exemple :

   Castan => Castan, Bruno
   Montaigne => Montaigne, Michel de
   Zweig => Zweig, Stefan
   // etc.

Notez que la liste peut alors intégrer des formes concurrentes telles que :

   /Arouet|Voltaire/ => Voltaire

III. — Une fois cette liste constituée, relancez IndexMatic, assurez-vous que le style AUTEURS est encore sélectionné et entrez dans le mode « Liste de requêtes ». Coller votre liste dans l'éditeur de requêtes et validez. (Bien entendu, il est recommandé de sauvegarder la liste sous forme de fichier texte pour réutilisation ultérieure. L'éditeur de requêtes vous permet de sauvegarder et de charger un tel fichier.)

Il ne reste plus qu'à générer l'index final. (Notez à toutes fins utiles que l'étape I ne serait pas nécessaire si vous disposiez d'une base de données référençant a priori tous les noms à indexer.)

 
2 — INDEX DES ŒUVRES CITÉES
==========================================
La problématique est rigoureusement similaire à la précédente. Vous travaillerez avec le style OEUVRES au lieu du style AUTEURS, mais la procédure me paraît identique. Les requêtes finales seront du genre :

    Syndrome de Gaspard => Syndrome de Gaspard (Le)

Astuce. — Le cas échéant, vous pouvez abréger une requête en utilisant le symbole $ (dollar) comme rappel de la clé :

    Syndrome de Gaspard => $ (Le)
    Castan => $, Bruno
    // etc.

 
3 — DISTINCTION DES ENTRÉES HOMONYMES
==========================================
« Comment distinguer deux œuvres qui portent le même titre dans le texte courant mais ne sont pas du même auteur et doivent donc renvoyer à deux entrées d'index différentes ? »

Là, ce n'est pas une question que je poserais de prime abord à IndexMatic, mais à vous-même ! Comment opérez-vous cette distinction ? Quel critère FORMEL permet, dans le document, de distinguer de tels homonymes ? Le texte fait-il apparaître le titre d'une œuvre et son auteur à proximité ? Peut-on dégager un motif récurrent qui caractérise cette liaison ?

Il faudrait ici un examen plus approfondi de la structure du document pour apporter une réponse concrète. À défaut, vous serez probablement contrainte de séparer manuellement les homonymes…

 
4 — BARRE OBLIQUE
==========================================
« Comment indiquer au script de considérer les barres obliques comme des caractères normaux ? »

La barre oblique (/) étant un opérateur spécial d'IndexMatic, il est nécessaire de la faire précéder d'un caractère d'échappement, l'anti-slash (\), pour l'indiquer en tant que telle :

    jeunesse\/vieillesse

Le caractère d'échappement s'utilise de la même manière dans les requêtes basées sur des expressions régulières. Par exemple :

    /jeunesse ?\/ ?vieillesse/s

détecterait indifféremment les formes :
  « jeunesse/vieillesse »,
  « jeunesse / vieillesse »,
  « jeunesse/ vieillesse »,
  « jeunesse /vieillesse »
quelle que soit l'espace intercalaire (fine, insécable, etc.).

 
J'espère avoir répondu à l'essentiel de vos interrogations.

Cordialement,
Marc

#47 By Hollie ( 23 October 2012 - 21:54 )

I am indexing a list of names. Within the document they are listed by FirstName-LastName. But I need the index to be LastName-FirstName. I ran the IndexMatic and it worked. Is there a way to switch the names when I can making Query List? I am trying not to do a lot of manual work, since I need to index about 5,000 names.

#48 By Marc ( 25 October 2012 - 09:03 )

Hi Hollie,

If <FirstName> and <LastName> can be captured separately in a regex pattern, e.g.:

    /(\m\w+) (\m\w+)/

then you can reverse the matches using:

    /(\m\w+) (\m\w+)/ => $2 $1

That way « John Smith » is reported « Smith John » in the index.

See also: http://www.indiscripts.com/post/201...

Regards,
Marc

#49 By laurent G ( 07 November 2012 - 08:59 )

Bonjour Marc,

Je suis en train de tester votre magnifique outil.
J'ai toutefois un petit souci.
Voici la recherche effectuée :

/colbert
/COLBERT|Jean-Baptiste COLBERT/=>COLBERT, Jean-Baptiste

et les résultats :

Colbert 36-37, 39-40, 45, 55, 59, 103
COLBERT, Jean-Baptiste 36-37, 40, 45, 55, 59, 103

Et curieusement, ils ne sont pas identiques.
Le bug viendrait du fait que la référence de la page 40 se trouve sur la première ligne de cette page. En effet, si je décale le paragraphe, le résultat est bon.
Pouvez-vous m'éclairer un peu plus ?

Laurent (celui du "débogage" des autres scripts)

#50 By Marc ( 07 November 2012 - 11:29 )

Bonjour Laurent,

Merci pour ce signalement de bug. C'est étonnant en effet. Si iX² avait indiqué en page 39 la référence de la page 40, j'aurais eu une explication toute prête liée au tampon de pré-lecture, mais là c'est apparemment l'inverse qui se produit. Si je comprends bien, c'est le Colbert indiqué en pages 39-40 qui pose problème, car cette expression seule n'apparaît QUE page 40, n'est-ce pas ?

Histoire de clarifier la situation :

1) Qu'y a-t-il exactement aux pages 39 et 40 ?

2) Avez-vous lancé les deux requêtes séparément ou ensemble (dans une liste de requêtes) ?

3) La sensibilité à la casse est-elle activée ou désactivée ?

4) Une autre contrainte est-elle attachée à la recherche (style de caractère, etc.) ?

Merci à vous,
Marc

#51 By laurent G ( 07 November 2012 - 12:11 )

Je reprends les différents points.
1) Sur la page 39,j'ai le mot Colbert au milieu de page.
Sur la page 40, il se trouve en première ligne.
2) Ensemble
3) Non
4) Non

Des copies d'écran seraient peut-être plus explicites ? Mais comment faire ?

Merci
Laurent

#52 By Marc ( 07 November 2012 - 20:34 )

Rebonjour Laurent,

Je viens de tester et je confirme le bug. S'il y a moins de 12 caractères avant le Colbert de la page 40, alors iX² ne prend plus en compte celui trouvé à la page précédente lorsque la requête comporte une réécriture queconque de la forme:

    /colbert/ => toto

Le bug ne se produit pas quand le terme est automatique (i.e. homonyme à la clé) :

    /colbert/

De même, la réécriture par défaut fonctionne :

    /colbert/ => $0

Le problème se situe donc dans une zone très étroite de l'algorithme, une friction curieuse entre l'opérateur de réécriture et le tampon de pré-lecture. Bon, va falloir élucider ça.

Merci d'avoir trouvé cette aiguille dans la botte de foin !

@+
Marc

#53 By Marc ( 09 November 2012 - 03:50 )

=========================================
    UPDATE v. 2.027 [EN]
=========================================

Various bugs fixed, including the one reported by Laurent G. (#50).
(See details in the readme file.)

=========================================
    MàJ v. 2.027 [FR]
=========================================

Correction de divers bugs, notamment celui signalé par Laurent G. ci-dessus (#50).
(Cf. détails dans le fichier lisezmoi.)

@+
Marc

#54 By DaveB ( 02 January 2013 - 17:32 )

Thank you for all of your great work on the script. This is an extremely valuable tool.

I have a quick question for which I've been unable to find an answer on your site. I have several terms that I would like to index and also provide a cross-reference in the form:

bar 7, 22, 38; see also foo.
...
foo 9, 12, 17; see also bar.

I have tried
/bar|bars => bar
//bar => ; see also foo.
/foo|foos => foo
//foo => ; see also bar.

but comments only seem to be added when no page counts are found, rather than appending to the end of a given list of pages.

Thoughts on how I might achieve this?

/d

#55 By Marc ( 04 January 2013 - 08:17 )

Hi DaveB,

[As you are the very first 2013's comment author at indiscripts, let me wish you first Happy New Year!]

Your question is totally relevant and reveals an issue in dealing with *both* actual entries and cross-reference for first-level topics.

Your query list indeed is syntactically correct. It should not cause IndexMatic to ignore the "see also" reference when the entry is found ... but it does :( The reason behind this 'denial' is that iX cannot mix up page numbers and references so far. (We obviously need to fix this!)

In the meantime, a possible solution is to rewrite your queries as follows:

    /bar|bars => bar
    // bar > see also => foo
    /foo|foos => foo
    // foo > see also => bar

You will then get the index in this form:

    bar » <page numbers>
             see also » foo
    foo » <page numbers>
             see also » bar

In other words, "see also" is treated and rendered as a sub-topic of the respective primary terms. This does not exactly meet your goal, but I hope this provides an acceptable workaround. Tell me!

@+
Marc

#56 By HolgerR ( 07 January 2013 - 15:57 )

Bonjour Marc,
is it possible to use the start of line anchor '^' (caret)? I have to index product names there a word often is only relevant if it's the first one.
Eg. in 'Screw for plate' the 'plate' should not be indexed although there is a rule for 'plate' too.
Merci
Holger

#57 By Marc ( 07 January 2013 - 20:49 )

Hi HolgerR,

The ^ anchor is not implemented in IndexMatic. However, you should have the possibility to extract only the first word of any match using a rewriting rule. For example, if you are targeting a character style, the query:

    /(\w+).*/W => $1

should do the job.

I hope that helps you.

@+,
Marc

#58 By Nicholas Lamme ( 07 January 2013 - 21:13 )

Hello, I must do a biblical index for a 300 page book. Many of the references are similar to what follows:

(Mr. 13:28-37)
(Mt. 24:43; Lc. 12:39)
Lucas 18:1-8

You get the point. Some are more complex than others, so I wrote a grep expression to find them with a view to styling them with a generic character style "bibRef".

(\d+ )?((\w+)?\.? \d+[[:punct:]]\d+)(.\d+)?([, \d]+(.\d+)?)*([[:punct:]]\d+.\d+)?

and

(I|II)( )((\w+)?\.? \d+[[:punct:]]\d+)(.\d+)?([, \d]+(.\d+)?)*([[:punct:]]\d+.\d+)?

This second one is for books of the Bible that begin with "I" or "II".

Then I style them. However, I run into two problems with the IndexMaticPro.

1) When it outputs to a text file, it doesn't grab the string, or the whole verse styled, but grabs the individual parts. For example (from a test run that I did):

//
Miqueas 213
2-3 212
49-56 212
vv 210
22-37 210
37-41 209
26-28 209
50 207
34-35 207
16-25 206
11-12 206
Hch 205
51-53 204

//

And 2) if I try to enter my reg. expression into the query list, it runs and tells me that : "Sorry, no result!". I know that my reg. expression works, at least in InDesign and I am not sure if perhaps I am writing it incorrectly for the script.

What I would like to do is grab each individual reference, not its constituent parts. For example:

Mr. 13:28-37 <<page number>>
Mt. 24:43 <<page number>>
Lc. 12:39 <<page number>>
18:1-8 <<page number>>

In the final formatting, the abbreviated references will not be there, but each reference will exist under its own heading. But this is the idea that I am trying to achieve, but cannot seem to make the script work for me.

Thank you so much for your help.

#59 By Marc ( 08 January 2013 - 10:08 )

Hi Nicholas,

Thanks for your input. First of all, there are two main strategies to reach your goal:

(1) If a specific Character Style is explicitly applied to the strings you want to index, the easiest solution is to target that style (or style group) using the IndexMatic's Style panel, then send the global query:

    /.+/

(2) Otherwise, you'll have to build a custom regex to extract the matches, but keep in mind that IndexMatic's regular expressions are JavaScript-based, not GREP-based, so the syntax may differ in a few cases.

Note that iX² does not support Posix elements [[:XXX:]]. Instead, it provides a number of Unicode metacharacters in the form \pXX, as described in the manual page 22: http://www.indiscripts.com/blog/pub...

For example, your first query:

(\d+ )?((\w+)?\.? \d+[[:punct:]]\d+)(.\d+)?([, \d]+(.\d+)?)*([[:punct:]]\d+.\d+)?

is GREP-compliant, but in IndexMatic you should probably rewrite it:

/(\d+ )?((\w+)?\.? \d+\p{P}\d+)(.\d+)?([, \d]+(.\d+)?)*(\p{P}\d+.\d+)?/

where \p{P} matches any punctuation character.

Also, my general advice if you run into complex patterns and have trouble in understanding IndexMatic output, is to work on a sample document and build your regex gradually, testing matches through the Hit report feature. This way you can more easily identify what goes wrong and fix the query step by step.

Regards,
Marc

#60 By DaveB ( 12 January 2013 - 20:51 )

Re: #s 55 and 56
Marc,

Thank you for your solution, and please pardon the time it took for me to offer closure to the query. The ideas you provided will work.

/d

#61 By Olaf ( 22 January 2013 - 23:03 )

Hi,
I'm using iX to index a book and running into an issue. It's not a bug.
My index has hunreds of personal names and thousands of other terms. I've been careful to prepare it for plurals by using "s?" and that's working fine.
However, I'd like to know if there's an easier way to handle possessives formed with 's (apostrophe + s). Do I have to go through my very long query list and add another form of every name (and really, all nouns) that includes 's?
For example if I now have
Joe Smith
John Johnson
dogs?

do I now need
Joe Smith|Joe Smith's=>Joe Smith
John Johnson|John Johnson's=>John Johnson
dogs?|dog's|dogs'=>dog

Is there any way to tell iX that any time it encounters the pattern apostrophe+s it should consider it invisible (so when it sees "Joe Smith's" it ignores 's and notices only "Joe Smith")?

I think /dogs?=>dog will index dog, dogs, dog's and dogs' if I don't treat the apostrophe as alphabetic. Right?

But do I now have to add s? to every name and noun that might at some point in the book be possessive?

Does this question even make sense? Have I missed something in the User Guide?

Thanks,
Olaf

#62 By Olaf ( 22 January 2013 - 23:10 )

Another question: Is there a way to define my own rules for alphabetizing? I'm doing books that have a lot of transliterated Arabic and I would love it if it could ignore "al-" when sorting. In other words, al-Raydāniyya should be in the R section, not the A section.
Thanks,
Olaf

#63 By Marc ( 23 January 2013 - 14:20 )

@ Olaf (#62)

Thanks for posting.

> [...] do I now need:
> Joe Smith|Joe Smith's=>Joe Smith

First of all, to properly work your query would need to be specified as a regex using the starting slash:

    /Joe Smith|Joe Smith's=>Joe Smith

(but I guess this was implicit in your example).

Now the good news is that you don't even need a regex in that particular case (if default settings are used). Indeed, by default IndexMatic considers apostrophes non-alphabetic (Allow Apostrophe checkbox turned OFF). Hence, assumed Whole Word is active, the simple token-based query:

    Joe Smith

will find any occurrence of "Joe Smith" as expected, including any match found in "XXX Joe Smith's XXX", because the apostrophe character is seen as a boundary, as well as spaces or punctuation signs.

Rephrased as a verbose regex-based query, this is strictly equivalent to:

   /Joe Smith/w => Joe Smith

So, a problem in managing possessive forms may only arise if you include apostrophes in the alphabet (Allow Apostrophe turned ON). In such case, the string "Joe Smith" would not be identified as a whole word in "XXX Joe Smith's XXX" and therefore that location would not be reported in the index.

The reasoning is nearly identical for the /dogs? pattern (except you need here an explicit regex to address the plural form).

Provided that Allow Apostrophe is unchecked, the query:

    /dogs?/w => dog

will find the key in both "...dog...", "...dogs...", "...dog's..." and "...dogs'..."

> I think /dogs?=>dog will index dog, dogs, dog's and dogs'
> if I don't treat the apostrophe as alphabetic. Right?

Absolutely right! That's why I'm not sure I understand the issue you are trying to solve. It seems to me that the default process exactly do what you want it to. No need to rewrite your queries at all.

Am I misunderstanding the question?

@+,
Marc

#64 By Marc ( 23 January 2013 - 14:31 )

@ Olaf (#63)

> Is there a way to define my own rules for alphabetizing? I'm doing
> books that have a lot of transliterated Arabic and I would love it
> if it could ignore "al-" when sorting.

Unfortunately the sorting algorithm cannot be customized this way, but your suggestion is very interesting. Are there some 'official' alphabetizing rules about transliterated Arabic I could find online? I may add transliterated languages among the sorting options.

Thanks.
Marc

#65 By Olaf ( 23 January 2013 - 19:40 )

Thanks for the responses.
I don't know of any official rules for alphabetizing transliterated Arabic. I usually end up replacing all the "al-"s wih some nonsense punctuation, sort everything, then re-replace the "al-"s. There are non-Arabic situations when "ignore strings" would be useful. Words like "the" or "a" in English, for example.

As for the issue with possessives, your answer confirms what I thought should be happening. Unfortunately, a lot of them were missed in the last index I created. I'll have to see if there's a pattern to what it didn't find (but with thousands of references in the index, I might not be able to see anything useful). (I just hope I wasn't imagining it!)
There remains the issue of plural possessives ("The confusion was caused not just by the three Joe Smiths' identical names, but also by their similar voices.")
A more realistic example:
In the current book there are two Mamluk sultans named al-Nasir Muhammad. I can imagine a sentence that says "the two al-Nasirs' reigns" or "both Muhammads' reigns." Someone writing about English queens might find occasion to write "Elizabeths' something." I don't want to include "s?" on names.

I don't necessarily think this is something iX should be dealing with--it's just one of the many things I worry will somehow happen when I'm indexing. For nouns that aren't names, it's not a problem as long as my queries have "s?" on them.

I wonder if there's any safe and sane way to include a switch of some sort that tells iX to look for any word that is just like one in the query list, except with an S at the end. Would save me typing s? a thousand times.
Thanks.

#66 By Marc ( 25 January 2013 - 12:51 )

@ Olaf

Sorry for the delay.

> As for the issue with possessives, your answer confirms what
> I thought should be happening. Unfortunately, a lot
> of them were missed in the last index I created.

Please, if you can reproduce that issue, send my a sample doc and your query list so that I investigate. Should be a bug.

> I don't want to include "s?" on names.
> [...] For nouns that aren't names, it's not a problem as long
> as my queries have "s?" on them.

Well, possessive forms like xxx's and xxxs' are English-specific, while iX cannot make any assumption about the language(s) in use. Therefore it's not easy to design a global feature for such case.

Also, reformatting every key with an ending "s?" could lead to very odd results. Indeed, the general pattern:

    /(xxx)s?/ => $0

would report words like "does" or "less" as "doe" and "les"!

To prepare your query list and anticipate special cases relative to possessive forms, I suggest you run a Hit report based on the following query:

    /\w+['’]s?/

This way you will more easily identify potential issues in this area.

@+
Marc

#67 By Olaf ( 29 January 2013 - 20:54 )

Thanks. I didn't think of using the hit report to help spot issues. It looks like all the missed possessives were names that ended with the letter ī (i with a macron) followed by an apostrophe+s. Some were my fault for writing bad queries, but some don't seem to be. I think I've checked them all now and my index is good. If I can get it to repeat the problem and I'm sure it's not my fault, I'll send a file.

Another question: could there be an option to tell iX that certain letters are equivalent? Ideally, I could give it a set of alphabet instructions that would apply to the whole query list/document being indexed. There could be a flag to put in queries in which these equivalencies are not to apply.

For example, if some sources quoted in a book spell the historian's name al-Maqrizi but the author spells it al-Maqrīzī, iX would recognize that these are hits for the same query. This would also catch typos where an author once forgets to put a macron on a vowel or a dot under a consonant (like if it's al-Maqrīzī 34 times but is al-Maqrizī once and no one caught it).

It could perhaps also be told to alert me to spellings that use different letters (i.e., lack diacritics) from what I used in the query. And the spelling used in the query would be the one to use in the index.

Just something that occurred to me while indexing today. Another indexing plugin I used to use had a txt file that defined the alphabet and (either in the same txt file or another one) alphabetization rules.

For now at least, I'm considering my possessives issue closed. I'm sending the author his index.

Olaf

#68 By Olaf ( 29 January 2013 - 22:17 )

Just remembered something else: when there's a syntax error in the query list is there any way it could tell me what the error is or where? With 1000 queries in the list, an message telling me only that there's an error isn't much help!
Thanks.

#69 By Olaf ( 31 January 2013 - 21:30 )

I feel like I'm abusing this comment function with all my questions, but I can't seem to stop! I have another one:
Is there a way to build in the ability to define how page ranges are formatted such that 119-121 can be converted to 119-21, but 87-89 and 299-301 would stay the same? Some people like to only show the last digit with the others are the same (121-123 becomes 121-3). There are other permutations I've seen. Would be cool to be able to define how we want these handled.
Thanks.

#70 By Marc ( 04 February 2013 - 09:17 )

@ Olaf

> [#69] When there's a syntax error in the query list is there any
> way it could tell me what the error is or where?

The next release of iX will be more verbose, I swear!

> [#70] ...ability to define how page ranges are formatted
> such that 119-121 can be converted to 119-21

Excellent suggestion too. Some users already asked for this feature. I'm in the process of improving these Page Range settings.

> I feel like I'm abusing this comment function with all my questions...

Not at all. Questions, issue reports and suggestions are always welcome here ;-)

@+
Marc

#71 By sple ( 06 February 2013 - 11:57 )

Bonjour,

utilisateur à l'époque d'indexbrutal, je suis très intéressé par l'achat d'indexMatic pro. Si j'ai bien compris, IndexMatic est complètement indépendant de l'outil d'indexation d'Indesign et n'utilise donc pas les marqueurs d'index. Dans le cadre d'un process de production d'Epub via un format pivot XML (Indesign-->XML-->Epub), IndexMAtic permet-il, d'une manière ou d'une autre, de récupérer un lien entre le mot indexé et sa référence ?
Merci.

#72 By Marc ( 06 February 2013 - 17:18 )

Bonjour sple,

> IndexMatic permet-il, d'une manière ou d'une autre,
> de récupérer un lien entre le mot indexé et sa référence ?

Comme vous l'avez compris, IndexMatic produit une sortie — texte, XML ou « extrait » — totalement indépendante de la fonctionnalité d'index interne à InDesign. Par conséquent, le script n'encode aucun lien ou référence-retour entre un terme indexé et ses occurrences dans le document. Tout au mieux pourrait-on envisager d'encoder des hyperliens entre les folios rassemblés dans l'index et les pages correspondantes, mais le script n'offre pas cette fonction pour le moment.

Cordialement,
Marc

#73 By Bruno ( 08 February 2013 - 01:54 )

J'utilise pour la 1re fois votre script pour créer un index avec environ 2800 entrées à opérer.

À chaque fois que je crée un index avec +/-120 entrées, il y a toujours 8-9 entrées qui ne sont pas trouvées. Elles apparaissent à leur place dans la liste, mais avec un tiret au lieu du numéro. Mais je les retrouve une 2e fois, à la fin, avec le bon no de page. Il me faut alors les retrouver la 1re occurrence et la remplacer par la 2e. C'est pas sorcier, mais c'est ça qui m'empêche de procéder par gros bloc.

Y a-t-il une solution?

Merci.

#74 By Marc ( 08 February 2013 - 09:52 )

Bonjour Bruno,

Ainsi que vous me l'avez précisé par courriel, le problème réside en fait dans la discrimination des espaces EN SORTIE. Cette question mérite en effet un éclairage car IndexMatic présente une petite faiblesse sur ce point.

Supposons que nous recherchons la clé simple "abc def ghi" avec l'option espace générique activée. Cela revient donc à envoyer la requête suivante :

    abc def ghi

ou explicitement :

    abc def ghi/s

IndexMatic va associer à cette clé toutes les variantes possibles avec espace simple, espace insécable, espace cadratin, etc.

Mais, contrairement à ce qui est normalement attendu, les termes résultant vont refléter ces variantes d'espace. Autrement dit, l'index va produire plusieurs entrées, différenciées selon les types d'espaces.

Pour éviter ce problème et rassembler toutes les concordances trouvées dans un seul terme canonique, la solution consiste à reformuler la requête ainsi :

    abc def ghi => $

La variable $ permet en effet de récupérer la clé elle-même et de l'utiliser littéralement comme terme de la requête. Ainsi, toutes les variantes d'espace seront synthétisées au sein d'une entrée unique : "abc def ghi".

D'une façon générale, cette technique permet de « lisser » certaines disparités présentes dans le texte et révélées par le processus d'indexation.

P. S. — Il va de soi qu'on pourrait obtenir le même résultat en écrivant explicitement :

    abc def ghi => abc def ghi

La forme :

    abc def ghi => $

n'est qu'un raccourci plus confortable.

@+
Marc

#75 By Teobaldo ( 11 February 2013 - 12:38 )

Bonjour

J'ai la nécessité d'indexer une longue liste de mots (plus de 1500) provenant d'un document Word. Il s'agit d'un livre de science.

Je suis intéressé par la version Pro, mais je vous en prie de répondre à ces trois questions:

- La version Pro permet compiler un nombre illimité de mots dans le document source?

- Je peux trouver les expressions formées de plus d'un mot? Par exemple, «vías de comunicación"

- Dans le livre, il y a beaucoup de termes écrites avec IPA (International Phonetic Alphabet). Le script va les trouver?

Merci Beaucoup!

#76 By Glenn ( 11 February 2013 - 18:34 )

I would like an author index to search names for first last and put last, first in the index. Is this possible?
Regards

#77 By Glenn ( 11 February 2013 - 19:14 )

Sorry, I should have looked closer. I figured it out.

#78 By Marc ( 12 February 2013 - 02:00 )

@ Teobaldo (#76)

Merci de votre intérêt pour IndexMatic.

> La version Pro permet-elle de compiler un nombre illimité
> de mots dans le document source ?

Il n'y a pas de limite fixée au niveau du programme (ni pour le volume des documents analysés, ni pour le nombre de termes à intégrer dans un index). La seule limite est celle de la mémoire physique dans laquelle le script s'exécute et traite les informations. Il existe évidemment un seuil au-delà duquel IndexMatic ne parviendrait plus à « digérer » un volume excessif de données, mais cette limite ne peut se déterminer qu'empiriquement, selon les ressources système. En pratique, IndexMatic peut normalement adresser sans difficulté des milliers d'entrées.

> [Est-ce que] je peux trouver les expressions formées
> de plus d'un mot ? Par exemple, « vías de comunicación »

Oui, en utilisant les modes Requête simple ou Liste de requêtes (basées sur des expressions composées ou des expressions régulières). Vous trouverez dans le manuel d'utilisation, et dans cette FAQ, de plus amples précisions et exemples.

> Dans le livre, il y a beaucoup de termes écrits avec
> IPA (International Phonetic Alphabet). Le script va-t-il
> les trouver ?

Sous réserve que la ou les requête(s) soient bien formulées, IndexMatic peut trouver n'importe quelle chaîne formée de caractères Unicode du plan multilingue de base (jusqu'à U+FFFD).

Concernant les caractères intégrés aux extensions IPA (zone U+0250–U+02AF), ils sont inclus par défaut dans l'alphabet latin étendu d'IndexMatic :

• http://www.indiscripts.com/blog/pub...

Par conséquent, ils sont reconnus par le métacaractère \w dans cet alphabet.

Il convient toutefois de souligner que la boîte de dialogue d'IndexMatic ne peut pas afficher un glyphe s'il est absent des polices système sous-jacentes. Bien que cela soit sans conséquence sur l'index généré, on perd évidemment en « lisibilité » au sein de l'interface.

À noter aussi que les fonctionnalités de tri d'IndexMatic sont prévues pour traiter l'alphabet phonétique de façon relativement homogène avec l'alphabet latin canonique. Ainsi, des caractères comme ɐ (U+0250 LATIN SMALL LETTER TURNED A) ou ɛ (U+025B LATIN SMALL LETTER OPEN E) conduiront typiquement à un classement à l'image de celui-ci :

    abc
    ɐbc
    bac
    edf
    ɛfg
    fac

Cordialement,
Marc

#79 By Damien ( 12 February 2013 - 16:16 )

Bonjour

Cela fait peu de temps que j’utilise le script.
Et je n’arrive pas à mes fins sur 2 choses :

— J’ai des références a indexer du type : 0001390004R ou 00030600000011ou 00029200 ou 00055100xxx.
Lettres et chiffres étant mélangés, l’ordre alphabétique ne me convient pas.
Est-ce qu’en rentrant mes refs. dans liste de requêtes, je peux garder l’ordre rentré dans celui-ci ?
(Le fait de cocher [pas de tri] dans la partie « sortie » change tout de même l’ordre que je rentre).

— Pourquoi indexmatic ne me propose pas de choix du style de caractère quand je souhaite travailler à partir d’un livre ?

Y aurait-il des choses que je ne prends pas en compte ?
D’avance, merci bien pour votre réponse.

#80 By Marc ( 14 February 2013 - 09:52 )

@ Damien

[Désolé pour le délai de réponse.]

> Lettres et chiffres étant mélangés, l'ordre alphabétique ne
> me convient pas. Est-ce qu'en rentrant mes refs. dans liste
> de requêtes, je peux garder l'ordre rentré dans celui-ci ?

Oui, si vous saisissez uniquement des requêtes littérales et cochez l'option [Pas de tri].

> [Mais] le fait de cocher [Pas de tri] dans la partie « sortie » change
> tout de même l'ordre que je rentre…

Dès lors que des termes « variables » (c.-à-d. issus d'expressions régulières) figurent parmi les requêtes, vous ne pouvez pas présumer du classement final des entrées. Dans cette situation, en effet, iX ne traite pas le flux de recherche de façon linéaire.

Le problème est le suivant : à défaut de tri explicite, IndexMatic ne dispose d'aucune consigne pour ordonner les termes collectés via une regex. Par exemple, la requête :

    /000[A-Z\d]+/

va vraisemblablement déboucher sur plusieurs entrées d'index …dans un ordre indéterminé.

N. B. — Il existe une option de sous-tri dite « Séquence numérique » pour les entrées de second niveau. Ce mode de classement tente d'évaluer et d'ordonner numériquement les termes plutôt qu'alphabétiquement. Cette routine a été conçue initialement pour permettre de classer des sous-entrées représentant des données quantitatives (mais cela ne correspond peut-être pas au classement spécifique que vous recherchez pour vos références). Pour tester cette option, vous pouvez créer artificiellement des entrées de second niveau en envoyant une requête du genre :

    /000[A-Z\d]+/ => REFERENCES > $0

puis en sélectionnant l'option Sous-tri: Séquence numérique. Vous obtiendrez alors un index de la forme :

   REFERENCES
      00029200 : <folios>
      0001390004R : <folios>
      00055100123 : <folios>
      00055100456 : <folios>
      00030600000011 : <folios>

Observez que les termes sont alors évalués comme des sortes de nombres :

    29 200 < 139 004 < 55 100 123 < 55 100 456 < 30 600 000 011

[Je réponds à votre seconde question séparément.]

@+
Marc

#81 By Marc ( 14 February 2013 - 10:04 )

@ Damien [suite]

> Pourquoi IndexMatic ne me propose pas de choix du style de caractère
> quand je souhaite travailler à partir d'un livre ?

Il devrait normalement le faire ! Mais prenez note qu'il vous présentera uniquement les styles COMMUNS à tous les documents du livre. Quand certains styles ne sont pas nommés de façon uniforme, iX considère qu'il ne peut pas les « factoriser » et les ignore.

Si ce mécanisme ne fonctionne pas alors que vos styles sont pourtant homogènes, merci de m'envoyer par e-mail un petit échantillon du livre pour que j'étudie le problème.

@+
Marc

#82 By Damien ( 21 February 2013 - 10:20 )

Pas de problème pour le délai de réponse (moi-même...), et merci d'avoir pris le temps pour cela.

Pour l'histoire du style de caractères j'avais bien le même nom dans tout mon livre, mais il a juste fallu faire une actualisation pour résoudre le problème.

Pour ce qui est de la liste de références,rien à faire, je n’arrive pas à laisser l’ordre que je rentre dans la liste de requêtes. Malgré l’option [Pas de tri] cochée.

Mais je ne saisis pas très bien l’explication avec le terme variable. J'ai l'impression qu'il y a trop forme différente de références (c'est ce que vous nommez « variables », je pense).

Je cherche encore, en utilisant l'option « Séquence numérique » pour les entrées de second niveau. L’idée serait de ranger plutôt dans cet ordre :
00011100000 : <folios>
00015200xxx : <folios>
00015400 : <folios>
009767xxxxx : <folios>
00984700 : <folios>
08399600000400 : <folios>
123260000 : <folios>

Merci beaucoup Marc

#83 By Marc ( 21 February 2013 - 19:00 )

@Damien

> L’idée serait de ranger plutôt dans cet ordre :
>    00011100000 : <folios>
>    00015200xxx : <folios>
>    00015400 : <folios>
>    009767xxxxx : <folios>
>    00984700 : <folios>
>    08399600000400 : <folios>
>    123260000 : <folios>

Je m'aperçois en vous lisant que cet ordre n'est rien d'autre que l'ordre alphanumérique pratiqué par la fonction de tri native de JavaScript. (Du moins, me semble-t-il.)

Du coup, je viens à l'instant de mettre à jour IndexMatic — v. 2.028 — qui offre tout simplement une nouvelle option de tri baptisée [alphanumeric]. Peut-être que cela résoudra votre problème (?)

@+
Marc

#84 By Marc ( 21 February 2013 - 19:03 )

=========================================
     UPDATE v. 2.028 [EN]
=========================================

Minor update: added the [alphanumeric] sort option. (See details in the readme file.)

=========================================
     MàJ v. 2.028 [FR]
=========================================

Mise à jour mineure. Ajout de l'option de tri [alphanumeric]. (Cf. détails dans le fichier lisezmoi.)

@+
Marc

#85 By Damien ( 22 February 2013 - 11:59 )

Alors là... chapeau !
J'ai bien l'impression qu’il marche bien cet ordre alphanumérique.
Bravo pour cette mise à jour super rapide et merci.

#86 By Matt ( 25 February 2013 - 15:33 )

Hello

Do your scripts work in CS6 / Mac?

thanks...

#87 By Matt ( 25 February 2013 - 16:23 )

It does seem to work - nice! Have tried the test script only so far... have just purchased the PRO script.

One more question, to do with indexing people's names...

I have been supplied a list of index subjects, in which all names are already listed in last name, firstname format; but in the book text we never see this formatting, so the script wont pick these up.

Chaplin, Charlie - this doesnt work!
Mikhail Chehov - this works!

Any ideas or clever scripts to iron this out?

thanks in advance for any time / /assistance

#88 By Marc ( 26 February 2013 - 13:06 )

@ Matt

> I have been supplied a list of index subjects, in which all names
> are already listed in last name, firstname format; but
> in the book text we never see this formatting, so the
> script wont pick these up.

You need to slightly rephrase your original list of subjects so that it works as a Query List which IndexMatic can understand.

Instead of:

     Chaplin, Charlie

use:

     Charlie Chaplin => Chaplin, Charlie

or, more generally:

     /(Charlie) (Chaplin)/ => $2, $1

N. B. — Keep in mind that the global syntax of a complete query is:

     <MY KEY> => <MY TERM>

where <MY KEY> refers to what you are looking for (in the document), while <MY TERM> specifies the associated index entry. When no term is supplied, IndexMatic implicitly takes the KEY as the TERM. In other words, the query is understood as:

     <MY KEY> => <MY KEY>

(“what you search is what you get”).

This default mechanism works fine when you are targeting words and expressions which should remain *unchanged* in the final index. But, as soon as some rewriting is needed, the full KEY=>TERM syntax is required.

@+
Marc

#89 By Matt ( 28 February 2013 - 23:54 )

Thanks Marc

That seems to work, but this book includes footnote refs that cite

Chaplin, C.

and sometimes just the second name appears...

Chaplin

So my index needs to find all instances of

Charlie Chaplin
Chaplin, C.
Chaplin

And collate them all into index entry

Chaplin, Charlie

? Bit confused - is this possible with a script? Unfortunately I am not familiar with regular expressions, any help much appreciated...

merci!

#90 By Marc ( 01 March 2013 - 02:10 )

@ Matt

> So my index needs to find all instances of
> Charlie Chaplin
> Chaplin, C.
> Chaplin
> And collate them all into index entry
> Chaplin, Charlie

In that case, why don't you simply use

    Chaplin => $, Charlie

?

Marc

#91 By Matt ( 01 March 2013 - 23:06 )

Why not indeed! Works well, thanks, just taking first baby steps with these expressions...

merci!

#92 By Camilo ( 03 March 2013 - 19:52 )

I already have a concordance list for a genealogical book (it seems highly undesirable manually tag these compound entries as character styles in Indesign, as an alternative...)

My list:
Vicente Brigard Caro
Juan María Dombroski Sordo
Etc.

But the output seems restricted in Indexmatic only to the first word and what It is needed is to capture the whole line, as showed above. How to manage this?

Thank you.

#93 By Marc ( 03 March 2013 - 23:20 )

Hi Camilo,

If your query list looks like:

    Vicente Brigard Caro
    Juan María Dombroski Sordo
    etc.

and if your document actually contains these expressions, then IndexMatic should detect and report the full entries.

So, maybe you have some specific settings that break the regular process. Please, send me a sample document and a screenshot of the IndexMatic's dialog just before you build the index.

@+
Marc

#94 By Camilo ( 04 March 2013 - 11:18 )

After your confirmation I checked the process and indeed I got full entries!:

Bárbara López Medina 16
Ignacio Umaña Sanabria 3
José Solís Folch de Cardona 13
Juan López 4
Santiago Umaña Sanabria 22

As I have a list it seems very easy now to continue the process.

Thank you for this beautiful software.

#95 By Dan ( 19 March 2013 - 16:43 )

I'm needing to include in the index the letter "n" and the footnote number for instances where an indexed term appears in a footnote. Like this: n6, 12. Is this possible? Thanks.

#96 By Marc ( 19 March 2013 - 17:50 )

Hi Dan,

Unfortunately, there is no way for IndexMatic to make a distinction between matches found inside vs. outside footnotes.

For example, suppose "MyEntry" is found twice on page 12. The first match may appear in the story while the 2nd match may appear in a footnote. In any case, the script will just report "MyEntry" as a Page 12 entry —with page rank = 2.

Therefore, the only way to render differently footnote-extracted terms is to create a separate index (!) using the "Footnotes: <Only>" option in the Context panel.

Regards,
Marc

#97 By Gavin ( 26 March 2013 - 16:06 )

The scope page range function does not appear to work in CS6. I have set up an InDesign document with two different page numbered sections, when I select [All pages] as the range, I only get results from one section?

Please advise what I'm doing wrong?

#98 By Marc ( 02 April 2013 - 09:19 )

Hi Gavin,

Thanks for your report. It might be a CS6-only specific issue, but I need to check that.

What if you manually enter a page range? Same problem?

@+
Marc

#99 By François ( 12 April 2013 - 17:42 )

Bonjour Marc,

Je cherche à insérer des balises pour la mise en forme rapide de l'index, les balises me semblant le plus pratique sont <>, hélas la balise fermante pose un problème :

Prélude pour Henri Barda => <Prélude pour Henri Barda i> pour piano

Résultat de la requête :

<Prélude pour Henri Barda i.
pour piano, 299.

Pouvez-vous expliquer cela ?

Bien à vous,
François

#100 By Marc ( 12 April 2013 - 17:55 )

Bonjour François,

Je cite le manuel d'utilisation, page 18 :

« Le symbole > jouant un rôle particulier dans la syntaxe d'un terme, vous devez utiliser la séquence \> pour introduire ce caractère en tant que tel. »

Cf. http://www.indiscripts.com/blog/pub...

En effet, souvenez-vous que le caractère > introduit une relation SUJET > MEMBRE dans les index à deux niveaux. C'est ce qui explique les résultats insolites que vous avez obtenus.

Par conséquent, au lieu de :

   Prélude pour Henri Barda => <Prélude pour Henri Barda i> pour piano

il convient de formuler la requête :

   Prélude pour Henri Barda => <Prélude pour Henri Barda i\> pour piano

ou, en abrégé :

   Prélude pour Henri Barda => <$ i\> pour piano

Cela devrait résoudre votre problème.

@+
Marc

#101 By Camilo ( 16 April 2013 - 12:23 )

Good morning,

I need to apply two character styles to the same entry.

And found, happily, that IM considers it as valid and do not break or divide the words when different ch. styles are mixed.

May I trust in this? My results are perfect but want to be more confident as this nex ch. style will be used as a lot of variables for headings.

Thank you.

generic character style (a): Luis Umaña Morales

additional character style (b): Herrera
Beatriz Umaña Herrera

Indexmatic result: PERFECT
Beatriz Umaña Herrera 1
Luis Umaña Morales 1

#102 By Marc ( 16 April 2013 - 14:45 )

Hi Camilo,

> […] found, happily, that IM considers it as valid and do not break
> or divide the words when different character styles are mixed.
> May I trust in this?

As long as you *target a parent style group* that both contains charStyle1 and charStyle2, any text range which has those styles mixed can be parsed as a single unit by IndexMatic.

@+
Marc

#103 By Camilo ( 28 April 2013 - 20:27 )

About NO sorting. I found that the entries are arranged, under this negative option, in the inverse order:

My order in the layout is:
dsfgh 3
aghyuik 7
xcvbn 21

and the result after generating the index (requiring no sort):
xcvbn 21
aghyuik 7
dsfgh 3

Of course, numbering the entries, converting the number to text, and reversing the sort is a tip, but think I am doing something wrong.

Thank you.

#104 By Chris ( 13 May 2013 - 14:20 )

Greetings, Marc, from Nouvelle-Zelande!

According to page 28 of your manual, IndexMatic automatically creates a set of character and paragraph styles for the different components of the indx snippet. Does this mean that all I have to do once the snippet is created is to edit settings of those styles, and the style changes will be made throughout the snippet?

Regards.

#105 By Marc ( 13 May 2013 - 14:30 )

Hi Chris,

You are almost correct ;-) The snippet *in itself* just contains 'neutral' style tags that match the regular IndexMatic style names (IndexMatic-Topic, IndexMatic-Location, etc.).

Then, when you place that snippet in your destination document, any style that is already defined is properly applied. Therefore, you just have to set styles once *in the destination document*. When you update the index the newly placed snippet—which then becomes a regular text frame—simply inherits the existing style attributes.

Note. — In the case the destination document is not the source document (the one that contains the text to be indexed), you need to make the destination doc active before you run iX. You will then select the source document via the Scope panel, and generate the index. Once the snippet is ready, IndexMatic offers you the option to place it into the active document (i.e., your destination).

@+
Marc

#106 By Stef ( 13 June 2013 - 15:01 )

Bonjour, j'ai une sorte de dictionnaire à indexer, 5000 articles chapeautés chacun par "expression originale / expression traduite".
Je souhaiterais indexer uniquement "l'expression traduite". Comme ce chapeau a un style propre, est-il possible de conditionner l'indexation à la séquence qui commence après 'espace-slash-espace' jusqu'à la fin du style ? parce qu'en fait, le mot traduit comporte parfois 2,3 ou 4 mots... D'avance merci.

#107 By Marc ( 13 June 2013 - 19:33 )

Bonjour Stef,

> j'ai une sorte de dictionnaire à indexer, 5000 articles chapeautés
> chacun par "expression originale / expression traduite".
> Je souhaiterais indexer uniquement "l'expression traduite"

1) Lancez IndexMatic.

2) Sélectionnez le style visé dans la rubrique « Style ».

3) Sélectionnez le mode de recherche « Requête unique ».

4) Entrez la requête suivante : / \/ (.+)/W => $1

5) Cliquez sur « Produire l'index ».

@+
Marc

#108 By Camille ( 20 August 2013 - 12:59 )

Bonjour,

Est-ce normal que tri latin générique organise l'ordre alphabétique comme si l'espace n'existait pas ? J'ai donc par exemple Chen Gaoyong puis Cheng Conglin puis Chen Guang alors que les Chen devraient être rassemblés... Les noms sont en alphabet latin, y a t il une option que j'ai mal cochée ?
2/ Est-il possible de reprendre l'ordre alphabétique sans générer à nouveau l'index (j'y ai fait des reports images à la main) ?

En tout cas mille mercis pour cet outil qui m'est devenu indispensable !
Cordialement, Camille

#109 By Marc ( 21 August 2013 - 12:43 )

Bonjour Camille,

Merci pour ces encouragements.

1) Effectivement, les fonctionnalités de tri d'IndexMatic ne prévoient pas d'option pour classer « mot par mot » les entrées avec espace interne. Du coup, l'algorithme rend l'espace muette et place « Cheng Conglin » AVANT « Chen Guang » (CHENGC < CHENGU). Je prends bonne note de ce problème et vais réfléchir à une solution.

2) C'est là aussi une question importante qui a été évoquée par d'autres utilisateurs : comment maintenir l'ordre des entrées après un ajustement manuel ? Je ne vois pas de solution ergonomiquement simple, sauf à développer une interface additionnelle permettant à l'utilisateur de spécifier un classement ad hoc. Comment voyez-vous les choses ? Lorsqu'un nouvel index est généré, IndexMatic doit de toute façon ré-analyser l'intégralité du document sur la base d'un nouveau jeu de requêtes ; il ne peut rien présumer des termes sur lesquels il va déboucher et il ne dispose d'aucune information sur l'index qui aurait été précédemment produit et réagencé par vos soins. D'où la difficulté.

Il existe peut-être des voies plus simples, ou plus « autonomes », pour traiter les questions que vous soulevez.

D'une part, on trouve chez Peter Kahrel le script Language Aware Paragraph Sorter — http://www.kahrel.plus.com/indesign... — qui propose une option de tri Word by Word. Exécuter ce script en aval d'IndexMatic pourrait vous aider à résoudre la question (1).

D'autre part, si vous vous appuyez sur l'option d'export XML d'IndexMatic, alors il est envisageable de retraiter le flux en aval via une feuille XSLT qui assure le maintien d'un classement personnalisé. Je ne suis pas expert sur ce terrain mais je ne doute pas que cette perspective soit féconde. À étudier.

Cordialement,
Marc

#110 By Madeline Lostland ( 21 September 2013 - 14:09 )

Bonjour Marc,

Superbe outil ! Un grand merci.

Je reviens à nouveau sur ces 2 points :

1/ Envisagez-vous toujours la possibilité de "pouvoir transformer" l'index obtenu avec IndexMatic en index standard d'ID (utilisant la fonctionnalité d'index interne d'ID avec pose de balises d'entrée d'index) ?

2/ Avez-vous des infos concernant la conservation des enrichissements manuels pouvant être faits dans l'index généré ?

Merci d'avance.

Cordialement,
Madeline

#111 By Marc ( 22 September 2013 - 01:04 )

Bonjour Madeline,

Merci de m'offrir une occasion de préciser un peu les conditions d'évolution d'IndexMatic, dont la mise à jour a été continuellement repoussée ces derniers mois. (InDesign CC a introduit d'énormes problèmes de compatibilité, surtout en termes d'interface, et c'est pouquoi mon calendrier de développement a autant souffert — pour l'ensemble des produits.)

Je précise au passage que la version actuelle (2.028) est « officieusement » compatible avec les versions CS6 et CC-32bits d'InDesign. En d'autres termes, le script fonctionne mais n'est pas à l'abri de certains bugs, quoique ces derniers restent relativement inoffensifs au dire des utilisateurs.

Concernant les fonctionnalités en attente, elles sont très nombreuses et m'obligent à temporiser.

1) La possibilité de réinjecter le résultat d'IndexMatic sous forme d'index InDesign est à l'étude. Jusqu'à présent, mes tests n'ont pas abouti à des performances satisfaisantes. Je pense, au demeurant, que cette fonctionnalité gagnerait à être détachée du programme et implémentée sous forme de script autonome. (Dans cette hypothèse, elle serait délivrée en gratuiciel.)

2) La conservation des enrichissements manuels introduit deux champs de réflexion :

— L'un concerne l'extension du système de réécriture dans les requêtes elles-mêmes, de façon à permettre notamment une gestion plus minutieuse de la « ponctuation sortante », les questions de casse, les espaces spéciales, les retours à la ligne, l'inclusion des numéros de notes, ainsi que la mise en texte des références croisées. C'est surtout dans ce domaine que nos efforts porteront.

— L'autre versant concerne le traitement des enrichissements stylistiques ou assimilés (italique, etc.). Sur ce point, il me semble que l'export sous forme d'extrait InDesign est l'approche la plus fertile, parce qu'elle permet de préserver parfaitement la mise en style d'un index, en évitant les fastidieux reformatages manuels. Mais le découpage par défaut proposé par IndexMatic dans cette modalité d'export manque encore de granularité. Il serait judicieux par exemple de proposer certains opérateurs de mise en forme des entrées d'index, comme l'italique et le gras qui sont souvent réclamés. À l'étude également.

Dans l'immédiat, je vous invite à explorer les possibilités offertes par les styles GREP d'InDesign. J'ai constaté que de nombreux index pourraient être puissamment prémaquettés par cette méthode.

Cordialement,
Marc

#112 By Jose ( 23 September 2013 - 22:57 )

Hello, I recently purchased the indexMatic2 script and it does a great job, but I was wondering if there was a way to have it find names with an InDesign book when they are not on the same line. We have some doctors names that go onto the next line cause of spacing but for some reason it passes up those names if they are not together on the same line.

(Ex: John Doe, MD (it finds this) John
Doe, MD (it won't find these)

The break is not a hard break it's just part of the text flow. Any help would be greatly appreciated.

Thanks,

Jose

#113 By Marc ( 24 September 2013 - 00:04 )

Hi Jose,

The expression "John Doe, MD" should be found in both cases—regardless of soft line breaks.

Please, send me a sample doc at: support[at]indiscripts{dot}com.

@+
Marc

#114 By Camilo ( 03 November 2013 - 20:08 )

Have some index entries: body text and footnotes. The idea is to add the letter n to the footnotes references:

Paris, 13, 18, 24n, 34, 36. 36n, etc.

Indexmatic already generated two files: one for main text and another one for footnotes. How to mix both in a sequential order?

#115 By Camilo ( 05 November 2013 - 15:45 )

a) It is possible to mix in the index operation both paragraph and character styles? In the tests I am doing they are excluyent.
(Query by word /[\w ]+/)

b) What is the grep in this nomenclature to tag numbers and/or other characters before the entry?

Thank you.

#116 By A.N.K. ( 12 November 2013 - 17:44 )

URGENT: I am laying out a 1000 page catalog and need to index the items. In my layout, I have been given the exact text that is to be used as the index items. I have successfully used your script to pull the correct names of the products for the index, but the page numbers are incorrect. The reason they are incorrect is because the index info that I was given is NOT to remain in the layout, but yet I need it for your script to pull the right index names. I have created "Conditional text" in Indesign but in order for your script to pull the right info the conditional text needs to be VISIBLE. BUT when it is visible it REWRAPS the text in the layout making the index information on the "incorrect" page. So my question is what is the best approach for your script? Should I use this "additional/ unprinted" information for the script or for your script do I need to define the index with info within the layout that is going to be used in the final layout? #upagainsttheclock

#117 By Marc ( 14 November 2013 - 07:43 )

@ Camilo

#115 Sorry, IndexMatic does not provide any specific formatting for footnotes (so far).

#116 a) When you select both a paragraph and a character style in the Styles panel, they should be 'mixed' in the sense of a logical AND.

b) What are you trying to do? (Keep in mind that lookbehind operations are not supported in JS regex.)

@+
Marc

#118 By Marc ( 14 November 2013 - 07:54 )

@ A.N.K.

Indeed, IndexMatic needs to have conditional texts visible to handle them — cf. http://www.indiscripts.com/post/201... — so this is not the right approach to achieve your goal.

Couldn't you place your index markers on a dedicated layer?

@+
Marc

#119 By Camilo ( 14 November 2013 - 14:01 )

There are two ways to use IMatic.

One, using a queries list.
Other, extracting entries directly from Indesign through styles.

I have in a very long file both ways.
It is exactly the same or do you have a suggestion?

#120 By Marc ( 14 November 2013 - 18:38 )

Camilo,

Using query list and specifying styles are not 'exclusive' ways to generate an index. You can use both features, that is, run the queries within the scope of the selected styles.

@+
Marc

#121 By Camilo ( 15 November 2013 - 20:29 )

Sorry to extent my posts but I am heavily dependent of IMatic as I am indexing a huge book.

Two fast questions:

a) How to index word separated by periods?
I have some entries marked as:
Luise, Anne, Marie
that IM extracts as
Anne, 12
Luise, 12
Marie, 12

But I want Luise, Anne, Marie, 12 (if possible).
Only periods are the joining element.

How to write the grep syntax for this?

b) It has been impossible for me to obtain a list of no sorted entries. I mean, I need for my first list the entries exactly in the same order that appear in page, in that case the first indexed word will be the first one in page 1, and my list will be ordered by number page. Tried all combinations...

#122 By Marc ( 16 November 2013 - 09:45 )

Hi again Camilo,

> a) How to index words separated by periods?

If you need to extract ONLY words separated by periods, use the following pattern:

    /\w+(, \w+)+/

If you need to extract both single words AND words separated by periods, use the following pattern:

    /\w+(, \w+)*/

> b) It has been impossible for me to obtain a list of no sorted entries.
> I mean, I need for my first list the entries exactly in the same order
> that appear in page […]

Let me explain the problem: the concept of “order of entries as they appear in page” makes no sense to IndexMatic. Indeed, you assume here that a page can only contain a single stream of text, which is only a specific case in an InDesign-based layout. As soon as a page contains two text frames, there is no obvious implicit order.

Technically, IndexMatic retrieves words and expressions basing on an extraction engine which is optimized to be fast and efficient. Its main job is to recognize text patterns and entry-to-page relationships in order to produce the index or the “hit report”. (It also computes the “page rank” if needed.) But you can make no assumption about the ORDER those results are collected.

If you only need to extract a word list “with respect to the order” these expressions occur within a specific story or text frame, better is to use the InDesign GREP search engine. [Nota: IndexMatic *does not use* GREP at all, it implements a much faster mechanism.]

You will easily find on the Internet basic sample scripts that illustrate how to query GREP for simple tasks. I also strongly suggest you give a look at Peter Kahrel's “Indexes and Concordances” page:

http://www.kahrel.plus.com/indesign...

Very helpful utilities are provided here that could somewhat extend IndexMatic features.

@+
Marc

#123 By Camilo ( 16 November 2013 - 11:33 )

Thank for this very good post!
It covers perfectly my enquiries.

Related to the order of entries: I have a book where some entries are:

Henry Brigard and his sisters Andrea, Susan, and Louise traveled to Chile.

My idea is to index the three sisters but they lack the family name. If I use IndexMatic I will have the three entries separate by alphabetical order (only names) and will be difficult to know what family name they have and where they have to be inserted.

But, If I have a list ordered by page it will see immediately that they are linked to Henry and that they ARE Brigard; and very fast, in a manual operation, I can decide how to manage these entries. (Also, they could be seen in the same line with Henry or in the next paragraph return). I think I have at least 200 entries like this!

That is the reason behind the 122 post.

I will check P. Kahrel to have more tools.
Thanks again for your help.

Camilo

#124 By Winn ( 25 November 2013 - 02:41 )

Am indexing a large book with Biblical book names in it. How can I get Genesis and Gen. references to show up in the same entry vs. two entries.

Winn

#125 By Marc ( 25 November 2013 - 08:10 )

Hi Winn,

> How can I get Genesis and Gen. references to show up
> in the same entry…

Type the query as follows:

    /Gen(esis|\.)/I => Genesis

Regards,
Marc

#126 By Winn ( 26 November 2013 - 00:28 )

Thanks Mark,

I'm a bit of a novice at this. The above query worked to accomplish what I needed.

Can you run the script and get the results in the order that is listed in Query List in this case Genesis, Exodus, Leviticus, Leviticus, etc.

Thanks

Winn

#127 By Winn ( 26 November 2013 - 08:02 )

oops! My Bad! Marc

Winn

#128 By Winn ( 27 November 2013 - 00:24 )

Marc,

I think the answer to my above question (#127) is in #123 above.

Thanks,

Winn

#129 By Marc ( 02 December 2013 - 07:03 )

@ Winn

> I think the answer to my above question (#127) is in #123 above.

Indeed ;-)

Marc

#130 By ck ( 09 December 2013 - 21:56 )

How do I create this format
Animals
...Dogs 3
......Brown 4
......Black 5
...Cats 6
......Orange 7
......Stripped 8

using the Query-based option? The periods represent indentation since the spaces didn't show up in my preview.

Thanks!

#131 By Marc ( 10 December 2013 - 01:54 )

@ ck

For the time being IndexMatic does not provide topic grouping at the 3rd level. As shown in the manual you can specify TOPIC > SUBTOPIC relationship (e.g. Animals > Dogs), but the syntax X > Y > Z is not supported.

@+
Marc

#132 By Julien ( 27 January 2014 - 19:27 )

Bonjour,
Je découvre Indexmatic dont je pense qu'il peut me faire gagner beaucoup de temps sur la production d'un très gros index mais mes premiers essais ne fonctionnent pas comme je m'y attendais.
Dans un document, je souhaite indexer toutes les expressions ayant un style de caractère donné: "I. glandulifera", "I. balfouri", "I. parviflora", "I. noli-tangere"
Comment faire pour qu'Indexmatic ne considère pas "I." d'une part et "glandulifera" d'autre part comme étant deux entrées d'index séparées (avec pour conséquence que "I." n'est pas indexé puisqu'il ne contient pas le minimum requis de 2 caractères)?
(Le problème se pose aussi avec "Impatiens glandulifera", chacun des mots est indexé séparément).
Je précise que le style de caractère est appliqué aux espaces incluses dans chaque expression.

J'imagine que la solution réside dans une requête (mes essais étaient en automatique) mais je ne trouve pas comment dire "Style de caractère: style1" + "n'importe quelle chaîne de caractères".

Merci pour votre aide.

#133 By Marc ( 28 January 2014 - 03:35 )

Bonjour Julien,

Après avoir sélectionné le style de caractère cible, passez en mode « Requête simple » et saisissez l'expression régulière suivante :

/.+/

Cordialement,
Marc

#134 By Julien ( 28 January 2014 - 08:47 )

Bonjour Marc,
Merci pour cette réponse rapide et efficace.
J'ai encore une question: je fais un test sur une page et quand je sélectionne [Pas de tri], les entrées sont listées dans l'ordre inverse d'apparition. Y a-t-il moyen de lister les entrées dans l'ordre du texte?
Cordialement,
Julien

#135 By Marc ( 28 January 2014 - 22:48 )

@Julien

> Y a-t-il moyen de lister les entrées dans l'ordre du texte?

Ce point a souvent été abordé par les utilisateurs — cf. notamment #123 b) ci-dessus. Je traduis ma réponse en français :

Bien qu'elle apparaisse évidente à l'intuition, la notion d'un ordre implicite des entrées « telles qu'elles se suivent dans le texte » n'est pas définie pour IndexMatic.

Cela présupposerait tout d'abord qu'une page ne puisse contenir qu'un seul flux de texte, ce qui constitue seulement un cas particulier de mise en page. Sitôt qu'une page comprend au moins deux blocs, l'ordre du texte devient incertain.

Techniquement, la capture des mots ou expressions via IndexMatic repose sur un algorithme d'extraction visant à la fois la vitesse et l'efficacité. L'essentiel du travail consiste à détecter des motifs textuels et à établir la correspondance entre les entrées d'index et les numéros de page. (Sans parler d'autres calculs tels que le « page rank », etc.) Compte tenu de ce mode opératoire, aucune hypothèse ne peut être faite quant à l'ORDRE selon lequel les résultats sont collectés.

Dans le cas où vous souhaitez seulement extraire une liste d'expressions selon leur ordre d'apparition au sein d'un bloc-texte ou d'un article spécifique, il me semble plus judicieux d'utiliser le moteur Grep d'InDesign. [N.B. — IndexMatic *ne sollicite pas* les fonctionnalités Grep.]

On trouve sur le Net de bons exemples de scripts illustrant l'emploi de Grep pour des tâches simples. Je vous invite tout spécialement à visiter la rubrique “Indexes and Concordances” de Peter Kahrel :

http://www.kahrel.plus.com/indesign...

Y sont proposés de nombreux utilitaires qui me semblent de nature à combler les « manques » d'IndexMatic.

P.S. — J'ajoute aussi pour les francophones le site http://indigrep.com/ de Laurent Tournier.

Cordialement,
Marc

#136 By Camilo ( 28 February 2014 - 21:09 )

Have some entries already finished like:
Louise Marianne Gaulois Mauriac

that sometimes may appears reduced as:
Louise Marianne Gaulois.

But generating the index IM only catches the whole «Louise Marianne Gaulois Mauriac», not the lesser one, without Mauriac. This shorter one is lost in the output.

How to modify the menu to obtain both results?

Thanks.

#137 By Marc ( 01 March 2014 - 05:21 )

Hi Camilo,

What about the query:

    Louise Marianne Gaulois => $ Mauriac

?

#138 By Camilo ( 02 March 2014 - 13:23 )

Hi Marc,

My point is not well explained...

My list comes from a different file with full names like Louise Marianne and composed parent names like Gaulois Mauriac.

If I use this list as a query list (/[\w ]+/) IM only find when the same four words are the document. Am I wrong?

I need a general query where IM recognises when the name is identical but lacking one word. For example, that catches also Louise Marianne Gaulois although Mauriac is NOT in the document to be indexed. (Sometimes that girl LMGM may be present in the file with four words and IM gets her!)

Thanks for your fast reply!

#139 By Laszlo ( 02 March 2014 - 19:27 )

Dear Mark,

Does indexmatic working with InDesign CS6 (version 8.0.2) as well.

Cheers

Laszlo

#140 By Marc ( 02 March 2014 - 20:54 )

@ Camilo

The query I suggest is:

Louise Marianne Gaulois => $ Mauriac

so it will find any occurrence of "Louise Marianne Gaulois"—including those that also precede "…Mauriac"—and then index all these locations as

$ Mauriac

that is, "Louise Marianne Gaulois Mauriac".

In other words, the KEY expression is LMG and the final ENTRY is LMGM. This should address your specific issue.

Now there is no way to make this rule generic. If you ask iX to grab partial expressions, you need to explicitly specify the full index entry. If you use a generic regex like /[\w ]+/ then the script has no way to 'guess' missing or implied terms.

=============================================

@ Laszlo

IndexMatic is officially CS3/CS4/CS5 compliant, and unofficially CS6 compliant. As far as I know CS6 is well supported, although iX has not been specifically updated for that version. The best is to test the TRY version on your platform anyway.

Regards,
Marc

#141 By Camilo ( 02 March 2014 - 23:26 )

@Marc,
Perhaps duplicating the list and reducing the four words entries to three words, eliminating the last one, will output all the entries that lat may be easily checked. Alo this grep may be in ome way adapted to the four word entries. Thank you.

@Laszlo
Indexmatic is working perfectly in CC and Maverick.

#142 By Jac ( 03 April 2014 - 05:44 )

Hi Marc,
I'm using CS6 and can generate an index, but it is only generating it for the letter A. Can you help please?
Thanks, Jac

#143 By Marc ( 03 April 2014 - 14:49 )

@ Jac

Are you using the TRY version? (It's limited to 50 entries per index.)

@+
Marc