GeometricBounds

GeometricBounds is the axis-aligned bounding box of a page item, written in the y-before-x order y1 x1 y2 x2.

In short: GeometricBounds is the axis-aligned bounding rectangle of a page item, given as four numbers in points. It is the quickest way to know how big a frame is and where its box sits, and it appears on both Page elements and page items. The catch is the axis order: the four numbers are y1 x1 y2 x2 — that is top, left, bottom, right, with the vertical coordinate first, the opposite of the (x, y) ordering used almost everywhere else. From those four numbers the renderer derives width as right − left and height as bottom − top.

The axis order is y before x

This is the one thing to memorize, because it is the opposite of the (x, y) ordering used almost everywhere else:

GeometricBounds="y1 x1 y2 x2"

That is top, left, bottom, right — the vertical coordinate comes first. The parser reads the four numbers in exactly that order into a Bounds record:

The parser requires exactly four numbers. A value with any other count is rejected, and the item falls back to deriving its bounds elsewhere (see below).

What the renderer computes from it

Once parsed, the box yields the frame's dimensions directly:

• width = right − left = x2 − x1
• height = bottom − top = y2 − y1

Because Y grows downward, y2 (bottom) is the larger number and y1 (top) the smaller, so the height subtraction is positive. A page declared GeometricBounds="0 0 841.89 595.276" is therefore 595.276 pt wide and 841.89 pt tall — an A4 page with its top-left at the origin.

Bounds vs. the real outline

GeometricBounds is only the bounding box. The actual shape of a page item lives in its PathGeometry. For an axis-aligned rectangle the two agree; for a triangle, an ellipse, or a Bézier blob the bounding box is just the tightest box around the outline.

Real-world InDesign exports often omit GeometricBounds on page items entirely and serialise only the path. When the attribute is absent, the parser derives the box from the path's anchor points: it scans every anchor and takes the minimum Y as the top, the maximum Y as the bottom, the minimum X as the left, and the maximum X as the right. Either way the frame ends up with the same Bounds record — one read from the attribute, the other reconstructed from the geometry.

Where it appears

The bounds are always in the element's own inner coordinate space — the same space the path anchors live in — and the item's ItemTransform maps that space onto the page.

Frequently asked questions

What is the axis order of GeometricBounds? The four numbers are y1 x1 y2 x2, meaning top, left, bottom, right — the vertical coordinate comes first. This is the reverse of the (x, y) ordering used in most other IDML geometry, so it is the one thing worth memorizing.

How are a frame's width and height computed from GeometricBounds? Width is right − left (x2 − x1) and height is bottom − top (y2 − y1). Because Y grows downward, y2 (bottom) is the larger number, so the height subtraction comes out positive. The parser requires exactly four numbers; any other count is rejected.

What happens when a page item has no GeometricBounds? Real InDesign exports often omit GeometricBounds on page items and serialise only the PathGeometry. When the attribute is absent, the parser derives the box from the path's anchor points — taking the minimum and maximum X and Y — so the item ends up with the same Bounds record either way.