Copy link to clipboard
Copied
Dear forum,
Every time we are completing the current issue of our magazine we suffer from — as I call it — ‘the update numbering in the book’ bug.
Usually, we have enough time to check and fix the problems, but with the latest issue — the day before yesterday — things went a wrong way: at the last moment, I had to move pages in the book and update numbering. As the result, three images changed their position a little and PDF files went to the printers with the glitches unnoticed. I saw it but was thinking it was OK because in previous issues this was done intentionally: pics were moved over the spine on the opposite page a little — deliberately. Other coworkers who were working on these docs didn’t notice the change: most probably, they were too tired by the end of the working day.
Luckily, nothing terrible has happened: the RIP guys removed unnecessary pieces on the fly from the imposed PDF. But I would like to sort it out: why this happens and how to avoid it in the future.
Here, on my site, I wrote a detailed description of what happens illustrated with screenshots and included files for testing in case someone is willing to play with it.
Thank you in advance!
Regards,
Kasyan
This reply will get rather lengthy. It is showing jumps of objects that touch the jump zone. Touching the jump zone means the edge of an object lies within the zone. The edge of an object is defined by the visibilty of the object. Applied strokes to a rectangle will count! Nested objects like tables that run outside a text frame will not count. Anchored object that are touching the zone will not jump if the parent, the text frame with the anchor, is not touching the zone.
Let's illustrate this
...Copy link to clipboard
Copied
Hi Kasyan,
thanks for the download link.
Now that I had a first look into your documents, one thing did catch my eye:
The amount that your elements are moving is exactly the amount that inner and outer margins are differing in size.
Inner margins are 22 mm
Outer margins are 18 mm
That is no coincident!
Hm. Shall I predict that if the difference were 0 mm, that no element would move?
Not now. Perhaps tomorrow after having a second look.
Regards,
Uwe Laubender
( ACP )
Copy link to clipboard
Copied
Hi Uwe,
Thank you for your quick reply. Yes, setting both margins — inside & outside — to 20 mm seems to solve the problem: the images don't shift. So, as a workaround, theoretically it's possible to make both margins equal in InDesign and later on imposing at the printers, move pages 2 mm away from spine.
Regards,
Kasyan
Copy link to clipboard
Copied
Hi Kasyan,
did some additional tests. This time with documents I created from scratch in InDesign 2020.
Same issues if I'm using your values for page size and margins, number of gutters and gutter width. At one moment I thought I could provoke the bug even without doing a book file. With your values: yes. With different values for inner and outer margins: no.
What I can tell now:
1. The bug is already with InDesign CS6. I tested this as well.
2. If the bug hits: All frames are affected that touch the inner margins and end between the inner and the outer margins.
It's not, that touching the spine is important. No! Even frames that were 5 mm away from spine were affected, because the inner spine's value was 22 mm. Hm. Maybe it's important that the inner margins's value is greater than the outer margin's value?
EDIT: I'll share an update on why and how the bug works in a new reply below.
The main trigger for the bug is:
Changing the start page of a document from:
even to odd OR odd to even
AND changing this back
Don't think that's a bug with documents in book files per se.
A distinct value or a range of values for inner and outer margins with a facing pages document is the second trigger.
But I'm not sure what the exact values are. Or if there is a distinct range. Could also be a coefficient between inner and outer margins' values. EDIT: Deatils on this later below in an extra reply.
I also checked if the margin preferences for the individual pages in the document spreads were overridden.
But as far as I can tell this is not the case with your documents. And definitely it is not the case with my generated documents from scratch. For that test I used Marc Autret's function at:
EDIT: Overriding of margin preferences is not the cause of the bug.
Regards,
Uwe Laubender
( ACP )
Copy link to clipboard
Copied
Hi Kasyan,
I removed the original post's contents.
EDIT: I'll share an update on why and how the bug works in a new post below.
Regards,
Uwe Laubender
( ACP )
Copy link to clipboard
Copied
Hi Kasyan,
after intensive testing over the weekend I will postulate a zone where jumping of objects will happen.
I call this the jump zone. This is a longstanding bug. All objects on a page that will jump are clearly inside the page's area.
They should not move if pages are added or removed, if numbering of pages is changing.
What is a jump zone?
If horizontal values for left and right margins differ, there is a BUG that in effect forms a zone on the page.
I call this zone JUMP ZONE because objects that touch the zone with their edges could jump horizontally.
When will objects jump?
1. When a left-hand page becomes a right-hand page OR a right-hand page becomes a left-hand page.
2. When a left-hand page becomes a right-hand page and later when a right-hand page becomes a left-hand page again.
This could happen within a single InDesign document open.
WARNING:
It could even happen to InDesign documents that are not visibly open.
That's with InDesign documents that are part of a InDesign book file.
The book file's feature with auto-numbering pages can do this even if no document is visibly open.
The damage is done if auto-numbering took place AND the book file is saved.
How large is the jump zone?
The height of the zone is the height of the page.
The width of the zone can be calculated:
inner margin MINUS outer margin
How large is the jump?
The width of the jump zone.
Where is the jump zone positioned?
Positive value: The zone is at the spine of the page.
Objects that touch the zone jump towards the spine.
Negative value: The zone is at the edge of a page away from the spine.
Objects that touch the zone jump away from spine.
What versions of InDesign are affected?
All versions CC up to InDesign 2020, Mac OS X and Windows.
InDesign CS6, Mac OS X and Windows.
Possibly also InDesign CS5 and CS5.5, Mac OS X and Windows.
I did not test this.
How can I avoid jump zones?
Make right and left margin values the same!
Are there workarounds if I cannot avoid jump zones?
1. Anchor objects
that touch the jump zone to text frames that do not touch the jump zone.
Nested objects will not jump if the parent objects are not touching the jump zone.
2. Group an object
to another one that is touching the top or the bottom edge of the page.
Tests are showing that objects will not jump if they touch the bottom OR the top of the page.
( OR both, bottom and top edges of the page .)
Other things to consider about moving objects?
The following is independently of jump zones:
Objects could move to other pages if their edges touch exactly the horizontal edges on pages in facing pages.
Depending on the version of InDesign this could also happen with objects touching the spine.
Reason: Rounding errors.
What can provoke all this?
1. Add or remove an odd number of pages
so that left-hand pages become right-hand pages and vice versa.
2. Renumber start pages of sections
so that left-hand pages become right-hand pages and vice versa.
Note:
Every document has at least one section by default.
The start of that section is the first page in the document.
Some screenshots and test documents in my next post.
Regards,
Uwe Laubender
( ACP )
Copy link to clipboard
Copied
This reply will get rather lengthy. It is showing jumps of objects that touch the jump zone. Touching the jump zone means the edge of an object lies within the zone. The edge of an object is defined by the visibilty of the object. Applied strokes to a rectangle will count! Nested objects like tables that run outside a text frame will not count. Anchored object that are touching the zone will not jump if the parent, the text frame with the anchor, is not touching the zone.
Let's illustrate this with a couple of screenshots.
A facing pages document where horizontal margins are set where the inner margins' values differ from the outer margins' values.
Master A: Inner margins are smaller than outer margins
Master B: Outer margins are smaller than inner margins ( that's the case with your document! )
Page 1 of the document with some rectangles on the page:
Pages 2-3 of the document:
On the left-hand page master A is applied, on the right-hand page master B is applied.
Pages 4-5 of the document:
In this case the margins from the master are overridden:
The next screenshots are showing the proposed jump zones ( yellow zone with guides ) where objects that touch the zone will probably jump:
Now I will provoke the bug by doing two things:
1. Change the start page of the document from 1 to 2 so that left-hand pages become right-hand pages and right-hand pages become left-hand pages:
At this time some objects already jumped position. Some did not. When and why is dicussed at the end of this post.
2. Now I change the start number of the document back to 1.
This will bring us not back to the original position of all objects on the pages in the document:
The results discussed:
All files and screenshots can be downloaded from my Dropbox account:
https://www.dropbox.com/s/duov096cu2q481l/Jump-Zones-Explained-Facing-Pages-Documents.zip?dl=0
Regards,
Uwe Laubender
( ACP )
EDITED: 3 February 2020
1. Did a bug report at Adobe InDesign Uservoice:
Objects on the page jump if a left-hand page becomes a right-hand page and vice versa
Uwe Laubender, December 02, 2019
2. Kasyan discovered a workaround:
Lock all items in your document before adding pages, removing pages or moving pages around:
https://community.adobe.com/t5/indesign/bug-in-book-s-update-numbering-feature/m-p/10842790#M170295
Copy link to clipboard
Copied
Hi Kasyan,
did a bug report at Adobe InDesign Uservoice:
Objects on the page jump if a left-hand page becomes a right-hand page and vice versa
Uwe Laubender, December 02, 2019
Please vote for fixing the bug. Thanks.
Uwe Laubender
( ACP )
Copy link to clipboard
Copied
Hi Uwe,
I am terribly sorry for the late reply! For months, I had no access to the e-mail account I was registered here on the forum so, after the forum software update, I didn't get any notifications about new replies.
Only today, I restored access to it and found out your reply.
Thank you very much for your scrupulous research!
To solve the problem I wrote a script which I run from my 'batch processor' against the active book twice:
I am going to share the script on my site.
I voted for your bug report.
Thank you a lot again!
Regards,
Kasyan
Copy link to clipboard
Copied
Hi Kasyan,
thank you for voting to fix the bug!
However, I see that only 3 votes are done for now. So we will not see a fix in the near future, I think.
It took me a day or two to get all the details of the bug. Also did a script for internal use that is creating the yellow rectangles and some guides to visualize the "jump zones" of a facing-pages document.
Regards,
Uwe Laubender
( ACP )
Copy link to clipboard
Copied
Uwe,
I posted a tweet asking my followers — who are mostly script developers/users — to vote. Also, I just made a quick test: it doesn't happen with locked objects, but it does happen on locked layers. So, an alternative approach to solve this by the script would be the following:
— Kas
Copy link to clipboard
Copied
Hi Kas,
thanks so much. What a cool discovery!
Locking all objects before adding or removing pages to a document is a fantastic workaround.
And it's so easy doing this by a ExtendScript (JavaScript):
// WARNING: Here we do not bother if some items are already locked before
// and should stay locked after unlocking all again:
app.documents[0].pageItems.everyItem().locked = true;
The reverse, unlocking all items in the active document:
// WARNING: Here we do not bother if some items were already locked before
// and should stay locked after unlocking all again:
app.documents[0].pageItems.everyItem().locked = false;
Regards,
Uwe Laubender
( ACP )
PS: Totally missed your answer here. Just discovered it right now.
Copy link to clipboard
Copied
Finally, being on lockdown at home because of coronavirus, I found time to post my solution to the problem here on my site.
— Kas