Quote:
Originally Posted by Turtle91
Sooo, here's a pic to demonstrate what I was trying to explain. This is my current theory. I'm open to others...
Attachment 209840
The black square is the physical display...assume an 800x600 dimension.
The red squares are the header and footer...assume a 50x600 dimension.
The green box is the device/app calculated display size for the html page.
The left image shows where the device/app determines the header/footer positioning first, then the remaining landscape (700x600) is used for display of the html page. In this case the use of 100% or 100vh would return the 700x600.
The right image shows where the device/app determines the display size for the html page first (800x600) then adds the dimensions for the header/footer for a total (900x600) which is greater than the actual screen dimension.
The problem here is that you don't necessarily have to display anything in the header/footer, it's enough that the device/app reserves the space ... thus causing an overflow situation and an extra page.
Depending on what methodology the device/app uses to calculate display/page size, you can have some show the extra page, and some not. |
ADE/RMSDK does not show blank pages that I know of. Bookfusion does show blank pages.