Map "traversal" -- notes shifting when you down/up arrow into/out of a container

I know this issue has been spoken about here, but I have done some testing and have noticed a pattern. Before I send it off to support, I just want to see if others are seeing the same behaviour.

In these series of GIFs, I have a note that shows the Y coordinate as its name (and for the uninitiated, as per atbref in Tb the Y axis is negative in the up direction and vice versa.)

What I’m doing is selecting the note, down-arrowing into it as if it was a container, and then up-arrowing back to the map above. In a certain bound (which in my tests seems roughly about -15 to the up and about +3 to the down (although I think it’s influenced by if the app is full-screened or windowed and how many notes you have and where they are), the up arrow back to the map from the map one level down returns the note to the previous scroll position as when you left it.

Have a look at the following few GIFS:

traverse1

traverse2

traverse3

All working fine.

However, once you get to a certain point down or up (and a similar thing happens on the X axis, not sure of the bounds the spread seems broader than the Y axis), the traversal starts with the note hunting out a point closer to Y=0 until the vertical scroll bar has hit its upper or lower limits:

traverse4

Using the breadcrumb bar to click back rather than the up arrow retains the previous map position with no traversal, but for those of us who prefer more keyboard and less mouse, it’s a bit of an annoyance (although Shift-Command-Up Arrow will retain the previous map position.)

If someone has the time, could they have a go at replicating this and then if it’s confirmed I’ll ping tech support with this thread.

Thanks in advance.

What version are you using?

Woops – sorry! 7.5.6. On Mojave 10.14.1.

I see similar behavior – although I didn’t follow the technique all the way to the end as described in the OP. It’s certainly an edge case – I don’t know if it would be commonly encountered in daily use.

Thanks for the confirmation.

I came across it when I was setting up a structure with containers, and going back up would scoot an upper-level map out of of view when I had enough vertical notes to push the bottom one over the boundary that triggers this.

I’ll pass this thread to support via email just for the info.

It depends on how nested your outline is from the root map. Each time you navigate up the Outline hierarchy (back from Child → Parent container), the system’s default view of the Canvas skews down and to the right (i.e. {-Y},{+X})

This is what’s causing the “shift” or “drift” of canvas views that everyone has been mentioning.


The best workaround is to set global params for all items to:

$MapScrollX=4;
$MapScrollY=4;
$InteriorScale=1.5;


An easy way to repair this with existing projects:

  1. copy the rule globally from Outline view (make sure to select all hidden children)
  2. adjust the system Default settings within Document Inspector (under System tab > Category: Map > Attributes: InteriorScale & MapScrollX & MapScrollY)

What this does:

  • each time you drill down from Parent → Child, the default {X,Y} will adjust to {4,4}.
  • each time you drill back up to the Parent, it will skew the Parent view. To fix this, drill up to the Grandparent, then drill down back to the Parent, this will reset the Parent view back to {4,4}.
  • be mindful when drilling down from your /root map without first re-adjusting the view position by scrolling up and to the left.
    • every other layer will self-correct except for /root (since you can’t set its Xpos & Ypos)
  • {4,4} at scale 1.5 was chosen to allow for those who still like to preview items within a Container’s viewport.
    • a good starting Parent container size for previewing nested notes at {4,4} is $Width=8.5; $Height=6
1 Like

Wow – many thanks for the very thorough briefing! Much appreciated!

I’m having a hard time reproducing this — and right now I’ve got containers with Ypos at +/- 42. Could you send along the sample document?

I won’t be near my Mac for a few days – but one thing I have according to the notes I took about it is that if I had multiple objects on a map separated vertically (containers/notes/not sure about adornments), that sometimes seemed to act as a limit to how far stuff would traverse up or down (or if at all).

Maybe just try it with one container on a map set at around Y+3.5 or greater until I can send through a sample (or someone else does).

Glad you asked since I wasn’t able to reproduce the viewport option at {4,4}. Sorry about that.

This simple instead adjusts to {11,11} for scaling purposes:

This approach is good for map-friendly folks but nullifies any viewport preview capabilities. As such, the container prototype closes the viewport and instead previews its child count.

The sample includes a few generations at different sibling sizes in order to preview layout differences for scaling grid arrays of differing (map) container size.

{11,11} seems to scale well at various sibling counts.

  • One negative is having to scroll up to Xpos/Ypos:{0,0} for newly added notes.
  • One positive is that {11,11} seems to more favorably de-skew the “shift & drift” when drilling up levels.

I think we’ve got this one under control in the current backstage release.

Great! And thanks @awohali for sending the file.

Dear @awohali

Although you posted this quite a while ago, I want to thank you very much for this advise and example file.
I am struggling for many many years being unhappy with continuously changing positioning in maps and this really works for me.
I still do not understand why 11,11 are the magic numbers though.
If still active would you be so kind to explain a bit more.

All the best, Paul