IndexMatic² | Frequently Asked Questions [UPDATE]
August 29, 2013 | IndexMatic² | en | fr
IndexMatic² 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]
IndexMatic² 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 IndexMatic² (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 | IndexMatic² 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² 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² 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 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 étonnamment « lourd », en raison des boucles de contrôle qui sont exigées par l'algorithme et de la faiblesse inhérente à InDesign dans ce domaine. C'est un aspect que j'évoque dans le manuel d'utilisation et dans la présente FAQ. On va faire le maximum pour améliorer cela dans les prochaines màj d'IndexMatic.
> Concernant l'analyse des tableaux, si ceux-ci sont provisoirement
> 'transformés en texte'. Alors tout est fulgurant.
Ce serait une solution envisageable dans les cas extrêmes — en travaillant sur un document temporaire — encore faut-il s'assurer que la conversion des tableaux en texte ne bouleverse pas la pagination, ce qui n'est pas une mince affaire !
> […] en lisant ce post : http://www.indiscripts.com/post/201...
> je me demande ou en est le biscuit car en effet, obtenir des
> numéros de page cliquables lors de l'export de l'extrait
> en comblerait plus d'un.
Merci de me le rappeler. Je vais faire remonter cet item sur ma « todo list ». Ah ! Si seulement les journées avaient 48 h ;-)
@+,
Marc
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
Bonjour, j'ai une sorte de dictionnaire à indexer, 5000 articles chapeautés chacun par "expression originale / expression traduite".
Je souhaiterais indexer uniquement "l'expression traduite". Comme ce chapeau a un style propre, est-il possible de conditionner l'indexation à la séquence qui commence après 'espace-slash-espace' jusqu'à la fin du style ? parce qu'en fait, le mot traduit comporte parfois 2,3 ou 4 mots... D'avance merci.
Bonjour Stef,
> j'ai une sorte de dictionnaire à indexer, 5000 articles chapeautés
> chacun par "expression originale / expression traduite".
> Je souhaiterais indexer uniquement "l'expression traduite"
1) Lancez IndexMatic.
2) Sélectionnez le style visé dans la rubrique « Style ».
3) Sélectionnez le mode de recherche « Requête unique ».
4) Entrez la requête suivante : / \/ (.+)/W => $1
5) Cliquez sur « Produire l'index ».
@+
Marc
Bonjour,
Est-ce normal que tri latin générique organise l'ordre alphabétique comme si l'espace n'existait pas ? J'ai donc par exemple Chen Gaoyong puis Cheng Conglin puis Chen Guang alors que les Chen devraient être rassemblés... Les noms sont en alphabet latin, y a t il une option que j'ai mal cochée ?
2/ Est-il possible de reprendre l'ordre alphabétique sans générer à nouveau l'index (j'y ai fait des reports images à la main) ?
En tout cas mille mercis pour cet outil qui m'est devenu indispensable !
Cordialement, Camille
Bonjour Camille,
Merci pour ces encouragements.
1) Effectivement, les fonctionnalités de tri d'IndexMatic ne prévoient pas d'option pour classer « mot par mot » les entrées avec espace interne. Du coup, l'algorithme rend l'espace muette et place « Cheng Conglin » AVANT « Chen Guang » (CHENGC < CHENGU). Je prends bonne note de ce problème et vais réfléchir à une solution.
2) C'est là aussi une question importante qui a été évoquée par d'autres utilisateurs : comment maintenir l'ordre des entrées après un ajustement manuel ? Je ne vois pas de solution ergonomiquement simple, sauf à développer une interface additionnelle permettant à l'utilisateur de spécifier un classement ad hoc. Comment voyez-vous les choses ? Lorsqu'un nouvel index est généré, IndexMatic doit de toute façon ré-analyser l'intégralité du document sur la base d'un nouveau jeu de requêtes ; il ne peut rien présumer des termes sur lesquels il va déboucher et il ne dispose d'aucune information sur l'index qui aurait été précédemment produit et réagencé par vos soins. D'où la difficulté.
Il existe peut-être des voies plus simples, ou plus « autonomes », pour traiter les questions que vous soulevez.
D'une part, on trouve chez Peter Kahrel le script Language Aware Paragraph Sorter — http://www.kahrel.plus.com/indesign... — qui propose une option de tri Word by Word. Exécuter ce script en aval d'IndexMatic pourrait vous aider à résoudre la question (1).
D'autre part, si vous vous appuyez sur l'option d'export XML d'IndexMatic, alors il est envisageable de retraiter le flux en aval via une feuille XSLT qui assure le maintien d'un classement personnalisé. Je ne suis pas expert sur ce terrain mais je ne doute pas que cette perspective soit féconde. À étudier.
Cordialement,
Marc
Bonjour Marc,
Superbe outil ! Un grand merci.
Je reviens à nouveau sur ces 2 points :
1/ Envisagez-vous toujours la possibilité de "pouvoir transformer" l'index obtenu avec IndexMatic en index standard d'ID (utilisant la fonctionnalité d'index interne d'ID avec pose de balises d'entrée d'index) ?
2/ Avez-vous des infos concernant la conservation des enrichissements manuels pouvant être faits dans l'index généré ?
Merci d'avance.
Cordialement,
Madeline
Bonjour Madeline,
Merci de m'offrir une occasion de préciser un peu les conditions d'évolution d'IndexMatic, dont la mise à jour a été continuellement repoussée ces derniers mois. (InDesign CC a introduit d'énormes problèmes de compatibilité, surtout en termes d'interface, et c'est pouquoi mon calendrier de développement a autant souffert — pour l'ensemble des produits.)
Je précise au passage que la version actuelle (2.028) est « officieusement » compatible avec les versions CS6 et CC-32bits d'InDesign. En d'autres termes, le script fonctionne mais n'est pas à l'abri de certains bugs, quoique ces derniers restent relativement inoffensifs au dire des utilisateurs.
Concernant les fonctionnalités en attente, elles sont très nombreuses et m'obligent à temporiser.
1) La possibilité de réinjecter le résultat d'IndexMatic sous forme d'index InDesign est à l'étude. Jusqu'à présent, mes tests n'ont pas abouti à des performances satisfaisantes. Je pense, au demeurant, que cette fonctionnalité gagnerait à être détachée du programme et implémentée sous forme de script autonome. (Dans cette hypothèse, elle serait délivrée en gratuiciel.)
2) La conservation des enrichissements manuels introduit deux champs de réflexion :
— L'un concerne l'extension du système de réécriture dans les requêtes elles-mêmes, de façon à permettre notamment une gestion plus minutieuse de la « ponctuation sortante », les questions de casse, les espaces spéciales, les retours à la ligne, l'inclusion des numéros de notes, ainsi que la mise en texte des références croisées. C'est surtout dans ce domaine que nos efforts porteront.
— L'autre versant concerne le traitement des enrichissements stylistiques ou assimilés (italique, etc.). Sur ce point, il me semble que l'export sous forme d'extrait InDesign est l'approche la plus fertile, parce qu'elle permet de préserver parfaitement la mise en style d'un index, en évitant les fastidieux reformatages manuels. Mais le découpage par défaut proposé par IndexMatic dans cette modalité d'export manque encore de granularité. Il serait judicieux par exemple de proposer certains opérateurs de mise en forme des entrées d'index, comme l'italique et le gras qui sont souvent réclamés. À l'étude également.
Dans l'immédiat, je vous invite à explorer les possibilités offertes par les styles GREP d'InDesign. J'ai constaté que de nombreux index pourraient être puissamment prémaquettés par cette méthode.
Cordialement,
Marc
Hello, I recently purchased the indexMatic2 script and it does a great job, but I was wondering if there was a way to have it find names with an InDesign book when they are not on the same line. We have some doctors names that go onto the next line cause of spacing but for some reason it passes up those names if they are not together on the same line.
(Ex: John Doe, MD (it finds this) John
Doe, MD (it won't find these)
The break is not a hard break it's just part of the text flow. Any help would be greatly appreciated.
Thanks,
Jose
Hi Jose,
The expression "John Doe, MD" should be found in both cases—regardless of soft line breaks.
Please, send me a sample doc at: support[at]indiscripts{dot}com.
@+
Marc
Have some index entries: body text and footnotes. The idea is to add the letter n to the footnotes references:
Paris, 13, 18, 24n, 34, 36. 36n, etc.
Indexmatic already generated two files: one for main text and another one for footnotes. How to mix both in a sequential order?
a) It is possible to mix in the index operation both paragraph and character styles? In the tests I am doing they are excluyent.
(Query by word /[\w ]+/)
b) What is the grep in this nomenclature to tag numbers and/or other characters before the entry?
Thank you.
URGENT: I am laying out a 1000 page catalog and need to index the items. In my layout, I have been given the exact text that is to be used as the index items. I have successfully used your script to pull the correct names of the products for the index, but the page numbers are incorrect. The reason they are incorrect is because the index info that I was given is NOT to remain in the layout, but yet I need it for your script to pull the right index names. I have created "Conditional text" in Indesign but in order for your script to pull the right info the conditional text needs to be VISIBLE. BUT when it is visible it REWRAPS the text in the layout making the index information on the "incorrect" page. So my question is what is the best approach for your script? Should I use this "additional/ unprinted" information for the script or for your script do I need to define the index with info within the layout that is going to be used in the final layout? #upagainsttheclock
@ Camilo
#115 Sorry, IndexMatic does not provide any specific formatting for footnotes (so far).
#116 a) When you select both a paragraph and a character style in the Styles panel, they should be 'mixed' in the sense of a logical AND.
b) What are you trying to do? (Keep in mind that lookbehind operations are not supported in JS regex.)
@+
Marc
@ A.N.K.
Indeed, IndexMatic needs to have conditional texts visible to handle them — cf. http://www.indiscripts.com/post/201... — so this is not the right approach to achieve your goal.
Couldn't you place your index markers on a dedicated layer?
@+
Marc
There are two ways to use IMatic.
One, using a queries list.
Other, extracting entries directly from Indesign through styles.
I have in a very long file both ways.
It is exactly the same or do you have a suggestion?
Camilo,
Using query list and specifying styles are not 'exclusive' ways to generate an index. You can use both features, that is, run the queries within the scope of the selected styles.
@+
Marc
Sorry to extent my posts but I am heavily dependent of IMatic as I am indexing a huge book.
Two fast questions:
a) How to index word separated by periods?
I have some entries marked as:
Luise, Anne, Marie
that IM extracts as
Anne, 12
Luise, 12
Marie, 12
But I want Luise, Anne, Marie, 12 (if possible).
Only periods are the joining element.
How to write the grep syntax for this?
b) It has been impossible for me to obtain a list of no sorted entries. I mean, I need for my first list the entries exactly in the same order that appear in page, in that case the first indexed word will be the first one in page 1, and my list will be ordered by number page. Tried all combinations...
Hi again Camilo,
> a) How to index words separated by periods?
If you need to extract ONLY words separated by periods, use the following pattern:
/\w+(, \w+)+/
If you need to extract both single words AND words separated by periods, use the following pattern:
/\w+(, \w+)*/
> b) It has been impossible for me to obtain a list of no sorted entries.
> I mean, I need for my first list the entries exactly in the same order
> that appear in page […]
Let me explain the problem: the concept of “order of entries as they appear in page” makes no sense to IndexMatic. Indeed, you assume here that a page can only contain a single stream of text, which is only a specific case in an InDesign-based layout. As soon as a page contains two text frames, there is no obvious implicit order.
Technically, IndexMatic retrieves words and expressions basing on an extraction engine which is optimized to be fast and efficient. Its main job is to recognize text patterns and entry-to-page relationships in order to produce the index or the “hit report”. (It also computes the “page rank” if needed.) But you can make no assumption about the ORDER those results are collected.
If you only need to extract a word list “with respect to the order” these expressions occur within a specific story or text frame, better is to use the InDesign GREP search engine. [Nota: IndexMatic *does not use* GREP at all, it implements a much faster mechanism.]
You will easily find on the Internet basic sample scripts that illustrate how to query GREP for simple tasks. I also strongly suggest you give a look at Peter Kahrel's “Indexes and Concordances” page:
http://www.kahrel.plus.com/indesign...
Very helpful utilities are provided here that could somewhat extend IndexMatic features.
@+
Marc
Thank for this very good post!
It covers perfectly my enquiries.
Related to the order of entries: I have a book where some entries are:
Henry Brigard and his sisters Andrea, Susan, and Louise traveled to Chile.
My idea is to index the three sisters but they lack the family name. If I use IndexMatic I will have the three entries separate by alphabetical order (only names) and will be difficult to know what family name they have and where they have to be inserted.
But, If I have a list ordered by page it will see immediately that they are linked to Henry and that they ARE Brigard; and very fast, in a manual operation, I can decide how to manage these entries. (Also, they could be seen in the same line with Henry or in the next paragraph return). I think I have at least 200 entries like this!
That is the reason behind the 122 post.
I will check P. Kahrel to have more tools.
Thanks again for your help.
Camilo
Am indexing a large book with Biblical book names in it. How can I get Genesis and Gen. references to show up in the same entry vs. two entries.
Winn
Hi Winn,
> How can I get Genesis and Gen. references to show up
> in the same entry…
Type the query as follows:
/Gen(esis|\.)/I => Genesis
Regards,
Marc
Thanks Mark,
I'm a bit of a novice at this. The above query worked to accomplish what I needed.
Can you run the script and get the results in the order that is listed in Query List in this case Genesis, Exodus, Leviticus, Leviticus, etc.
Thanks
Winn
oops! My Bad! Marc
Winn
Marc,
I think the answer to my above question (#127) is in #123 above.
Thanks,
Winn
@ Winn
> I think the answer to my above question (#127) is in #123 above.
Indeed ;-)
Marc
How do I create this format
Animals
...Dogs 3
......Brown 4
......Black 5
...Cats 6
......Orange 7
......Stripped 8
using the Query-based option? The periods represent indentation since the spaces didn't show up in my preview.
Thanks!
@ ck
For the time being IndexMatic does not provide topic grouping at the 3rd level. As shown in the manual you can specify TOPIC > SUBTOPIC relationship (e.g. Animals > Dogs), but the syntax X > Y > Z is not supported.
@+
Marc
Bonjour,
Je découvre Indexmatic dont je pense qu'il peut me faire gagner beaucoup de temps sur la production d'un très gros index mais mes premiers essais ne fonctionnent pas comme je m'y attendais.
Dans un document, je souhaite indexer toutes les expressions ayant un style de caractère donné: "I. glandulifera", "I. balfouri", "I. parviflora", "I. noli-tangere"
Comment faire pour qu'Indexmatic ne considère pas "I." d'une part et "glandulifera" d'autre part comme étant deux entrées d'index séparées (avec pour conséquence que "I." n'est pas indexé puisqu'il ne contient pas le minimum requis de 2 caractères)?
(Le problème se pose aussi avec "Impatiens glandulifera", chacun des mots est indexé séparément).
Je précise que le style de caractère est appliqué aux espaces incluses dans chaque expression.
J'imagine que la solution réside dans une requête (mes essais étaient en automatique) mais je ne trouve pas comment dire "Style de caractère: style1" + "n'importe quelle chaîne de caractères".
Merci pour votre aide.
Bonjour Julien,
Après avoir sélectionné le style de caractère cible, passez en mode « Requête simple » et saisissez l'expression régulière suivante :
/.+/
Cordialement,
Marc
Bonjour Marc,
Merci pour cette réponse rapide et efficace.
J'ai encore une question: je fais un test sur une page et quand je sélectionne [Pas de tri], les entrées sont listées dans l'ordre inverse d'apparition. Y a-t-il moyen de lister les entrées dans l'ordre du texte?
Cordialement,
Julien
@Julien
> Y a-t-il moyen de lister les entrées dans l'ordre du texte?
Ce point a souvent été abordé par les utilisateurs — cf. notamment #123 b) ci-dessus. Je traduis ma réponse en français :
Bien qu'elle apparaisse évidente à l'intuition, la notion d'un ordre implicite des entrées « telles qu'elles se suivent dans le texte » n'est pas définie pour IndexMatic.
Cela présupposerait tout d'abord qu'une page ne puisse contenir qu'un seul flux de texte, ce qui constitue seulement un cas particulier de mise en page. Sitôt qu'une page comprend au moins deux blocs, l'ordre du texte devient incertain.
Techniquement, la capture des mots ou expressions via IndexMatic repose sur un algorithme d'extraction visant à la fois la vitesse et l'efficacité. L'essentiel du travail consiste à détecter des motifs textuels et à établir la correspondance entre les entrées d'index et les numéros de page. (Sans parler d'autres calculs tels que le « page rank », etc.) Compte tenu de ce mode opératoire, aucune hypothèse ne peut être faite quant à l'ORDRE selon lequel les résultats sont collectés.
Dans le cas où vous souhaitez seulement extraire une liste d'expressions selon leur ordre d'apparition au sein d'un bloc-texte ou d'un article spécifique, il me semble plus judicieux d'utiliser le moteur Grep d'InDesign. [N.B. — IndexMatic *ne sollicite pas* les fonctionnalités Grep.]
On trouve sur le Net de bons exemples de scripts illustrant l'emploi de Grep pour des tâches simples. Je vous invite tout spécialement à visiter la rubrique “Indexes and Concordances” de Peter Kahrel :
http://www.kahrel.plus.com/indesign...
Y sont proposés de nombreux utilitaires qui me semblent de nature à combler les « manques » d'IndexMatic.
P.S. — J'ajoute aussi pour les francophones le site http://indigrep.com/ de Laurent Tournier.
Cordialement,
Marc
Have some entries already finished like:
Louise Marianne Gaulois Mauriac
that sometimes may appears reduced as:
Louise Marianne Gaulois.
But generating the index IM only catches the whole «Louise Marianne Gaulois Mauriac», not the lesser one, without Mauriac. This shorter one is lost in the output.
How to modify the menu to obtain both results?
Thanks.
Hi Camilo,
What about the query:
Louise Marianne Gaulois => $ Mauriac
?
Hi Marc,
My point is not well explained...
My list comes from a different file with full names like Louise Marianne and composed parent names like Gaulois Mauriac.
If I use this list as a query list (/[\w ]+/) IM only find when the same four words are the document. Am I wrong?
I need a general query where IM recognises when the name is identical but lacking one word. For example, that catches also Louise Marianne Gaulois although Mauriac is NOT in the document to be indexed. (Sometimes that girl LMGM may be present in the file with four words and IM gets her!)
Thanks for your fast reply!
Dear Mark,
Does indexmatic working with InDesign CS6 (version 8.0.2) as well.
Cheers
Laszlo
@ Camilo
The query I suggest is:
Louise Marianne Gaulois => $ Mauriac
so it will find any occurrence of "Louise Marianne Gaulois"—including those that also precede "…Mauriac"—and then index all these locations as
$ Mauriac
that is, "Louise Marianne Gaulois Mauriac".
In other words, the KEY expression is LMG and the final ENTRY is LMGM. This should address your specific issue.
Now there is no way to make this rule generic. If you ask iX to grab partial expressions, you need to explicitly specify the full index entry. If you use a generic regex like /[\w ]+/ then the script has no way to 'guess' missing or implied terms.
=============================================
@ Laszlo
IndexMatic is officially CS3/CS4/CS5 compliant, and unofficially CS6 compliant. As far as I know CS6 is well supported, although iX has not been specifically updated for that version. The best is to test the TRY version on your platform anyway.
Regards,
Marc
@Marc,
Perhaps duplicating the list and reducing the four words entries to three words, eliminating the last one, will output all the entries that lat may be easily checked. Alo this grep may be in ome way adapted to the four word entries. Thank you.
@Laszlo
Indexmatic is working perfectly in CC and Maverick.
Hi Marc,
I'm using CS6 and can generate an index, but it is only generating it for the letter A. Can you help please?
Thanks, Jac
@ Jac
Are you using the TRY version? (It's limited to 50 entries per index.)
@+
Marc