Problem with 'resize' command

[zeRafio]

My question is about Applescript but I think the issue is the same with Javascript.

Can someone confirm that in InDesign 19.5.1 this snippet errors when applied on a vertical graphic line:

resize someLine in outer stroke bounds from top left anchor by replacing current dimensions with values {3, 70} 

 The same goes with a horizontal graphic line with inverted values {70, 3}

[error 11269 : the requested value is not an allowed dimension]

[m1b]

Hi @zeRafio, I can confirm this error in ExtendScript:

I mean... it makes sense, right? A vertical line has no width—it has zero width, and moreover it can't have width. So the error makes perfect sense.

You can see this happening here:

graphicLine.resize(
    CoordinateSpaces.PARENT_COORDINATES,
    AnchorPoint.TOP_LEFT_ANCHOR,
    ResizeMethods.MULTIPLYING_CURRENT_DIMENSIONS_BY,
    [1, 4]
);

This operation works fine, without error, on a vertical line, because it isn't trying to change the width. But this will throw the error:

graphicLine.resize(
    CoordinateSpaces.PARENT_COORDINATES,
    AnchorPoint.TOP_LEFT_ANCHOR,
    ResizeMethods.MULTIPLYING_CURRENT_DIMENSIONS_BY,
    [1.1, 4]
);

 Are you trying to achieve something? Are you trying to avoid this error? Or just curious? Maybe you should work with a Rectangle rather than a GraphicLine?

- Mark

[zeRafio]

Thanks for confirming, @m1b 

I'm pretty sure the command was working in the past.

Here is an screenshot of the applescript dictionary of indy 19.5.1:

So you should be able to modify the visible bounds of a graphic line, wright?

Try it, it will trigger the same error.

I'm using a transformation matrix.

But here I get a second issue: stroke weight is not changed.

set scaleMatrix to make transformation matrix with properties {horizontal scale factor:rateH, vertical scale factor:rateV}
transform aBox in parent coordinates from top left anchor with matrix scaleMatrix

So I have to add a 'set stroke weight to…' command.

If you have a better solution, I'm interested.

[m1b]

Hi @zeRafio, yes sorry I should have realised what you wanted. So you are seeing the different meaning that the `resize` method has, versus the `transform` method. It is reflected in the normal UI: try to "resize" a vertical line via the UI—you can't. But you can scale it. Same with scripting.

So the following works fine, and doubles the stroke weight:

var doc = app.activeDocument;
var verticalLine = doc.selection[0];

app.transformPreferences.properties = {
    adjustStrokeWeightWhenScaling: true,
    dimensionsIncludeStrokeWeight: true,
    whenScaling: WhenScalingOptions.APPLY_TO_CONTENT,
};

var tm = app.transformationMatrices.add({
    horizontalScaleFactor: 2,
    verticalScaleFactor: 2,
});

verticalLine.transform(
    CoordinateSpaces.pasteboardCoordinates,
    AnchorPoint.centerAnchor,
    tm,
);

If your stroke didn't scale, then you might have a different "adjustStrokeWeightWhenScaling" setting.

The `transform` method is the best way to scale things, generally in Indesign scripts, I think. "Resize" is a special case for certain objects, and if they can't be resized via the UI, then scripting won't help, most likely.

- Mark

[zeRafio]

Here are my pref settings:

 It's exactly what's in your script.

[zeRafio]

I played with scale values to see what happens:

first example: results should be 3 and 30
strokeWeight: 1, horizontalScaleFactor: 3, verticalScaleFactor: 2, = result: 2
strokeWeight: 10, horizontalScaleFactor: 3, verticalScaleFactor: 2, = result: 20

second example: results are what is expected
strokeWeight: 1, horizontalScaleFactor: 3, verticalScaleFactor: 3, = result: 3
strokeWeight: 10, horizontalScaleFactor: 3, verticalScaleFactor: 3, = result: 30

third example: results are what is expected
strokeWeight: 1, horizontalScaleFactor: 3, verticalScaleFactor: 4, = result: 3
strokeWeight: 10, horizontalScaleFactor: 3, verticalScaleFactor: 4, = result: 30

In short, the transform method is sizing strokeWeight only if its value is less or egal to the verticalScaleFactor.

My problem is unchanged.

[m1b]

Thanks @zeRafio, those are great experiments. I'm starting to understand your issue I think. Well, I hope.

It is a bare fact that in any normal scaling operation in Indesign a stroke is never non-proportionally scaled*. Just look at the UI... how would the UI show "horiztonal stroke weight" AND "vertical stroke weight". Indesign just isn't built with this capability. Imagine a GraphicLine that was on, say a 30° angle, after scaling disproportionately those two stroke weights would be a mess.

So what choice does Indesign have but to choose one of the scaleFactors (it seems to choose the smallest)? That behaviour seems logical choice to me, actually.

Or, have I misunderstood again? I'd kind of like to know exactly what you are trying to do, and how this issue is breaking it for you.

- Mark

* There might be exceptions within transformed coordinate spaces — @Marc Autret is expert on these. A low-tech possibility could be to import a stroked object as a graphic and scale it disproptionately. I think that would work.

[zeRafio]

Or, have I misunderstood again?
You're almost there!

That behaviour seems logical choice to me, actually.
I can't see why, despite your explanation.
Why is it possible in the UI to set the length of a graphic line, then set its thickness without any limitation?
We should be able to do the same with AS or JS. (And as I already said, I'm pretty sure it was possible in previous versions with the 'resize' method.)

There might be exceptions within transformed coordinate spaces
That's why I'm using 'parent coordinates' intead of 'pasteboard coordinates'.
But it does not help.

[m1b]

> Why is it possible in the UI to set the length of a graphic line, then set its thickness without any limitation?

I think you might be mixing up terms. You can't "set its thickness" at all via the UI. Look:

Where is it's geometric "thickness"?

With a GraphicLine, there is no geometric thickness. If I set the scale (in the Transform Panel above) to horizontal: 200, and vertical: 100, literally nothiing will happen.

If you have a diagonal GraphicLine, and do that same scale [h: 200%, v: 100%] via the UI, it will change the geometry without changing the strokeWeight. Which is a decision I discussed before (and makes perfect sense to me).

Contrast this to shapes, such as a Rectangle, which do have a geometric width:

Maybe when you say "set its thickness" maybe you mean "set its strokeWeight"? If so, strokeWeight is a property of the object distinct from its geometry. And we have normal access to it from the scripting API. You can scale strokeWeight easily, eg:

myLine.strokeWeight *= 2;

Maybe you are confusing the various interactions strokeWeight can have with things like visibleBounds etc. Conceptually, strokeWeight can have a strong bearing on visibleBounds, of course, because when the visibleBounds are calculated they must take into account the strokeWeight. Maybe you are thinking that it makes sense to set the visibleBounds and expect Indesign to scale the strokeWeight?

Look at this code, which sets the visibleBounds with double the current width:

var doc = app.activeDocument;
var graphicLine = doc.selection[0];
var b = graphicLine.visibleBounds;
var horizontalScaleFactor = 2;

graphicLine.visibleBounds = [
    b[0],
    b[1],
    b[2],
    b[1] + (b[3] - b[1]) * horizontalScaleFactor,
];

This will fail (as you noticed) on a vertical line, but will work fine on a non-vertical line, but it won't change the strokeWeight. If we set the visibleBounds, Indesign is first calculating the horizontal extent of the item plus the horizontal extent of the strokeWeight, and then setting the geometric width of the item to a value of W (your setting) minus the horizontal extent of the strokeWeight. If you step through that operation you will see that it MUST fail when trying to scale the horizontal extent of a vertical line.

But all of this comes back to the fact that "strokeWeight" is a single numerical value. There is no such thing in the UI as horizontalStrokeWeight = 2, verticalStrokeWeight = 1. What would this look like?

There is only one number for strokeWeight.

Indesign simply does not allow this control via the normal UI and never has.

But again, it would help me immensely if you could explain your exact case, because I think that would really focus me in on why you can't achieve it, rather than discussing more generally and maybe still missing your point.

- Mark

[zeRafio]

Ok. Let's simplify this.

Here is a proof that the "bounds" of an orthogonal graphicLine can be read and written:

tell application id "InDn"
	set {y, x, b, r} to visible bounds of item 1 of selection
	tell active document to set zero point to {20, 20}
	set visible bounds of item 1 of selection to {y, x, b, r}
end tell

If it could'nt be read, it should trigger an error at the first line or, at least, return some empty value.

And, more interesting, why the third line does not errors?

With the help of the second line, you can see that the bounds are actually applied as the line is moved on the page.

[m1b]

Hi @zeRafio, your example doesn't reveal anything unusual. Just that:

1. reading the visibleBounds of a vertical line makes sense. Because a line with a stroke has a visible thickness.

2. setting the visibleBounds to the exact same values that you just read doesn't throw an error because, by pure logic, the visibleBounds you read will result in no change to the geometry of the line.

Calculating the visibleBounds in the orthogonal axis is this:

// let's call the orthogonal dimension "width", so
lineWidth + strokeWidth = totalVisibleWidth

// and with real values, in pts:
0 + 10 = 10

// this is what we see in your example, no surprises

And setting the visibleBounds in the orthogonal axis causes indesign to calculate like this:

// indesign must calculate the item's new width (which is currenty zero)
newItemWidth - strokeWidth = itemWidth

// and with real values, in pts
10 - 10 = 0

// ie. no change at all, so no error

Are you just trying to understand what's going on here? Or do you have a real use case where you need to—how would I put it—scale a line orthogonally. I mean even considering the phrase "scale a line orthogonally" surely you can see that it is geometrically nonsense?

I'm afraid at this stage you haven't made a clear case for there being a bug, or—in my view—even anything strange going on at all.

- Mark

P.S. I was racking my brain to try and understand what we are missing here and it occurred to me to ask: Do you accept the notion that a geometric line has zero thickness? And if so, that setting a line's thickness to anything but zero is an invalid operation?