Indiscripts

InDesign's scripting infrastructure is based on DOM objects (Document, Story, Paragraph…) and any such object has an associated collection (Documents, Stories, Paragraphs…). Collections typically arise in complex specifiers like myDocument.stories.everyItem().words. They also provide two essential members, the length property and the count() method. How do they differ?

The Japanese scripter あるふぁ found a bug affecting any ExtendScript code based on ...==null. This is not a critical issue (because experienced developers never use such condition!) but the case provides the opportunity to summarize important rules regarding falsey values and the equality operator…

ScriptUI provides a set of usual mouse events (mouseover, mousedown, mouseup, click…) which are of primary interest in responsive user interfaces (UI). Developers can add event listeners to any UI component that needs to respond accordingly when the mouse enters the scene. But handling such events requires carefulness if your script has to support both CS and CC environments.

As an InDesign maniac I often use it for achieving tasks that would normally involve Illustrator or Photoshop. The best example of this deviance is PNG conversion. You read it well! And here is a tool that translates any InDesign shape, group, or whatever, into a PNG stream. Not a big deal, but let me explain…

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…