However, I must clarify that bounding boxes and related topics have not been addressed yet. (Next chapters coming soon…)

So maybe it's the right place to bring some insights en primeur. In short, here is why Ariel's code does the job:

1. Although bounding boxes are not coordinate spaces in the strict sense, they provide additional coordinate systems (always related to coordinate spaces). A little known fact is that a given page item—say an Oval instance—has distinct bounding boxes depending on the coordinate space you consider along its hierarchy. Study the figure below. At a minimum, one can distinguish the inner space bounding box of the object (blue rectangle), and its spread-space-related bounding box (magenta).

So for the same object, there are as many distinct bounding boxes as coordinate spaces involved in the hierarchy: inner space, parent space(s)… spread (and page) space, and finally pasteboard space. Each bounding box reflects the orientation—in fact, the transformation state—of the coordinate space you consider. Two bounding boxes do not coincide as soon as the related coordinate spaces are connected through an affine map that contains some non trivial rotation and/or shearing parameter.

2. Another curious fact is, while InDesign's GUI shows the inner space bounding box of the selection (for a single object), the geometricBounds property always returns the coordinates of the pasteboard-related bounding box (which in most cases is equivalent to the spread-related bounding box). In addition, obj.geometricBounds returns the [top,left,bottom,right] values in a special coordinate system, the Ruler space system, which I will not explore here.

[To keep things simple, I just consider the basic situation depicted above—an oval rotated in its parent spread—and will handle coordinates in the pasteboard space, as already suggested.]

3. The PageItem.resolve() method has three parameters: location, inSpace, and consideringRulerUnits (optional). The most important one, location, has almost ten different forms (all are very poorly documented). Basically, location specify a point anywhere in any space. You can define as well a bounding box related location, a ruler space related location, or a coordinate space location. Here we only consider the first option. The full syntax of a bounding box location is as follows:

[ MyAnchorPoint, MyBoundingBoxLimits, MyCoordinateSpace ]

which means: "considering the bounding box relative to this coordinate space (3rd param), considering whether outer strokes are included or not in that box (2nd param), take this anchor point (1st param)."

Fortunately we have a shortcut: MyAnchorPoint alone is equivalent to [ MyAnchorPoint, BoundingBoxLimits.GEOMETRIC_PATH_BOUNDS, CoordinateSpaces.INNER_COORDINATES ]—that's the shortcut that Ariel uses.

Therefore, in the above figure:

• the location of the blue point is (fully encoded): [ AnchorPoint.TOP_LEFT_ANCHOR, BoundingBoxLimits.GEOMETRIC_PATH_BOUNDS, CoordinateSpaces.INNER_COORDINATES ]

• the location of the magenta point is: [ AnchorPoint.TOP_LEFT_ANCHOR, BoundingBoxLimits.GEOMETRIC_PATH_BOUNDS, CoordinateSpaces.SPREAD_COORDINATES ]

Finally, given a location, the inSpace parameter tells resolve() in which coordinate space that location must be expressed.