Skip to main content
Inspiring
July 2, 2015
Question

Why is PageItem.resize() unit independent? What other methods are?

  • July 2, 2015
  • 1 reply
  • 2598 views

I am continuing my journey through InDesign scripting units and values blues. I am currently trying to resize a PageItem and have found the following code resizes the selected PageItem in 'points' not my viewPreferences.horizontalMeasurementUnits, 'millimeters'.

document.selection[0].resize( CoordinateSpaces.pasteboardCoordinates, AnchorPoint.centerAnchor, ResizeMethods.ADDING_CURRENT_DIMENSIONS_TO, [ 100, 0 ] );

I am still trying to work out the best way to work with units and values of size. I thought all properties and methods used the documents viewPreferences unit properties when dealing with values of size… Turns out I was wrong!

I am asking the experienced scripters:

  1. Considering all methods that manipulate, measure, compare or return values of size, what would be the ratio of methods that are unit dependent vs unit independent be? I.e. viewPreferences vs points.
  2. If Adobe were to work on making this more consistent in the future which direction do you think they would go?

I ask so that I can pick a methodology that I feel will be simpler across a wider range of methods and possibly be more future proof.

This topic has been closed for replies.

1 reply

Community Expert
July 2, 2015

It is true that .resize() works in points only. As far as I know it's the only function that doesn't consider the document's measurement units.

Whether Adobe will ever change this I don't know. But in the meantime you can convert a value into points using JavaScript's UnitValue function. For example, suppose you have a text frame selected. Then you can get the position of the frame's top in points no matter what the document's units are using the following method:

top = app.selection[0].geometricBounds[0];

topInPoints = UnitValue(top, app.documents[0].viewPreferences.horizontalMeasurementUnits).as('pt');

It's quite a mouthful but it works.

Another method could be the use the .horizontalScale and .vericalScale properties.

Peter

McShamanAuthor
Inspiring
July 2, 2015

Hmmm thats a bit of a shame. I was kinda hoping maybe Adobe might be moving to a unit independent system. It would make more sense. It would mean as developers you wouldn't have to constantly check the users settings and you could easily combine and compare elements that typically use different unit types. E.g. PageItem geometric bounds and stroke weights.

Marc Autret
Legend
August 10, 2015

There is just an exception for locations, provided that:

(1) coordinates are passed using the ruler system syntax;

(2) the param consideringRulerUnits is set to true.

In such case your x and y are interpreted with respect to user units and custom zero-point.

Hi Marc,

and it seems consideringRulerUnits is coming with a condition :

Adobe InDesign CS6 (8.0) Object Model JS: PageItem

Let me quote the description text for consideringRulerUnits according to DOM documentation:

"This parameter has no effect unless the reference point is specified relative to a page. (Optional) (default: false)"

I'm not exactly sure what this condition is all about.
Does that mean, that setting consideringRulerUnits to true is only working, if the coordinate space of the in parameter or maybe the from parameter of transform() is set to CoordinateSpaces.PAGE_COORDINATES ? I'm a little bit confused what reference point the documentation is talking about.

Uwe


Hi Uwe,

> Does that mean, that setting consideringRulerUnits to true is only working, if the coordinate space of the in parameter

> or maybe the from parameter of transform() is set to CoordinateSpaces.PAGE_COORDINATES ?

Not at all—but the official doc is very confusing on this point.

The consideringRulerUnits option has only to do with the syntax of a location. In the transform() method, this location is the origin during the transformation (that is, the from parameter.) And in the resolve() method, this is of course the location parameter. The in parameter of transform() refers to the targeted bounding box, keeping in mind that the concept of bounding box is space-dependent. (I think I've already posted something on that subject.)

Now, what is the location syntax that complies with consideringRulerUnits==true? That's the RULER SPACE syntax. (Two other formats are available, BOUNDS SPACE and COORDINATE SPACE, I won't discuss them here.)

To my knowledge the RULER SPACE syntax has two possible forms:

1. [ [X,Y], pgIndex ]

where [X,Y] is a location relative to the ruler origin (zero point) of the spread or page-ruler-space associated to the client object.

This depends on both the Zero Point location and the RulerPerPage vs. RulerPerSpread vs. RulerOnSpine option.

Then (X,Y) will be interpreted in ruler units if consideringRulerUnits==TRUE.

pgIndex is the page index in the parent spread if RulerPerPage is ON, otherwise the value of pageIndex has no effect although it is required (use 0).

Note: if RulerPerPage is ON, pgIndex may actually be set to 1+maxIndex

Note: if RulerOnSpine is ON, the Zero Point has a fixed location.

2. [ [X,Y], pgAtLocation ]

where [X,Y] is a location relative to the ruler origin (zero point) of the spread or page-ruler-space associated to pgAtLocation.

In that scheme pgAtLocation is a location specified in the BOUNDS SPACE format (anchor point enum or anchor point relative coordinates, including BoundingBoxLimits if needed, etc.)

I know that's a bit complicated. What is important to notice is, the RULER SPACE syntax does require a page to be specified (pgIndex in form 1, pgAtLocation in form 2), and this is the only format that gives sense to consideringRulerUnits. That's why the doc says, “This parameter has no effect unless the reference point is specified relative to a page.”

Hope that helps.

@+

Marc