Indiscripts

Without doubt this is a “very bad practice.” When it comes to naming arguments and variables, every programmer should prefer descriptive and intention-revealing names over short forms. We all read this rule in Clean Coding bibles. Tokens like userName, swatchArray, or currentWordCount sound of course much better than s, a, and i…

Dealing with coordinate spaces and transformation matrices is one of the most obscure and underappreciated exercises in InDesign scripting and programming. The fault mainly lies with Adobe documentation, especially the Scripting DOM reference, which does not clearly explain the topic and some of its essential keys. The following document (PDF, Chapters 1-3) attempts to shed some light on the beast…

• Go to the newest release of this document

The pattern array.sort(compareFunc) is widely used by JavaScript programmers when elements being sorted are not supposed to represent basic strings in the sense of UTF16 ordered character sequences. In particular, sorting numbers forces you to provide that stupid custom compareNumbers routine which, in most cases, just looks like function(x,y){return x-y}. And even when you have to sort actual strings, there are countless situations where the default Unicode code point order is inappropriate. But a question arises: what is the performance cost of using a non-native comparison routine?

Exploring the prototypal relationships between basic ExtendScript's entities reveals an interesting network of hidden objects. The following diagram shows that ExtendScript's own implementation of JavaScript is deeply connected with a root function (referred to as [[Function]] in the figure) which provides the actual prototype—that is, the __proto__ property—of many visible objects, including Function and Object themselves…

For obscure reasons ExtendScript 3.x is somewhat allergic to the character "\x00" (U+0000). Some String and RegExp routines become silently defective as soon as your source string contains one or more NUL character. Although most of these bugs have been fixed in CS5 (ExtendScript 4.1), this still leads to compatibility and portability issues. Here is a snippet that allows to split any string and get proper results in all versions.

As an InDesign scripter, you probably know that PageItems, Paragraphs—or any other collection—exposes a method named anyItem() which randomly digs up a sample in the set. The only question is: what the hell can it be used for?

A number of InDesign scripts manipulate words for counting, indexing, or other processing purposes. Given a text container—basically a Story—the InDesign Scripting DOM provides many ways to handle text contents through specialized subclasses of the Text interface: one can easily access to insertion points, character ranges, lines, paragraphs, text columns, styled-text chunks, and… words. Although this concept seems pretty straightforward, I tried to understand a bit better what it really means.

Although jsPerf is a very effective tool in a pure JavaScript environment, you may want to benchmark competing code snippets in the specific ExtendScript field. Here is a simple way to test and improve your InDesign scripted functions…

While Photoshop has a handy Actions panel that gives you the ability to record and playback simple operations, InDesign provides no way —without scripting!— to automate those daily repetitive tasks. But, hey!, why not use a script to mimic such action manager? This is my very first step in that direction...