Possible bug. Strange page numbering in ACCESS (sideloaded kepub)

[arspr]

Hi, this thread is a spin off from Kobo Extended Driver plugin thread. I posted the issue there (this is the first post) because I wasn't sure if it could be a driver conversion issue. But jgoguen has discarded it, and now my bets are fifty per cent in ACCESS bug, fifty percent in some strange bug or wrong format within the epub.

Less story and more description. The problem is that I detected that page numbers made strange jumps forwards and backwards on a "normal" ebook which had been kepubized. So, I stripped down the epub to get a test sample, and the bug is still there. I upload it (this is actually the epub_original version from this last post which includes a fixed toc.ncx)

Please, could some expert user take a look at it and explain what the hell is going on?

In order to test/replicate the issue:

• Grab the epub and add it to Calibre.
• In KoboTouchExtended driver tick "Enable Kobo Extended Features". (This setting enables automatic conversion from epub to kepub before uploading to your Kobo device).
• In KTE driver also enable "Use full book page numbers". (If you don't tick this option, you won't trigger the issue as ACCESS would show you the numbers of pages relative to each chapter, which are just one all the time. We want page numbering against the whole book).
• Send the book to your device using Calibre.
• The book has just eight chapters, (eight xhtml files), and each one has a short sample text saying its file name and the current position. Example: "info.xhtml -- 4/8" which tells you that you are in the info.xhtml file which is the fourth page/chapter/file in the book which has a total number of eight pages.
• Well, the bug is that if you look at the page number informed by ACCESS renderer in the footer, you will actually see this sequence when you advance through it: 1 (actually hidden as it's the initial file supposed to be a cover), 2, 3, 6, 7, 8, 4, 5
• Forget about the name of each file, they're just the true names of the files in the original true book. And also forget about some chapters showing or not in the footer. The book ToC only has entries for four of its eight files. (Or DO NOT forget about these data if you think that the problem is somehow triggered by them).

Thanks in advance.

[Rumpelteazer]

I've been having the same problem, it's only been happening in some of the books I've read in the past week or so. I'm a newbie when it comes to Kobo and since it started happening after I connected it to my notebook for the first time I assumed I messed up something in the settings (before I only had connected it to my desktop). I was planning on doing a factory reset when I finished my current book to see if that would fix it.

Sorry I can't be of more help.

[GeoffR]

Originally Posted by arspr

[*]In KTE driver also enable "Use full book page numbers". (If you don't tick this option, you won't trigger the issue as ACCESS would show you the numbers of pages relative to each chapter, which are just one all the time. We want page numbering against the whole book).

This is your problem, the full book page numbers for kepubs feature doesn't work properly, which is probably why Kobo disabled it.

[tlaine]

The table of contents in your sample is messing things up.

[arspr]

This discussion comes from KoboTouchExtended driver for Calibre thread

Originally Posted by davidfor

...When the user changes the font, font size, margins or line spacing, you rerender and recalculate the page numbers.

I've just noticed that when full book page numbering is off, Kobo does actually have that behaviour.

Wow!, I do think it's PREEETTY strange and USELESS. I mean, page numbering in a ebook is quite "stupid" as an accurate way of positioning. But it just has two main functions:

• Comparing (in an approximate way) book sizes. More or less like it happens with books in paper. A book with 100 pages is not exactly 10 times shorter than a book with 1000 pages because they will probably have completely different editions. But you can always say that the 100 page book is A LOT shorter.
• Allowing "accurate" (more or less) jumps or references inside the book. If I say "hey, I really liked the passage in page 32 about the hero death", anyone with the same book can easily find it. BUT with the Kobo system you have to say "... in page 32, with this font, this margin and that spacing". Very, very useful, more or less like a square wheel, which can also roll if pushed hard enough.

Nevertheless, this behaviour doesn't seem to be active in Full Book Page Numbering mode (luckily, although I'm not sure).

Originally Posted by davidfor

Yes it is on a low power device. To use per chapter page numbering, you render the current chapter and calculate the numbers. When the user changes the font, font size, margins or line spacing, you rerender and recalculate the page numbers.

To do full page numbering, you need to render the complete book. And re-render each time the settings are changed. For a short book, that will be OK. But, for a long book (think all of Lord of the Rings in one book), that could take some time. And the devices have limited RAM, so t might not even be possible.

Even if the numbering in full book mode went as in the strange Koboish chapter mode, what you say is not necessarily a serious difficulty.

I mean, after the first few tries looking for a comfortable looking, how many times do you change rendering settings in a book? And even if you are making thousands of changes a day because you are really nervous I propose the following method:

• Kobo devices has a beautiful DATABASE, don't they? So till you change something in rendering settings (or even in the book itself), you just need to perform that rendering ONCE and then write down the number of pages each chapter has.
• Of course, on the first run, if the book changes, (or because the weird Koboish numbering method, when you change the reading settings), you need to recalculate those page numbers. And, as you say, it can be really taxing with "The Bible" on Kobo ZX Spectrum model. But I suggest the following solution: can't you make that calculation in the background with your spare resources? I mean, just show a "Calculating pages" text in footer, keep your main CPU resources in making the device responsive to the user inputs without great delays, and then take all the time you need to finish that calculation.
• And because the RAM is also an issue, perform the former process splitting chapters/files in smaller pieces.

Originally Posted by davidfor

Full book page numbering with epubs and the RMSDK is only possible because it calculates the number of pages based on the compressed size of the files. They are independent of the reader settings.

I didn't know that was the process.

But nevertheless I think it's a clever, easy and accurate enough method. What problem does it actually have? Because the page numbering is made on the "amount of letters", (that's the size in disguise, with the added distortion of the compression process and the fact that a lot of those letters are invisible code tags), the only trouble it has is that "pages" with light and fast dialogues are going to be much longer than dense descriptions. And? I don't need an extremely accurate reference system, just a RELIABLE one.

So please, Kobo, as we say in a Spanish idiom: Do not try to fix what currently works.

[Terisa de morgan]

Originally Posted by arspr

• Allowing "accurate" (more or less) jumps or references inside the book. If I say "hey, I really liked the passage in page 32 about the hero death", anyone with the same book can easily find it. BUT with the Kobo system you have to say "... in page 32, with this font, this margin and that spacing". Very, very useful, more or less like a square wheel, which can also roll if pushed hard enough.

People is going to kepub because they want what you don't like

Originally Posted by arspr

Of course, on the first run, if the book changes, (or because the weird Koboish numbering method, when you change the reading settings), you need to recalculate those page numbers. And, as you say, it can be really taxing with "The Bible" on Kobo ZX Spectrum model. But I suggest the following solution: can't you make that calculation in the background with your spare resources? I mean, just show a "Calculating pages" text in footer, keep your main CPU resources in making the device responsive to the user inputs without great delays, and then take all the time you need to finish that calculation.

Not good. Users are not going to be happy with this.

Originally Posted by arspr

So please, Kobo, as we say in a Spanish idiom: Do not try to fix what currently works.

But I like the fix, it doesn't work for me in the way you're saying it. I would have stayed with epub if I would have wanted the behaviour you desire

So: "No funciona, así que mejor que lo toquen" (Spanish)

[Terisa de morgan]

Originally Posted by arspr

Comparing (in an approximate way) book sizes. More or less like it happens with books in paper. A book with 100 pages is not exactly 10 times shorter than a book with 1000 pages because they will probably have completely different editions. But you can always say that the 100 page book is A LOT shorter.

BTW, File size is one of the most USELESS options in Kobo. Two books, one with 100 pages and other with 1000 pages. The first one has a lot of maps and pictures, the second one is plain text, no decorations, no figures. You can't say NOTHING about them looking at the file size.

[arspr]

Originally Posted by Terisa de morgan

People is going to kepub because they want what you don't like

Not good. Users are not going to be happy with this.

But I like the fix, it doesn't work for me in the way you're saying it. I would have stayed with epub if I would have wanted the behaviour you desire

So: "No funciona, así que mejor que lo toquen" (Spanish)

I don't follow or understand you.

I mean, do you prefer a page numbering system that is dependant on the font settings? Can you explain which are its advantages?

But nevertheless, are you saying that the main reason for your switch from epubs to kepubs is PAGE NUMBERS? Of course, every single person can adopt the opinions, likings and preferences he/she wants but I don't see your motivation as a general one...

What doesn't work in Adobe page numbering? It works perfectly and it's fully reliable. Its only issue is that the pages inside the book would have "different" lengths if, as davidfor says, they are calculated based on the file size.

Originally Posted by Terisa de morgan

BTW, File size is one of the most USELESS options in Kobo. Two books, one with 100 pages and other with 1000 pages. The first one has a lot of maps and pictures, the second one is plain text, no decorations, no figures. You can't say NOTHING about them looking at the file size.

I don't exactly know how the page numbering process goes, but I think you are completely wrong. I suppose that page numbering goes about the size (compressed or not, it doesn't matter), of the HTML files, not about the epub size. Embedded images, fonts or whatever would be irrelevant.

And as I said, it's not an exact process but just an approximate enough one. (Like in paper books as I also said BTW). And fully reliable.

Are you sure that the Koboish one which adds font sizes and margins to the mixture is more precise? Can you explain how?

[davidfor]

Originally Posted by arspr

I don't follow or understand you.

I mean, do you prefer a page numbering system that is dependant on the font settings? Can you explain which are its advantages?

But nevertheless, are you saying that the main reason for your switch from epubs to kepubs is PAGE NUMBERS? Of course, every single person can adopt the opinions, likings and preferences he/she wants but I don't see your motivation as a general one...

What doesn't work in Adobe page numbering? It works perfectly and it's fully reliable. Its only issue is that the pages inside the book would have "different" lengths if, as davidfor says, they are calculated based on the file size.

Do a little reading around here. There have been a lot more complaints about the ADE page numbering than the kepub version. With the ADE method, the page number doesn't change each time the screen does. Depending on the font size, there can be multiple pages on a screen or a page can cover multiple screens. People seem to like the idea that tapping the screen to display the next screen worth of text changes the page number as well.

Edit: And to prove my point, the first thread I read after posting this was https://www.mobileread.com/forums/sho...89#post2692389.

The ADE method is handy telling someone where to look in a book, but it is fragile. It needs exactly the same version of the book. Unpacking and repacking it could change the compression used which will change the number of pages calculated for that book.

For the algorithm used by ADE, see https://wiki.mobileread.com/wiki/ADE#Page_numbers.

I don't exactly know how the page numbering process goes, but I think you are completely wrong. I suppose that page numbering goes about the size (compressed or not, it doesn't matter), of the HTML files, not about the epub size. Embedded images, fonts or whatever would be irrelevant.

And as I said, it's not an exact process but just an approximate enough one. (Like in paper books as I also said BTW). And fully reliable.

Are you sure that the Koboish one which adds font sizes and margins to the mixture is more precise? Can you explain how?

I think Terisa was referring to the displayed file size. The library lists show the file size in KB or MB. That is pretty useless because the included cover images tend to be bigger than the text.

[Terisa de morgan]

Originally Posted by arspr

I don't follow or understand you.

I mean, do you prefer a page numbering system that is dependant on the font settings? Can you explain which are its advantages?

I can't care lees about it, but I've read a lot of messages about it.

Originally Posted by arspr

But nevertheless, are you saying that the main reason for your switch from epubs to kepubs is PAGE NUMBERS? Of course, every single person can adopt the opinions, likings and preferences he/she wants but I don't see your motivation as a general one...

Me? No, but I've read a lot of people who say it. My main reason is another one you don't like either, number of pages in a chapter.

Originally Posted by arspr

What doesn't work in Adobe page numbering? It works perfectly and it's fully reliable. Its only issue is that the pages inside the book would have "different" lengths if, as davidfor says, they are calculated based on the file size.

I don't need reliable. I need other features.

Originally Posted by arspr

I don't exactly know how the page numbering process goes, but I think you are completely wrong. I suppose that page numbering goes about the size (compressed or not, it doesn't matter), of the HTML files, not about the epub size. Embedded images, fonts or whatever would be irrelevant.

I think it count characters, not the html size, but I think there's more info about this method in the thread about the "Count pages" plugin.

Originally Posted by arspr

And as I said, it's not an exact process but just an approximate enough one. (Like in paper books as I also said BTW). And fully reliable.

Being like paper books can be good or bad, not an advantage itself. Anyway, as I've told you, I can't care less about the number of pages and its reliability.

Originally Posted by arspr

Are you sure that the Koboish one which adds font sizes and margins to the mixture is more precise? Can you explain how?

I've answered about this, I believe

Originally Posted by davidfor

I think Terisa was referring to the displayed file size. The library lists show the file size in KB or MB. That is pretty useless because the included cover images tend to be bigger than the text.

Yes, I've understood it wrong, you're right.

[arspr]

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.

[davidfor]

Originally Posted by arspr

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.

I don't "insist in people asking for this". I pointed out that there has been a LOT of discussion of the page numbering used by the ADE/RMSDK renderer and wanting a page number per screen system. But, a lot of people question the per chapter numbering of kepubs and want full book numbering. But, they want page per screen for the full book.

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?

Yes, per chapter page numbering does make a goto page function harder. It also makes it less important. "Page 5 of Chapter 5" or "halfway through chapter 5" is pretty easy to get to.

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?)

Personally, to remember a place in a book, I use a bookmark or something else significant.

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...

I pointed to the algorithm used for ADE page numbering. It is based on compressed files. If someone does something else, then it is just adding to the confusion.

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.

I doubt that Kobo think anything like that. I have made a couple of suggestions of reasons I think they have gone the way they have, but I don't know for sure. But, isn't it good they give you a choice? You can decide which page numbering system you like and want to use.

[arspr]

Originally Posted by davidfor

Personally, to remember a place in a book, I use a bookmark or something else significant.

Sure, but how do you tell to other user where it is?

Originally Posted by davidfor

I pointed to the algorithm used for ADE page numbering. It is based on compressed files. If someone does something else, then it is just adding to the confusion.

Of course I wouldn't have "fixed" ADE numbering. I would have just adopted a "fixed" version of it in the Kobo ACCESS rendering (where they have already adopted a different system BTW). So no greater confusion, just the same one we have right now: two systems. I just think a per chapter and relative numbering method is not a good idea.

Originally Posted by davidfor

I doubt that Kobo think anything like that. I have made a couple of suggestions of reasons I think they have gone the way they have, but I don't know for sure. But, isn't it good they give you a choice? You can decide which page numbering system you like and want to use.

Yes, I can choose but it is an all-or-nothing decision. Like I said about statistics, I don't really care about page numbers. And my turning point to ACCESS is based (or not) in other prominent features.

BUT despite of that fact, I think the current page numbering adopted in ACCESS is really pointless and quite worse over all than the original RMSDK/ADE one.

[Terisa de morgan]

Originally Posted by arspr

Of course I wouldn't have "fixed" ADE numbering. I would have just adopted a "fixed" version of it in the Kobo ACCESS rendering (where they have already adopted a different system BTW). So no greater confusion, just the same one we have right now: two systems. I just think a per chapter and relative numbering method is not a good idea.

Chapter numbering was my main reason for going kepub, so everybody is different. And I don't use to tell another users what page I'm reading or share my notes, so no problem with absolute/relative numbering.

[Abtacha]

Originally Posted by arspr

Sure, but how do you tell to other user where it is?

If it's at the beginning/end of a chapter use that, otherwise tell them to search for a phrase or word unique to the section you're referring to.
With e-books you're not bound to such a crude means as page numbers to find something
(That last bit is only part joke by the way, since comparing page numbers in paper books will only work if everyone has exactly the same format/edition/potentially-even-printrun)