TOC Page Numbers?

[jackie_w]

Originally Posted by 93terp

Thanks, I'll cautiously give it a try!

Just ask for help if you get stuck

[ZodWallop]

Originally Posted by jackie_w

I know such a feature is technically feasible because I like messin' around and cobbled something together last year using my own copy of KoboTouchExtended calibre driver to update the TOC on-the-fly during send-to-device.

For my own experiments, when deciding what page number each chapter started at, I used the ADE page numbers for epubs and for kepubs the old Kobo concept of (x words = 1 page), where I get to choose x...

Given the 'one screen = one page' nature of kepub now (a change I prefer, honestly), would it be possible for your TOC hack to update the page numbers based on that?

For example, the Kobo knows to change the total page count from 400 pages to 538 pages when I increase the font. It is also able to recalculate the pages per chapter. So the Kobo knows that Chapter Four use to start on page 56, but now starts on 64. I wonder if that could be used to add the page number to the TOC?

Having said all that, I personally don't care for page numbers in table of contents. That's a leftover from the paper book days. As long as the reader tells me how many pages the current chapter is and that I'm on page xxx of xxx, that's good enough for me.

[93terp]

Originally Posted by jackie_w

Just ask for help if you get stuck

thanks, will do!

[jackie_w]

Originally Posted by ZodWallop

Given the 'one screen = one page' nature of kepub now (a change I prefer, honestly), would it be possible for your TOC hack to update the page numbers based on that?

No, I'm afraid not, it's a one-time hack re-write of the NCX and/or NAV file during calibre send-to-device. I never claimed this was classy.

Originally Posted by ZodWallop

For example, the Kobo knows to change the total page count from 400 pages to 538 pages when I increase the font. It is also able to recalculate the pages per chapter. So the Kobo knows that Chapter Four use to start on page 56, but now starts on 64. I wonder if that could be used to add the page number to the TOC?

I wouldn't even know where to start to do a TOC re-calc on-the-fly every time the line-height/font-size/margins were changed. It doesn't necessarily mean that someone more technically adept than me wouldn't, though. I do wonder what negative impact it might have on performance. Also, the TOC has always been central, in some way, to how Kobo has chosen to do things. So I do wonder whether having fluid TOC contents is even possible.

[JSWolf]

As part of the processing of ePub, Sony would add page numbers to the NCX ToC and because Sony used RMSDK, the page number were accurate. The same cannot be said about Access unless they get rid of the inaccurate 1/1 page numbering.

[ZodWallop]

Originally Posted by JSWolf

...unless they get rid of the inaccurate 1/1 page numbering.

One screen equaling one page is the expected behavior by almost every reader new to an ereader. How many questions/threads are there about "I turn the page and the page number doesn't change"?

You of course are welcome to feel how you want. But not everyone feels the same.

[MGlitch]

Originally Posted by JSWolf

As part of the processing of ePub, Sony would add page numbers to the NCX ToC and because Sony used RMSDK, the page number were accurate. The same cannot be said about Access unless they get rid of the inaccurate 1/1 page numbering.

Putting aside the tired old dead horse that is "accurate" page numbering in a media where there's clearly multiple ways to determine page numbers.

There's likely a way for Kobo to have their current page numbering system for kepub and to update the ToC. We already know they can, and do, update the pages of a book and pages in a chapter. They'd just have to make it so the displayed ToC called for the first page of the chapter whenever the ToC was brought up. It wouldn't matter what the page was as long as the number was being refreshed upon calling of the ToC.


Note I say "just", I don't know how easy this would be for them to do. I suspect, given Jackie's response, that they would likely not want to modify the actual ToC etc of the kepub file, but as they have full control of the UI it's entirely possible they can do something like displaying information in the displayed ToC on the Kobo device which isn't strictly speaking in the ToC.

Now how important this is to Kobo, and how likely it is that someone else would be so passionate about this issue, and have the time and skills to implement it without having full access to all the inner workings of the software is probably the same odds: low to none.

I seem to recall Nook offering page numbers at one point, and then dropping them. I'm not sure if it was that, or nested ToC, or possibly some combo of the two. Sadly the Nook forums where this was discussed have long since been shuttered and abandoned. It's possible google's waaaaay back machine might have them, but as that's a different brand, with a different OS, and different hardware, I'm not particularly fussed to try and find it. I only mention it as a case of the feature once existing, and then not and folks moving on. Because there is no such thing as a page in an ebook.

[davidfor]

Originally Posted by JSWolf

As part of the processing of ePub, Sony would add page numbers to the NCX ToC and because Sony used RMSDK, the page number were accurate. The same cannot be said about Access unless they get rid of the inaccurate 1/1 page numbering.

Except that it would actually be "fairly easy"* to calculate either type of mythical page number** on the fly and display them on the ToC screen.


* "fairly easy" is a programmers term meaning something like "should be able to do it without that much work but do need to do some investigation". It is NEVER used around any one with the word "Manager" in their job title as they interpret it as "extremely simple to do and will be done tomorrow".

** Yes, both page numbering systems are completely arbitrary. But, I like "mythical". And I either or every time you insist that the RMSDK page numbering is in some way more real or accurate than any other numbering. Which I do depends on my mood. Please, don't bother arguing back. I've read all of your sermons about it.

[ZodWallop]

Originally Posted by MGlitch

I seem to recall Nook offering page numbers at one point, and then dropping them.

It was Nook. In my first days of using an ereader, I relied on the page numbers in the TOC to determine how long a chapter was, so I knew if I could read it on a break or not.

That was back in the days of the Nook Simple Touch.

[4691mls]

Originally Posted by ZodWallop

It was Nook. In my first days of using an ereader, I relied on the page numbers in the TOC to determine how long a chapter was, so I knew if I could read it on a break or not.

That was back in the days of the Nook Simple Touch.

My Sonys had them. My Tolino Shine 2 has them. I use them as you did, to see how long a chapter is. I also like to see where the junk at the end of the book starts so I don't get caught by surprise if the story ends on page 350 of 400 or whatever.

[JSWolf]

Originally Posted by ZodWallop

One screen equaling one page is the expected behavior by almost every reader new to an ereader. How many questions/threads are there about "I turn the page and the page number doesn't change"?

You of course are welcome to feel how you want. But not everyone feels the same.

You cannot have ToC page numbers with the current Access Kobo is using. But you can with any version of RMSDK.

[MGlitch]

Originally Posted by JSWolf

You cannot have ToC page numbers with the current Access Kobo is using. But you can with any version of RMSDK.

And? It’s already been demonstrated that it’s possible for Kobo to add this feature if there was enough demand.

They have not which implies there is not which means the majority doesn’t care about page numbers in the TOC in ebooks.

Go count the threads asking for ToC page numbers compare it to the confusion posts mentioned by Zod. Let us know the numbers Jon.

[JSWolf]

If you had page numbers for the ToC with KePub, it would take a lot more time to update if you changed line height, font size, and/or the font as every time you made a change, the ToC page numbers would have to be updated.

But with RMSDK page numbers in the ToC, that can be done once when the eBook is imported to the database. And from there on, no need to update the page numbers.

[MGlitch]

Originally Posted by JSWolf

If you had page numbers for the ToC with KePub, it would take a lot more time to update if you changed line height, font size, and/or the font as every time you made a change, the ToC page numbers would have to be updated.

But with RMSDK page numbers in the ToC, that can be done once when the eBook is imported to the database. And from there on, no need to update the page numbers.

Jon, Access already updates the chapter start and stop pages when you make any of those changes, it adjusts instantly. That's why it can display xx of yy for a chapter. Do you really think the maths involved to figure out the new page number for the start of the chapter are so complex that it'd throw the device for a loop?

Becuase, I promise you, they aren't.

[JSWolf]

Originally Posted by MGlitch

Jon, Access already updates the chapter start and stop pages when you make any of those changes, it adjusts instantly. That's why it can display xx of yy for a chapter. Do you really think the maths involved to figure out the new page number for the start of the chapter are so complex that it'd throw the device for a loop?

Becuase, I promise you, they aren't.

But it also has to update the ToC every time. But you probably are correct that it's not as much as I made it sound.