wrong page numbers in epub file

[shtilkek]

hi, i have a pocketbook 623 and i have this problem where the number of pages doesnt correspond the number of "screens"

it takes 2-3 scrolls for the page counter to change

is there any way to fix this so it shows the actual number of pages? thank you!

[dmalinovsky]

It's by design. If you want to have screen pages, you should install KOReader.

[JSWolf]

Originally Posted by shtilkek

hi, i have a pocketbook 623 and i have this problem where the number of pages doesnt correspond the number of "screens"

it takes 2-3 scrolls for the page counter to change

is there any way to fix this so it shows the actual number of pages? thank you!

Pocketbook is using RMSDK which is th underlying software for Adobe Digital Editions. ADE uses 1024 uncompressed characters = 1 page. That's the most accurate eBook page numbering you can possibly get. The page number won't change if you change the font, font size, line-height, and any other settings.

[chrisridd]

Originally Posted by JSWolf

compressed characters

What does that mean? Text without the HTML markup?

[dmalinovsky]

Originally Posted by chrisridd

What does that mean? Text without the HTML markup?

Internally, ePub is just a ZIP archive with a special folder structure. So a page is 1K of a ZIP-archive. I know, it's not the best way since compression ratio will skew page numbers, but it's a de facto standard by Adobe.

[chrisridd]

Oh just a block of the uncompressed HTML? That’s surprisingly crude but apparently “good enough”

[dmalinovsky]

Originally Posted by chrisridd

Oh just a block of the uncompressed HTML? That’s surprisingly crude but apparently “good enough”

Even worse, it's a block of the compressed HTML.

[chrisridd]

Originally Posted by dmalinovsky

Even worse, it's a block of the compressed HTML.

Indeed

[rcentros]

Originally Posted by shtilkek

hi, i have a pocketbook 623 and i have this problem where the number of pages doesnt correspond the number of "screens"

it takes 2-3 scrolls for the page counter to change

is there any way to fix this so it shows the actual number of pages? thank you!

I like that the PocketBooks show ePub page numbers. But if you want to count screens instead, just go to Settings (when reading a book), tap Display (four arrows pointing to four corners) and turn off built-in page numbering. Unlike Kobos this isn't instant, PocketBooks calculate the number of screens and it takes maybe a minute or two to change this when you change margins or font sizes. (You'll three dots or dashes where the page numbers should be, until it's finished calculating.)

I should mention that I tested this on my Touch HD 3 and PB615 so it should be the same on the PB623 but I can't guarantee it.

[rcentros]

Originally Posted by dmalinovsky

It's by design. If you want to have screen pages, you should install KOReader.

You don't have to use KoReader, just turn off built-in page numbers and it will calculate (and number) the screens instead. As mentioned in my other post, it's not instant when you change font size or margins, but once you've got that set it's no different than using a Kobo (in KePub mode) or KoReader.

[JSWolf]

Originally Posted by dmalinovsky

Internally, ePub is just a ZIP archive with a special folder structure. So a page is 1K of a ZIP-archive. I know, it's not the best way since compression ratio will skew page numbers, but it's a de facto standard by Adobe.

1024 bytes as 1K can also mean 1000 bytes.

[shtilkek]

Originally Posted by rcentros

I like that the PocketBooks show ePub page numbers. But if you want to count screens instead, just go to Settings (when reading a book), tap Display (four arrows pointing to four corners) and turn off built-in page numbering. Unlike Kobos this isn't instant, PocketBooks calculate the number of screens and it takes maybe a minute or two to change this when you change margins or font sizes. (You'll three dots or dashes where the page numbers should be, until it's finished calculating.)

I should mention that I tested this on my Touch HD 3 and PB615 so it should be the same on the PB623 but I can't guarantee it.

thank you! but sadly it does not work for me, theres just no option like that i guess ill have to learn to live with it

[rcentros]

Originally Posted by shtilkek

thank you! but sadly it does not work for me, theres just no option like that i guess ill have to learn to live with it

I'm sorry to hear that. I thought my PB615 (Russian version of the Basic Lux) would be about the same age as your Touch Lux, but I guess it must be a little newer.

[Eric Muller]

IIRC, it's actually 1024 bytes of the uncompressed HTML file that make up a page. The idea is to be able to compute a number of pages solely from the zip headers, without having to look inside (i.e. uncompress) the HMTL files, and consequently to be able to navigate to a certain page by opening solely the corresponding HTML file. Zip headers indicate the uncompressed size, so there is no reason to use the compressed size; in fact, once you go "inside" an HTML, you need uncompressed bytes. This approximation works very well; after all, two paper editions of the same text can have very different page count, so there is no single truth (if you have to make it; of course EPUB also supports explicit page numbers, to match a given paper edition). Even the byte vs. character is not much of a problem in practice (although you can fool that by using NCRs in UTF-32 to get 32 bytes per character: "€" 8 characters per NCR and 4 bytes per character!)

Kindle took a different and more complicated approach. In particular, it better accounts for images. Also, remember that the notion of page comes into play for paying authors, so it needs to be more accurate; and Amazon is practically between every author and every reader, so it can spend some time determining page numbers.

[JSWolf]

Originally Posted by Eric Muller

IIRC, it's actually 1024 bytes of the uncompressed HTML file that make up a page. The idea is to be able to compute a number of pages solely from the zip headers, without having to look inside (i.e. uncompress) the HMTL files, and consequently to be able to navigate to a certain page by opening solely the corresponding HTML file. Zip headers indicate the uncompressed size, so there is no reason to use the compressed size; in fact, once you go "inside" an HTML, you need uncompressed bytes. This approximation works very well; after all, two paper editions of the same text can have very different page count, so there is no single truth (if you have to make it; of course EPUB also supports explicit page numbers, to match a given paper edition). Even the byte vs. character is not much of a problem in practice (although you can fool that by using NCRs in UTF-32 to get 32 bytes per character: "€" 8 characters per NCR and 4 bytes per character!)

Kindle took a different and more complicated approach. In particular, it better accounts for images. Also, remember that the notion of page comes into play for paying authors, so it needs to be more accurate; and Amazon is practically between every author and every reader, so it can spend some time determining page numbers.

Some say it's 1024 compressed characters and you say 1024 uncompressed characters. Do you have a link to show if it's compressed or uncompressed? I cannot seem to find anything.