Blank pages in Epub when it is read.

[mattfr]

I am just wondering if anyone has some words of wisdom about the blank pages issue in Epub readers? Is there anything in the code of the Epub you can add to prevent this phenomenon? It seems random on different Ereaders. No matter how clean the code is at the end of the section the blank page still appears when it is read with an Ereader. Thanks, Mattfr

[Karellen]

Do you have a book you can share? If it is in copyright, you could scramble it before uploading.

[DiapDealer]

Do you have any reason to believe Sigil lies at the root of your issue? Using Sigil to make a problematic epub does not necessarily make this about Sigil. Post some code samples and we might be able to rule Sigil out (or in). Otherwise, we're flying completely blind.

[JSWolf]

Originally Posted by mattfr

I am just wondering if anyone has some words of wisdom about the blank pages issue in Epub readers? Is there anything in the code of the Epub you can add to prevent this phenomenon? It seems random on different Ereaders. No matter how clean the code is at the end of the section the blank page still appears when it is read with an Ereader. Thanks, Mattfr

The problem comes in some programs when the content hits the bottom of the page. If the next page is another HTML file, then you could get a blank page.

This has nothing to do with Sigil.

[Turtle91]

As JSWolf mentioned, it is more than likely some kind of overflow issue. Unfortunately, your coding could be perfectly correct but the reader device/app could be causing it's own issues...thus the randomness.

For example, if you have an image on a page that uses 100%, or 100vw/vh, that would be perfectly acceptable coding...But if the device/app calculates screen space and sets aside landscape for headers, footers, etc. the TOTAL area used would be greater than the screen...causeing the overflow and the extra blank page at the end.

As Diap mentioned, we can't troubleshoot any further without something to work with...example coding and what devices you are seeing the problems with would help.

Cheers!

[JSWolf]

Originally Posted by Turtle91

As JSWolf mentioned, it is more than likely some kind of overflow issue. Unfortunately, your coding could be perfectly correct but the reader device/app could be causing it's own issues...thus the randomness.

For example, if you have an image on a page that uses 100%, or 100vw/vh, that would be perfectly acceptable coding...But if the device/app calculates screen space and sets aside landscape for headers, footers, etc. the TOTAL area used would be greater than the screen...causeing the overflow and the extra blank page at the end.

As Diap mentioned, we can't troubleshoot any further without something to work with...example coding and what devices you are seeing the problems with would help.

Cheers!

I wonder if there is a fix for this if it is an overflow issue.

For an image, use a bottom margin of 0. For the last paragraph, use a class that gives it a bottom margin of 0.

Do you think these might work?

[Turtle91]

I have these same issues even with a zero margin set on everything, that's why I mentioned that it could be caused by the device/app itself rather than anything the coding does. Hard to tell without seeing any of the coding.

[JSWolf]

Originally Posted by Turtle91

I have these same issues even with a zero margin set on everything, that's why I mentioned that it could be caused by the device/app itself rather than anything the coding does. Hard to tell without seeing any of the coding.

I normally have blockquotes set with a 1em bottom margin. But when the blockquote is at the end of the chapter, I use a class to set the bottom margin to 0 so a blank page might not happen.

[Turtle91]

And that almost certainly helps, but the problem is still there even when ALL items have a zero margin. I’m pretty sure ONE of the issues is how (and in what order) the device/app allocates it’s reading space. That is completely independent of the coding. I’ll draw a picture of what I mean after I get home from work.

[JSWolf]

Originally Posted by Turtle91

And that almost certainly helps, but the problem is still there even when ALL items have a zero margin. I’m pretty sure ONE of the issues is how (and in what order) the device/app allocates it’s reading space. That is completely independent of the coding. I’ll draw a picture of what I mean after I get home from work.

I use Bookfusion on iOS and the problem of the blank page does exist.

[Turtle91]

Sooo, here's a pic to demonstrate what I was trying to explain. This is my current theory. I'm open to others...



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.

[JSWolf]

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.

[Turtle91]

Originally Posted by JSWolf

ADE/RMSDK does not show blank pages that I know of. Bookfusion does show blank pages.

Unfortunately I am not privy to which methodology the different devices/apps use....so the only way to get it fixed is to submit a bug report to the respective programmers.... Obviously after you've checked that there are no problems with the epub code itself.

FYI, I got this theory from conversations with Kris during his creation of Marvin. He did not publish a fix, so Marvin also suffers from this minor, but annoying, problem.

[JSWolf]

Originally Posted by Turtle91

Unfortunately I am not privy to which methodology the different devices/apps use....so the only way to get it fixed is to submit a bug report to the respective programmers.... Obviously after you've checked that there are no problems with the epub code itself.

FYI, I got this theory from conversations with Kris during his creation of Marvin. He did not publish a fix, so Marvin also suffers from this minor, but annoying, problem.

I did report the bug in the Bookfusion thread. I'll see how that goes.

[PeterT]

Why not include a test book that exhibits the issue along with some screen shots

Sent from my Pixel 7a using Tapatalk