MobileRead Forums - View Single Post - Possible bug. Strange page numbering in ACCESS (sideloaded kepub)

arspr · 11-21-2013, 02:55 AM

A joint answer to both of them.

Koboish numbering is dynamic, relative, based over your current book layout. ADE/RMSDK is static and absolute based on whatever you want (character count, file size, compressed file size, they are all more or less equivalent).

Advantages of Kobo relative system. It looks "prettier" (every time you move your position you get a new number and that new number is +/-1 over your previous one) and therefore it shows you the amount of "page" turns you've made (and through a simple substraction, the number of pages you need till the end of chapter).

Disadvantages of Kobo relative system. Nearly everything else. Both of you insist in people asking for this system. But I've also seen a lot of people asking for a GoTo Page function... And that function is pretty much linked to an absolute system. Now, I understand the Koboish lack of it. In Kobo system you would need a lot of fields in that GoTo Page function (Chapter, page in chapter, AND rendering options) and it would possibly be nearly useless, because, was the 18th page I remember the same 18th page I have right now? Or did I changed anything in fonts/margins/whatever and old-18 is not current-18 anymore?

Advantages of ADE/RMSDK-like system. (Please notice the -like). You can easily see and compare sizes of books (aproximately). You can easily link to absolute possitions (aproximately) inside the book. You can have an easily implemented GoTo Page function.

Disadvantages of ADE/RMSDK-like system. It's "uglier". Page numbers do not have a direct link with page refreshes/movements. (BTW, do you actually keep looking at them? I mean, I NEVER look at page numbers in either ebooks or paper books BUT when I want to remember where something interesting/important was. Do you really NEED that every time you turn a virtual page that artificial number moves up/down by 1? Are you sure that it is a key feature?)

And now about my former "-like". Kobo has total control over his kepub rendering engine, don't they? If they detect flaws in the ADE method, please, just fix them, but do not break the whole scheme. I mean, compressed sizes are maybe affected by the compresion process. OK, then use html uncompressed sizes...

But if Kobo thinks what a majority of the people actually want is beauty over usefulness, then I agree they MUST keep its current system. I suppose I'm the weird one here when I prefer features over pretty flowers.

11-21-2013, 02:55 AM	#11
arspr Dead account. Bye Posts: 587 Karma: 668244 Join Date: Mar 2011 Device: none	A joint answer to both of them. Koboish numbering is dynamic, relative, based over your current book layout. ADE/RMSDK is static and absolute based on whatever you want (character count, file size, compressed file size, they are all more or less equivalent). Advantages of Kobo relative system. It looks "prettier" (every time you move your position you get a new number and that new number is +/-1 over your previous one) and therefore it shows you the amount of "page" turns you've made (and through a simple substraction, the number of pages you need till the end of chapter). Disadvantages of Kobo relative system. Nearly everything else. Both of you insist in people asking for this system. But I've also seen *a lot of people asking for a GoTo Page function...* And that function is pretty much linked to an absolute system. Now, I understand the Koboish lack of it. In Kobo system you would need a lot of fields in that GoTo Page function (Chapter, page in chapter, AND rendering options) and it would possibly be nearly useless, because, was the 18th page I remember the same 18th page I have right now? Or did I changed anything in fonts/margins/whatever and old-18 is not current-18 anymore? Advantages of ADE/RMSDK-like system. (Please notice the -like). You can easily see and compare sizes of books (aproximately). You can easily link to absolute possitions (aproximately) inside the book. You can have an easily implemented GoTo Page function. Disadvantages of ADE/RMSDK-like system. It's "uglier". Page numbers do not have a direct link with page refreshes/movements. (BTW, *do you actually keep looking at them?* I mean, I NEVER look at page numbers in either ebooks or paper books BUT when I want to remember where something interesting/important was. Do you really NEED that every time you turn a virtual page that artificial number moves up/down by 1? Are you sure that it is a key feature?) *And now about my former "-like".* Kobo has total control over his kepub rendering engine, don't they? If they detect flaws in the ADE method, please, just fix them, but do not break the whole scheme. I mean, compressed sizes are maybe affected by the compresion process. OK, then use html uncompressed sizes... But if Kobo thinks what a majority of the people actually want is beauty over usefulness, then I agree they MUST keep its current system. I suppose I'm the weird one here when I prefer features over pretty flowers.