IndexMatic 2 | Frequently Asked Questions [UPDATE]
January 08, 2013 | IndexMatic | en | fr
IndexMatic 2 is without doubt one of the most advanced word indexing scripts ever available to publishers, authors, book designers who use InDesign (CS3, CS4, and CS5+). There are many ways to configure, refine and handle its features. Users gradually discover that what they thought was impossible is, in fact, definitely within scope of the product. The purpose of this page is to boost your learning curve through concrete Q&A.
1/ General Points
User's Guide
Version Number
CS5.5 Compatibility
Saving User's Preferences
IndexBrutal vs. IndexMatic
2/ Scope, Context & Search options
Preventing the index from being indexed!
Autoextracting a Vocabulary
Matches and Page Rank
“Whole Word” and Regular Expressions
Conditional Text
Targeting several Character Styles
Inner Spaces and Whole Words
Automatic Mode vs. Query modes
3/ Basic Queries
Uppercase Letters and Diacritics
Term Rewriting / Subtopics / Cross-References
Dealing with Plural Forms
Queries and White Spaces
Website Names, URLs
Key Length / Grouping Alternatives
Using the "\w" Metacharacter
Extracting XML Data
Special Space Characters
4/ Advanced Queries
Header Sections (A, B, C…)
Punctuation
Redundant Matches
Stats on letters
Using alone the "$" Symbol
5/ Output
XML Output
Multiple indexes
6/ Limitations and Known Issues
OS Error: -982 / Verdana
Preserving Text Formatting
Non-Latin Alphabets
Freezed Progress Bar / Table indexing
Delayed result
“Indirect” Character Styles
Stop Words?
'Not Well Formed' Error (InDesign Snippet)
1/ General Points
User's Guide
• IndexMatic sounds easy to play but difficult to master. Is there a good step by step instruction on how to use its advanced features?
[BOTH VERSIONS] The right place to learn is the user's guide (PDF), which is provided in both English and French language. This manual has been designed to guide you from the basics to the next level, including technical information on the query interpreter, regular expressions, and additional notes about how the script actually scans and parses InDesign documents.
More concrete examples and case studies will be addressed in this FAQ, which I hope will be enriched by users' comments!
Version Number
• How to know what exact version of IndexMatic I'm using?
[BOTH VERSIONS] The major version number is displayed in the title bar of the main dialog, typically, “IndexMatic PRO | 2.0” (pro version) or “IndexMatic TRY | 2.0” (trial version). The full version number is displayed at the bottom right of the main dialog. E.g: “2.026”.
CS5.5 Compatibility
• We bought a license of IndexMatic PRO, but some days ago we also bought the upgrade to InDesign CS 5.5. Can we reuse the script in CS5.5?
[BOTH VERSIONS] IndexMatic2 works in both InDesign CS3, CS4, CS5, and CS5.5. (In CS3, a few features are not available.) To install the script in a newer InDesign installation, simply put the script file, IndexMaticPro.jsx or IndexMaticTry.jsx, in the Script Panels folder of the new release.
Reminder. — The easiest way to locate the Scripts Panel folder is to start InDesign, open the Scripts panel (Window > Utilities > Scripts), right-click the “User” or “Application” item, then click “Reveal in Finder/Explorer.”
Saving User's Preferences
• Is there any way to save the last-used state of the dialog box? It is a little frustrating having to choose each of the menus each time I use the script.
[TRY VERSION] InDesign session persistent settings are only supported in the PRO version of IndexMatic.
IndexBrutal vs. IndexMatic
• I used your script “IndexBrutal” for years. Can I reuse in IndexMatic the wordlists I prepared in IndexBrutal?
[BOTH VERSIONS] All what you did with IndexBrutal can be done with IndexMatic2 (and so much more!) but you cannot reuse IndexBrutal's queries “as is” if syntactic operators were invoked. Indeed, IndexMatic offers a different way to manage case sensitivity, topic-rewriting and the "whole word" option. Roughly, you should apply the following conversion rules:
| IndexBrutal syntax | IndexMatic2 syntax |
|---|---|
| roar|noise | roar=>noise |
| >punish | punish/W |
| !smith | smith/I |
| !UNESCO | UNESCO/i |
2/ Scope, Context & Search options
Preventing the index from being indexed!
• As I lay out the index at the end of my book, I don't want that IndexMatic scans the index chapter itself! How to tell the script to ignore that section?
[BOTH VERSIONS] There are several ways to proceed. I recommend one of the following methods:
(a) In the Scope panel, select Range > Page range... and enter the explicit interval of page numbers that you need to inspect, excluding the Index pages. E.g.: 1-250 if the index is inserted on page 251.
(b) Another easy strategy is to set up all text to be indexed on a dedicated layer, e.g. “Indexable”, while the Index section is set on another layer. So you don't have to worry about page ranges: in the Scope panel, just select “Indexable” in the Layer(s) dropdown list.
Autoextracting a Vocabulary
• I need to index an entire book but I have not preset any wordlist. Is there a way to automatically extract the most relevant vocab entries and then manually refine the set before processing IndexMatic?
[PRO VERSION] IndexMatic offers an “Automatic Mode” which can be used to detect and grab the most representative words from your document(s). First, open your book in InDesign and launch the script. In the Scope panel, select the “Book” item in the Document(s) list. In the Default Options panel, set the Page Rank to 3 or 4 (these are usually appropriate values). Click the Hits... button to open the Hit Report dialog. Uncheck “Display stats” and click Run. This creates a wordlist that you can easily cleanup and use as a starting point in the Query List mode.
Matches and Page Rank
• Given a regular expression like /Steve|Bill/ which produces two terms—"Steve" and "Bill"—does the Page Rank apply on each term, or considering the total number of matches per page?
[BOTH VERSIONS] The Page Rank operates on each separate term that the query implicitly produces. Suppose that "Steve" occurs three times on page 10 and two times on page 11, while "Bill" occurs two times on page 10 and three times on page 11:
On Page 10: … Steve … Bill … Steve … Bill … Steve.
On Page 11: … Bill … Steve … Bill … Steve … Bill.
Then, the query:
/Steve|Bill/3
sets the Page Rank to 3 and leads to the following output:
Bill: 11
Steve: 10
By contrast, if the query provides an explicit term:
/Steve|Bill/3 => My Friends
then IndexMatic considers that each alternate match counts in the "My Friends" Page Rank. So the above query leads to:
My Friends: 10-11
(Since the total match count is 5 on each page, the Page Rank is obviously satisfied.)
“Whole Word” and Regular Expressions
• Our document relies on a special markup syntax using the following format:
"...\index{the word to be indexed}..."
As we want to extract every marked word, we tried the query:
/\\index\{([^}]+)\}/ => $1, but this does not work.
[BOTH VERSIONS] Always consider the context where the matches appear. Your target format, \index{the word to be indexed}, seems to be directly embedded in the text—I mean, without any separation—so you probably have to disable the Whole Word option. Try one of the following:
(a) Uncheck the “Whole Word” checkbox in the Default Options panel (so that the flag is globally disabled).
OR
(b) Append the local flag W at the end of your pattern:
/\\index\{([^}]+)\}/W => $1
Conditional Text
• Our annual report is written in several languages that we manage in a single InDesign document through conditional texts (rather than linguistic layers). Can IndexMatic target separately each language (i.e., each condition)?
[BOTH VERSIONS] Regarding conditional text, IndexMatic simply considers the contents wich is enabled at the moment you launch the script. So, just activate the condition that corresponds to a specific language and you get the related index.
Targeting several Character Styles
• The data we have to index are all laid out in the following form: "Name/Reference". The first part (Name) has the character style "Product Name" while the second part (/Reference) has the character style "Product Ref". When we select the style "Product Name" in IndexMatic and we send the query /[a-z]+\/[0-9]+/i, the script returns no result. How can we make it work, and is it possible to render the items in the form: "Name (Reference): page numbers"?
[BOTH VERSIONS] IndexMatic cannot directly target mixed-style content (unless you select no style!), but there is a simple workaround: gather the required character styles in a style group. This allows you to target that group in the IndexMatic's Style panel—style groups are listed in the form: [group_name] *. Here is how to proceed with your example:
1. In InDesign, create a character style group, say "Product", and move the existing styles ("Product Name" and "Product Reference") in the newly created group.
2. Start IndexMatic. In the Character Style dropdown list, select: [Product] *.
3. Send the query: /([a-z]+)\/([0-9]+)/i => $1 ($2).
Inner Spaces and Whole Words
• I want to find matches that contain white spaces, like "sold out" or "back pay". Do I need to uncheck the “Whole Word” option?
[BOTH VERSIONS] No. The purpose of the Whole Word option is to ensure that a match is not preceded or followed by a character that belongs to the current Alphabet. This does not preclude the presence of spaces or non-alphabetic characters within the search key.
For example, with the default settings (Whole Word active) the query back pay finds any occurrence of "back pay", but ignores a string such as: "rollback pay".
It is generally useful to disable Whole Word when a partial token can be found in several expressions that unambiguously refer to the same topic, for example: modern/W => modernity
Assumed that the substring "modern" can only occur in words that relate to modernity, the key:
modern/W
is much more efficient than a complete pattern like:
/modern(i(sm|ty|ze))?/
Automatic Mode vs. Query modes
• I was trying to generate an index based on a character style and I found out that IndexMatic only considers single words, but not compund expressions like “The Vice President” even if the complete expression (including the spaces) has an appropriate character style applied. Do I have a possibility to grab complete runs of character-styled characters?
[BOTH VERSIONS] You had probably invoked the Automatic Mode, which is not appropriate for your goal. In Automatic Mode, IndexMatic only grabs words—in the sense of the current Alphabet. To get extended results, you have to select the Single Query (or Query List) mode in order to send your own command(s). Here are some usual queries when you are filtering content by character style:
To globally capture every character-style run, use:
/.+/
To capture words-and/or-space strings only, use:
/[\w ]+/
To capture words only, use:
/\w+/
3/ Basic Queries
Uppercase Letters and Diacritics
• I use the query /[A-Z]\w+/I to retrieve words that start with an uppercase letter. Unfortunately the class [A-Z] does not match uppercase letters with diacritics such as À or É. How to fix this?
[BOTH VERSIONS] Use \m instead of [A-Z]. The class [A-Z] only sees ASCII uppercase letters, while the metacharacter \m matches any uppercase letter of the current alphabet. (Similarly, \l matches any lowercase letter of the current alphabet.)
Term Rewriting / Subtopics / Cross-References
• I would like to index words that does not actually appear on the pages (e.g. indexing "France" on pages that only talk about "Paris"). How to do?
[BOTH VERSIONS] Take advantage of the rewriting-operator (=>). Every occurence of "Paris" in the document can be rendered "France" in the index, using the following query:
Paris => France
Of course you can both generate the topics "Paris" and "France" by these two queries:
Paris
Paris => France
The first line above indexes "Paris" as itself, while the second line creates alongside the topic "France" (from the same matches).
Another approach is to output "Paris" as a subtopic of "France":
Paris => France > $0
The above query is more relevant in that it allows to manage other France-related subtopics, for example:
Bordeaux => France > $0
A compact way to write together the two queries is then:
/Paris|Bordeaux/ => France > $0
And the resulting index looks like:
France
Bordeaux: page numbers
Paris: page numbers
In addition, if you want to get "Paris" as a first-level heading in your index, you can easily redirect the reader to the topic "France" by adding the following cross-reference (note the double slash at the beginning of the query):
// Paris => See France
Finally, our complete query list could be:
// Bordeaux => See France
// Paris => See France
/Paris|Bordeaux/ => France > $0
• In a topic like "FRANCE" I would like to have a sub entry, e.g. "Paris", which does not contain any page number and only refers the reader to an external topic named "PARIS". How to?
[BOTH VERSIONS] The syntax for cross-references allows you to declare a "See..." reference from any existing (or non-existing) topic or subtopic. Simply format the “fake term”—see Manual, page 20—as a formal subtopic:
// FRANCE > Paris => See PARIS.
Now consider a query list having the following lines:
...
FRANCE
PARIS
// FRANCE > Paris => See PARIS.
...
The final index will look like:
…
FRANCE: page numbers
Paris: See PARIS
…
PARIS: page numbers
…
Dealing with Plural Forms
• Given a list of words in singular form, is it possible to capture both the singular and the plural forms?
[BOTH VERSIONS] IndexMatic is not able to deduce alone what is the plural form of a word, so it is necessary to specify the corresponding alternatives in the queries.
To index singular and plural forms—or other variants—under the same heading, the best way is to extend the original words to regular expressions. Here is the most common example, including the letter 's' at the end of the word:
/cats?/ => cat
which can be also expressed:
/(cat)s?/ => $1
So, when you have several items based on the same plural transformation, you can easily factorize the keys as follows:
/(cat|dog|snake)s?/ => $1
Of course, you have to deal with a number of special cases:
/stor(y|ies)/ => story
/wom(a|e)n/ => woman
/person|people/ => person
etc.
Queries and White Spaces
• We want to capture the string " USD" (with a space before), but the query: " USD" seems to be interpreted as "USD" without space. Why?
[BOTH VERSIONS] When a key is based on a simple token (with no starting slash), spaces at the beginning of the string are automatically ignored. Similarly, trailing spaces are ignored if the key has no ending slash. Study the following queries:
sample
sample/w
sample => Words > $0
In each case the considered token is just "sample" (without space).
To compel IndexMatic to take ending/trailing space(s) into account, simply enclose the key between slash characters:
/ USD/
Note that the expression is then parsed as a regular expression, but this has no side-effect unless you use pattern-specific operators.
Website Names, URLs
• Is it possible to index every website mentioned in my document and to render the entries in the form:
"name [URL], page numbers"?
[BOTH VERSIONS] This primarily depends on how these elements are treated in the document.
If a specific character style is applied to website names and/or their URLs, there is no difficulty in retrieving these items using the Style filter and a generic query like: /.+/
If the data are not styled, you have to provide your own wordlist to grab website names (as the script cannot recognize a priori the name of a website in the text.)
If you only have to grab the URLs, send a query like:
/(http:\/\/|www\.)[^ ]+/I
or a more sophisticated one. This approach can be used as a preparatory step to identify websites. You can then get the results from the Hit Report and build an improved query list that considers both websites' name and URL.
Key Length / Grouping Alternatives
• I found it very useful to target a list of subtopics with queries like:
/John|Bill|Kate/=>Authors>$0. But, how many terms can be in such a query? I have several hundreds of such terms. Can this number be handled by the query? Or what would be the alternative approach?
[BOTH VERSIONS] The maximum length of an IndexMatic key is set to 172 characters since version 2.025. This allows to write complex regular expressions, but indeed you cannot handle a hundred of alternative expressions this way. The solution is to use a regular Query List:
John => Authors > $0
Bill => Authors > $0
Kate => Authors > $0
...
However, you still can optimize the list with a set of grouped alternative terms, provided that each key does not use more than 172 characters. For example:
// A...
/Aaron|Adelle|Alban|Andre|Arnold|Ava/ => Authors > $0
// B...
/Barton|Beatrice|Benjamin|Brandon|Breanna/ => Authors > $0
// C...
/Celeste|Charmaine|Chuck|Constance|Curt/ => Authors > $0
...
Using the "\w" Metacharacter
• What is the exact scope of the \w metacharacter?
[BOTH VERSIONS] The \w metacharacter automatically fits the current Alphabet settings: it matches any character of the selected alphabet, and optionally matches the hyphens, the digits, the apostrophe, and/or the underscore—depending on the checked boxes in the Alphabet panel. See the user's guide to have complete details on these features.
Note that the behavior of \w is IndexMatic-specific. In pure JavaScript regular expressions, \w only matches an alphanumeric character, including "_". Hence, if you want to make \w behaves as in JavaScript, select the ASCII alphabet and check the “Allow digits” and “Allow underscore” boxes. Otherwise, you can still use the character class [a-zA-Z0-9_].
Extracting XML Data
• Is IndexMatic able to parse text like:
"...<index>New Orleans</index>..."?
And is it possible to extract the attribute as well? Like:
"...<index entry="New Orleans, LA">New Orleans</index>..."
[BOTH VERSIONS] To grab the content of the <index> element, send the following query:
/<index>([ \w]+)<\/index>/ => $1
And to grab the attribute:
/<index entry="([ \w,]+)">/ => $1
Special Space Characters
• At a specific location of a regular expression, I want to specify "thin space" OR "hair space" rather than the IndexMatic's generic space. Is it possible?
[BOTH VERSIONS] Simply enter the explicit character class: [~<~|] (GREP syntax), or [\u2009\u200A] (Unicode code points). See also the user's guide, page 22.
Note. — Whatever the Generic Space settings, IndexMatic alway considers the special characters you specify.
4/ Advanced Queries
Header Sections (A, B, C…)
• I want to add header sections to my index (A, B, C, etc). This is purely a styling/organizational issue. Do I need to manually add these to my index? If so, is there at least a way to add A, B C, etc to my Query file so that I don't have to re-enter that info when I re-build my index?
[BOTH VERSIONS] The current version of IndexMatic does not offer an easy way to add extra headers to the index, unless you use cross-reference queries in the form:
// My Extra Topic => see also...
However, in the above syntax the right side cannot be empty or filled with white spaces, hence you cannot tell the script to create simple headings such as A, B, C... The next release should take your request into consideration.
For the time being, the only workaround I can see is to use a fake character, such as a dot, and to add the following queries:
// A => .
// B => .
etc.
Then you can use a GREP style rule that applies the [None] swatch to \t\. (i.e. TAB + DOT).
Also, in the specific case you use regex-driven queries that produce first-level TOPICS, e.g.:
/\w{3,}/
you have the option to extract the first letter as a TOPIC and to push the entries as SUBTOPICS:
/(\w)\w{2,}/ => $1 > $0
Then, in the Entry Case field of the Output panel, select "Upper > Auto". You will get something like:
A
{A-entries}
B
{B-entries}
etc.
Punctuation
• What is the most generic way to indicate a punctuation character in a regular expression?
[BOTH VERSIONS] The Unicode metacharacter \p{P} will capture any punctuation sign. Some refinements are available (see the user's guide, page 22).
Redundant Matches
• In the book I'm indexing I have three variants of first names ("P. H. Nielsen", "L.-D. Nisipeanu", and "G. Kasparov") which I grab from character-style runs. My queries are the following:
// 1. Catches "P. H. Nielsen" etc.
/([A-Z]\. [A-Z]\. )([A-Z]\w+)/ => $2, $1
// 2. Catches "L.-D. Nisipeanu" etc.
/([A-Z]\.\-[A-Z]\. )([A-Z]\w+)/ => $2, $1
// 3. Catches all like "G. Kasparov"
/([A-Z]\. )([A-Z]\w+)/ => $2, $1
But Nielsen is then duplicated in the output as both "Nielsen, H." and "Nielsen, P. H." How to fix this?
[BOTH VERSIONS] Since IndexMatic does not support the “lookbehind” assertion, it is not possible to prevent "P. H. Nielsen" from being detected by your third query, which in this case is redundant since your first query already treats that string. This is a common issue when one need to control the very beginning of the input string. By chance you can solve the whole problem through a single query:
// Catches all cases from a single pattern:
/([A-Z]\.(?:[ -][A-Z]\.)?) ([A-Z]\w+)/ => $2, $1
This works because the ? operator in the middle of the query is greedy, which forces the engine to grab "P. H." rather than "P." alone. As a general strategy, when you need to capture variants of a single data type it's better to address all the cases from a unique query. Using multiple queries causes redundancy if two distinct regular expressions have a chance to capture the same string.
Note. — The syntax (?: in the above pattern declares a non-capturing parenthesis. This allows to create an optional group,
(?:[ -][A-Z]\.)?
without increasing the number of captured placeholders, so $2 always refers to the second part of the global pattern, ([A-Z]\w+).
Stats on letters
• I want to report all letters contained in a document, including non-Latin letters, with their related frequency. Can this be done through the “Hit Report” feature?
[PRO VERSION]
1. Enter the following (single) query:
/[\p{Ll}\p{Lu}\p{Lt}]/IW
2. Set the Entry Case to [No change].
3. Press the Hits... button.
Note. — The \p metacharacter is not affected by the Alphabet settings, you can always use it to search characters from their Unicode properties.
Using alone the "$" Symbol
• We are testing different regular expressions in order to find the most relevant in URL extraction. Can IndexMatic display what pattern has produced each specific set of results?
[BOTH VERSIONS] In the query term, the $ symbol always represents the original key in its literal form. For example:
/[a-z]{3}\d/ => $
will report in a single topic, "[a-z]{3}\d", every page that contains a sequence of three letters followed by a digit.
Hence, you can easily 'backup' the relationship between each pattern and the found terms. In your case, a possibility is to output the patterns as first-level topics and the URLs as related subtopics:
/pattern1/ => $ > $0
/pattern2/ => $ > $0
etc.
5/ Output
XML Output
• I'm confused about the XML file output. Once you edit your XML file, how do you get that info back into InDesign and turn the XML info into an index?
[PRO VERSION] The XML output feature is independent from InDesign. It allows you to retrieve your index as a pure XML file for further processing (database, etc.), but it is not intended to comply with the InDesign XML workflow—wich is very specific.
Multiple indexes
• My problem is to create multiple indexes for a book (index of places separately from the index of personal names, etc.). Is IndexMatic capable of making such multiple indexes?
[BOTH VERSIONS] Basically, IndexMatic does not manage multiple indexes at the same time. You have to configure options/queries first to build the PLACES index, then you need to re-run the script and apply new settings in order to create the NAMES index, etc. Switching to specific prepared wordlists from the Query Editor should help you to quickly achieve these tasks.
If each index targets a one-level topic set, another option is to create a single query list based on subtopics, where each subtopic represents in fact a sub-index (NAMES, PLACES, etc.), for example:
/Boston|Atlanta|Paris/ => PLACES > $0
/John|Bob|Jiri/ => NAMES > $0
Although this results in a single file, your final entries will be rendered in the form:
NAMES
Bob 5, 12-13, 20...
Jiri 14, 18, 22...
John 17, 20-23...
PLACES
Atlanta 7, 9, 12-13...
Boston 15...
Paris 12-15, 17-22...
6/ Limitations and Known Issues
OS Error: [-982] / Verdana
• Testing IndexMatic on InDesign CS5 / Mac (Lion), I got the following error message: "JavaScript Error. Error Number: 1. Error String: OS Error: [-982]."
[BOTH VERSIONS] This error is related to a corrupted or missing font file. Please, make sure that Verdana is properly installed on your system.
Preserving Text Formatting
• Is there a way to preserve character-level formatting in an index entry? For example: book titles, movie titles, species names, etc., are typically italicized.
[BOTH VERSIONS] Sorry, no. That's a serious limitation which I'm really aware of. IndexMatic is primarily a text-driven search engine and it does not keep track of applied formatting.
Note that this is not as easy as it sounds, because the same expression, or text pattern, may appear with different formatting in the document. Suppose IndexMatic finds “New York Times” italicized on page 1 and the same string with no formatting on page 2... Is this the same TOPIC? How to compute hits, Page Rank, etc., in that context?
Non-Latin Alphabets
• IndexMatic doesn't work properly with Russian language. Have you any plan to extend it for support Cyrillic alphabet?
[BOTH VERSIONS] IndexMatic can handle any Unicode character from the Basic Multinlingual Plane but indeed it does not provide any practical way to specifically target and sort Cyrillic-based terms. So far, only Latin alphabets are fully supported in this regard. We are studying the possibility of adding non-Latin alphabets in a future release.
Freezed Progress Bar / Table indexing
• The progress bar seems to freeze when I'm indexing a long document including a number of tables.
[BOTH VERSIONS] Due to the heavy (and someway inefficient) structure of table components in the InDesign Document Object Model, indexing table contents can be particularly slow, which leads to long stage in the progress bar. Be patient!
Delayed result
• I thought IndexMatic had crashed, but after a long delay the final index suddenly appeared. How to know whether the script is still running?
[BOTH VERSIONS] Indeed, some Mac-platform users reported that the progress bar may disappear as the indexing process is ongoing. More likely the progress bar is then hidden by another element, but this is—of course!—an unexpected behavior. We are investigating on this issue.
“Indirect” Character Styles
• When indexing based on character styles, IndexMatic seems to find only those character styles that are explicitely applied and not those that are applied by "nested styles" or a "GREP style" within a paragraph style. Can you make the script find character styles that are formatted with a nested/GREP style?
[BOTH VERSIONS] IndexMatic indeed does not inspect indirect styles, it only considers formal Character and Paragraph styles, whatever the way they are enriched or overridden.
As suggested by Laurent Tournier](http://www.indiscripts.com/post/2011/07/indexmatic-2-public-release-and-user-s-guide#c853), a workaround is to use a companion script in order to convert local formatting to pure character styles. Some interesting tools are reviewed in this post from InDesign Secrets: “Free Scripts Help Fix Word Formatting”.
Stop Words?
• Is there a way to prevent usual words like ‘the’, ‘is’, ‘are’ from being indexed in Automatic mode?
[BOTH VERSIONS] You can filter short worts by setting the “Min. Length” value to 4 or 5 in the Search Mode panel. However, IndexMatic does not provide stopword lists (as seen in Wordalizer). We may add this feature in a future release.
'Not Well Formed' Error (InDesign Snippet)
• I encountered an error when trying to build the index to an InDesign Snippet: I've tracked down the issue to the use of '&' in a normal search key. If I generate this to a text file it works fine, but to an InDesign Snippet it always gives 'Not well formed'. Is there a way I need to escape the '&'?
[PRO VERSION] Fixed in version 2.027.

Comments
Bon, je découvre (…sans aucune surprise à vrai dire…!!) que je ne voyais que 5% des possibilités de ce script…
Bref, à lire dès que j'ai deux heures devant moi…
I am trying to test this program but appears an OS error [-982] in both version, Pro and Try.
Mac, Lion 10.7.2, Indesign CS5.5 / 7.5.2
Thank you
Hi Maria,
Thanks for your feedback. Does the error occur before the script dialog appears?
Please, send me —marc {at} indiscripts {dot} com— a screenshot of the error message and if possible your sample document exported as IDML.
I will investigate as soon as possible.
Thanks,
Marc
I posted the required.
Hi,
The message appears inmediately after clicking the script. Any Indexmatic window or aditional activity is showed. Simply nothing happens.
Thanks.
Maria
[NOTE]
The issue mentioned above is solved. If you encounter the “OS error [-982]”, make sure that the Verdana font file is *properly* installed in your system.
Special thanks to Dominique Chiron (http://doopix.com), who gave me helpful details about “OS Error Codes” in Lion.
Marc
This looks amazing...but...does it have any way to hyperlink the page numbers to the page in the generated index?
Hi daneyul,
About hyperlinks, please see this comment:
http://www.indiscripts.com/post/201...
@+
Marc
Darn, guess I'll need to keep using the native ID a while longer. :<
Thanks for the quick reply!
Hi... Thanks for these FAQs. Sometime i also feel difficulties..specially with space But really here you gave the solutions in a very easy & cool manner. I am a developer and Now whenever i fell any trouble than will post again here.
Sincerely..
Hi Marc,
one additional comment / the reason for my yesterday’s question: I was not able to use my query list of approx. 1000 entrie in the try version, it was cut to ca 550 entries. Thx Jan
Bonjour,
merci pour tous ces scripts très utiles.
J'ai toutefois un problème avec la version test d'indexmatic sous CS3 : le texte contenu dans des tableaux imbriqués dans d'autres tableaux n'est pas indexé. Ce type de configuration n'est peut-être pas très orthodoxe, mais en l'occurrence c'est le résultat d'une mise en page automatisée sur laquelle je n'ai aucun contrôle. Est-ce-que ce problème est limité à CS3 ou à la version test? Sinon est-il prévu d'y remédier ?
Bonjour Claude,
Merci pour votre commentaire.
En effet, IndexMatic ne considère que le contenu des tableaux de premier niveau et ignore tout tableau imbriqué. Cette limitation est documentée dans le manuel (page 6) et concerne aussi bien la version TRY que la version PRO.
> Est-il prévu d'y remédier ?
Cela ne dépend que de ma capacité à concevoir un algorithme plus puissant, capable de traverser les tableaux sans induire des temps d'exécution exponentiels ! Hélas, pas de solution en vue pour le moment.
N. B. — La limitation d'IndexMatic est due à l'inefficacité caractéristique d'InDesign en matière d'adressage des cellules. Durant le parcours d'un tableau, le script sollicite intensément l'application afin de détecter les cellules vides, d'extraire le texte, d'identifier les pages associées, etc., mais InDesign répond à chacune de ces commandes avec une lenteur endémique. Pour prendre en charge les tableaux imbriqués, il faudrait en quelque sorte « boucler sur elle-même » la routine d'IndexMatic (i.e. la rendre récursive), ce qui provoquerait une dégradation vertigineuse des performances.
Cela étant, il existe peut-être une approche complètement différente du problème. Le tout est de la trouver.
@+
Marc
Merci pour cette réponse documentée.
La chose m'avait échappée dans le manuel, pourtant très bien fait.
Je vais creuser de mon côté pour résoudre mon problème. Une exploration sur 2 niveaux me suffirait.
I am trying to produce an index based on a character style sheet using an InDesign book file. When I try to select the relevant character style sheet in the Indexmatic dialogue box, many of the character style sheet names (including the one I need to use!) are listing as 'NaN'.
If I try again with just one document open, all the names of the character style sheets are displaying correctly?
I would be most grateful for any advice on why is this happening and how to resolve it.
Many thanks
Marie
Hi Marie,
Thanks for your feedback. It seems like something goes wrong while the script attempts to extract the common styles from the book chapters.
I'd need more detail to study this bug:
1) What version of ID? What OS?
2) When you run IndexMatic having the book file open in the Book Panel but *no document open* in ID workspace, does the script dialog display correct information in the Scope panel? In particular, does the 'Document(s)' listbox display the right number of documents available in the book?
3) Does the 'NaN' error you mention also occur in the Paragraph styles list?
4) Is there something special to notice about your styles (special characters in names, imported styles, etc.)?
Thanks for your patience. I'll try to fix this ASAP. Feel free to email me further detail or samples if needed: marc [at] indiscripts {dot} com
Regards,
Marc
Bonjour,
je souhaiterais indexer une liste de noms présents dans un document, mais je rencontre quelques difficultés dans la syntaxe à adopter pour une requête personnalisée.
Le document se présente ainsi dans un style de paragraphe dédié :
Prénom (saut de ligne forcé)
Nom
Je voudrais un résultat dans l'ordre inverse et sans saut de ligne; Nom Prénom.
Comment indexer le prénom "jusqu'au saut de ligne", puis le nom et les remettre dans l'ordre inverse afin que la recherche se fasse par le nom et non le prénom ?
Merci.
Bonjour Fabrice,
Merci pour cette question, elle va me permettre de préciser le cas épineux du SAUT DE LIGNE FORCÉ, sur lequel le guide d'utilisation fait cruellement silence.
Tout d'abord, le SAUT DE LIGNE FORCÉ (U+000A) est traité par défaut comme un caractère « blanc » depuis IndexMatic 2.025 (alors qu'il était considéré comme un caractère de saut dans les versions antérieures). Cela signifie que ce caractère est pris comme une espace lorsque l'option ESPACE GÉNÉRIQUE est activée — sinon il serait capturé tel quel et converti en saut de ligne dans l'index résultant. [Ce n'est pas le cas du saut de ligne simple, lequel marque la fin d'un paragraphe, donc d'un segment d'indexation, et se soustrait par conséquent à toute possibilité de capture via une requête IndexMatic.]
Dans les situations courantes d'indexation, le fait d'assimiler le SAUT DE LIGNE FORCÉ à une simple espace est le comportement recherché par les utilisateurs. Cela permet d'adresser plus simplement des expressions composées même si elles sont parasitées dans la composition par un saut « manuel » dépourvu de valeur sémantique.
Cependant, dans l'exemple que vous exposez, la valeur séparatrice du SAUT DE LIGNE FORCÉ importe !
On peut capturer spécifiquement ce caractère grâce au raccourci \n (ou \u000A). Un des problèmes identifiés — sur lequel nous travaillons ! — est que cet élément interfère quelquefois avec l'option MOT ENTIER (irruption d'espaces additionnelles dans l'index, typiquement). C'est pourquoi je vous recommande de désactiver l'option MOT ENTIER (flag \W) lorsque votre cible est suffisamment fine pour s'en affranchir.
Passons maintenant aux travaux pratiques. Pour indexer la forme :
<MOT><SAUT DE LIGNE FORCÉ>
<MOT>
l'approche la plus immédiate est d'envoyer la requête :
/\w+\n\w+/
Mais, dans le cas qui vous occupe, considérant que chaque prénom ou nom peut contenir des espaces internes, il faudra plutôt envisager ceci :
/[\w ]+\n[\w ]+/
Libre à vous d'affiner ce motif si nécessaire. Par exemple, utilisez le méta-caractère \m pour imposer une majuscule comme lettre initiale du nom et du prénom :
/\m[\w ]+\n\m[\w ]+/
[N'oubliez pas qu'à ce stade, le SAUT DE LIGNE FORCÉ est converti en saut de ligne dans l'index résultant.]
Reste maintenant à réorganiser les éléments dans l'ordre « Nom Prénom » et à absorber le saut de ligne. Heureusement, l'opérateur de réécriture d'IndexMatic vient à notre secours :
/(\m[\w ]+)\n(\m[\w ]+)/W => $2 $1
Dans la requête ci-dessus, $2 représente la seconde parenthèse capturante (le Nom), tandis que $1 attrape le contenu de la première (le Prénom).
Notez au passage la présence du flag /W, comme suggéré plus haut.
Voilà. J'espère que vous y voyez maintenant un peu plus clair ;-) Dites-moi si cette solution résout votre problème.
@+,
Marc
C'est plus clair en effet et ça fonctionne (me reste à le tester sur un document long) ! Merci beaucoup.
Hello,
Off topic I think, but there was not a place complain...
I was very impressed by the program possibilities, so I decided to buy. Unfortunately the form gives error message suggesting I have the wrong NIP number. I swear the number is right number. What to do?
Hi janusz,
> Unfortunately the form gives error message suggesting I have the
> wrong NIP number. I swear the number is right number. What to do?
Well, I really don't know, sorry :(
When you purchase a product on Indiscripts.com, the operations related to the payment are entirely performed through PayPal [although you don't need to create a PayPal account to purchase with your Credit Card.]
The whole payment processing is hidden to our server and all we can do from this place is to check whether a payment is complete, or not.
So, I suggest you contact PayPal and/or your card issuer to clarify this problem. (I even don't know how NIP numbers do work behind the scene!)
Sorry not to be more helpful.
Regards,
Marc
NOTE. — About Indiscripts' Terms of Sale and payment processing, please refer to this page: http://www.indiscripts.com/pages/cg...
Bonjour
je vous remercie pour ce script étonnant la vitesse peut varier de fulgurante à très longue suivant ce qu'il doit analyser (j'ai un book avec énormément de tableaux longs. Avoir coché l'option tableau implique un temps d'attente sur le livre semblable a celui que certains moteurs de rendu d'image de synthèse.. on peut aller boire un café, faire ses course, se brosser les dents, faire sont lit.. mais le travail est finalement produit, ce qui est une excellente chose. Par contre, en lisant ce post: http://www.indiscripts.com/post/201... , je me demande ou en est le biscuit car en effet, obtenir des numéros de page cliquables lors de l'export de l'extrait en comblerait plus d'un.
Merci pour votre travail
PM
Concernant l'analyse des tableaux, ci ceux-ci sont provisoirement 'transformés en texte'. Alors tout est fulgurant. Reste à les retrouver à leur états originels
Merci Piem pour ce retour très sympathique :)
En effet, le processus d'indexation des tableaux est étonamment « lourd », en raison des boucles de contrôle qui sont exigées par l'agorithme et de la faiblesse inhérente à InDesign dans ce domaine. C'est un aspect que j'évoque dans le manuel d'utilisation et dans la présente FAQ. On va faire le maximum pour améliorer cela dans les prochaines màj d'IndexMatic.
> Concernant l'analyse des tableaux, si ceux-ci sont provisoirement
> 'transformés en texte'. Alors tout est fulgurant.
Ce serait une solution envisageable dans les cas extrêmes — en travaillant sur un document temporaire — encore faut-il s'assurer que la conversion des tableaux en texte ne bouleverse pas la pagination, ce qui n'est pas une mince affaire !
> […] en lisant ce post : http://www.indiscripts.com/post/201...
> je me demande ou en est le biscuit car en effet, obtenir des
> numéros de page cliquables lors de l'export de l'extrait
> en comblerait plus d'un.
Merci de me le rappeler. Je vais faire remonter cet item sur ma « todo list ». Ah ! Si seulement les journées avaient 48 h ;-)
@+,
Marc
oui :)
Je n'ai pas le gène des maths/logique/code, cependant
j'imagine les choses ainsi:
nb: quand je dis 'on' bien sur je parle du script :)
si la page comporte un ou des tableaux on crée sur cette page un layer provisoire (par exemple tbcsv*)
, bien sur on ignore l'analyse des tableaux, alors on (se contente de) copy & paste les entités de tables sur le calque tbcsv*, ensuite on explose en texte (peu importe les options tab ou virgule ou autre, tout fera l'affaire)
(a ce moment la pagination est anecdotique, tant que les tableaux se trouvent à leur bons numéros de page - le texte en excès étant tout de même analysé)
on récupère les infos , on supprime le layer tbcsv* et on passe au suivant.
Peut-être y a t-il des difficulté de sélection lorsque le tableau est en partie ou totalement verrouillé.. je ne sais pas
Quoi qu'il en soit je suis déjà heureux de gagner du temps grâce à ce script.
Merci encore
Bonjour Piem,
> si la page comporte un ou des tableaux on crée sur cette page
> un layer provisoire […] ensuite on explose en texte […]
> a ce moment la pagination est anecdotique, tant que […]
> les tableaux se trouvent à leur bons numéros de page…
Sachez que lors de la conception d'IndexMatic ce type de stratégie a été sérieusement étudiée et pesée. Mais elle se heurte à une série d'obstacles dont je vous donne les deux plus rédhibitoires :
1) La production de contenus temporaires sur un calque de réception dédié aux tableaux « explosés » induit un temps additionnel qui peut se révéler dévastateur sur des documents longs (ou sur un livre entier) lorsque le nombre de pages concernées par cette opération s'accroît. Toute modification, même provisoire, de gros documents de travail, implique des temps de rafraîchissement coûteux pour InDesign, dont IndexMatic pâtirait — outre que le script a pour règle d'or de ne pas « toucher » aux documents cibles.
2) La conversion des tableaux en texte ne résout aucunement le cas épineux des tableaux multipages. Techniquement, un tableau ancré en page 1 et qui se déploie sur plusieurs pages via des blocs chaînés n'est pas « vu » par InDesign comme appartenant à ces différentes pages. Il est vu seulement comme un élément de la page 1. Par conséquent, lors de l'explosion de ce tableau en texte, le problème se pose de conserver la pagination réelle de façon à ce qu'IndexMatic retourne les bons folios pour tout fragment de texte indexé. Or, vous devez savoir que c'est précisément cette question — déterminer la page réelle où apparaît telle cellule d'un tableau — qui consomme du temps de calcul dans IndexMatic !
Le jour béni où les développeurs d'InDesign nous donneront un moyen de récupérer efficacement la PAGE où apparaît une cellule donnée d'un tableau donné, le temps de travail d'IndexMatic sera considérablement raccourci — mais pas pour CS3, CS4 et CS5 !
Cela étant, je ne désespère pas de trouver moi-même une autre solution algorithmique... Qui vivra verra ;-)
@+,
Marc
Les tableaux multi-pages posent un gros problème. Je comprend
Après tout, l’utilisateur, s'il est ordonné, peut préparer le terrain lui même et cacher le layer contenant les véritables tableaux
Merci d'avoir été si clair :)
PM
Je suis têtu, sans doute mon côté breton:
J'insiste:)
Pourtant lorsque vous copiez/collez des tableaux chainés sur plusieurs pages, vous ne vous retrouvez plus avec 1 tableau multipage mais avec 1 tableau (ou au moins un) par page et qui sont tout à fait indépendants. il n'y a plus de chainage.. L'explosion en texte ne pose plus de souci puisque ce que vous avez copié/collé n'est que ce que la page contenait.(me trompe-je?)
j'ai par exemple un tableau de disjoncteurs reparti sur 5 ou six pages.. ça le fait
Je ne suis pas sûr d'avoir parfaitement saisi votre idée, mais je vais creuser cela à tête reposée. (Après tout, j'ai du sang breton moi aussi ;-)
@+
Marc
Je ne veux pas polluer trop longtemps votre fil avec des questions auxquelles vous avec déjà dû réfléchir et je m'excuse auprès des lecteurs et autres spécialistes d'Indesign
Vous avez laissé ouverte la porte à des approches différentes, je vais parler avec mes mots qui ne sont pas 'techniques' :)
copier/coller des cadres de texte contenant des flux de tableau(x) (avec l’outil de sélection V) n'est pas copier le tableau en entier (ce qui d'ailleurs me semble impossible sans être obligé entrer dans le tableau lui même avec l'outil texte puis de tout sélectionner..etc).
Donc, lorsque vous sélectionnez (V) 1 (ou +) cadre contenant le tableau
Le flux ( le chainage) des pages précédentes et suivantes est ignoré, le résultat collé est un nouveau tableau, réduit à ce qui se trouvait visuellement sur la page. Le cas échéant et suivant votre sélection, on peut conserver le chainage présent sur la page.. mais c'est tout, rien ne va ni ne vient au-delà.
En ce sens, un tableau réparti sur 6 pages, une fois copié/collé, devient 6 tableaux indépendants (1 par page).
Indesign peut éclater un tableau en csv en un éclair
C'est sur ce point que je voulais attirer votre attention.
Le copier-coller d'InDesign possède en effet des propriétés remarquables, du fait de sa capacité à conserver la « photographie » d'une page par-delà la rupture qui s'opère dans le chaînage des blocs prélevés. Et — vous avez raison de le souligner — c'est un point singulièrement spectaculaire dans le cas des tableaux car, lorsqu'un bloc-texte chaîné contient seulement la « séquelle » d'un tableau initié dans un autre bloc, il est VIDE de tout contenu du strict point de vue de la structure objet. (Tout tableau InDesign est « ancré » via un caractère spécial, U+0016, situé dans le bloc d'origine. Notez d'ailleurs qu'il suffit de copier ce caractère pour récupérer et coller le tableau tout entier à un autre emplacement.) Mais le copier-coller du bloc séquellaire s'affranchit totalement de ces considérations et parvient à répliquer l'extrait de tableau, comme par magie, dans un objet neuf et autonome.
Je comprends mieux votre suggestion désormais, même si elle présente encore pas mal de difficultés techniques que je vais vous épargner. Quoi qu'il en soit, c'est de toute évidence une piste à creuser.
Merci de votre excellente contribution.
Marc
Hello again its me (Jannusz with the billing problem).
I'm just after the long talk with PayPal guys. They checked everything and gave me authoritative judge: From your side everything is correct. Probably the script on the page: http://www.indiscripts.com/store/ix...
checking the VAT ID number is wrong, giving the message:
"Ooops! The VAT ID Number is not valid or doesn't match your country."
So what to do?
Maybe I'll send you money from PayPal to you account directly?
Best regards
Janusz
PS Nobody from Poland ever bought the Indexmatic?
Hi janusz
> Probably the script […] checking the VAT ID number is wrong,
> giving the message: "Ooops! The VAT ID Number is not valid or
> doesn't match your country."
> […]
> PS Nobody from Poland ever bought the Indexmatic?
Most of the time our “VAT checker” works fine—and we already have (many!) customers in Poland who successfully supplied their VAT ID.
However, the script depends on the availability of the UE's VAT Number Validation Service (VIES), which might—rarely—fail.
Note: a Poland VAT ID always starts by 'PL' and is followed by one block of 10 digits. Could you please make sure that this field is correct and try again?
If this still does not work, please contact me privately at:
support [at] indiscripts {dot} com.
Regards,
Marc
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
@ 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
I just upgraded to cs 6 .... is there a newer version of indexmatic pro ?
@ 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
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?
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
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
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.
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
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
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
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
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
@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
@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
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.
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
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)
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
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
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
=========================================
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
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
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
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
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
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.
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
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
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
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
@ 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
@ 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
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.
@ 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
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
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.
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.
@ 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
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.
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
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.
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
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!
I would like an author index to search names for first last and put last, first in the index. Is this possible?
Regards
Sorry, I should have looked closer. I figured it out.
@ 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
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.
@ 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
@ 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
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
@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
=========================================
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
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.
Hello
Do your scripts work in CS6 / Mac?
thanks...
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
@ 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
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!
@ 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
Why not indeed! Works well, thanks, just taking first baby steps with these expressions...
merci!
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.
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
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.
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.
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
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?
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
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
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
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
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
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.
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.
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