Quote:
Originally Posted by arspr
Yes I know that RMSDK page numbering (or nearly any kind of page numbering in an ebook) is inaccurate, but at least it doesn't leap like a mad frog...
If there's nothing wrong with the epub, now I do understand why Kobo uses only page numbers relative to each chapter...
But it's somehow quite sad that they cannot get a normal numbering work in a normal way, (even if inaccurate or artificial). So they are forced to use only chapter pages.
(I still hope that there's some kind of bug inside the epub, not in the ACCESS renderer. Why, if you know the pages of each chapter, just ADD them up and you have the total pages of the ebook. Then, when switching chapters, add the total number of pages from the previous chapters to your current 1, 2, 3... Is that so difficult to code and make it work flawless?).
|
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.
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.
Overall, I think this is a bug in the ACCESS renderer. But, it might be something missing in the book. Remember, we are talking about kepubs, not epubs. They don't have to follow the same rules. And we don't actually know the full specs for kepubs. Maybe to be a valid kepub, it must have a TOC entry for each file. If that is the case, the bug in the firmware is that it displays the book at all.