View Single Post
Old 02-07-2024, 02:17 PM   #29
DNSB
Bibliophagist
DNSB ought to be getting tired of karma fortunes by now.DNSB ought to be getting tired of karma fortunes by now.DNSB ought to be getting tired of karma fortunes by now.DNSB ought to be getting tired of karma fortunes by now.DNSB ought to be getting tired of karma fortunes by now.DNSB ought to be getting tired of karma fortunes by now.DNSB ought to be getting tired of karma fortunes by now.DNSB ought to be getting tired of karma fortunes by now.DNSB ought to be getting tired of karma fortunes by now.DNSB ought to be getting tired of karma fortunes by now.DNSB ought to be getting tired of karma fortunes by now.
 
DNSB's Avatar
 
Posts: 47,114
Karma: 169815798
Join Date: Jul 2010
Location: Vancouver
Device: Kobo Sage, Libra Colour, Lenovo M8 FHD, Paperwhite 4, Tolino epos
Quote:
Originally Posted by JSWolf View Post
I read this a while ago. It was about the current Sony Reader (at the time) being slower to go to an ID then to go to the top of the HTML and it was correct. I've not tested on Kobo. But It was correct about the Sony Reader.
Are those the same Sony readers that crapped out if the file size was over 250KB?

I did a quick test with a epub that has multiple subchapters within it's mass of chapters using a Kobo Sage. To the naked eyeball, going from the ToC to chapter 103 did not take any more time than going from the ToC to a subchapter in chapter 103. The chapter 103 link is to the xhtml file, the subchapters links are to an id. Using my iPhone to record the process, both took the same number of frames at 30fps from when the link went dark to when the text was displayed (averaged over 5 tests of chapter and subchapter) so any differences in timing were less than 30ms.

Doing this test did reinforce my wish that you could collapse the ToC.
DNSB is offline   Reply With Quote