[alex_hk90]

I think we are basically saying the same thing.  It's just not entirely straight-forward to figure out which pages to copy if the same source page is already present multiple times in the page ordering and you decide to change the page order drastically.  For example, if I have 1,3-4,6,1,3-4,6, and then I decide to add "1,3-4,6" again at the end, I have to decide programmatically which instance of those pages to copy annotations/cropping from. I could just default to using the first instance found in the previous page ordering, but there are plenty of times where that would be wrong, and people might argue I should use the last instance.  Also, if I do something like remove some of the pages in the middle, I'm currently preserving the page the annotations are assigned to (in terms of the song's pages, not the source file) in case the user changes the page ordering multiple times in a row. This of course is why the annotations don't currently shift to match their originally assigned page.  Going forward, I'm going to have to just outright delete all of the information for the pages if the page order is changed and pages are removed.  People will just have to realize that changing the page order can have a large impact on what annotations/cropping values are present on a given page.

Mike

I think we're saying similar things. I agree you can't really automatically determine which instance of the source page should be copied, so instead the user should decide this.

To go through an example to illustrate how I'm thinking this could work:
- the source file has 6 pages, and when you import the file into MobileSheets it automatically creates 6 pages (in order 1-6) corresponding to the source pages;
- these pages (1,2,3,4,5,6) are now independent from the source pages (in the backend MobileSheets would think of them something like A,B,C,D,E,F), so any annotations/cropping/etc. on them will be maintained on the specific page (i.e. annotations on 2/B remain on 2/B rather than 1/A even if it is re-ordered: 2,1,3,4,5,6 = B,A,C,D,E,F) - this handles moving/re-ordering;
- for removals/deletions (i.e. 2,1,4,5,6), there would be a warning that all annotations/etc. will be lost for that page (3/C in this case);
- for adding new pages, the user would have the option of either copying an existing page or importing it from scratch from the source file: if you copy an existing page you get all the annotations/etc. from that page (e.g. from 2,1,4,5,6 you decide you want to duplicate the first 2 to get 2,1,4,5,6,2, which is actually B, so behind the scenes it creates B,A,D,E,F,G, where G is a copy of B but now independent of B and 2);
- now you have 2,1,4,5,6,2 but actually B,A,D,E,F,G so you can have different annotations/etc. on the first 2 (B) than the second 2 (G);
- if you want another copy of page 2, you can either import it from the source file (without any annotations/etc.), copy the first 2 (B) to get the annotations/etc. from that, or copy the second 2 (G) to get the annotations/etc. from that - whichever way you will get (in the backend) B,A,D,E,F,G,H (for 2,1,4,5,6,2,2 - assuming you are creating the copy at the end, there's no reason you can't create it somewhere else) and you can then move any of the 2s (B,G,H) around maintaining their annotations/etc.;
- of course MobileSheets needs to know which of the 2s you are moving, so you won't just be able to type in what you want (e.g. 2,2,1,4,5,6,2) because it will be impossible to tell which order to put the 2s, instead if there is any chance of ambiguity (as there is in this example) it should tell the user and then the user would have to select/drag/up-down the specific pages you want to move (e.g. you could long-press on the second last 2 and drag it to the front - MobileSheets would see this as moving G to the front so result in G,B,A,D,E,F,H in the back-end, and still 2,2,1,4,5,6,2 in the front-end, with no ambiguity).

Is this the solution you were thinking of as well?