Most likely, the frame containing the skyline is touching the left-hand page.
Yes correct, skyline frame is touching the spine which is why its showing. So am I crazy that this is how IND has always worked? Just doesn't make sense that you'd have to nudge your graphics and design this way. Now all of my full bleed looking designs all have a 1 px white margin just so they don't show on a blank master? Just doesn't jive
I zoomed to make sure both the skyline and blue bg frames snapped exactly to the spine edge and now I am getting two different results. m1 right-hand page is still getting the footer and m2 left-hand page is getting the header. Both of the masters here (10 and 11) are using the same A master for the header/footer.
I think, it's a bug and not a corrupt file.
Can remember, that we discussed a perhaps related case years ago.
It was—and still even with InDesign CC 2017.1—it is weird:
Pasted inside objects suddenly were missing on an odd document page after a different master was applied on the corresponding even document page.
Here some posts—different cases in detail—that could be related:
Re: Why does implementing Indesign cs6 master page affect a whole spread, rather than a single page?
The problems revolve around:
1. Nested objects on nested master pages (masters based on masters).
2. Detached or not detached objects.
3. If nested objects' centers cross the spine.
Don't know if that matters, but I tried to recreate the problems back then with InDesign CC 2017.1—and succeeded.
Below a download link to my Dropbox account with a weird document where I tried to desribe the problems in detail by comments I did on the masters and the regular document pages:
If someone likes to open the InDesign document the presented spread will be A Master.
The issue presented in that document could be related to the issue reported here.
But I'm not sure.
To understand the problem I presented there first inspect the two master spreads and read my comments.
Then go to spread one of the document, read the comments there and finally proceed spread by spread to get what's going on and wrong.
Thanks for the information, definitely looks like a bug that should be identified and fixed by Adobe. In my experiments I randomly nudged, moved and snapped objects to the spine (without anything embedded in the frame) and depending on unknown factors I could get the object on the master to appear or disappear. I was beginning to think I was crazy! Hope this get resolved because its making my design process much more complex when designing books with 10 masters, 100's of pages and different synced books.
bugs like that are very hard to describe and to analyze.
Can you remember, if you ever had this situation? :
1. Master x is based on master y.
2. You detached items from y on x and removed them?
3. You detached items from y on x and moved them?
I think here lies a wide field where InDesign can err when it comes to pasted inside objects.
Be them frames holding images or deeper nested items. Frames in frames in frames etc.pp.
To workaround all this one could implement a workflow where
1. No master is based on another one.
2. No element is crossing the spine.
3. Elements touching the spine should be positioned 0.001 mm away from spine.
4. If possible let no pasted inside element's center cross the spine.
That would bring stability to InDesign documents and would prevent one from nasty surprises.
Yes. The troublesome document I am referring to involves master page items based on other masters. I always start with my foundation Phi Grid as the A master which has header and footer graphics. I then create a bunch of variations off that master and add new master page items. For this document I have a vertical line (from A master) on both pages and override and remove that line on other spreads.
But then again, I have other situations where I haven't moved or removed anything and the object still shows on a blank.
I agree, my students have the same problem when using facing pages. It isn't a consistent issue, but when it happens, it is annoying.
We usually zoom in and nudge it just a little and it goes away. Even more interesting is that if you move it back to the same spot you had it at originally, it usually won't reflow to the other page.
One work around is to re-enter the size values. For example, working on an A4 document and you have an rectangle box 210mm wide and set to '0' on the x axis, by changing the measurement of the box to 209.99999 seems to work, and Indesign automatically, jumps it back up to 210mm.
... and Indesign automatically, jumps it back up to 210mm.
It's an illusion that InDesign "jumps it back". In fact InDesign is showing 210 where indeed 209.999999999936 may be fact.
You could test that by scripting where the "real" bounds can be shown.
alert( "geometrciBounds:"+"\r"+app.selection.geometricBounds.join("\r") );
Or you could alert the positions of the path points in x/y pairs:
var sel = app.selection; var pathPoints = sel.paths.pathPoints.everyItem().anchor; alert( "path points anchors:"+"\r"+pathPoints.join("\r") );
You're absolutely right Uwe, the geometric bounds scripts also reveals the x/y points and show that the object is sat at -5.00000001 mm instead of -5 mm, so this could explain why the object is being attached to the other master page.