Posts: 1,047
Threads: 112
Joined: Dec 2015
Reputation:
11
04-26-2024, 08:46 AM
(This post was last modified: 04-26-2024, 08:47 AM by BRX.)
I think I reported this before but I can't find the thread anymore.
I'm using half page turns in vertical mode and prepare my sheets for D.C./D.S, al coda by duplicating the pages with the page order and crop the not needed parts.
But it still happens that at the turn from the next to last to the last page (and if the last page is only a cropped coda with one or two lines) the lower half page of the next to last pages doesn't stay in place and with the page turn becomes the upper part of the last page with the coda following.
That's not good for the sheet reading. You expect the last half page tp stay in place and read it to the end. Instead it "disappears" (to the next page) unexpectedly with the half page turn and you have to focus and find your place in the tune anew which is very confusing.
Do you know what I mean or do you need an msf with a song where this happens?
Posts: 13,323
Threads: 301
Joined: Apr 2012
Reputation:
235
Send a .msf and .mcf (Settings->Backup and Restore->Export Settings) to mike@zubersoft.com so I can take a look at it. This will just be easier for me to investigate it. One thing I'll say is that I don't allow half pages from different songs to be shown at once - I think that's really important to avoid confusion. It sounds more like you are saying the page is shifting unexpectedly though on the last page.
Thanks,
Mike
Posts: 1,047
Threads: 112
Joined: Dec 2015
Reputation:
11
04-26-2024, 08:51 PM
(This post was last modified: 04-26-2024, 08:51 PM by BRX.)
Yes, that's the case. The page that is shown in the lower part doesn't stay there when the page is turned but is show as the upper part of the last page (thus vanishing from the focus of the eyes). I'll send you a link with the files. I guess it's because of the cropping of the pages.
Posts: 13,323
Threads: 301
Joined: Apr 2012
Reputation:
235
Brix,
I finally had time to look at the files you sent. We need to discuss what you believe would be the correct way to handle the scenario with your file in a way that is consistent in all possible scenarios. Here are the issues:
1) On page 5, it is cropped enough that both pages 5 and 6 will fit on one page, so MobileSheets displays it that way as it would be pointless to require an additional page turn to see page 6 when it fits at the bottom
2) If a page turn occurs, page 6 would normally be left at the bottom and page 7 would be shown at the top, but page 6 is less than half the height of the screen, so a half page turn doesn't make sense. Also, page 7 is also so small that it doesn't even take up half the screen, so pages 6 and 7 can both fit on the screen at the same time. For this reason, MobileSheets shows page 6 at the top and page 7 at the bottom.
I understand that you don't want this behavior, as you want page 6 to remain at the bottom. Here is the problem though - I would have to shift page 6 up after the page turn, otherwise page 7 would be anchored to the top of the screen and page 6 would be at the bottom of the screen with a weird gap between them. That seems like it would be terribly confusing to a user. If I don't do that, and anchor the bottom of page 7 to the top of page 6 at the bottom of the screen, this causes complete chaos with the layout code, as that's now a special situation that only makes sense when each page is of a certain size. Also it might be confusing to see the pages in that order as there is no half page turn that occurs and no half page turn divider between the pages. Also, the behavior needs to make sense even when the user isn't turning half pages (i.e. they jump to page 6 with the page slider or if it was the last viewed page). Having the pages in the wrong order in this scenario would just be confusing, as the user didn't see page 6 at the bottom to start.
So I need recommendations on what you believe would not be confusing to get you what you want, but also still work when jumping to a page when there are multiple pages that all fit on the screen at the same time. One way to accomplish this without a code change is to add blank pages to your PDF, use the snipping tool to copy over the segments you want to keep, and remove pages 6 and 7 from the page order. The location you paste the images would determine where they land with the half pages and then it would work the way you want.
Thanks,
Mike
Posts: 1,047
Threads: 112
Joined: Dec 2015
Reputation:
11
05-03-2024, 01:44 AM
(This post was last modified: 05-03-2024, 01:45 AM by BRX.)
Hi Mike. Thanks for looking into the problem. I already assumed that this happens due to the (small) crops essentially and see your problems solving that.
I'm aware I could circumvent it with blank pages or better editing the PDF itself so that the short crops are indeed on a real page together but I don't like changing/editing the PDF for that. I could highlight the "moving part" so it's easier to see what happened and find it again.
Essentially I'd like to prevent the "vanishing" of the notes you are looking at. As I said it happened with this song and it was disorienting and I lost my place in the tune. But I have no good solution how to tell MS to recognize the situations where pages are too small and this can happen.
I have only one idea consisting of two parts (if possible).
Is it possible I can tell MS through the page numbering if it can and shall consider two (or more) cropped pages as one page, so a page turn turns directly to the next page after the last cropped one (still talking half pages here).
Let's say you have pages 1-3,4,5,6 and 4 and 5 are cropped to fit (cropped) on a half page. If you allow a syntax like 1-3,(4,5),6 which would treat 4,5 as a whole (half) page and turns directly to 6 appearing at the top while 4,5 stay at the bottom? Is this feasible?
Also one could use [] to indicate that a page should not integrate the next one to show together so that small crops can be turned separately as half pages without moving. Does that make sense?
This doesn't prevent the unexpected move if the user didn't prepare it beforehand and adjusts the order. So the second part could be a warning if a user crops a page that it is less than a quarter of the orginal page that this could lead to show other pages with it on the screen and to unexpected moves while page turning. (Of course there should be a box with "do not show this warning again" so it doesn't pop up every time and nags, but you would have done a warning you can always refer too if somebody complains).
I don't have other ideas right now. Do you see other solutions to the (probably relatively rare) problem?
Posts: 13,323
Threads: 301
Joined: Apr 2012
Reputation:
235
Is it possible I can tell MS through the page numbering if it can and shall consider two (or more) cropped pages as one page, so a page turn turns directly to the next page after the last cropped one (still talking half pages here).
No, that's not currently possible, and would be quite complicated to support. This would basically require a lot of new code that would render each cropped page individual, then combine them into a new bitmap, and treat that as the image for the page. However this would require so many complicated changes with changing the page order to support specifying that multiple pages should be combined as one, changes to the rearrange pages screen to support this concept (not even sure how it would show up in the UI), and then all the rendering changes. I really don't want to go down this path, as it then also causes all sorts of complexity with the processing if the user zooms in on the page, or changes the page order to eliminate the joined pages later after making changes that wouldn't make sense with the original page size. I think you would be better off modifying the PDF itself using the snipping tool to just white out the existing page using the cut option and then just past the parts you want on top of that. These changes are completely reversible in the annotation editor if needed.
As far as solutions - using the vertical scrolling display mode for this one song would be one solution, as you wouldn't end up with the half page turn problem.
Mike
Posts: 1,047
Threads: 112
Joined: Dec 2015
Reputation:
11
Yeah, I have to agree that it's not worth those big changes to solve these rare occurrences (of course I'm aware it's not possible with the current code and meant a future implementation).
I will prepare the pages one or the other way to prevent the "move" and hope I'm seeing the problem beforehand in rehearsal or when preparing the page order so it doesn't happen unexpectedly live.
Thanks for considering.
Posts: 1,047
Threads: 112
Joined: Dec 2015
Reputation:
11
Hi Mike, just a little postscriptum.
I was adjusting the song with the snipping tool and because I misread your "you can revert it in the annotation editor" a bit I snipped and pasted on the "doubled through page order" first page.
And that was (as I understand or rather haven't found a way to undo) not reversible since I pasted over some notes and of course that showed up in both iterations of the doubled page.
I was able to revert it with a "swap file" from a backup, but if I hadn't have that I'd have damaged/destroyed my original pdf.
So I would appreciate it if you supply the same warning like in the page order editor for cases when a PDF is permanently changed by pasting with the snipping tool. It took me by surprise that it didn't after the discussion for the page order editor and the (I think excellent) way of warning you ended up for that.
Posts: 13,323
Threads: 301
Joined: Apr 2012
Reputation:
235
You can undo those changes - just tap the three dots at the top right corner of the annotations editor, then tap "Allow editing of embedded PDF annotations". Then you can delete any image you pasted.
Mike
Posts: 1,047
Threads: 112
Joined: Dec 2015
Reputation:
11
|