Indiscripts

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 <anySpace> 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 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 rely 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!

• See also:
— Spaces and Transformations in InDesign (the definitive guide);
— HilfDirSelbst: “Koordinaten einer Tabellenzelle” (DE).