News from Bookeen about firmware upgrade

[lmarie]

Originally Posted by slayda

I've read ebooks on my Cybook that were shorter (and more interesting) than this thread, even without page numbers.

Heh.

I also agree with your earlier comment about checking back in this thread to see if there really is any news about the firmware upgrade....

[JSWolf]

I'm not sure if this is the thread or not, but if it is not, I do apologize.

I did test Mobipocket Reader and the page numbers don't work properly. They only seems to work when paging forward. Jumping to a specific page gives you a completely different place in the book then if you paged forward to what is supposed to be the same page. So yes, HarryT is 100% correct in that page numbers are broken.

[delphidb96]

Originally Posted by jgray

I thought I'd make a comment about the way Mobi does the funny paging. My understanding is that this is due to the fact that the format originalted on Palm devices and all the constraints imposed by that. It seems that to speed up the handling of long ebooks, the text is stored in the Mobi file in chunks that are decompressed on the fly when reading. Only a specific chunk of text is decompressed at a time, which is the cause of the paging problem when you jump a huge distance in the file. This is especially bad when you jump backwards, as others have noted.

So, if Bookeen implemented the Mobi way of doing things (which it seems they did), then the Cybook is going to have the same problem as any other Mobi reader software, on any platform. As to whether they are allowed to implement this differently, only they know for sure.

Exactly. And from what I've studied about the Mobi format, it ain't gonna be easy unless Mobi updates their presumptive model on what platform is used. There's tons of PDAs out there which have more memory and better memory handlers. Plus there are the Linux, Mac and Win PC families and now the e-ink devices. Sure, having rigidly-defined 'chunks' for much older PDAs and the cellphones makes sense - but even there Mobi could take a page from, say LZ compression techniques and just have a 'sliding-window' of 'working' text from within the single-file of ebook data.

This just points out one more reason to move away from archaic ebook formats like Mobi (and others), which were designed long ago, under different constraints than we have today. Why carry the old baggage forever?

The other thing that is missing from this discussion is the fact that the Cybook handles other ebook formats, not just Mobi. How is the paging issue handled in these other formats by the Cybook software?

Hmmm... Don't really read much HTML because my source for HTML ebooks tends to put each chapter into it's own HTML file. That's a non-starter for the Cybook at this point. And the few TXT ebooks I've seen are so heavily laden with line-breaks as to make them damn nea unreadable - and we all know the Cybook doesn't do RTF just yet. That leaves PDF. And it does a decent job of 'displaying' the file, but if the PDF ebook isn't pre-formatted for the Cybook, that's just hell to use. And I never get quite the fineness of control of font sizes.

Now if someone - anyone - would just port FBReader over to a Cybook, that might be a non-DRM alternative. (Of course, if someone *were* to port FBReader over, could they implement the Pukall PC1 cipher decryption module so's to allow for reading Secure Mobi? The module ain't that complex.)

Derek

[HarryT]

Originally Posted by JSWolf

I'm not sure if this is the thread or not, but if it is not, I do apologize.

I did test Mobipocket Reader and the page numbers don't work properly. They only seems to work when paging forward. Jumping to a specific page gives you a completely different place in the book then if you paged forward to what is supposed to be the same page. So yes, HarryT is 100% correct in that page numbers are broken.

It is indeed in the thread, Jon - but easily overlooked among everything else. I reported that paging forward to a particular point in the book (in my case, the start of chapter 4) resulted in the book being on page 52, but then going back to the start of the book and doing a "goto page 52" took me to a different place, from which I had to page back 14 pages to get back to what had previous been shown as page 52, but which had now become page 38.

That's why I believe that page numbers are pretty useless on Mobi devices, and hence Bookeen's decision not to display them is a rational one.

[jgray]

Originally Posted by delphidb96

Hmmm... Don't really read much HTML because my source for HTML ebooks tends to put each chapter into it's own HTML file.
Derek

I thought that the Cybook could handle a bunch of Zipped HTML files. If you want a single HTML of an ebook, just explode the Mobi version of Woodcraft from my home page. I did that as a single file, although I probably should have used separate files.

If you would like a text file without the short-line breaks, I can email you a text copy of Woodcraft (or does the PM function allow attachements?). The copy I submitted to PG is wrapped at 76 characters, as that is how they want them. I still have an un-wrapped copy.

It will be interesting to see how things are handled when epub is added to the Cybook.

[tompe]

Originally Posted by jgray

The other thing that is missing from this discussion is the fact that the Cybook handles other ebook formats, not just Mobi. How is the paging issue handled in these other formats by the Cybook software?

I tested with a text file and it handled it very badly and gave a totally wrong total page count (it said 17 but the page count was around 100).

[tompe]

Originally Posted by delphidb96

Exactly. And from what I've studied about the Mobi format, it ain't gonna be easy unless Mobi updates their presumptive model on what platform is used. There's tons of PDAs out there which have more memory and better memory handlers. Plus there are the Linux, Mac and Win PC families and now the e-ink devices. Sure, having rigidly-defined 'chunks' for much older PDAs and the cellphones makes sense - but even there Mobi could take a page from, say LZ compression techniques and just have a 'sliding-window' of 'working' text from within the single-file of ebook data.

That is how it works now. The records is just an implementation detail and of course you have to decode a set of records to display the text. It is not that property that is the problem. The problem is that you have to render the whole document to get the page breaks. But that might be relatively fast. Look at TeX/LaTeX that render to get page breaks rather fast.

[delphidb96]

Originally Posted by tompe

That is how it works now. The records is just an implementation detail and of course you have to decode a set of records to display the text. It is not that property that is the problem. The problem is that you have to render the whole document to get the page breaks. But that might be relatively fast. Look at TeX/LaTeX that render to get page breaks rather fast.

Maybe I'm just dense.

Look, the easiest way to count pages in "text" is to have a loop that counts characters and line-returns. If X characters (this is depending upon the font and size chosen) are counted before hitting a line-return, one (1) unit is added to the line count and the character count is restarted. But if a line-return is hit before the character count hits the 'magic value', the line-count is incremented and the character count is zeroed. Keep doing that until every displayable character is read. Oh wait. Add in a section to do the same as the line-return initiates whenever a page-break character string is found. I note that one doesn't have to 'render' anything as long as a lookup table is created and kept for the 'magic numbers' for each font family on the Cybook. Those metrics can just be plugged in to the page-count algorithm and off we go.

As for HTML, it's not as if we don't have pretty darned good parsers out there to scan through the files and 'count' the displayable characters, so the same would apply. Do I understand correctly that Mobigen turns the input files into HTML before sticking it in the PRC container? Seems easy enough without having to actually 'render' the display. And we all know that at this time the Cybook just displays ONE font family/size at a time, so that means we don't have to do fancy footwork around multiple sizes and fonts to do this counting.

But then, I've been out of the programming racket for a few years.

Derek

[HarryT]

Originally Posted by delphidb96

Do I understand correctly that Mobigen turns the input files into HTML before sticking it in the PRC container?

Yes, a Mobi book is HTML (with a few custom tags) encapsulated in a PRC "wrapper".

[hmls]

Originally Posted by HarryT

But why would it? It's certainly never done so in my 6 months-odd of owning it. Even when I had the annoying bug of the machine rebooting or hanging when looking up words in the dictionary, it still remembered what page it had been on!

Might this be related to the issue that some people have with losing bookmarks, I wonder? A dodgy SD card? Corrupted file system?

This is certainly an excellent question. I've had my Cybook for a few weeks now and it "lost my place" when I turned in on quite frequently. As a matter of fact, I had this problem the very first day I started reading on the Cybook. At the time I was copying books directly to the Cybook's memory (I have a Mac so no syncing for me). Now I copy books directly to an SD card using a card reader. I haven't had any problems since I started doing that. And it is related to the bookmark problem in some way because I decided to start bookmarking my place before I turned off the Cybook and discovered that the bookmarks didn't work all the time either. When I couldn't make a bookmark was when the Cybook would lose my place.

[tompe]

Originally Posted by delphidb96

Maybe I'm just dense.

Look, the easiest way to count pages in "text" is to have a loop that counts characters and line-returns. If X characters (this is depending upon the font and size chosen) are counted before hitting a line-return, one (1) unit is added to the line count and the character count is restarted. But if a line-return is hit before the character count hits the 'magic value', the line-count is incremented and the character count is zeroed. Keep doing that until every displayable character is read. Oh wait. Add in a section to do the same as the line-return initiates whenever a page-break character string is found. I note that one doesn't have to 'render' anything as long as a lookup table is created and kept for the 'magic numbers' for each font family on the Cybook. Those metrics can just be plugged in to the page-count algorithm and off we go.

As for HTML, it's not as if we don't have pretty darned good parsers out there to scan through the files and 'count' the displayable characters, so the same would apply. Do I understand correctly that Mobigen turns the input files into HTML before sticking it in the PRC container? Seems easy enough without having to actually 'render' the display. And we all know that at this time the Cybook just displays ONE font family/size at a time, so that means we don't have to do fancy footwork around multiple sizes and fonts to do this counting.

But then, I've been out of the programming racket for a few years.

Derek

I really do not know what you are not understanding.

The current algorithm seems just to count characters and they count markup characters and characters in the <head> that is not displayed. To be able to count lines in an html file you have to render it in some way.

Remember also that the Cybook can read html files.

[tompe]

Originally Posted by hmls

This is certainly an excellent question. I've had my Cybook for a few weeks now and it "lost my place" when I turned in on quite frequently. As a matter of fact, I had this problem the very first day I started reading on the Cybook. At the time I was copying books directly to the Cybook's memory (I have a Mac so no syncing for me). Now I copy books directly to an SD card using a card reader. I haven't had any problems since I started doing that. And it is related to the bookmark problem in some way because I decided to start bookmarking my place before I turned off the Cybook and discovered that the bookmarks didn't work all the time either. When I couldn't make a bookmark was when the Cybook would lose my place.

It is most probably because of a corrupt file system that these problems occur. The problem is that nearly all people having these problems seems to be people that do now know so much about computers or are afraid to test things beacause it has been nearly impossible to get somebody with the problem to confirm that the file system is corrupt.

[delphidb96]

Originally Posted by tompe

I really do not know what you are not understanding.

The current algorithm seems just to count characters and they count markup characters and characters in the <head> that is not displayed. To be able to count lines in an html file you have to render it in some way.

Remember also that the Cybook can read html files.

Why? I mean a good html parser module can be used to ignore any <metadata>, <title>, etc. sections while just counting the displayed characters. That's one of the reasons why html parsers were created.

And to state that the Cybook can read html files ignores the 800-pound-gorilla - that it can't handle external links. This isn't a problem with monolithic html ebooks, but is a real pain-in-the-ass for multi-file html ebooks.

Derek

[tompe]

Originally Posted by delphidb96

Why? I mean a good html parser module can be used to ignore any <metadata>, <title>, etc. sections while just counting the displayed characters. That's one of the reasons why html parsers were created.

Why are companies releasing sub standard programs? You have to ask them. I also find it extremely strange that they have not implemented it better since as you say there are a lot of support available for this.

And to state that the Cybook can read html files ignores the 800-pound-gorilla - that it can't handle external links. This isn't a problem with monolithic html ebooks, but is a real pain-in-the-ass for multi-file html ebooks.

My purpose was just to remind about that since you asked about html in prc files. Event if html was not used in prc files the page number thing should work for html files.

[JSWolf]

Originally Posted by HarryT

It is indeed in the thread, Jon - but easily overlooked among everything else. I reported that paging forward to a particular point in the book (in my case, the start of chapter 4) resulted in the book being on page 52, but then going back to the start of the book and doing a "goto page 52" took me to a different place, from which I had to page back 14 pages to get back to what had previous been shown as page 52, but which had now become page 38.

That's why I believe that page numbers are pretty useless on Mobi devices, and hence Bookeen's decision not to display them is a rational one.

After seeing the bug in action, I really think Bookeen should do away with goto page as it only inflames people to want to see page numbers which are useless since they don't work. If they worked, then yes, displaying them is a very good idea. But since they are broken, just ignore them.