Automating A3 in-store signs: how to fit variable-length names to a fixed frame without distorting type

Question

We generate in-store A3 landscape signs automatically from our ERP: a JSON job feeds an ExtendScript that drives InDesign 2026 and exports the PDF, with no manual step. Each sign holds 2 or 3 uppercase lines (the product name) whose length varies a lot from product to product.

Design goal: the largest possible cap height (these are read from the street), the text block filling the sheet, and no distorted type.

What the script does today: it sets the point size from the height each line gets, then raises horizontalScale until the line reaches the frame width. That lands at 115-130%, which is visibly distorted, so this is clearly the wrong tool.

Questions:

1. Is there a scripting equivalent of Illustrator's Type > Fit Headline in InDesign, or is adjusting tracking the accepted way to make a short line fill the measure?

2. For a line that is too long, is switching to the condensed cut of the same family the recommended automated fallback, rather than reducing the point size?

3. Is Line.horizontalOffset / Line.endHorizontalOffset the reliable way to measure the rendered line width so size and tracking can be computed in a single pass instead of a shrink-until-it-fits loop? Anything to watch out for (justification, optical margin alignment, first baseline offset)?

4. For an automated pipeline like this, are variable fonts with a wdth axis the right long-term answer for width fitting?

5. Is there any built-in feature (auto-size text frames, object styles, paragraph style settings) we should be using instead of a custom fitting loop?

Thanks. Happy to share the script if it helps.

Peter Kahrel · Answer

> 1. Is there a scripting equivalent of Illustrator's Type > Fit Headline in InDesign, or is adjusting tracking the accepted way to make a short line fill the measure?

No, there isn't.

> 2. For a line that is too long, is switching to the condensed cut of the same family the recommended automated fallback, rather than reducing the point size?

I don't think that there's a recommended action, it's informed by taste and the amount of excess. If the line is only a little bit too long, then reducing the point size may be appropriate, if it's too long by a lot (whatever 'a lot' is), then a condensed type may be better. Or maybe even a combination of the two.

> 3. Is Line.horizontalOffset / Line.endHorizontalOffset the reliable way to measure the rendered line width so size and tracking can be computed in a single pass instead of a shrink-until-it-fits loop? Anything to watch out for (justification, optical margin alignment, first baseline offset)?

The horizontalOffsets are reliable. But how are you going to compute the increase in point size when you know you have, say 12 points space left on the line? And shrinking is even more complicated. A shrink-until-it-fits loop is very quick, depending on the precision and the number of iterations. Apart from that, there are more clever ways to fit type.

> 4. For an automated pipeline like this, are variable fonts with a wdth axis the right long-term answer for width fitting?

I don't know.

> 5. Is there any built-in feature (auto-size text frames, object styles, paragraph style settings) we should be using instead of a custom fitting loop?

If you can adjust the frame to the text, that's easy. You can use the auto-size settings in the text frame preferences (and/or set that in an object style).

Sign up

To post, reply, or follow discussions, please sign in with your Adobe ID.

Sign in to Adobe Community

To post, reply, or follow discussions, please sign in with your Adobe ID.