I did a test text document to see if the progress bar was page number or file position. It is fileposition so the progress bar is no indicator of page number. The consequence of that seems to be that if you have a html file with a lot of invisible html code before the start of the text then the progress bar indicator will be very misleading if it is a short story.

My test text document has at least 60 pages. When I go to jump to page the Cybook claims the number of pages is 17. Seems like a bug to me.

My test document was like:

12345612345678907890
12345612345678907890
12345678901234567890
12345678901234567890
1
2
3
4
5
6
7
8
9
0

I did a test text document to see if the progress bar was page number or file position. It is fileposition so the progress bar is no indicator of page number. The consequence of that seems to be that if you have a html file with a lot of invisible html code before the start of the text then the progress bar indicator will be very misleading if it is a short story.

My test text document has at least 60 pages. When I go to jump to page the Cybook claims the number of pages is 17. Seems like a bug to me.

My test document was like:

12345612345678907890
12345612345678907890
12345678901234567890
12345678901234567890
1
2
3
4
5
6
7
8
9
0


Given that it definitely doesn't paginate the book, file position is really the only thing the "page number" has to go on. I'd guess it's probably doing something like:

page_length = file pos of this page - file page of previous page
number_of_pages = total file size / page_length
progress_bar_position_% = (file pos of this page) / (total file size ) * 100

So a file with wildly different amounts of text on each page might well completely throw off the page count.

Given that it definitely doesn't paginate the book, file position is really the only thing the "page number" has to go on.

another way to solve this problem, is to "index" the book: the book should be "rendered" in memory page-by-page when it's first opened and each time when the font is changed by the user. Of course the Gen3 should do this automatically and in the background, it shouldn't be visible to the user.

The index could be really simple: just a coupling between file position and page number.

Shouldn't take more than an afternoon to program it (for a decent software engineer) ;)

That's exactly what the Sony Reader does, of course. The downside is that, for a long book, there's a delay of about a minute when you first open the book, and when you first select a different font size. Given that the current way the Gen3 works appears to be the way that ALL versions of the Mobi reader get page numbers, I'd guess that this is code (or at least, algorithm) supplied by Mobi rather than anything that Bookeen have done themselves.

I agree, that pagenumbers should be prerendered to be exact. The book can be read at once, and the rendering happens in the background. Until that has happened, the total pagenumber count could be approximated.

I agree, that pagenumbers should be prerendered to be exact. The book can be read at once, and the rendering happens in the background. Until that has happened, the total pagenumber count could be approximated.
If you use eBook Library to put the eBook onto the 500/505, it is prerendered and the reader does not need to do anything to paginate except read the XML file that has the info already in it. This is the bit that Harry keeps leaving out. The 500/505 does not have to do it itself if done via the supplied software.

If you use eBook Library to put the eBook onto the 500/505, it is prerendered and the reader does not need to do anything to paginate except read the XML file that has the info already in it. This is the bit that Harry keeps leaving out. The 500/505 does not have to do it itself if done via the supplied software.

But, given the fact that the 505 now mounts directly as a USB drive, why would anyone use the Connect software other than to buy books from the Sony store? Given that you buy your books elsewhere, do you still use Connect to transfer your books to your Reader? I would have thought that it was a lot easier just to transfer them directly to the mounted drive, is it not?

Please let me be clear, by the way; I never found the time that 500 took to paginate a book to be the slightest "problem"; just wanted to clarify that this is the "price" (if that's the right word) for having "real" pagination, and it's what the Gen3 would also need to do if one wanted "real" page numbers on it. Personally I regard page numbers as irrelevent, and see no need for them.

Yes, I use eBook Library to put content on my 505 as I use collections to keep my content organized.

But, given the fact that the 505 now mounts directly as a USB drive, why would anyone use the Connect software other than to buy books from the Sony store?

I still have my trusty old, obsolete, wrinkled, alzhimers PRS500... so I HAVE to use eBook Library. However, if I did get a spiffy new 505 I would probably still use it to organize my eBooks and also since I need to keep it around for the 500.

Also, another "why would anyone use it" apparently would be to pre-index the books. Also, I think the software autoconverts .doc files to .rtf too.

BOb