Resetting zeroPoint | Not working when pages AND spread are rotated

Report · Jan 22, 2018

Hi together,

I'm looking for the solution of a peculiar problem with resetting the zeroPoint to the upper left corner of a page.

( I suspect a bug or at least an unfinished feature. )

Have a facing pages document with two A4 pages on a spread.

1. Step: Rotate the pages by 4° counter clockwise so that the spine touches only one corner of each of the pages.

2. Step: Align the page left from the spine with the page right from the spine by moving it on the y-axis.

3. Step: Counter rotate the spread so that the view on the pages is in parallel to the rulers.

( Spread rotation always rotates the view, page rotation does not. )

Fig.1 is showing a rectangle selected with the upper left corner set to position [0,0]. The ruler origin is set to SPINE.

The rulers are reset and do not align with the upper left corner of the page left from the spine.

That's the first issue. You can also see the spine ( I drew a graphic line ) that is in parallel with the rotated spread:

Now I tried to move the zeroPoint to the upper left corner of the page.

First I dragged the cross-hair ( upper left corner where the guides meet ) to the upper left corner of the page.

That failed. The new zero point remains at the old zero point position.

See a movie clip where I tried this:

Dropbox - zeroPoint-DraggingCrossHairToUpperLeftCornerOfPage.mp4

Two screen shots of the clip.

Fig. 2 Dragging the cross-hair to the upper left edge of the page.

The yellow rectangle plays no role now. We come to it later.

The green arrow shows the distance that the reset zeroPoint is away from the upper left corner of the page.

Fig. 3 The result after dragging. The zero point landed at the upper left corner of the red rectangle ( now the magenta one ).

Ok. Let's try this by scripting.

app.documents[0].zeroPoint = [0,0];

should do it, but unfortunately it will not move it to the upper left corner of the page.

That's the amount we would move the zero point.

But unfortunately that does not work as expected.

app.documents[0].zeroPoint = [ -2.142 , 30.632 ];

moves the zero point to the upper left corner of the yellow rectangle.

That's a bit off…

Here the link to some test documents and the screenshots:

Dropbox - zeroPoint-issue-FacingPages-RotatedPages-CounterRotatedSpread.zip

zeroPoint-issue-FacingPages-RotatedPages-CounterRotatedSpread.zip

FacingPages-RotatedPages-AlignedPages-CounterRotatedSpread-RulerOrigin-PAGE-CS6.idml

FacingPages-RotatedPages-AlignedPages-CounterRotatedSpread-RulerOrigin-SPINE-CS6.idml

FacingPages-RotatedPages-AlignedPages-CounterRotatedSpread-RulerOrigin-SPREAD-CS6.idml

FacingPages-SCREENSHOTS

RulerOrigin-PAGE-PageRectangle-LeftFromSpine.png

RulerOrigin-PAGE-PageRectangle-RightFromSpine.png

RulerOrigin-PAGE-RectangleAtZeroPoint-LeftFromSpine.png

RulerOrigin-PAGE-RectangleAtZeroPoint-RightFromSpine.png

RulerOrigin-SPINE-PageRectangle-LeftFromSpine.png

RulerOrigin-SPINE-PageRectangle-RightFromSpine.png

RulerOrigin-SPINE-RectangleAtZeroPoint.png

RulerOrigin-SPREAD-PageRectangle-LeftFromSpine.png

RulerOrigin-SPREAD-PageRectangle-RightFromSpine.png

RulerOrigin-SPREAD-RectangleAtZeroPoint.png

zeroPoint-Reset-Problem-1.png

zeroPoint-Reset-Problem-2.png

zeroPoint-Reset-Problem-3.png

zeroPoint-Reset-Problem-4.png

I tested with all available ruler origins, SPREAD, PAGE and SPINE.

With e.g. ruler origin SPINE there is yet another issue in the horizontal guides.

The zero point is visible near the upper left corner of the page left from the spine.

And not around the spine I drew.

However, if you move a rectangle to the zero point you'll get it to the spine.
Unfortunately not exactly to the upper left corner of the page right from the spine…

That's it for now…

Ah, all my tests shown here are done with InDesign CS6 8.1, but the issues are also with InDesign CC v9.3.0 to the current CC 2018.

Has anyone an idea to workaround that problems by scripting? I tested a lot.

One thing I tried: Unrotated the spread, reset the zero point > That's working.
But if you rotate the spread again the zero point moves again.

Regards,
Uwe

Report · Jan 22, 2018

I think, I found a solution to the problem moving the zero point to a distinct position on a rotated pasteboard.

Screenshot below: The tip of the red arrow R that's the poition of the misplaced zero point after applying new coordinates naively, the zero point reset to [0,0], that's point Z and the tip of the green arrow T , our target point, form the same angle that the pasteboard is rotated. So now I know how to correct that issue: I'll do a counter rotation to the coordinates of the tip of the black arrow, point C. The coordinates of C will be applied to the zeroPoint. That will move the zeroPoint to target T.

The coordinates of target T in this example can described as an array taken from the bounds of the page: [ page.bounds[1] , page.bounds[0] ]. T needs to be calculated differently in case the page is rotated in regard to the horizontal ruler.

All that could lead into a script* that is able to place the zeroPoint to the tip of a pressed cursor also in rotated spreads, which is not possible correctly with the UI controls due to a bug right now. This problem is immanent with spread rotations that are done with the Pages panel's Rotate Spread View feature for 90° CW, 90° CCW and 180°. Also with spread rotations that can only be done by scripting like my 4° CW rotation example is showing.

* I still have to write this script, though, now that the solution path is clear to me.

Regards,
Uwe

Report · Jan 23, 2018

Hi Uwe,

That's not a bug. In spreadOrigin mode, you need to consider [0,0] as expressing the “top-left corner of the in-spread box of the leftmost pages.” Yeah, that's not obvious! Give a look here:

http://indiscripts.com/blog/public/data/coordinate-spaces-and-transformations-4/CoordinateSpacesTran...

Edit: I think there is a mistake in my PDF! Do not consider the leftmost page only, but the whole area occupied by the pages.

Best,

Marc

Report · Jan 23, 2018

Now here is a script that should do the job:

// Your stuff
// ---
var doc = app.properties.activeDocument;
var spd = doc.spreads[0];
var PG_INDEX = 0;
var pg = spd.pages[PG_INDEX];
// First, reset the ruler system to its default.
// ---
doc.zeroPoint = [0,0];
// Ruler origin in spread coords (pt units.)
// ---
var xyOrig = spd.resolve([[0,0],PG_INDEX],CoordinateSpaces.spreadCoordinates,true)[0];
// Page's top-left corner in spread coords (pt units.)
// ---
var xyPage = pg.resolve(AnchorPoint.topLeftAnchor,CoordinateSpaces.spreadCoordinates)[0];
// Offset.
// ---
var dx = xyPage[0] - xyOrig[0];
var dy = xyPage[1] - xyOrig[1];
// Change origin.
// ---
doc.zeroPoint = [dx+'pt',dy+'pt'];

Best,

Marc

Report · Jan 23, 2018

Hi Marc,

implemented and tested your code.
Works without flaws!

One question:

Why did you set consideringRulerUnits to true with spd.resolve() ? ( default value is false )

Since we access spread coordinates and not page coordinates setting this parameter should have no effect.
And if it had an effect—it does not—we would perhaps mix pt with mm values in the next step where the offset is calculated.

Also tested without parameter consideringRulerUnits and get the same results as expected.

Thanks a lot,
Uwe

Report · Jan 23, 2018

One question:
Why did you set consideringRulerUnits to true with spd.resolve() ? ( default value is false )
Since we access spread coordinates and not page coordinates setting this parameter should have no effect.
And if it had an effect—it does not—we would perhaps mix pt with mm values in the next step where the offset is calculated.

I use true to make explicit that I am using (and speaking in) ruler units. Of course this makes no difference here, because the coordinate pair [0,0] is the same whatever the actual unit. But I think important to keep in mind that the location specifier [[0,0],index] is understood in terms of ruler coordinates and units. Indeed, this entirely depends on what you want to do. There are case where you want to provide points unit (i.e consideringRulerUnits==false) while querying the ruler system, but in most contexts this special form is used to handle ruler-relative units—typically those returned by geometricBounds and visibleBounds properties.

Note: Do not confuse input and output units. While the location specifier is expressed in the ruler-relative syntax, the output of resolve() is always in points, since it always refers to a coordinate space.

Report · Jan 23, 2018

https://forums.adobe.com/people/Marc+Autret … Note: Do not confuse input and output units. While the location specifier is expressed in the ruler-relative syntax, the output of resolve() is always in points, since it always refers to a coordinate space.

Ah! You guessed it…
Indeed I thought in this direction.

Thanks,
Uwe

Report · Jan 23, 2018

What's also interesting:

If we lookup zeroPoint in the DOM documentation the discription says:

"The ruler origin, specified as page coordinates in the format [x, y]."

Isn't that misleading? It should read: "…specified as coordinates in the format [x, y]", I think…

At least this was misleading me to believe, that I have to translate the values somehow and do a rotation of anchor values to counter the offset that I saw in my first attempt. So now—with your help—I can throw away a lot of code and replace it with your very efficient one.

Best,
Uwe

Report · Jan 23, 2018

If we lookup zeroPoint in the DOM documentation the discription says:
"The ruler origin, specified as page coordinates in the format [x, y]."
Isn't that misleading?

Yep, this is definitely misleading, since the terms "page coordinates" has absolutely no meaning by itself. As I wrote in my PDF:

“InDesign rulers support a user defined origin “specified as page coordinates in the format [x, y]” via the property Document.zeroPoint. Adobe’s documentation lacks exactness and accuracy on what the term “page coordinates” is supposed to refer to, since there is no apparent relationship between rulers’ orientation and the transform state of the pages.”

That was one of the main reason I needed to investigate InDesign coordinate systems. Despite the difficulty of the task and probably some mistakes, the purpose of my PDF was to answer that kind of questions…

Best,

Marc

Report · Jan 23, 2018

Hi Marc,

thank you very much for commenting and the code.

Will test soon…

Ok. Understood. It's no bug that if I apply a pair of x/y coordinates according to the anchor of a pathPoint as value for zeroPoint, that the zeroPoint will not be positioned at that coordinates if the spread is e.g. rotated.

However I see a real bug for users working on rotated spreads utilizing the cross-hairs of the rulers to drag and drop a zero point. The zero point will never land at the intended position.

Thanks,
Uwe

Report · Jan 23, 2018

However I see a real bug for users working on rotated spreads utilizing the cross-hairs of the rulers to drag and drop a zero point. The zero point will never land at the intended position.

I get your point and I agree.

However, any user who is crazy enough to change the zero-point in a 4° rotated spread view having counter-rotated pages should be prepared for a ride 😉

Report · Jan 23, 2018

https://forums.adobe.com/people/Marc+Autret wrote
… However, any user who is crazy enough to change the zero-point in a 4° rotated spread view having counter-rotated pages should be prepared for a ride 😉

Agreed.
But this nasty bug with setting the zero point by using the cross-hairs in rotated spreads is also with spreads that can be rotated by the Pages panel to the following angles: 90° CW, 90° CCW and 180°.

It's time to do a bug report on this issue again now that the InDesign Feedback site "Uservoice" is live:

Adobe InDesign Feedback

Regards,
Uwe

Report · Jan 25, 2018

Laubender wrote
… It's time to do a bug report on this issue again now that the InDesign Feedback site "Uservoice" is live:
Adobe InDesign Feedback

I did another report. Vote here if you like:

Dragging the zero point to a new location will not work in rotated spreads – Adobe InDesign Feedback

Regards,
Uwe

Report · Jan 23, 2018

https://forums.adobe.com/people/Marc+Autret wrote
… However, any user who is crazy enough to change the zero-point in a 4° rotated spread view having counter-rotated pages should be prepared for a ride 😉

Scripters as well 😉

As we can see in this example with rotated pages where I added a yellow rectangle according to the page.bounds array:

Also with bleed and slug values changed to 0 the selected green rectangle will return [object Page] if you ask for app.selection[0].parentPage :

The blue rectangle will return null when asked for parentPage. But that was expected:

Regards,
Uwe

Adobe Community

Resetting zeroPoint | Not working when pages AND spread are rotated

1 Correct answer