Okay, I see what you're talking about now, Zuberman.
You are thinking of it it in terms of how the application tracks things internally. I am thinking of it in terms of how I (the user) see it.
I don't see any problem with having it work the way I suggested. Even if it were a combo of PDFs and JPGs. PDFs have the concept of pages, so any PDF that is part of a song would have its pages recognized. JPGs do not have a concept of pages, so any JPG would be treated as a single page.
The Files tab has an order for all the components (PDFs and JPGs) of a song. The song's page order should simply be the page order of each component, in the order the components are set in the Files tab.
So, if there was a PDF with 2 pages, a JPG, and another PDF with 3 pages, then the song would have 6 pages. If they were in that order on the Files tab, then p.1 and 2 would be the pages from the first PDF. Song page 3 would be the JPG, and song pages 4 - 6 would be the pages from the second PDF. If a JPG were actually more than one page and the user wanted to treat it that way, the user would use a custom page order to have the JPG shown twice (or however many is needed) and then crop each one to show only the portion of the JPG that is desired. That is just how I do it now with a multi-page PDF that has a DS and Coda requiring showing the 1st and 2nd pages multiple times, but showing a different portion of the page each time.
From the user perspective, this is the intuitive way for it to work.
There is no reason for the internal organization of the component files to be exposed to the user.
The application already works (at least with multiple JPGs) to display the pages in the correct order., so it already has the info that it needs.
From the user perspective, the 4th page I see as I hit my page turner button (when there is no custom page order defined), should be referred to as Page 4 in the custom page order field, period. My example song has 2 pages. The application knows there are two pages there as it shows them to me one after the other. Therefore, the application should allow me to refer to Page 2 in the custom page order.
Anyway, if I can ever figure out how to get my printer/scanner to work with Linux, I will scan the pages into PDFs and be done with this problem (until the next rehearsal where they hand me more pages of sheet music...). But, for now, my printer and computer are not playing nicely together.
You are thinking of it it in terms of how the application tracks things internally. I am thinking of it in terms of how I (the user) see it.
I don't see any problem with having it work the way I suggested. Even if it were a combo of PDFs and JPGs. PDFs have the concept of pages, so any PDF that is part of a song would have its pages recognized. JPGs do not have a concept of pages, so any JPG would be treated as a single page.
The Files tab has an order for all the components (PDFs and JPGs) of a song. The song's page order should simply be the page order of each component, in the order the components are set in the Files tab.
So, if there was a PDF with 2 pages, a JPG, and another PDF with 3 pages, then the song would have 6 pages. If they were in that order on the Files tab, then p.1 and 2 would be the pages from the first PDF. Song page 3 would be the JPG, and song pages 4 - 6 would be the pages from the second PDF. If a JPG were actually more than one page and the user wanted to treat it that way, the user would use a custom page order to have the JPG shown twice (or however many is needed) and then crop each one to show only the portion of the JPG that is desired. That is just how I do it now with a multi-page PDF that has a DS and Coda requiring showing the 1st and 2nd pages multiple times, but showing a different portion of the page each time.
From the user perspective, this is the intuitive way for it to work.
There is no reason for the internal organization of the component files to be exposed to the user.
The application already works (at least with multiple JPGs) to display the pages in the correct order., so it already has the info that it needs.
From the user perspective, the 4th page I see as I hit my page turner button (when there is no custom page order defined), should be referred to as Page 4 in the custom page order field, period. My example song has 2 pages. The application knows there are two pages there as it shows them to me one after the other. Therefore, the application should allow me to refer to Page 2 in the custom page order.
Anyway, if I can ever figure out how to get my printer/scanner to work with Linux, I will scan the pages into PDFs and be done with this problem (until the next rehearsal where they hand me more pages of sheet music...). But, for now, my printer and computer are not playing nicely together.