Indiscripts

« Optimiser InDesign pour les documents longs »

Wed, 20 Sep 2023 12:37:00 +0200

Parution imminente d'un nouveau livre-arsenal de Laurent Tournier : Optimiser InDesign pour les documents longs — Avec les scripts et le GREP. Si vous pensiez à une aimable mise en jambes agrémentée de quelques points de doctrine, vous êtes loin du compte ! Le PDF que l'auteur nous a communiqué en primeur recense plus de 200 scripts du monde entier, tous testés en situation, et le même volume de commandes GREP couvrant les problématiques les plus étendues. L'idée était déjà géniale en soi, mais la mise en œuvre, par sa densité et sa précision, fait tomber à la renverse…

D'entre nous, les plus impénitents n'ont pas oublié qu'InDesign permet de composer des livres. Du lourd, du massif, du plantureux. Saviez-vous qu'un document individuel peut contenir 9999 pages, et que le système de numérotation tolère des folios jusqu'à 999999 ? Si vous souhaitiez accoucher d'une encyclopédie de l'ampleur de l'Universal-Lexicon de Zedler, ce serait presque techniquement possible avec InDesign. (Je dis presque parce que je n'ai pas vérifié.)

Sauf que le document long pose des problèmes qu'on ne rencontre guère à l'échelle du dépliant ou du magazine municipal. Le volume de textes, d'illustrations, de tables, de notes, d'annexes et de liens internes crée une sorte d'entropie dans les fondations de l'ouvrage. On ne peut plus contrôler tout ça d'un simple coup d'œil. Et la moindre modification architecturale, le plus infime revirement de choix typographique, aura des conséquences au fin fond de vos blocs de mise en page. Plus vous barbotez dans l'arrière-cuisine, moins vous vous sentez les coudées franches pour manœuvrer. Comme si ce satané document ne tenait finalement debout que par l'opération du Saint-Esprit.

Atelier d'expert

Il fallait apporter à ce métier, non pas un guide de maintien bouffi de théorie, mais un manuel de survie en milieu instable, avec des solutions éprouvées (par l'auteur) quoique méconnues (du lecteur). Laurent Tournier a eu cette idée fracassante : poser un miroir sphérique au milieu de son atelier de metteur en pages et enregistrer jour après jour les gestes qu'il y accomplissait, les outils dont il s'emparait, commandes, scripts, expressions régulières.

Son expertise parle pour lui, il a déjà signé un guide de référence (le seul en langue française) décortiquant le Grep InDesign et ses prodiges. Cette fois-ci, il nous fait carrément visiter la salle des machines ! Tambour battant, Optimiser InDesign pour les documents longs explore quelque chose comme 200 scripts et plug-ins, et autant de modèles Grep, dans tous les domaines éditorialement cruciaux : import Word, traitement des images, correction ortho- et typographique, gestion des polices, contrôle et application des styles, suivi de maquette, tableaux, indexation, bibliographie, formules mathématiques, rétroconversion. On n'est pas sur du menu vegan à douze calories, l'image qui vient en tête est plutôt celle du banquet final de La Grande Traversée !

Encyclopédie scriptique

Voilà donc une encyclopédie concrète, unique en son genre, qui vous fait palper toutes les étapes de l'automatisation InDesign, coins et recoins, sans s'attarder sur les fioritures mais donnant toujours le lien ou l'astuce de secours. Au passage, l'auteur fait la part belle aux développeurs de scripts (ses appréciations et l'index final témoignent de sa gratitude à leur endroit) — c'est un soin qu'on ne saurait bouder à une époque où le pillage anonyme se donne des airs de révolution culturelle.

Vendu une bouchée de pain au format PDF, ce livre numérique s'adresse bien sûr aux maquettistes exécutants, auxquels j'ajouterai les éditeurs éclairés qui mettent les mains dans le cambouis, notamment les universitaires. Serait-il traduit en anglais qu'il deviendrait instantanément un best-seller. C'est d'ailleurs tout le mal qu'on lui souhaite.

• Optimiser InDesign pour les documents longs, Laurent Tournier, PDF (237 pages), 2023, 15 €, à paraître sur indigrep.com.

• Voir aussi :
— GREP et InDesign (2e éd.)
— Toutes nos chroniques de livres.

IndexMatic³ | Frequently Asked Questions

Sun, 10 Sep 2023 17:34:00 +0200

With its hundreds of interconnected features and its documentation erected in front of you like a Gothic cathedral, IndexMatic³ will undoubtedly inspire you with this fateful question: where to start? And we often start with something concrete, a specific problem that needs to be solved right now. The purpose of this page is to guide you quickly and clearly into the inner workings of the program, from the questions most frequently asked to the tech support…

1/ General Points
    Learning IndexMatic³
    IndexMatic³ vs. IndexMatic²
    Upgrade Discount Price
    Creative Suite Backwards Compatibility
    Using a Credit Card thru PayPal

2/ Scope & Search Options
    Autoextracting a Vocabulary
    Matches and Page Rank
    “Whole Word” and Regular Expressions
    Conditional Text
    Inner Spaces and Whole Words
    Automatic Mode vs. Query modes

3/ Basic Queries
    Regex Syntax: the / Prefix
    Uppercase Letters and Diacritics
    Term Rewriting / Subtopics / Cross-References
    Dealing with Plural Forms
    Queries and White Spaces
    Website Names, URLs
    Key Length / Grouping Alternatives
    Meaning of the "\w" Metacharacter
    Extracting XML Data
    Special Space Characters
    Generic Apostrophe
    Consolidating Terms into a Single Reference

4/ Proper Names
    Proper Names vs. Acronyms
    Reformatting a Name List
    Redundant Matches

5/ Advanced Queries
    Punctuation
    Stats on Letters
    Using the "$" Symbol
    Emojis
    Arabic Diacritics

6/ Output
    XML Output
    Bypass Sorting
    Multiple indexes

7/ Limitations and Known Issues
Preserving Text Formatting
“Indirect” Character Styles

1/ General Points

Learning IndexMatic³

• IndexMatic³ sounds easy to play with, but not-so-easy to master. Is there a good step-by-step instruction on how to use advanced features?

Your central, unique, official learning place is the user's guide (PDF, 110 pages), which is provided in both English and French language. This documentation has been designed to guide you from the basics (getting started, purpose, UI) to the next level, including technical information on managing “scoped” documents, using the query interpreter, mastering regular expressions, shaping the output index with respect to your needs, and so on.

Becoming an IndexMatic³ expert does not require considerable time, but essentially concentration. Read the manual calmly, gradually, without being distracted by notifications from your smartphone or social networks! The concepts will fall into place little by little, your tests and queries will become more fruitful, more sensible, more efficient. You will then carry out tasks that you did not even imagine possible at the start of your training.

→ Our YouTube channel also offers more targeted tutorials for French-speaking audience.

More concrete examples and case studies will be addressed in this FAQ!

→ IndexMatic³ Manual (PDF)

IndexMatic³ vs. IndexMatic²

• I am an experienced IndexMatic² fan. I have been using it for years to offer my clients (mainly publishers) an additional tailor-made indexing service. Can I reuse in iX³ the wordlists and queries I prepared in iX²? If so, why should I upgrade to the new version?

All what you did with IndexMatic² can be done with IndexMatic³. The fundamental query syntax definitely remains, it has only been augmented with new schemes like “Generic Hyphen”, “Directives”, “Topic Formatters”, “Stop Word Flag”, etc. So, yes, iX² queries and query lists should still work fine: just make sure they do not contain special codes that are now parsed as syntactical operators. For an overview, see Topic Structure Cheatsheet, Metacharacters, and Query List: Directives.
Indiscripts' policy has never been to push its customers into unnecessary or captive spending ;-) Our products are subscription-free and our licenses are perpetual (at least, as long as InDesign can run the underlying script.) So, if you love IndexMatic² and feel comfortable with it, if it still meets all your expectations in the field of indexing, there is no reason to change (and we will keep it in our catalogue — although without new updates). The reasons why we redesigned IndexMatic were summarized in the 2023 announcement. To put it in three words: speed, efficiency, ease of use.

→ Migration from IndexMatic² to IndexMatic³ (chart)

Upgrade Discount Price

• I've been using IndexMatic² Pro for years. Can I get the new version for less than the full price since I previously purchased an older version?

When upgrading to IndexMatic³ (Expert), IndexMatic² Pro users have access to a privileged discount which reduces the standard license price by €50—so they only pay the difference! This offer applies to single licenses as well as multi-seat licenses. The procedure is detailed in the IndexMatic Upgrade Page.

Basically, you need to find your (original) iX² “Download Link” in order to deduce your discount code. If you accidentally lost the URL, simply get in touch with us at support[at]indiscripts{dot}com and provide enough details (invoice number, company name, email address…) so that we can retrieve the original order.

→ IndexMatic Upgrade Page

Creative Suite Backwards Compatibility

• I refuse to pay a subscription to Adobe and I still work — fully satisfied! — with InDesign CS6. Does IndexMatic³ support this environment? (Any plan to make it available in Affinity Publisher too?)

1. IndexMatic³ has been rewritten from scratch taking into account features introduced in the latest versions of InDesign CC (i.e, versions 9.x to 18.x), but we made it our business to maintain backward compatibility up to 6.x. That is, the program still runs in InDesign CS6, CS5, and CS4, supporting both macOS and Windows platforms. This is a key advantage compared to competing solutions and we dearly wish to preserve it!

Note. - Of course, because some features (hidden blocks, endnotes, etc) are just missing in older InDesign versions, IndexMatic³ won't include them while running in such environments.

2. Although extensibility solutions are being explored at Serif Labs in 2023, it is difficult to predict how quickly they might mature. As of this writing, there is no solid prospect for us to consider porting IndexMatic³ to Affinity Publisher.

→ IndexMatic³ System Requirements

Using a Credit Card thru PayPal

• I attempted to make a payment by using my pro credit card (without logging into a PayPal account) but the system rejected the information and returned “the credit card cannot be used for this payment”.

It happens that PayPal rejects your credit card, or even does not offer you this payment option. Highly frustrating! And no one knows the comprehensive criteria for this rejection.

It seems that the country you are purchasing the product from is sometimes the culprit, which could cause the problem to appear when using a VPN. According to other sources, similar issues may arise if your credit card, or your email address, is linked to an active PayPal account which you're not logged in. Also, PayPal has limits on non-member credit card usage for security.

Whatever the reason, creating a PayPal account and adding your credit card to it as a funding source can obviously solve the problem. But we understand very well that this approach is unacceptable if you simply do not want to have a PP account!

Note. - We are actively seeking alternative payment solutions (provided they offer the same level of security as the PayPal interface and do not penalize the customer).

Anyway, if any difficulty arises during the transaction, do not hesitate to contact us directly at legal[at]indiscripts{dot}com to set up a direct payment option by bank transfer.

→ IndexMatic³ Order Form

2/ Scope & Search options

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³?

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. Select the book chapters in the Target Documents list. In the Finder panel, set the Page Rank to 3 or 4. Also, select the appropriate language in the Stop Words list. Ctrl-Click the Hits button to open the Hits and Stats dialog, set all display fields to [None] except the “Entry Term” field. Click OK. This generates a wordlist that you can easily grab, cleanup and use as a starting point in Query List mode.

→ Customizing Hits and Stats ; Grab Hits Data

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?

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

→ Page Rank

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

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 Finder > Options (so that the flag is globally disabled).

(b) Append the local flag W at the end of your pattern:
/\\index\{([^}]+)\}/W => $1

→ Whole Word

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)?

Regarding conditional text, IndexMatic³ simply considers the contents wich is enabled at the moment you launch the program. So, just activate the condition that corresponds to a specific language and you get the related index.

→ Off-Page Content and Ignored Elements

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?

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))?/

→ Whole Word

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 compound 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?

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 “letter sequence in 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+/

→ How to Create an Index from a Style

3/ Basic Queries

Regex Syntax: the `/` Prefix

• I'm trying to find a regex expression: everything inside curly brackets. My query is `\{.+?\}` and the script finds nothing. Where is my mistake?

Do not forget the / character at the beginning of a regex query (IndexMatic³ both supports literal and regular expressions).

Hence your complete query is: /\{.+?\}

→ Introduction to Regular Expressions

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?

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

→ Metacharacters ; GREP-like Operators

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?

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 => France

Finally, our complete query list could be:

   // Bordeaux => France
   // Paris => France
   /Paris|Bordeaux/ => France > $0

→ Cross-References

• 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?

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” as a formal subtopic:

// FRANCE > Paris => PARIS

Now consider a query list having the following lines:

    ...
    FRANCE
    PARIS
    // FRANCE > Paris => PARIS
    ...

The final index will look like:

    …
    FRANCE: page numbers
        Paris: See PARIS
    …
    PARIS: page numbers
    …

→ Cross-References ; “See” and “See also” Markers

Dealing with Plural Forms

• Given a list of words in singular form, is it possible to capture both the singular and the plural forms?

1. 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 easier 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[ae]n/ => woman
    /person|people/ => person
    etc.

Note. - In Query List mode, activate the “Magic Regex Term” button to avoid rewriting the term of simple regexes: the query /cats?/ alone will then automatically produces the expected term (“cat”), as well as /wom[ae]n/. See Magic Regex Term

2. But there is even more! You can transform a list of simple words, assumed to be singular, so that it systematically generates the corresponding query patterns. Let's start from the list:

cat
dog
snake
rabbit
horse
. . .

It will be assumed that all the elements thus referenced have a simple plural of the form +s. Then we can use the ~format directive do have the job done in just prepending one instruction to the query list:

//~format :: /^0s?/ => ^0
cat
dog
snake
rabbit
horse
. . .

This structure will detect both singular and plural occurrences, while assigning them a single, consistent index entry (that is, the singular form).

→ `format` directive

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?

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.

→ Generic Space

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"?

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\.)\S+/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 Hits report and build an improved query list that considers both website names and URLs.

→ Introduction to Regular Expressions

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?

The maximum length of an IndexMatic³ regex is no longer limited, so it actually depends of what the subsystem (that is, ExtendScript) can digest. We have not tested all environments, but it is likely that beyond 1,000 characters the interpreter will struggle. This still allows you to write very complex regular expressions. Should you reach the limit, a solution is to use a regular Query List:

    John => Authors > $0
    Bill => Authors > $0
    Kate => Authors > $0
    ...

Note. - And an even better solution is to simply use the ~format directive at the top of the “John¶Bill¶Kate...” list:
//~format :: ^0 => Authors > $0

You can still optimize the list using grouped alternatives. For example:

According to our tests, the regex engine gradually loses speed when the pattern involves a huge number of alternatives, to the point that it becomes more efficient to run separate queries performing exactly the same function!

→ Alternatives

Meaning of the "\w" Metacharacter

• What is the exact scope of the `\w` metacharacter?

The \w metacharacter automatically fits the current alphabet: it matches any character of the selected alphabet, and optionally matches the hyphens, digits, apostrophes, and/or the underscore — depending on the checked boxes in the Alphabet field.

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 “Digits” and “Underscore” switches. Otherwise, you can still use the character class [a-zA-Z0-9_].

→ Alphabet

Extracting XML Data

• Is IndexMatic³ able to parse text like:
"...New Orleans..."?
And is it possible to extract the attribute as well? Like:
"...New Orleans..."

To capture the content of the element, send the following query:
/([ \w]+)<\/index>/ => $1

And to capture the attribute:
// => $1

Note that a more advanced query (labeled “XML Tags” in the Favorites list) can even capture generic patterns of the form ... and produce the associated “tag > content” topic structure. Here is what it looks like:

/<([a-z][a-z0-9-]*)>([^<]+)<\/\1>/iW => $1 > $2

→ Saving/Restoring Favorite Queries

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?

Simply enter the explicit character class:
[~<~|] (GREP syntax), or [\u2009\u200A] (Unicode code points).

Note. — Whatever the Generic Space settings, IndexMatic³ alway considers the special characters you specify.

→ GREP-like Metacharacters ; Generic Space

Generic Apostrophe

• How to perform a simple search on a text containing both the ASCII apostrophe `' U+0027` and the typographic apostrophe `’ U+2019` ?

IndexMatic³ does not natively provide a generic apostrophe feature, but it's super-simple to write your queries as if it did: just use the special class ['] in your regexes. This code is interpreted as [’'] and will therefore capture both forms.

Note. - From a query list, it is then possible to forcibly output the typographic apostrophe by enabling the Magic Regex Term.

→ GREP-like Operators

Consolidating Terms into a Single Reference

• I have two terms that I would like to consolidate into one reference:
   1) Brahma
   2) Mahabrahma
The outcome I would like is that the index displays as follows:
   Brahma See Mahabrahma
   Mahabrahma 279, 293-295, etc
How should I proceed?

The merging query is

/Mahabrahma|Brahma/wI => Mahabrahma

(using both the whole-word flag /w and the case-sentitive flag /I.)

And the cross-reference is:

// Brahma => Mahabrahma

→ Cross-References

4/ Proper Names

Proper Names vs. Acronyms

• I am a genealogist, and my books have many people's names. I tried using the “Acronyms” query from the list of favorites. The result gives me many abbreviations without surnames. (People commonly used initials instead of given names in the 1800s.) For the instances where I have the abbreviations, the surname is not picked up in indexing. What should I do?

Dealing with proper names primarily depends on how your InDesign document is structured. The built-in favorite queries only provide generic patterns to give you some examples of using IndexMatic³ regular expressions. But it is usually necessary to adjust these commands according to the actual text found in the document, how it is commonly formatted, etc.

First, suppose you have a dedicated character style applied to the target names. It is then extremely easy to recover all the names regardless of their particular formatting (using the /.+/ query). And from the collected set, as typically extracted by the Hits feature, you can then study the different patterns in a systematic way — e.g. “John Doe”, “J. Doe”, “J. K. Doe”, “J. McDoe”… — and decide which of them will require some fine-tuning.

— There are cases where you want to re-use the /.+/ hits as a fresh, literal query list, because you need to add KEY => TERM rewriting rules that entirely depend on your expectations. For example, you have to add birthdates to the index and this information is not directly accessible in the InDesign document as it comes from a separate database.

— There are other cases where the whole structure is available in the /.+/ hits extracted from the text, but now you need to discriminate patterns like “John Doe”, i.e. \m\w+ \m\w+ and “J. Doe”, i.e. \m\. \m\w+. Then your original /.+/ single query should be exploded into sub-forms that will perform the required transformations — which also involves a query list, but made up of regular expressions.

The “Acronyms” query is just one particular component that may be involved here. It captures either simple uppercase sequences (“ABCD”), or strings of the form “A.B.C.D.”, “A. B. C. D.”, “A B C D”, or any mixed pattern:

/\m(?:\.?\ ?\m)+\.?/Is

But this is obviously insufficient to extract surnames. Maybe there wouldn't be much to change for it to work. Let's try this:

/\m(?:\.?\ ?\m)*\l+/Is

Does it look better? I imagine so, but again, it all depends on the source text. My main point in this discussion is that there is no one-size-fits-all answer.

→ IndexMatic³: The Big Picture ; Metacharacters

Reformatting a Name List

• I have a list of several hundred names in alphabetical order: “Arrabas, Jacques¶Burton, Robert W.¶Dupont de Boismont, Hyppolite¶etc. How to process it as a query list?

In most situations involving proper nouns, the central question is: in what form is the key element I am looking for in the document? And secondarily, which index entry to associate with it?

The specific part (the KEY) is usually the last name. Aside from genealogy books which require more careful queries, it is generally sufficient to identify that element in the text to produce the desired index entry. So, on average, we want to extract case-sensitive matches like “Arrabas”, “Burton”, “Dupont de Boismont” and generate the respective full terms that will then include the first name (in whatever form).

(If this general scenario encounters exceptions, they will be dealt with separately, on a case-by-case basis.)

Now consider the list initially provided:

    Arrabas, Jacques
    Burton, Robert W.
    Dupont de Boismont, Hyppolite
    . . .

What we want is to take the part before the comma as a search key (alone, case sensitive), and then produce a term absolutely identical to the entire input. For example,

Arrabas/I => Arrabas, Jacques

But we don't want to carry out this tedious transformation by hand on hundreds of lines! So we keep the list as it is, and put a hat on it: the magic format directive.

//~format /[^,]+/ :: ^1/I => ^0
Arrabas, Jacques
Burton, Robert W.
Dupont de Boismont, Hyppolite
. . .
// here hundreds of ", " lines

Now suppose that the “Burton” element is not OK, because we have to deal with both “Robert W. Burton” and “Nadia Burton”. Alright! We remove that particular line out of the scope of the format directive and we create a more elaborate query for it, maybe

/(Nadia) Burton|Burton/I => Burton, {$1:Robert W.}

which means: “If "Nadia" is found just before "Burton", then we're talking about Nadia Burton, otherwise our item is, by defaut, Robert W. Burton.”

And the final query list is then:

//~format /[^,]+/ :: ^1/I => ^0
Arrabas, Jacques
Dupont de Boismont, Hyppolite
. . .
Zipf, George Kingsley
 
// Special cases:
/(Nadia) Burton|Burton/I => Burton, {$1:Robert W.}
. . .

Note that a simple empty line stops the format directive.

→ Directives ; Ternary Operator

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?

Since ExtendScript 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+).

→ Greedy and Non-Greedy Quantifiers

5/ Advanced Queries

Punctuation

• What is the most generic way to indicate a punctuation character in a regular expression?

The Unicode metacharacter \p{P} will capture any punctuation sign. Some refinements are available.

→ Unicode Properties

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 “Hits” feature?

1. Enter the following (single) query:
/\p{L}/IW!

Note. - The special flag ! locally deactivates the “Stop Words” mechanism.

2. Ctrl-Click the Hits button.

3. Make the Entry Term and Frequency fields visible.

4. Click OK.

Note. — The \p metacharacter is never affected by the Alphabet settings, you can always use it to search characters from their Unicode properties.

→ Adding Local Flags ; Unicode Properties

Using 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?

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.

→ $-Variables

Emojis

• My recipe book contains emojis (EmojiOne font) that typically range from 🍄 (U+1F344) to 🍿 (U+1F37F). I use them to extract the category of the word that immediately follows, so my queries need to use patterns like /([🍄-🍿])(\w+)/=>$1>$2, or so. But IndexMatic³ will not find my items, why?

1. Unicode characters reflecting emojis are beyond the Basic Multilingual Plane (BMP), that is, they involve codepoints higher than U+FFFF. These cannot be integrated into a regex character class, because they are then interpreted as the UTF16 surrogate pair they contain. E.g, [🍄-🍿] just means [\uD83C\uDF44-\uD83C\uDF7F] to the interpreter, which is obviously not what you want to express.

The solution is to systematically describe the sets of emoji within an alternation structure of the form (a|b|c|...). This requires the characters to be given exhaustively, but it's the only way to provide them to the regular expression engine.

In your case, since the set of icons is known and fixed — say 🍅, 🍆, 🍇, 🍈, 🍉, 🍋, 🍐, 🍞 — you can use the query:

/(🍅|🍆|🍇|🍈|🍉|🍋|🍐|🍞)(\w+)/ => $1 > $2

2. But there is an even more expert approach. If the target emojis have consecutive code points — as in your example U+1F344 MUSHROOM — U+1F37F POPCORN — you can usually factor out the first UTF16 component (here \uD83C) and create a very compact regex of the form (\uD83C[\uDF44-\uDF7F]) which actually covers all food-related emojis. Hence the full query:

/(\uD83C[\uDF44-\uDF7F])(\w+)/ => $1 > $2

Note. - A good reflex is to save your discovery, (\uD83C[\uDF44-\uDF7F]), as a favorite query e.g “Emoji Food”.

→ Codepoints (Unicode ; Saving/Restoring Favorite Queries

Arabic Diacritics

• In Arabic, IndexMatic³ missed around 100 words that happens to have a Shadda. How to fix this?

Short answer: with “Arabic” selected in the Alphabet list, use the class [\w\p{Mn}] instead of \w when you need to target special diacritics such that the Shadda mark.

Why is this so? Well, U+0651 ARABIC SHADDA is not part of the basic set of Arabic letters in IndexMatic³, which explains why \w does not recognize it. My source for defining letters in different scripts is the Unicode standard. According to Unicode, U+0651 is not a letter (although it belongs to the Arabic block), it is rather a Nonspacing Mark (Nm) that inherits its script property from the preceding character. More precisely, it is a diacritical combining mark used with the Arabic alphabet and mainly available to Arabic and Syriac texts.

Thanks to your message, I'm now familiar¹ with the fact that Arabic texts may require such additional non-letter characters to have some diacritics properly specified and rendered.

¹ That's not a well-known fact from a Latin-centered language speaker like me :-/ In French, for example, all usual diacritics are already integrated in the set of Unicode letters, e.g ‘É’ is a single character (U+00C9 LATIN CAPITAL LETTER E WITH ACUTE). It is true that we can also specify the glyph ‘É’ by combining the letter E with the acute accent (U+0301 COMBINING ACUTE ACCENT), so one formal letter and a diacritical combining mark are used, but most of us are not aware of that option — which Unicode describes as a Canonical Decomposition (NFD).

Now, should we add Combining Diacritical Marks to the sets of IndexMatic letters? By default, we certainly shouldn't. In many languages, that's not what the user expects. The main reason is that a combining mark, alone, is not a letter and could be used with arbitrary characters that are not letters either. However, the issue you've reported shows that including combining marks might be an option... and such an option is definitely relevant in the case of Arabic language!

Workaround. - Technically, we already have the ability to use the composite class [\w\p{Mn}] instead of \w when dealing with Arabic letters. This way, a word like

الصّبي

processed through the query /[\w\p{Mn}]+/ will be properly identified, while /\w+/ would split it into two invalid forms:

الص
بي

But I now understand that it would be much more practical to override \w so it could already capture the Shadda as well. The solution I'm considering is to add an option “Include combining diacritical marks” to the Alphabet selectors (those that allow you to selectively include digits, hyphens…). At the moment this is a pending feature.

→ Alphabets ; Unicode Properties

6/ 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?

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.

→ XML Output

Bypass Sorting

Is there a way to index without sorting the results (alphabetical or otherwise)?

What you are looking for is the “Keep Original Order” button. It is available in Finder > Query List mode.

→ Keep Original Order

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?

1. Basically, IndexMatic³ does not manage multiple indexes at the same time. You can configure options/queries first to build the PLACES index, then you want to re-run the script and apply new settings in order to create the NAMES index, etc. Switching to specific prepared wordlists should help you to quickly achieve these tasks.

2. Another interesting 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...

→ Nested Topics ; Exporting and Re-Importing Settings

7/ Limitations and Known Issues

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.

Sorry, no. IndexMatic³ is primarily a text-driven search engine and it does not keep track of applied formatting.

Note that 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?

Note, however, that IndexMatic³ offers you very granular control of the styles generated in IDML or InDesign output. This makes it possible to post-process many formatting attributes for terms and headings (H0, H1, H2...), page numbers, separators, etc. In practice, many iX³ users take advantage of InDesign's GREP styles to adjust the typography of specific elements.

→ Predefined Output Styles

“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?

IndexMatic³ indeed does not inspect indirect styles, it only considers formal Character and Paragraph styles, whatever the way they are enriched or overridden.

A workaround is to use a companion script that converts local formatting to pure character styles. Some tools were reviewed in this post from CreativePro: “Free Scripts Help Fix Word Formatting”.

→ Style Overrides

Do you have a question to add? A bug to report?
Let's get in touch → support{at}indiscripts[dot]com

Claquos | Apply the "Buoy” Effect to your Charts

Sat, 19 Aug 2023 19:07:00 +0200

When you create a pie chart with Claquos, the script makes no special assumptions about which Object Style to apply, either to individual slices or to the entire group. It only takes control of fill colors and stroke model. That is, you can freely apply styles, effects, or other settings to your chart.

Even better, you can preset multiple effects within an object style and apply it uniformly to the group created by Claquos. This step-by-step tutorial shows you how to proceed.

I — Create your Object Style First

Before running Claquos, create an object style that will be dedicated to the resulting group. I say the resulting group, because the buoy effect we're trying to achieve uses shadows and bevels for the entire graph. That's why I called this style “BuoyFx-Group”.

1. The first thing to do is disable all Basic Attributes, except maybe the Stroke & Corner Options if you want to control and refine these settings:

2. Optionally, in Stroke & Corner Options, adjust Join and End Cap to slightly improve the roundness of the dividing lines:

3. Select Effects for Object and set the global Transparency. Usually you just want the default, normal blending mode, with a 100% opacity:

4. Still in Object mode, uncheck all effects except Inner Shadow and Bevel and Emboss. In our example inner shadows only produce a very slight fill effect (not the main effect), so keep Opacity low and adjust Angle and Size to subtly diffuse the shadow:

5. Still in Object mode, go to Bevel and Emboss. What we want here is a smooth inner bevel in Up direction. Better is to have a gray oval template available in your InDesign document while adjusting these settings, so you can control how Size, Soften, Angle and Altitude will affect the result with respect to the average dimensions of your pie charts:

6. As the ultimate refinement, go to Effects for Stroke and disable all effects, except the Basic Blending of the global Transparency section. For my part I switch to Overlay mode and significantly reduce the opacity (25%). Thus, whatever the Stroke model selected in Claquos, the separation lines on the buoy will be less marked and will look more like slight seams:

Check the result on a typical object of the dimensions of your project:

II — Deselect the Style and Run Claquos

Since the “BuoyFx-Group” style we have juste created is not meant to operate on internal pies, it is not a good idea to have it applied to the original pattern that needs to be transformed by Claquos. Better is to have [None] or [Basic Graphics Frame] selected at this stage—unless you otherwise have a particular style to apply to individual pies, but this is still a distinct question. By default, the program will just repeat the style and settings possessed by the template.

Once your data are loaded, go to the Layout panel and set Rounding to at least 20% (or maybe a little more) and uncheck “Outer arcs only”. This emphasizes the round, soft texture of the buoy. (Also, set the Hole value to 40 or 50%.)

So, this is what your raw pie chart might look like:

III — Apply the Style!

Finally, all you have to do is to keep the group selected in InDesign and apply the “BuoyFx-Group” style you have prepared:

Depending on the background you will be using behind your charts, you may need to improve the inner shadow, the altitude of the inner bevel, the blending mode of the Stroke effects, etc. In my example (on a white background) here's a zoomed-in preview showing the edge processing better:

Once you have your style perfectly tuned for your project, applying it to all of your graphics is a breeze. Remember that in order to create a distinct pie chart with new data, you only need to duplicate any existing one, select the group and run Claquos!

Meet Kasyan Servetsky, InDesign Wizard!

Tue, 01 Aug 2023 14:02:00 +0200

At the same time graphic designer, illustrator, prepress expert and scripting guru, Kasyan Servetsky has become one of the most active resource sharers in our microcosm. The InDesign community knows him well (but not enough for my taste!) because of the dozens of great utilities he has created over the past two decades: converters, batch processors, link managers, image resizers, font collectors, and many other gems. Let's step into the lab of this productivity freak…

• Your website is known as a cave of treasures offering tons of tools, links, snippets… But I've the feeling that your own work is not sufficiently visible and commented on. Would you say that “big box stores” won against quality craftsmanship?

Kasyan Servetsky : Years ago, I started my site just to share a few of my scripts and to familiarize myself with Dreamweaver a little. I didn’t expect it would become so popular. I’d rather say that “big box stores” can coexist with quality craftsmanship: both can find their niches. The internet in general and social networks in particular is the main source of information for me nowadays. I don’t have time to watch TV or listen to the radio. Thanks to social networks and forums I found new clients and friends with the same interests.

• Tell me about your professional activity.

K. S. : Currently, I work for Metodika Publishers — a small publishing house specializing in foreign language textbooks — where I am busy mostly with digital printing and preparing layouts: editing and fixing old PDF files provided by foreign publishers and making from them impositions in Kodak Preps.

Right before the Russia-Ukraine war, I found my dream job here in Ukraine: Adobe InDesign Server Automation Engineer. It was supposed that I would start working there at the end of March last year but the project was canceled because of the war.

• Such sad news! The rest of us who observe this drama from so far away can probably not measure its consequences in daily life. How do you get on, concretely?

K. S. : The situation here in Kyiv is much better than it was before the new year: no more regular missile attacks after which we had to live without electricity and water supply for a few days. About a year ago, our company resumed its work so I have regular work and wages. My wife works for an information agency. Our daughter completed the first grade at school and is on summer vacation now. All three of us have to stay mostly at home which makes it quite difficult for me to concentrate on my work. The most difficult situation was last spring — problems with food supply, no public transport working, no work — but now the situation is almost back to normal.

• Looking through your bio I thought you initially worked at the Kiev Polytechnic Institute…

K. S. : I’d like to clarify that I never worked at the Kiev Polytechnic Institute: it’s a high school and I studied there in the Printing department from 1990 to 1995. My specialty was Graphic design and illustration. In those distant times, here in Ukraine, we had no computers so everything was done by hand. Even a small type on a hardcover you have to do by hand with the thinnest — just a few hairs — brush. Another difficult thing to do was make a uniform background for a cover. First, I painted the background on a piece of thick paper with a pulverizer. Then, using tracing paper, I carefully transferred the outlines of my drawings from sketches to the background, and finally, I painted neatly the drawings. It was an elaborate and time-consuming process: the slightest inattention might ruin the whole work.

At that time, they taught us students already outdated technologies like linotype typecasting machines or punched-tape typesetting equipment…

• Wow! You were still light years away from the “digital revolution”, so what brought you into the field?

K. S. : In my last academic year, a small group of our students was invited by a publishing company that was looking for young employees. That’s where we were introduced to state-of-the-art publishing software like Photoshop, Illustrator, and Quark Xpress installed on, at that point, the most modern IBM 486 computers. At that moment I realized that was what I wanted to do in my life.

A few months later I found my first publishing job at the Osvita publishers: a publishing house specializing in the production of textbooks for schools. I had to study both at my new work on workdays and in high school during the evenings and on weekends. After a while, I made enough money to buy my first computer so I was able to learn the things I wanted to know and do some work on the side. By the end of the millennium, I was aware that our publishing house had been stuck in outdated technologies: we still worked in Corel Ventura running on 486 PCs. My bosses — people of preretirement age — didn’t want to learn new things and hated any changes. But I knew that I was capable of so much more so decided to quit.

• Setting out in search of adventure! And that's when InDesign popped up?

K. S. : For a year I was making my living as a freelancer. In 2002, I was offered the vacancy of a prepress specialist in the “Business” Weekly — then the leading economic periodical in Ukraine. I loved this company: they encouraged me to learn new things. In a few months, I offered them to switch from Quark to InDesign and InCopy, and they agreed. I had to solve the technical aspects of the process. There were two major issues: one was the fonts — we used Type 1 fonts — different versions for Mac and Windows. Our designers worked on Macs, but proofreaders and editors on Windows. I had to rework all fonts from scratch making OpenType versions.

Another problem was with InCopy files exported from InDesign. We all worked in shared folders (on a server). InDesign used the beginning of the text for InCopy file names. But the problem was that the text was Cyrillic which ruined the workflow. Desperately looking for a solution, I run across the sample scripts included with InDesign. They were well-commented, plain-text JavaScript files that I could read in TextEdit / Notepad. After some experimenting with them, without any programming knowledge, I was able to make a script that exported InCopy files using the base name plus a randomly generated number which worked perfectly for our workflow. That’s when my scripting career began. I automated all repetitious processes so our prepress department managed to do most of the work during one evening… instead of the week! Then I started writing scripts at the request of other people.

• Now, based on your background in both publishing industry and automation, how do you perceive the evolution of InDesign over the past few years?

K. S. : I have to admit that, in my daily work, I don’t use the new features that appear in every new version. I do mostly small edits in InDesign. In my opinion, the major weakness is the bugs introduced in modern versions. It makes me upset when something that worked, say, back in CS3 no longer works in the current version.

• By the way, have you started programming in `IDJS` (the new UXP programming model for ID)? How do you rate this technology?

K. S. : I read the Adobe UXP plugins development with React JS book by Davide Barranca. I also played a little with UXP scripts in InDesign and UXP Developer Tool. But so far, I had no time to get down to this seriously: have to do my daily work and bring into shape some of my existing scripts. I am sure the new technology would bring us new possibilities.

I am not going to migrate my existing scripts to UXP format because I don’t have time for this, but I am planning to make new projects as UXP scripts/plugins when the new InDesign version is released.

• I'd love to hear your feelings, or predictions, about how InDesign and the “AI hype” may interact in the future. Are you working on this topic already?

K. S. : As for me, I never used AI to write scripts. One of my customers was in raptures over AI: he showed me how he was able to get from ChatGPT a simple but working script for Illustrator and generate an interesting collage.

I am positive about new technologies. Remember, just a few years ago, Google Translate produced results that we could only laugh at. Now this is a service I use in my everyday life: reading information in any language without the need to spend years to become a polyglot. Of course, AI will never take the place of a professional programmer, as Google Translate will never substitute professional translators, but I am sure in a while, it will come in handy to regular users of Adobe products to automate repetitive tasks.

• Today, can a potential client, say a publishing house or a graphic design agency, contact you to benefit from your skills?

K. S. : As I’ve already mentioned, I am busy now because I have a full-time job. Currently, I work in my home office fixing and preparing layouts for digital printing. In parallel, I am adjusting already existing scripts for my past customers. I’m not able to get down to any new complex projects…

…but I can do simple scripts from time to time.

Interviewed by Marc Autret

• Where to go from now?
→ Kasyan's Personal Website: kasyan.ho.ua/indesign/scripts.html
→ Adobe Community Profile: community.adobe.com

• Related links
→ Metodika (UKR): metodika.ua
→ Kodak Preps: workflowhelp.kodak.com
→ UXP plugins development with React JS: ps-scripting.com
→ UXP Developer Tool: developer.adobe.com

Meet Kasyan Servetsky, InDesign Wizard!

Sun, 30 Jul 2023 16:41:00 +0200

At the same time graphic designer, illustrator, prepress expert and scripting guru, Kasyan Servetsky has become one of the most active resource sharers in our domain. The InDesign community knows him well (but not enough for my taste!) because of the dozens of great utilities he has created over the past two decades: converters, batch processors, link managers, image resizers, font collectors, and many other gems. Let's step into the lab of this productivity freak…

• Your website is known as a cave of treasures offering tons of tools, links, snippets… But I've the feeling that your own work is not sufficiently visible and commented on. Would you say that “big box stores” won against quality craftsmanship?

• Tell me about your professional activity.

• Such sad news! The rest of us who observe this drama from so far away can probably not measure its consequences in daily life. How do you get on, concretely?

• Looking through your bio I thought you initially worked at the Kiev Polytechnic Institute…

At that time, they taught us students already outdated technologies like linotype typecasting machines or punched-tape typesetting equipment…

• Wow! You were still a thousand miles from the “digital revolution”, so what brought you into the field?

A few months later I found my first publishing job at the Osvita publishers: a publishing house specializing in the production of textbooks for schools. I had to study both at my new work on workdays and in high school during the evenings and on weekends. After a while, I made enough money to buy my first computer so I was able to learn the things I wanted to know and do some work on the side. By the end of the millennium, I was aware that our publishing house had been stuck in outdated technologies: we still worked in Corel Ventura 4.1 running on 486 PCs. My bosses — people of preretirement age — didn’t want to learn new things and hated any changes. But I knew that I was capable of so much more so decided to quit.

• Setting out in search of adventure! And that's when InDesign popped up?

K. S. : For a year I was making my living as a freelancer. Then in 2021, I was offered the vacancy of a prepress specialist in the “Business” Weekly — then the leading economic periodical in Ukraine. I loved this company: they encouraged me to learn new things. In a few months, I offered them to switch from Quark to InDesign and InCopy, and they agreed. I had to solve the technical aspects of the process. There were two major issues: one was the fonts — we used Type 1 fonts — different versions for Mac and Windows. Our designers worked on Macs, but proofreaders and editors on Windows. I had to rework all fonts from scratch making OpenType versions.

Another problem was with InCopy files exported from InDesign. We all worked in shared folders (on a server). InDesign used the beginning of the text for InCopy file names. But the problem was that the text was Cyrillic which ruined the workflow. Desperately looking for a solution, I run across the sample scripts included with InDesign. They were well-commented, plain-text JavaScript files that I could read in TextEdit / Notepad. After some experimenting with them, without any programming knowledge, I was able to make a script that exported InCopy files using the base name plus a randomly generated number which worked perfectly for our workflow. That’s when my scripting career began. I automated all repetitious processes so our prepress department managed to do most of the work during one evening instead of the week. Then I started writing scripts at the request of other people.

• Now, based on your background in both publishing industry and automation, how do you perceive the evolution of InDesign over the past few years?

• By the way, have you started programming in IDJS (the new UXP programming model for ID)? How do you rate this technology?

• I'd love to hear your feelings, or predictions, about how InDesign and the “AI hype” may interact in the future. Are you working on this topic already?

• Today, can a potential client, say a publishing house or a graphic design agency, contact you to benefit from your skills?

…but I can do simple scripts from time to time.

Interviewed by Marc Autret

• Where to go from now?
→ Kasyan's Personal Website: kasyan.ho.ua/indesign/scripts.html

• Related links
→ Metodika (UKR): metodika.ua
→ Kodak Preps: workflowhelp.kodak.com
→ UXP plugins development with React JS: ps-scripting.com
→ UXP Developer Tool: developer.adobe.com

How to Create an Index from a Style

Mon, 10 Jul 2023 07:26:00 +0200

Creating an index (or any statistical report) from style(s) is really the easiest operation you can imagine with IndexMatic³. I swear! But for some reason that I still haven't been able to figure out, this question keeps coming up from users. So let's explain once and for all the procedure to follow…

Target the Style(s)

First, you have in your hands an InDesign document, or multiple style-consistent documents, or an entire book. Your goal is to extract data of interest based on one or several style(s). Are these paragraph styles or character styles? It doesn't matter. Only these portions of the text are of interest to you. You want IndexMatic to focus exclusively on the regions where the desired styles apply.

In the example above, I'm interested in the style Book Authors that tags authors names. In fact, this particular catalog has been divided into logical sections (A, B, C…) each of which bears a characteristic paragraph style for the names: “A Title - Book Authors”, “B Title - Book Authors”, and so on.

Therefore, when launching IndexMatic³, I select all the styles that matter to me in the Filters panel:

If your project involves character styles instead, do the same using the Character Styles subpanel. Note that you can combine the two filters, as discussed in the manual.

Run the “Universal” Query

Now all you have to do is enter a single query, which I informally call the Universal Query because it captures all available characters: /.+/

Note. — Although deadly easy to type in, this query should normally belong to your list of favorites under the label “ALL”. If not, proceed as instructed in the manual.

And… that's it! The Quick Matches feature will allow you to instantly precheck the matches, and producing the final index will be no more than a formality.

Refining?

Now suppose the Universal Query is too greedy. For example, in my test document the ISBN is identified by a generic style—named “Common Biblio Info”—which also applies to other elements. What if I want to extract and index ISBN numbers only, based on that filter?

Well, let's just refine the pattern! In this particular case I just had to select the desired style (Filters › Characters Styles) and change my query into /978.+/, since all ISBNs referenced in my document happen to start with “978”. Here is the resulting report:

The filter guarantees that among all items of the form “978…”, only those which have the style “Common Biblio Info” will appear. Often the combination of a style and a regular expression works wonders.

InDesign Scripting: Why are Endnotes so Hard to Decipher?

Sat, 03 Jun 2023 04:43:00 +0200

Endnotes were introduced in InDesign 13. Unlike footnotes, which are rendered in virtual containers attached to the host TextFrame, endnotes flow into extra containers of the EndnoteTextFrame class (a subclass of the TextFrame object).

However, the Endnote component is only browsable from Stories (or Tables, or Cells) that own endnote references. For example, if myStory denotes the main story of your document, myStory.endnotes collects the associated collection of Endnotes. But if you select a particular reference (or some Text supposed to contain one or several endnote references), you have no access to the underlying Endnote instances. Indeed, Text.endnotes is not implemented—while Text.footnotes is.

On the other hand, because both footnote and endnote numbers are based on the special character U+0004, there seems to be no direct way to discriminate them within a sample text:

It follows that the only method of extracting and parsing endnotes involves a global traversal of all objects that point to them. It's this strategy that I implemented in the $$.Dom.Endnote module of IdExtenso. In that example, the desired feature is only to get the numeral of the incoming Endnote specifier, so there's no need to dissect the remote content of the note(s). In some InDesign scripts, however, you want to tackle the problem and understand how endnotes work behind the scenes.

The Endnote component behaves like a proxy regarding text data. In this respect it resembles the Footnote object (only a little simpler). Basically, from a given Endnote myEnd, you can access Text collections like myEnd.texts, .characters, .words, .insertionPoints, .textStyleRanges… Strangely, the object does not expose .paragraphs or .contents properties, or anything that involves PageItem entities. Perhaps the reasoning adopted by the API designers is this: in contrast to footnotes, endnotes are rendered in another place (remote textframe) and then require a specific link to a distinct entity.

That distinct entity is the object EndnoteRange, returned by the property myEnd.endnoteTextRange. The job of this component is to decouple the logical object (Endnote) from its physical realization in the layout. But surprisingly, EndnoteRanges are not the kind of things you might actually select (like Words or TextStyleRanges). Although they only occur in EndnoteTextFrames, there is no direct connection from such a frame and the endnote ranges it contains.

So, here again, some contortion is needed to extract the information, typically using the code myEndnoteFrame.texts[0].endnoteRanges (which, by the way, tends to erroneously return an extra range that actually belongs to the next threaded frame!)

The big problem with EndnoteRanges is that they can be mixed with non-endnote text. The square brackets ⎡ and ⎦ shown in the below figure reflect special characters that InDesign inserts in the story to keep track of the entry/exit points of a range. Thus we can identify that the part highlighted in yellow escapes the legal content of the endnotes:

Also, as you can see, the endnote #44 has lost its number and its paragraph break. The content of an EndnoteTextFrame is freely editable because it is, in the background, managed exactly like a traditional text container. And a very unfortunate choice was made to encode the opening and closing brackets: both rely on the very same Unicode character, U+FEFF. Which means that you cannot analyze a fragment of text in order to extract its particular ranges, without having an exact count of all the markers that preceded it in the entire “endnote” story.

Note. — There is no actual EndnoteStory object, but you can check whether a specific Story has its isEndNoteStory property turned on.

In summary

The Endnotes collection embodies the references from the source text (the one that points to the endnotes), while the EndnoteRanges collection reflects the same data but from the perspective of the story that articulates the endnote content. A round-trip gateway makes it possible to go from an Endnote instance to the corresponding EndnoteRange, using the respective properties endnoteTextRange vs. sourceEndnote.

I haven't detailed the few properties exposed by the EndnoteRange class. They help recover start and end indices (pure integers) in the endnote story, so real InsertionPoints could be regenerated in order to make sense of the concrete text ranges. This approach works great as long as you parse the endnotes of the entire document.

But the API doesn't offer more local pointers: EndnoteRanges are not easily translatable into actual Text from a partial selection (or from an EndnoteTextFrame) while U+FEFF markers create ambiguities which complicate the task. A very similar problem arises on the side of the source text, since the markers U+0004 both denote Footnote and Endnote references.

IndexMatic³ in the Spotlight of CreativePro Magazine

Thu, 11 May 2023 20:55:00 +0200

If we judged the value of a magazine by the merit it gives to our work, I could tell you straight away, without further proof, that CreativePro is an excellent magazine! But that's not the real reason why I think so. In his review of IndexMatic³ published this month, Jeff Potter offers a meticulous and thoughtful exploration of what the product does and doesn't do, who it is for, from what perspective and for what purposes…

“Ten years ago, I used IndexMatic² for a very limited purpose in a local business directory project, and I thought it was beautifully implemented and meticulously documented,” Jeff writes in the preamble. And therefore you know that the reviewer is in the business, that he does not speak in a vacuum, that he will be able to appreciate the features and their evolution on concrete bases.

That's what I really like in this magazine: specialists in graphic arts software who not only give you practical keys, tips and tricks, but who do so from an authentic field experience. Jeff Potter devotes six full pages to IndexMatic³, with tests and screenshots to support. More than I would have dreamed of! He weighs the pros and cons with honesty, and he took the time to interview me to measure both the level of development of the program and what customers do with it around the world.

Resources, knowledge and community have been the three watchwords of CreativePro Network for nearly twenty-five years, driven by tireless enthusiasts known to all our readers in the InDesign universe (David Blatner, Mike Rankin, Anne-Marie Concepción, Keith Gilbert, Peter Kahrel…) So it's an honor to have my work recognized by such an established community. Not to mention these little sentences that are so good to read: “IndexMatic³ distills an amazing amount of power into a beautifully designed user interface—one refined enough that you might well forget that you are running a script.” Thank you Jeff, this gives fuel for the rest!

→ IndexMatic³ Review: “An Indexing Tour De Force”, by Jeff Potter.
→ CreativePro Magazine Issue 19: Virtual Photography, May 2023.

Dualité majuscules/minuscules dans IndexMatic³ [FR]

Fri, 07 Apr 2023 09:20:00 +0200

Give it a try!

IndexMatic³ TRY version offers all the features of the PRO release but is limited to 50 index entries. Need more? Consider to purchase a PRO version license.

Installation Note. — The TRY and PRO releases are both delivered in the jsx format. You simply need to put the file in your Scripts Panel folder. The script is instantly available in your InDesign Scripts panel.

• Purchase now IndexMatic³ Expert

Please, InDesign, Show Me a Sample of That Style!

Thu, 23 Mar 2023 14:04:00 +0200

Trivial story: you just have reopened an old InDesign document — or even a fresh one — and dozens of obscure names populate the style panels. You do not remember what that pesky “TDM Sub2” style refers to, or what it looks like, or where it is used. So you'll have to run the F/C dialog, select a Find Format, etc. We have a faster solution: right-click the style and “Goto Sample”…

Yes, it's that dumb, we simply added a Goto Sample item to the style panel popup menu. The style doesn't even need to be actually selected, just right click on the name.

What happens then? The underlying script automatically does what you would have done by hand: it runs a Find query, gets a sample text (if any) and shows it to you. This way you can navigate very quickly from style to style, check the elements that interest you, give the style a more meaningful name, change its formatting attributes, and so on.

I've been waiting for this feature for years and still don't understand how InDesign developers never implemented it.

The Script “StyleListGotoSample”

The script StyleListGotoSample.jsx was designed as a “startup script”, so you will install the JSX file — or a shortcut to it — in a subfolder named startup scripts (instead of Scripts Panel). If such a subfolder does not exist in your current installation, just create it.

The last step is to restart InDesign, which makes the Goto Sample action available in your style panel popup menu. The feature applies to both the Paragraph Styles and Character Styles panel.

15 InDesign Scripts and Snippets You May Have Missed

Tue, 21 Feb 2023 18:02:00 +0200

If you visit this website from time to time, you know that it contains a plethora of free InDesign scripts, but you may not know that other cool nuggets are regularly open-sourced in our GitHub repository called IdGoodies. The latter being hardly documented, here is an overview of some scripts—and interesting code snippets—you will find there…

1. BookUpdateTOCs (script)

Updates all Tables of Contents in the active Book. — You may find convenient to batch-update all TOCs present in a book, since InDesign doesn't seem to provide such a feature. This script inspects every chapter and runs the Update-Table-Of-Contents command if available. Then it displays a basic report at the end of the process.

TECH NOTE. — Chapters that aren't presently visible are temporarily opened, saved, and closed.

→ BookUpdateTOCs.jsx

2. DocPreventOpening (script)

Prohibits the opening of certain InDesign documents based on their filename. — This script prevents the opening of documents having a certain filename pattern. Change the RE_EXCLUDE constant in the code to make it fit your needs. The implementation relies on the event beforeOpen available in CS5/CS6/CC.

• To install the event listener just execute the script manually (once).

• To uninstall the listener, close your InDesign session. Of course if you have installed the code as a “startup script”, remove it from its folder!

DISCLAIMER. - Do not install this script as a startup script unless you really know what you are doing. Users will be unable to open documents having a certain file name pattern and won't be notified. In case you deploy this solution, make sure your clients are informed. Always provide instructions for uninstalling!

→ DocPreventOpening.jsx

3. DocShowClosestByName (script)

Makes active the closest document (with respect to name). — Based on the discussion “Javascript to find a similar filename among all open documents”, this script automatically selects the document having the most similar filename based on the Levenshtein distance.

TECH NOTE. — A custom RegExp can be supplied to the `showClosestDocByName` function in order to filter out specific name parts that must be ignored anyway (typically, shared suffixes among your set of documents.)

→ DocShowClosestByName.jsx

4. LinkAutoUpdate (script)

Updates links dynamically. — This script automatically updates ‘out-of-date’ links in InDesign. It is an event listener. You can either run it manually during your session, or load it as a startup script.

TECH NOTE. — An alternate code exists based on a script from あるふぁ（仮） which listens to the event `afterAttributeChanged` and delegates the task to BridgeTalk. The present implementation relies on the event `afterLinksChanged` available in CS5/CS6/CC.

→ LinkAutoUpdate.jsx

5. ReframeAllPages (script)

Reframes all pages with respect to item bounds. — Considering the active document, this script scans the page items of each page, determines the overall bounding box and reframe the page so it exactly fits the area. Page margins are reset to zero too.

TECH NOTE. — The script is undo-able and displays a short report.

→ ReframeAllPages.jsx

6. SelApplyStyleNone (script)

Resets the selection to the [None] style. — This script forcibly applies the [None] character style to the selected text or insertion point (if any), making sure that all specific character attributes are removed. The code has the same effect than clicking [None] in the Character Style panel (which unfortunately cannot be easily associated to a KB shortcut despite countless InDesign user requests.) So, you can attach a KB shortcut to this script and have a manual control of the “Apply None” action.

TECH NOTE. — All InDesign versions should be supported from CS4 to CC. Also, the script is undo-able (Cmd Z.)

→ SelApplyStyleNone.jsx

7. SelPlacePDFPage (script)

Simple interface for changing placed PDF page. — Need to constantly change the page of a placed PDF in the active document? Just select the graphic container and run this script.

ORIGINAL DISCUSSION: adobe.ly/3HoxrZ2

→ SelPlacePDFPage.jsx

8. DocBackupSave (snippet)

Backups a document before saving. — This function creates a backup of the target document before it saves it, so the consecutive versions are memorized, timestamped, and remain safe in a subfolder. The first time you call the function on a fresh, not-saved document, it simply invokes the native save method. Then, any subsequent call copies the existing document file in a backup folder before saving the new version. Each backup file is named as follows,

    --__

where the timestamp --

_ reflects the modified date/time of the document version.

Using backupSave(myDoc) rather than myDoc.save() may protect you against doomsday scenarios where a huge, in-progress document gets suddenly corrupted and cannot be recovered from the regular autorecovery feature. (Besides that, having consistent backups is still useful for ‘historizing’ your projects...)

TIP. — Assign your `backupSave();` script a KB shortcut, e.g. Cmd+Alt+S, going into Edit > Keyboard Shortcuts…

→ DocBackupSave.jsx

9. DocGrepTextFindAll (snippet)

Gets all Grep/Text found items in a temp file. — This function lists all text items found by the active GREP query (or TEXT query if no GREP available.) Results are saved in a UTF8-encoded file (typically findGrep.txt) then shown to the user. The function itself returns true if all went fine.

TIP. — Assign your `showFindAll();` script a KB shortcut, e.g Cmd+Alt+F, going into Edit > Keyboard Shortcuts...

→ DocGrepTextFindAll.jsx

10. FontGlyphCount (snippet)

Fast Glyph Counter for InDesign Font. — This snippet adds a glyphCount method to Font instances. You can use it in scripts that need to know how many glyphs are available in a font, in particular those which handle GID.

→ FontGlyphCount.jsx

11. GroupAddItems (snippet)

Adds one or several PageItems to a Group. — This snippet provides a addItems method to any singular Group instance. Such a feature is not available in InDesign's scripting API and it is hard to implement in a way that does not temporarily destroy the target group. The present solution relies on a brilliant idea proposed by Uwe Laubender — originally discussed in the InDesign Scripting Forum.

TECH NOTE. — The trick is to create a temporary `MultiStateObject` (MSO) which can then handle the target group into a State. New items are added to that state. When the state is finally released, the original group is restored with its new components. Issues may still arise in edge cases. The present code should deal with the target group G being part of an AnchoredObject (AO), or inside a ‘nested item’ (i.e pasted into.) However, no solution has been found in the particular case of G being directly nested in a `SplineItem`.

→ GroupAddItems.jsx

12. SelFirstImage (snippet)

Gets the top-left-most graphic. — Given a target page (and optionally a target layer) this snippet identifies and returns the “top-left-most” SplineItem containing a Graphic object. By ‘top-left-most’ we mean the object whose (top+left) coordinate is minimal. On average, this determines what the user perceives as the first geometric container of the page.

→ SelFirstImage.jsx

13. SelFlattenTransform (snippet)

Flattens the transformations of the selection. — This snippet operates on the selection. It clears the transformation attributes of every SplineItem while keeping path points in place. At the end of the process the objects look the same but they no longer undergo any scaling/rotation/shear component.

TECH NOTE. — The present implementation does not scan inner items from groups, MSOs, etc.

→ SelFlattenTransform.jsx

14. TableCellBox (snippet)

Creates a box enclosing a cell (or cell range). — Takes a table cell (single or plural specifier) and creates a Rectangle object that encloses the area, with respect to cell stroke(s) and existing transformations. This snippet is a 'proof of concept' following this technical discussion. The code illustrates and extends an idea from Uwe Laubender.

TECH NOTE. — The implementation deals with various InDesign issues, in particular the `obj.duplicate()` bug that affects GraphicCell's inner object. Also, the code supports the case of `MSO` or `Button` entities in the graphic cell. It can generate multiple ‘boxes’ if the incoming cell range runs across different spreads (due to threaded frames.)

→ TableCellBox.jsx

15. TextSortParagraphs (snippet)

Fast sort of InDesign paragraphs. — This snippet re-orders a range of paragraphs according to a sort function. By default Array.prototype.sort is applied to the contents, but the client code can supply a custom function as 2nd argument.

TECH NOTE. — The present implementation provides a mechanism that actually reorders the paragraphs once sorted and preserves individual character attributes. This is done by moving text ranges at the DOM level (no extra text container is created during the process.) The algorithm has been optimized to reduce the necessay moves to the strict minimum, so this function should run fast on average.

→ TextSortParagraphs.jsx

Go further! Discover IdExtenso, our opensource ExtendScript framework for InDesign.

À bâtons rompus chez Swash

Tue, 07 Feb 2023 09:32:00 +0200

Jean loup Fusz, un des piliers fondateurs de Swash Formation, m'a tendu un micro lors du lancement d'IndexMatic³.

Ceux qui ont déjà croisé Jean loup dans le cadre de l'InDesign User Group parisien ou sur les plateaux d'Adobe France connaissent son art de la médiation et le soin qu'il met à éclairer les angles morts en matière de design graphique et typographique. C'est donc un collègue scrupuleux et passionné qui m'a passé à la question dans cette interview parue la semaine dernière sur le blog de Swash.

Occasion inespérée (pour moi !) de donner quelques pistes sur ce drôle de métier qu'est l'automatisation InDesign. Et, pour vous, occasion de découvrir un Opac (Organisme Prestataire d’Actions de développement des Compétences) dynamique et sans ornières. Merci à eux pour ce sympathique coup de projecteur !

→ https://www.swash-formation.fr/ressources/indexmatic-outil-de-generation-dindex-dans-indesign-presente-par-son-auteur-marc-autret/

• Voir aussi : « Échantillonnez vos glyphes avec DeliverGlyphs » (script de JL Fusz)

What's New in IndexMatic³

Tue, 24 Jan 2023 23:10:00 +0200

Imagine you can extract, quantify, analyze and index every bit of text from your InDesign documents, in any language, based on your own criteria: a predefined word list, a set of fine-tuned regular expressions, such or such character styles or containers. This tool has just been born and is called IndexMatic³.

“Wait a minute! We already have a pretty suitable script for that purpose.” Yes indeed, IndexMatic² has been known for a decade by thousands of users around the world, and it still provides satisfactory results when it comes to making an independent index from an InDesign book. Well, it is exactly for this reason that IndexMatic³ succeeds and supplants it. Years of user feedbacks and feature requests… Read this little anthology:

— Is there no way to include/exclude paragraph STYLES selectively?

— Pleaaaase! Provide a solution for having page HYPERLINKS in the index!

— I need more ALPHABETS! Could it be possible to parse and index documents in Cyrillic, Hebrew, Arabic?

— Too bad I can't do a THREE or FOUR LEVEL index. Why stop at two?

— Can your program reveal matches in CONTEXT, as in the figure below?

— How can I target specific chapters in my book? And/or a CUSTOM SELECTION of opened documents?

— Could you please allow me to PREVIEW the results of my regular expressions? So frustrating that IndexMatic² ends up finding no results because of syntax errors!

— How could I filter out NOISE WORDS like ‘the’, ‘that’, ‘and‘, ‘which’…? (And the same in other languages!)

— We need much more contol on final SEPARATORS, cross-references and formatting! Also, our guidelines require us to format PAGE RANGES according to the Chicago Manual of Style rules.

— Is it possible to get ALPHABETIC HEADINGS A, B, C… automatically generated. I'm exhausted from manually adding those lines and reworking the layout.

— What about NOTE NUMBERS? I'd like to see them in the index.

And so on. In twelve years I counted a hundred requests of this kind, all extremely relevant, which could not be implemented in IndexMatic² as easily as one might think.

IndexMatic³: Reworked From Scratch

Consider iX³ as the premium flavor of IndexMatic, the one that addresses the above questions (and many more). It has been carefully redesigned with real-life user requests in mind. Its new “search engine” is faster, Unicode-aware, much more stable, and delivers instant results that you can view upfront, in the main dialog!

The script of course supports InDesign CC 2023… and still works fine in previous versions (CS6/CS5/CS4):

Above all, IndexMatic³ adds around fifty features to IndexMatic², some essential, others more advanced, which you will discover step by step by reading the user manual (109 pages).

So, What's The Deal?

• First, install and test the TRY version. If you have used IndexMatic² before, the difference should be obvious to you. (Note that iX³ and iX² are totally independent. Both can be installed in InDesign without conflict.)

• How is the TRY version limited? All the features are available but you cannot produce more than 50 index entries. It is however very sufficient to evaluate the program, and to determine whether or not your projects require a more powerful tool than those you already have.

• What about the previous version? Because IndexMatic³ is a major upgrade (also referred to as the “expert” version), we decided to maintain IndexMatic² (the legacy version) as a separate product, still available but no longer updated. Hence users and customers can still access a more affordable solution. IndexMatic² is known to run decently in InDesign 2023—although it hasn't been updated for several years.

• Why such a price difference between iX² and iX³? Just to give you a simple, quantitative comparison, the current IndexMatic² release has 5,600 lines of code, while IndexMatic³ (build 3.2301) has 40,000 lines of code (2,5MB). You will understand very quickly, by testing the two solutions, that they are not on the same scale.

• What Special Upgrade Price? The regular price for one IndexMatic³ lifetime license is, officially, €129. A 40% discount applies to IndexMatic² users whenever they decide to purchase the expert version. So they can always get access to iX³ for €79 (saving €50). Also, take note that during a short promo period, the 40% discount will apply to newcomers as well. (We decided to be generous with them too, shouldn't we?) But after that short period, only IndexMatic² users will have access to the PROMO code. (More detailed instructions will be sent to them.)

Acknowledgments

The development of IndexMatic³ would not have been possible without the invaluable help of some of my colleagues whom I would like to especially thank here:

— Peter Kahrel, one of the most knowledgeable people I know on both indexing issues and InDesign scripting!

— Roland Dreger, a German-speaking designer and developer who helped me a lot on translating the UI in German, and brought me a bunch of technical suggestions.

— Laurent Tournier, a friend and GREP-expert (well known to indiscripts' French visitors I guess) who is a seasoned IndexMatic user, always extremely relevant in his criticisms and ideas.

— Janus Bahs Jacquet, a Danish correspondent and IndexMatic user who suggested some very subtle improvements to the search system and other layers of the program.

— Ariel Walden, talented and renowned colleague at Id-Extras, who gave me helpful insights into Hebrew and right-to-left writing systems, and how they're handled in InDesign.

— Jean-Claude Tremblay, another famous InDesign guru and trainer, who helped me clarify didactic aspects in the iX²-to-iX³ transition.

Are You Ready for IndexMatic³ Expert?

Sat, 21 Jan 2023 22:45:00 +0200

Getting Started with IDJS (InDesign UXP Scripting Format)

Wed, 11 Jan 2023 15:32:00 +0200

The funniest thing I've read about the ExtendScript-to-UXP migration is in the (AI-generated?) documentation from Adobe: “ExtendScript uses an antiquated version of JavaScript (ES3), from the era when JavaScript was coded on punched cards.” LOL! Adobe is trying to make us feel like our JSX scripts are ancient artifacts, but let's see if IDJS will actually bring about a technological revolution in InDesign…

Unfortunately, there's not much information out there on this subject yet. The developers at Adobe.com have attempted to provide a cursory overview after InDesign 2023 (18.x) was released last October, but it's like trying to find a needle in a haystack of irrelevant and repetitive data.

I'm hoping that more thorough guides will be created soon—maybe on GitHub, github.com/AdobeDocs/uxp-indesign (when the many “lorem ipsum” will mutate into statements!)—but for now, it seems like script developers will have to rely on trial and error to document their own experiences. Thankfully, some of my colleagues are already on the case and are leading the charge for the “Unified Extensibility Platform” (UXP) revolution and the IDJS scripting file format.

UXP “Things You Need To Know”

First and foremost, UXP is the "modern way to create scripts and plugins for Creative Cloud products", it's like a magic wand that turns modern JavaScript (ECMAScript 6) and HTML markup into controls in native application windows. The most valuable resource I have seen on this subject is the YouTube's playlist UXP: Things you need to know created by the wizard Davide Barranca almost two years ago!

→ UXP: Things you need to know (Videos)
→ See also Davide's great opus Adobe UXP plugins development with React JS

Learning from UXP Announcements

The numerous UXP and UXP Scripting announcements posted last year on Medium's Adobe Tech Blog channel are still worth reading today to get a sense of the hype. Read especially those written by Padma Krishnamoorthy.

→ Big Updates Coming to UXP (22-Mar-2022)
→ Announcing UXP Scripting in Photoshop (9-Aug-2022)
→ See also, from V. Nachiyar, InDesign v. 18 Ships w/ Scripting Powered by UXP
→ and, from P. Barman, How Openicon Uses a Single UXP Codebase for Multiple Creative Cloud Apps

InDesign Scripting Gurus to the Rescue

Now, regarding more specifically UXP Scripting for InDesign—that is, the IDJS “specification” intended to ultimately replace JSX—a nice overview was posted last November by Gregor Fellenz, in German (translate.google is your friend if you don't speak German!) Last December, Martin Kraetke posted in turn an excellent article that sheds additional light on the syntactic jump from ExtendScript to ECMAScript 6. (UXP scripts are based on the V8 engine from Google Chrome, associated to a specific API wrapper for handling InDesign components.)

→ Quickstart UXP Scripting (DE) by G. Fellenz
→ Was bringt InDesigns neue UXP Scripting API? (DE) by M. Kraetke

Roland Dreger's GitHub Repositories

Finally, the scrupulous Roland Dreger—one of the most valuable script developers in the InDesign universe—jumped into the pot and opened the InDesign UXP Scripting repository, a set of “collected resources, articles and tutorials around UXP Scripting in Adobe InDesign”. On the other hand, he started experimenting with IDJS in a second repository: InDesign UXP Scripting Snippets. Although still in their infancy, these resources will allow you to familiarize yourself with the new concepts and get started writing scripts in the IDJS dialect.

→ InDesign UXP Scripting (Resources)
→ InDesign UXP Scripting Snippets

The Magic Parent Bounding Box

Thu, 04 Aug 2022 07:43:00 +0200

Geometry in InDesign can get deadly complex. Take a document, create a frame, insert a table, change a particular cell into a “graphic cell,” convert its inner object into an ellipse, play with strokes, rotate and scale the object, transform the parent frame in the fanciest way. Then ask yourself the question: what are the exact coordinates, shape or area of the final table cell?…

And still! I didn't tell you the whole story. Things like below may happen in a parallel universe (click the image to get a full insight into the nightmare) :

Even if no transformed spread incident occurs in the InDesign viewport, the problem of determining the basic, visually obvious coordinates of a Cell object remains highly technical. Just recently, Gerald Singelmann and Uwe Laubender discussed this thorny issue in the valuable HilfDirSelbst forum (in German.) My colleagues explore various approaches and tricks for recovering those hidden (x,y) data which the InDesign scripting DOM refuses to show us.

Note. — I also released my own solution in the IdGoodies repository, but the present post is not about the subtleties of that script.

One key fact is worth repeating here—as I feel it goes dramatically unnoticed (or misunderstood?) by InDesign scripters:

One can always access the bounding box of a page item
IN THE PERSPECTIVE OF ITS PARENT SPACE.

Sorry for the capital letters, that's really the crucial part. The “Parent Space Bounding Box”, also referred to as the “in-parent box”, is something that InDesign users cannot see in the GUI. But we scripters can grab it then study its coordinates, its transform state, and so on. Chapter 3 of the Coordinate Spaces and Transformations eBook explores the subject in depth.

Now, what does this visually mean? How does this help solve the “cell box” problem?

Well, look closely at the below image. The green Oval is the item inside the graphic cell (i.e., myCell.pageItems[0].) This object is badly distorted by internal transformations, as reflected in the GUI by its Inner Space bounding box. And that's all the scripting system will deliver us, geometrically speaking, since the cell container has no true geometric existence (no path, no bounds, no transformation matrix.)

Our goal is however to see the cell container as if it was itself a graphic object (which it is not!) We want to know its position, its dimensions, its transform state… Anyhoo, we want to get our hands on the red dotted rectangle representing the edges of the cell.

Now here is the little miracle. The cell object is drawn with respect to the TextFrame where the table flows. And this text frame happens to materialize the Parent Space of the green object (the one inside the cell.) Therefore, our cell container exactly matches the Parent Space Bounding Box (the “in-parent box”) of the Oval. I should say, more precisely, the “in-parent's visible bounding box”, the one that takes into account strokes and effects like the thick green border around the geometric path:

That's it! You just learned the magic parent box trick!

Disappointed? Ok, suppose you need to get the coordinates of point A marked on the figure. Its location, entirely determined from the inner object, can now be resolved as follows:

const MY_LOC = [
    AnchorPoint.TOP_LEFT_ANCHOR,
    BoundingBoxLimits.OUTER_STROKE_BOUNDS,
    CoordinateSpaces.PARENT_COORDINATES  // <<< HERE'S THE TRICK
    ];
 
myInnerObject.resolve( MY_LOC, <anySpace> )[0];
// where  is any destination space

These really are the coordinates of point A, not those of the top-left corner of the intrinsic bounding box, nor those of the in-pasteboard bounding box (which by the way could be determined using the very same method.)

This way of defining and accessing locations in a nontrivial bounding boxes is what makes InDesign's coordinate system a powerful toolbox for solving hard issues like the “cell box” problem I have just sketched.

Admittedly, this is not an appetizing subject. Although I have studied it for years, I still need to reread my own conclusions and recipes—endlessly!—to bring them back to my head. Nobody is comfortable with these damn matrices and coordinate spaces, and neither am I. Not to mention the bugs and quirks that InDesign injects here and there to belie the rules.

But I don't know of any other way to resolve coordinates regardless of user/UI settings. In many circumstances you just can't trust the geometricBounds property, or if you can, it will not reveal the rotation/scale/shear components that a particular component undergoes, nor will it tell you how to grasp implicite coordinates resulting from transformations.

Consider the task of creating a yellow rectangle that perfectly covers the selected cell while inheriting its particular transform state relative to the pasteboard. For my part, I would be absolutely unable to write such a script without resorting to special coordinate spaces and transformations.

On the other side, InDesign scripts that entirely relie on that dark energy are harder to design, implement, debug and understand. This is a huge downside. But once you've found the key to open one lock, it seems to open all the others!

After a few days of rewriting and fixing bugs, when I ran TableCellBox.jsx on a severely disarticulated document, I was almost surprised that the subsystem didn't explode while calculating the transformation matrices!

The Case of Converting InDesign Inches to Ciceros

Tue, 26 Jul 2022 21:18:00 +0200

While working on his Measurements scripts, my colleague Mikhail Ivanyushin reported me weird biases related to units conversion. In particular, he observed a discrepancy between InDesign's display and direct results from ExtendScript when addressing inches-to-ciceros translation…

The Issue

Mikhail considered the case of setting a frame width to (exactly) 12.75in:

Now, right-clicking the horizontal ruler and changing the measurement unit to “Ciceros”,

you get the value 71c9.441 in typographic notation (which means 71+9.441/12 in decimal notation.)

So, according to InDesign, 12.75in ≈ 71c9.441. The symbol ≈ accounts for the approximation.

Note. — InDesign's display precision is 1/10,000 up to 4 decimal points, and all measurements are internally coerced into PostScript points. See “Precision of HurryCover Measurements” for a more detailed discussion on this topic.

However, Mikhail's original ExtendScript code produced a slightly different result (71c9.5866), which deviates from the displayed value by +0c0.1456, that is, +0.0121 ci in decimal notation. This really is a tiny difference—something like 55 µm—but Mikhail wanted to explain the gap and improve his script. Most InDesign users aren't familiar with rounding errors, so they may visually consider 71c9.5866 as a wrong value compared to 71c9.441. In fact, they differ only by the size of three neurons!

In the previous version of the SizeInUnitsEng.jsx script, the general strategy was to apply an Adobe-to-French-Points conversion when dealing with ciceros. For that purpose, the factor 3528/3759, or similarly 254/271 was used, based on the fact that “French inch has size 27.1 mm [resp. French point is 0.3759 mm]; while Adobe inch is 25.4 mm long [resp. Abobe point is 0.3528 mm].”

Also, it was assumed that UnitValue's metric accurately reflects those ratios… which didn't appear to be the case at all!

So, What Is a Cicero?

• According to wikipedia FR, one cicero is 12 Didot points, that is:

1 ci ≈ 4.512 mm.

(The ≈ symbol is very important here, as the definition of the “point” itself varied across History, as well as the “French inch”.)

• According to wikipedia EN, a better estimation of the cicero (“1/6 of the historical French inch”) would be:

1 ci ≈ 4.51165812456 mm.

• According to InDesign's display, 1000 ciceros equals 4511.278 mm, so:

1 ci ≈ 4.511278 mm.

• Finally, according to the UnitValue class implemented in InDesign/ExtendScript,

1 ci ≈ 4.51104 mm,

so we clearly get an uncertainty from the 4th decimal place when dealing with millimeters.

Regarding inches, it's worth mentioning that InDesign display is altered by rounding errors as well, so it may appear that it doesn't even comply with its own rules in some cases. Just consider the 12.75in example above:

12.75 in ≈ 71c9.441 (ID display.)

Now, in Adobe metrics, we have two known facts:

(a) 1 in = 72pt (Adobe measurements.)

(b) 1 ci = 12.7872pt (straight from UnitValue.)

From (a), 12.75in = 918pt;
from (b), 10000ci = 127872pt,
which leads to the following conversion table:

It comes 12.75 inches = (71 + 117/148) ciceros. The decimal part expressed in 12th gives 351/37 (≈ 9.486486486), so the best approximation we can write is:

12.75 in ≈ 71c9.4865 (our result — vs. 71c9.441 from ID.)

So, according to our own calculations, InDesign displays is “wrong” by about +0c0.04. Still a microscopic error!

Choose your Factor!

As a matter of fact, we don't know with a sufficient accuracy the internal factor that UnitValue uses when it converts from ciceros. However, since it is considered that 1 cicero should equal “12 French points”, the best offer we can provide from the UnitValue perspective is:

const K = 12/(UnitValue("1ci").as("pt")); // 0.93843843843844

The value of K falls between 254/271 (≈0.937269373) and 3528/3759 (≈0.938547486) mentioned earlier. There are good reasons to suppose it will bring more consistent results.

Here is a sample script that you can use for testing this approach:

 
// Proposed factor when using intermediate
// conversion to points (French vs. Adobe.)
// ---
const K = 12/(UnitValue("1ci").as("pt"));
 
// Input parameters
// ---
var inputString = "12.75";
var inputUnit = "in";
 
// Rounding param.
// ---
var round = 4;
 
// Conversion.
// ---
var sizeAsAbobePt = UnitValue(inputString, inputUnit).as("pt");
var sizeAsFrenchPt = sizeAsAbobePt*K;
 
floatResult = parseFloat(sizeAsFrenchPt/12);
intResult   = parseInt(sizeAsFrenchPt/12);
 
// Refine the frac. part (typographic notation.)
// ---
diff = floatResult - intResult;
frac12 = (diff*12).toFixed(round);
 
// Output.
// ---
alert( intResult + "c" + frac12 );  // 71c9.4865

This leads to a very good approximation (71c9.4865) although InDesign still displays different digits (71c9.441) that anyway diverge from the theoretical result.

Note. — Don't be surprised if you observe differences at the 2nd or 3rd position after the decimal point in a fraction that itself represents how many 12th of the cicero unit we should take! The disagreement between 71c9.49 and 71c9.44 is, in fact, anecdotal. Since K is uncertain from the third decimal place, 10*K is uncertain from the 2nd decimal place, 100*K is uncertain from the 1st decimal place, and so on. In our particular example, sizeAsAbobePt is about 918 (in pt), which may even lead to a greater error. If we have used K=254/271, the final result would have been 71c8.4133! And I do not mention the additional rounding errors introduced by floating-point arithmetic (multiplications and especially divisions.)

A More Direct Solution

But, to me, there was still a mystery in Mikhail's algorithm: why on earth would the Adobe-to-French points translation have to be made?

Indeed, is there anything wrong in just invoking UnitValue(input).as("ci")?

Here is the simple code I've tested while investigating the issue:

var v = UnitValue("12.75in").as("ci");
// => 71.7905405405405 ; exact: 71 + 117/148.
 
// Convert decimal notation into typographic notation `#c#.#`
// ---
var n = parseInt(v,10); // Integer part: 71
 
var d12 = 12*(v-n);     // Dec. part × 12
// => 9.4864864864864 (exact: 351/37.)
 
12 <= d12 && (++n, d12-=12); // Who knows?
var result = n + 'c' + d12;
 
alert( result );
// => 71c9.4864864864864

Without a shadow of a doubt, this is the closest value to the theoretical result (71c9.4865) ever obtained. The reason is, almost all intermediate multiplications and divisions have been avoided, the core computation being just performed by UnitValue's internal processor.

Conclusion: if you use its native routines properly, ExtendScript can be more accurate and reliable than InDesign itself ;-)

Related links:

• Measurements and Explanations: Educational material about ratios of printing sizes, by Mikhail Ivanyushin;
• Associated Scriptopedia entry;
• IdExtenso::Units, a consistent facade for handling metrical units.

IndyFont 1.144 | Critical Bug Fix

Thu, 09 Jun 2022 03:53:00 +0200

Thanks to the feedback of an expert user, we discovered a critical flaw in the OTF export module of IndyFont. In short, the script was unable to generate a valid OpenType font having more than 255 glyphs in the Private Use Area. This serious issue is now fixed in iF 1.144. Go to your private link to update!

SmartSort 1.17 for InDesign CC/CS6/CS5/CS4

Wed, 06 Apr 2022 14:06:00 +0200

Fast, free, and feliz, SmartSort is an InDesign script that alphabetizes word lists (paragraphs or cells) with respect to the language used in your text. It's as easy as Right Click ▸ SmartSort… ▸ Sort! Version 1.17 essentially provides stability fixes. Download/update right now, and enjoy ;-)

How do I update the script? Simple: extract the new SmartSort.jsx file from the ZIP package, quit InDesign, replace the old file in your Scripts panel folder, restart InDesign. Done.

Why should I update? SmartSort is built upon the IdExtenso framework, which is regularly improved. An major update of the Collator component has just been released and provides stability fixes. SmartSort 1.17 reflects these changes.

• See also: SmartSort user's guide (PDF).

The Hard Problem of Quantified Alternatives in ExtendScript

Sat, 22 Jan 2022 01:05:00 +0200

In most cases, ExtendScript regular expressions cannot digest the (a|b)+ scheme. This bug is not new, but it's worth defining its symptoms and extent. This article presents a very simple problem, with no known solution to date…

Given an input string, suppose you want to capture every maximal substring formed of at least two letters and ending with a 'x'. (To make it simple, we shall admit that a letter is defined by its belonging to the \w class.) The solution is trivial, just run the regex /\w+x/g on the input string.

TEST #1 (ExtendScript/JavaScript)
 
input :: "Box x taxi x vaxx."
regex :: /\w+x/g
 
3 MATCHES FOUND -- See the ┊...┊ parts
 
✔ ┊Box┊ x taxi x vaxx.
✔ Box x ┊tax┊i x vaxx.
✔ Box x taxi x ┊vaxx┊.

Note. — We represent the consecutive matches nested in ┊...┊ based on a basic while(regex.exec(input)){...} loop that inspects RegExp.leftContext and RegExp.rightContext at each step. This presentation is more instructive than a simple display of the array of matches, because it tells us how the internal pointer of the regular expression progresses during execution.

A few things worth pointing out:
   • The isolated x are not captured because we target at least 2 letters.
   • ┊tax┊ is found in "taxi" since no \b assertion is specified.
   • ┊vaxx┊ is found rather than ┊vax┊x because \w+ is greedy, meaning that the + quantifier looks for a maximal match.

The most important fact, of course, is that the final character 'x' also belongs to the class \w. So, whenever \w+ eats too many 'x's, the regular expression is forced to backtracking. It must return what it has captured in excess from \w+ to make room for the x part. If the quantifier had been made non-greedy (/\w+?x/g) then the last match would be ┊vax┊x, which is no longer maximal.

So far, so good.

Now to the Bad News

Then, suppose your script should also consider some special syntax, say '%' followed by two digits, as representing a letter in the input string. And your goal is still to retrieve all maximal substrings formed of letters (including the %## meta-codes) and ending with 'x'. What would be the proper regex then? Easy:

/(%\d\d|\w)+x/g

is the logical answer you probably have in mind, and it works perfectly fine… in JavaScript!

TEST #2a (JavaScript only!)
 
input :: "Box x A%22%34x V%99xx."
regex :: /(%\d\d|\w)+x/g
 
3 MATCHES FOUND
 
✔ ┊Box┊ x A%22%34x V%99xx.
✔ Box x ┊A%22%34x┊ V%99xx.
✔ Box x A%22%34x ┊V%99xx┊.

Unfortunately, ExtendScript has a backtracking bug since the dawn of time—which in my opinion will never be fixed—and is not able to properly manage “quantified alternatives,” that is, subpatterns of the form (A|B)+, (A|B)*, etc.

TEST #2b (ExtendScript bug!)
 
input :: "Box x A%22%34x V%99xx."
regex :: /(%\d\d|\w)+x/g
 
5 MATCHES FOUND
 
✖ Bo┊x┊ x A%22%34x V%99xx.
✖ Box ┊x┊ A%22%34x V%99xx.
✖ Box x A%22%34┊x┊ V%99xx.
✖ Box x A%22%34x V%99┊x┊x.
✖ Box x A%22%34x V%99x┊x┊.

Since our regex /(%\d\d|\w)+x/g should execute as well with input strings without %## forms, the bug is visible already in our original example "Box x taxi x vaxx."

TEST #3 (ExtendScript bug!)
 
input :: "Box x taxi x vaxx."
regex :: /(%\d\d|\w)+x/g
 
6 MATCHES FOUND
 
✖ Bo┊x┊ x taxi x vaxx.
✖ Box ┊x┊ taxi x vaxx.
✖ Box x ta┊x┊i x vaxx.
✖ Box x taxi ┊x┊ vaxx.
✖ Box x taxi x va┊x┊x.
✖ Box x taxi x vax┊x┊.

And in fact you could put anything else in the alternation structure, even a single character (% instead of %\d\d), this won't clear the symptoms. The bug is not related to the complexity of the regular expression, only to its (A|B)+ form. In many circumstances, ExtendScript's engine will just fall in an infinite loop (which you can eventually prevent by adding to the input string a suffix that the alternation can never match.)

Note, in the above results, that a ┊x┊ match is wrongly reported at any position of 'x' in the input string, including isolated 'x's that couldn't even be regarded as the tail of a regular match. So we cannot rely either on the value of regex.lastIndex as a hint for completing the matches.

Just remember this sad law:

   Any Greedy Quantified Alternative Is
   Deeply And Irreparably Flawed
   (in ExtendScript.)

Ironically, I found a partial workaround that only works when, well, we don't actually need it! Indeed, if your pattern looks like /(%|\w)+x/g in the sense that it consumes a single character on each side of the alternation, then it seems that the “lookahead trick” /((?=%|\w).)+x/g escapes the bug:

TEST #4 (Lookahead trick for single char. alt.)
 
input :: "Box x taxi x vaxx."
regex :: /((?=%|\w).)+x/g
 
3 MATCHES FOUND
 
✔ ┊Box┊ x taxi x vaxx.
✔ Box x ┊tax┊i x vaxx.
✔ Box x taxi x ┊vaxx┊.

But as I said we don't need it at all, since %|\w could be just encoded as a class, [%\w], which entirely eliminates the alternation structure.

Sometimes you can be satisfied with a non-greedy quantifier. In this case the RegExp instance seems to work much better, but have in mind that it won't capture maximal matches:

TEST #5 (Non-greedy quantifier)
 
input :: "Box x taxi x vaxx."
regex :: (%|\w)+?x
 
3 MATCHES FOUND
 
✔ ┊Box┊ x taxi x vaxx.
✔ Box x ┊tax┊i x vaxx.
✔ Box x taxi x ┊vax┊x.

(Note that the last match is then ┊vax┊x, not ┊vaxx┊.)

Conclusion

The bug documented above is without a doubt one of the most dreadful in the ExtendScript regular expression engine. Barring a miracle, it will never be resolved since ExtendScript has been sentenced to death in the medium term. However, hundreds of existing scripts are likely to use RegExp objects, and sometimes very advanced patterns, which can collide at any time with the simple case of quantified alternations.

If you found a solution that I hadn't thought of, thank you in advance for sharing it!

Indiscripts

« Optimiser InDesign pour les documents longs »

Atelier d'expert

Encyclopédie scriptique

IndexMatic³ | Frequently Asked Questions

1/ General Points

Learning IndexMatic³

• IndexMatic³ sounds easy to play with, but not-so-easy to master. Is there a good step-by-step instruction on how to use advanced features?

→ Our YouTube channel also offers more targeted tutorials for French-speaking audience.

→ IndexMatic³ Manual (PDF)

IndexMatic³ vs. IndexMatic²

• I am an experienced IndexMatic² fan. I have been using it for years to offer my clients (mainly publishers) an additional tailor-made indexing service. Can I reuse in iX³ the wordlists and queries I prepared in iX²? If so, why should I upgrade to the new version?

→ Migration from IndexMatic² to IndexMatic³ (chart)

Upgrade Discount Price

• I've been using IndexMatic² Pro for years. Can I get the new version for less than the full price since I previously purchased an older version?

→ IndexMatic Upgrade Page

Creative Suite Backwards Compatibility

• I refuse to pay a subscription to Adobe and I still work — fully satisfied! — with InDesign CS6. Does IndexMatic³ support this environment? (Any plan to make it available in Affinity Publisher too?)

→ IndexMatic³ System Requirements

Using a Credit Card thru PayPal

• I attempted to make a payment by using my pro credit card (without logging into a PayPal account) but the system rejected the information and returned “the credit card cannot be used for this payment”.

→ IndexMatic³ Order Form

2/ Scope & Search options

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³?

→ Customizing Hits and Stats ; Grab Hits Data

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?

→ Page Rank

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

→ Whole Word

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)?

→ Off-Page Content and Ignored Elements

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?

→ Whole Word

Automatic Mode vs. Query modes

→ How to Create an Index from a Style

3/ Basic Queries

Regex Syntax: the / Prefix

• I'm trying to find a regex expression: everything inside curly brackets. My query is \{.+?\} and the script finds nothing. Where is my mistake?

→ Introduction to Regular Expressions

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?

→ Metacharacters ; GREP-like Operators

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?

→ Cross-References

• 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?

→ Cross-References ; “See” and “See also” Markers

Dealing with Plural Forms

• Given a list of words in singular form, is it possible to capture both the singular and the plural forms?

→ format directive

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?

→ Generic Space

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"?

→ Introduction to Regular Expressions

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?

→ Alternatives

Meaning of the "\w" Metacharacter

• What is the exact scope of the \w metacharacter?

→ Alphabet

Extracting XML Data

• Is IndexMatic³ able to parse text like:"...New Orleans..."?And is it possible to extract the attribute as well? Like:"...New Orleans..."

→ Saving/Restoring Favorite Queries

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?

→ GREP-like Metacharacters ; Generic Space

Generic Apostrophe

• How to perform a simple search on a text containing both the ASCII apostrophe ' U+0027 and the typographic apostrophe ’ U+2019 ?

→ GREP-like Operators

Consolidating Terms into a Single Reference

• I have two terms that I would like to consolidate into one reference: 1) Brahma 2) MahabrahmaThe outcome I would like is that the index displays as follows: Brahma See Mahabrahma Mahabrahma 279, 293-295, etcHow should I proceed?

→ Cross-References

4/ Proper Names

• 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?

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

Regex Syntax: the `/` Prefix

• I'm trying to find a regex expression: everything inside curly brackets. My query is `\{.+?\}` and the script finds nothing. Where is my mistake?

• 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?

→ `format` directive

• Is it possible to index every website mentioned in my document and to render the entries in the form:
"name [URL], page numbers"?

• 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?

• What is the exact scope of the `\w` metacharacter?

• Is IndexMatic³ able to parse text like:
"...New Orleans..."?
And is it possible to extract the attribute as well? Like:
"...New Orleans..."

• How to perform a simple search on a text containing both the ASCII apostrophe `' U+0027` and the typographic apostrophe `’ U+2019` ?

• I have two terms that I would like to consolidate into one reference:
1) Brahma
2) Mahabrahma
The outcome I would like is that the index displays as follows:
Brahma See Mahabrahma
Mahabrahma 279, 293-295, etc
How should I proceed?

• By the way, have you started programming in `IDJS` (the new UXP programming model for ID)? How do you rate this technology?