I'm adding image support with the next update (it's already implemented, I'm just about to start testing all the different options).
maks261 - The main reason I didn't support it at the moment is due to the dynamic nature of ChordPro and text files. They don't have a predefined number of pages, and the number of pages can change drastically depending on changes to the text display settings. Many of the features in MobileSheets are tied to the page of a song (not to the page of a file). For example, if you place link points, bookmarks, annotations, etc, they are tied to the song page, which may or may not be the same as the file page. So if a link point is tied to page 3 of a song using a ChordPro file, then you decreased the text display settings so that now there is only one page, what should happen to that link point? At the moment, nothing happens to it - it's just not displayed, and if change the text display settings back so that there are three pages again, the link point would show up like you would expect. Now let's assume there is a PDF after the ChordPro file. Now what should I do? Should I delete the link point? Should I incorrectly show it on the PDF? There is nothing in the code that ties it to the ChordPro file, so MobileSheets does not know which file it should be associated with. Could I rewire all the code to use file pages instead of song pages? Yes, but it would require significant changes. The "file page" in this instance would still have to be in terms of the page ordering, because users can remove pages, duplicate pages, etc, and have different elements (annotations, bookmarks, link points, etc) on different instances of a page. So I would need to go through the entire database and change things so that everything is tied to the page of a particular file (and add a reference to the database file ID), and then change all of the code everywhere that uses song pages to instead map that to file pages before accessing things like link points, annotations, etc. I would also then have to rework all of the code that tries to figure out how to correctly handle changes to page orders. However, once all this work is done, some things would actually get simpler, and then I could support dynamic file types at the same time as files with a fixed number of pages. So it's probably something I will do long term, maybe when I tackle the song versioning changes, but it's definitely not something I want to tackle in the short term due to the huge amount of code changes this will result in (and the potential for bugs).
Mike
maks261 - The main reason I didn't support it at the moment is due to the dynamic nature of ChordPro and text files. They don't have a predefined number of pages, and the number of pages can change drastically depending on changes to the text display settings. Many of the features in MobileSheets are tied to the page of a song (not to the page of a file). For example, if you place link points, bookmarks, annotations, etc, they are tied to the song page, which may or may not be the same as the file page. So if a link point is tied to page 3 of a song using a ChordPro file, then you decreased the text display settings so that now there is only one page, what should happen to that link point? At the moment, nothing happens to it - it's just not displayed, and if change the text display settings back so that there are three pages again, the link point would show up like you would expect. Now let's assume there is a PDF after the ChordPro file. Now what should I do? Should I delete the link point? Should I incorrectly show it on the PDF? There is nothing in the code that ties it to the ChordPro file, so MobileSheets does not know which file it should be associated with. Could I rewire all the code to use file pages instead of song pages? Yes, but it would require significant changes. The "file page" in this instance would still have to be in terms of the page ordering, because users can remove pages, duplicate pages, etc, and have different elements (annotations, bookmarks, link points, etc) on different instances of a page. So I would need to go through the entire database and change things so that everything is tied to the page of a particular file (and add a reference to the database file ID), and then change all of the code everywhere that uses song pages to instead map that to file pages before accessing things like link points, annotations, etc. I would also then have to rework all of the code that tries to figure out how to correctly handle changes to page orders. However, once all this work is done, some things would actually get simpler, and then I could support dynamic file types at the same time as files with a fixed number of pages. So it's probably something I will do long term, maybe when I tackle the song versioning changes, but it's definitely not something I want to tackle in the short term due to the huge amount of code changes this will result in (and the potential for bugs).
Mike