There are other scenarios where this will be a problem though, as I'm basically forcing the chord pro to be rendered to a specific page size (and aspect ratio) regardless of the screen size and dimensions:
1) If your device is in landscape orientation, MobileSheetsPro would no longer make use of the additional width and generate multiple columns. Instead, it would work like PDFs where the page would either be made extremely small (if the page scaling is set to "Fit Screen") or would be enlarged beyond the height of the screen (if using a page scaling like Fit Width)
2) If the aspect ratio of the generated image doesn't match that of the screen, you are going to wind up with wasted space, as the image won't fill the screen.
3) The quality of the rendered image may be worse due to the scaling. The impact of the scaling (and how noticeable it is) will depend on whether the rendered image is scaled up or scaled down.
Right now, I'm already using the approach of rendering the text file to an image, but the image is sized to match the dimensions of the screen, and the logic for laying out the pages of the chord pro file (and where to break lines, and such) is based on those dimensions, so no scaling is necessary. If I want to switch to either using a fixed size, or allowing the user to pick the page size, updates will be needed so that, when the code is trying to figure out what size bitmap to allocate for the image for the page, instead of using the screen dimensions, it grabs the fixed/user size instead. The framework will then figure out how much it needs to scale that size to fit the screen based on the page scaling setting, and the rest of the code should naturally work. This approach won't work for allowing one long continuous page with no breaks - that requires a much larger change to the framework because instead of scaling the image down to fit the screen, I have to tell the framework that instead of using the screen dimensions to lay things out, I want to use a value specified by the user.
Mike
1) If your device is in landscape orientation, MobileSheetsPro would no longer make use of the additional width and generate multiple columns. Instead, it would work like PDFs where the page would either be made extremely small (if the page scaling is set to "Fit Screen") or would be enlarged beyond the height of the screen (if using a page scaling like Fit Width)
2) If the aspect ratio of the generated image doesn't match that of the screen, you are going to wind up with wasted space, as the image won't fill the screen.
3) The quality of the rendered image may be worse due to the scaling. The impact of the scaling (and how noticeable it is) will depend on whether the rendered image is scaled up or scaled down.
Right now, I'm already using the approach of rendering the text file to an image, but the image is sized to match the dimensions of the screen, and the logic for laying out the pages of the chord pro file (and where to break lines, and such) is based on those dimensions, so no scaling is necessary. If I want to switch to either using a fixed size, or allowing the user to pick the page size, updates will be needed so that, when the code is trying to figure out what size bitmap to allocate for the image for the page, instead of using the screen dimensions, it grabs the fixed/user size instead. The framework will then figure out how much it needs to scale that size to fit the screen based on the page scaling setting, and the rest of the code should naturally work. This approach won't work for allowing one long continuous page with no breaks - that requires a much larger change to the framework because instead of scaling the image down to fit the screen, I have to tell the framework that instead of using the screen dimensions to lay things out, I want to use a value specified by the user.
Mike