Finally! Cybook Firmware upgrade available for download!

[Over]

Wow! When I least expected it!

BTW, why doesn't 1.5 have the auto-zoom for PDF files, unlike version 2.0?!

[ramboky]

Originally Posted by Manichean

This is what I actually tried to say earlier in this thread.

I missed that. Looks like everyone with 2.0 has the same problem.

In another thread you asked if this was a bug or by design. I can confirm it is definitely a bug. I had firmware 1.9 on my Opus when I bought it which had pretty much all the new functionality of 2.0 but was prone to freezes, hence the upgrade. Version 1.9 definitely read metadata from ePub files.

This is pretty appalling. Bookeen need to fire their developers. There is no excuse for releasing buggy, poorly tested code unless you're intending on labelling it BETA. Between the repeated delays and this release they are clearly not up to the job.

[eBookLuke]

Originally Posted by Terisa de morgan

Can you have Mobi FW at Opus?

Yes, you can

Luke

[srml]

Originally Posted by Jellby

There is no way (that I know of) in ePUB to specify top and bottom margins. You can only set margins in the non-standard Adobe-specific page templates.

What about "@page { margin-top: xxx; margin-bottom: yyy }"? That works for me and I think it's standards compliant.

[chlorine]

Originally Posted by Godzil

The Mobi PID and ADE authorisation are based on the serial number of the device, so no, they will not change.

So, to be sure I got this straight: I run linux and ade under wine. If I switch to 2.0, I need to authorize my cybook once on a windows computer, and then I can mount it as an usb drive and simply drag and drop the drm'd epub books on it.

Now if I switch back to 1.5 and back to 2.0 again, are you saying I don't need to re-authorize my cybook with a windows computer?

[EowynCarter]

Originally Posted by ramboky

This is pretty appalling. Bookeen need to fire their developers. There is no excuse for releasing buggy, poorly tested code unless you're intending on labelling it BETA.

Are you a devloper yourself ?

I am, and i can easily see how the meta data could have escape them. I didn't saw it either, until such a point i tried to add new books.
True, then sould have re-tested that, to make sure it wasn't broken... Or they did and the the file name was close enough to meta data and the lack for autor / publishers wasn't noticed.
Halas one tends to be lazy with testing things that *should* not have been touched, and thus not broken.

They'll probably release a fix for that one, and everything will be back to normal.

[vishcompany]

Originally Posted by Idoine

THAT is the bug in the mobi version, other than that, it's great

I second that. Dictionary lookup takes ages now (10+s).
So, finally we got folder view, but now we better keep only few books on the device, because of this new bug.
For the rest, also here, it's great. Boot-time and pageturs are much faster, no freezes yet (did not find time for long reading sessions though).

Now, I'm more than happy with the new fw and for the fact, that bookeen did release it (I sort of had given up, just kept reading the forums for the fun of it), but the thought, that it will take another year for bookeen to release a bugfix makes me - well I don't know a appropriate word for that...

Nevertheless: Thanx to bookeen for this nice christmas present, hope they will go on. The Gen3 is now back on the top of ebook readers and I'm very happy with it.

[HarryT]

Originally Posted by vishcompany

Now, I'm more than happy with the new fw and for the fact, that bookeen did release it (I sort of had given up, just kept reading the forums for the fun of it), but the thought, that it will take another year for bookeen to release a bugfix makes me - well I don't know a appropriate word for that...

Bookeen have, in the past, been relatively prompt in fixing bugs. I do suggest, though, that we all email "support@bookeen.com" and report the bugs. The more e-mails they receive, (hopefully) the quicker they'll fix it.

[chlorine]

For dictionary lookup speed, I implemented the following scheme, which seems to work OK: I placed the dictionaries on the root of the eBooks folder on the cybook. All my other books are on the SD card, but not in the eBooks folder: I created a MyBooks folder for them. I think it doesn't look up for dictionaries there, and I believe the same would happen if you created a MyBooks folder on the cybook itself.
Others should test this though, because I don't have that many books on the SD card.

EDiT: I'm not running 1.5 yet, but the previous version with folder support that was distributed at the Paris meetup, so the way folders are managed might be different for 1.5.

[ramboky]

Originally Posted by EowynCarter

Are you a devloper yourself ?

I am, and i can easily see how the meta data could have escape them. I didn't saw it either, until such a point i tried to add new books.
True, then sould have re-tested that, to make sure it wasn't broken... Or they did and the the file name was close enough to meta data and the lack for autor / publishers wasn't noticed.
Halas one tends to be lazy with testing things that *should* not have been touched, and thus not broken.

They'll probably release a fix for that one, and everything will be back to normal.

Yep, I am also a developer. If you have a proper testing strategy in place and comprehensive test scripts then breaks in core functionality just shouldn't happen in release code. Bugs do happen, regressions do happen but core functionality? That implies sloppiness to me. Laziness is not an excuse. Given the profile of this release I would have thought Bookeen would have been doubly careful but apparently not.

Bare in mind that v1.9 of the epub firmware has been sold in devices for months. And that firmware was (as far as I can tell) functionally identical to 2.0.

My replies may seem harsh but I, like many others have been trying to get answers from Bookeen's piss poor customer service for months and this is, in my opinion, yet another substandard response. If this was some freebie or open source software that would be one thing but this is firmware for a device there are actually selling. A device I am currently regretting purchasing two of...

I guess I'm ranting here because at least here someone will listen

Rant officially over!

I have emailed (politely) Bookeen with my bug report and will be happy to help them in any way I can to resolve the bug and get a new firmware release out the door in the new year. I will however never buy another Bookeen device nor recommend them to anyone.

[Abelturd]

Why is the cursor movement in the lookup mode so slow compared to cursor speed in menus?

[Crusader]

Is the metadata bug only limited to the status bar? In library view my books still show all the info (title/ author/ publisher). Can't remember if these are all books I uploaded pre-V2 update.

[EowynCarter]

Originally Posted by Crusader

Is the metadata bug only limited to the status bar? In library view my books still show all the info (title/ author/ publisher). Can't remember if these are all books I uploaded pre-V2 update.

I guess so. My "old" books still shows proper metadata.

[EowynCarter]

Core fonctionality ?
I don't really see reading meta data as core fonctionality... Displaying ePub is. And it work better than it ever did.

Bugs do happen, regressions do happen

Exactly.
The day me myself never make any bugs, i'll fell like I can yell at other for making some. But i'm not perfect, i know it, and don't have the pretention to expect other to be.

If bookeen had no intention of fixing that, that would be a reason to whine. But they probably will so.

[Jellby]

Originally Posted by tompe

Should that not be up to the renderer? Why do you need to specify something? If you have a status bar then tha page size is reduced and the renderer has to take that into account.

Let's see, I know the screen is 800x600, and so I use a 800x600 cover image, and set it to 100% width. It will take the whole screen, if the screen is in fact 800x600. But if you have a status bar making it only 780x600, the image is still 100% wide, and will extend beyond the bottom of the screen (or the status bar covers the bottom of the image, as you prefer). Since the image cannot react to the screen height, there's nothing the reader can do to "fix" this. It could automatically resize the image to fit the screen, as mobipocket does, but this is not a standard behaviour with ePUB.

A different issue is if, say, there is some text in a screen and then a image. If the text takes up 400px and then there comes an image 400px high, that's no problem without status bar, they fit in a 800px screen. But with a status bar, there is not enough space for the image, and it should be sent to the next page. If the reader does not do this and instead places the image in the same place covering it with the status bar, then it is a bug, indeed.

Originally Posted by tompe

But margins are specified in the css file and they seem to have effect. I am trying to see which specification cases the text to be placed to hight but it is hard to find it...

Top/bottom margins in the body element only affect the beginnig and end of the element, not the top and bottom of each page. Top margins of other elements can be discarded at pagebreaks (which is sometimes good, and sometimes bad). If a pagebreak occurs in the middle of a paragraph, there's no top margin there.

Originally Posted by srml

What about "@page { margin-top: xxx; margin-bottom: yyy }"? That works for me and I think it's standards compliant.

Hmm... I didn't know about that. In the OPS spec I had previous read it as if the margins are not supported by @page, but now I think they are. I shall make some experiments there...

But I still think the margins should be something settable by the user, and not hard-coded in the ePUB book. Anyway, the reader has some default right and left margins, doesn't it? then it should also have some sensible top and bottom margins (maybe they thought 0pt was a sensible default top margin, though).