Report on new firmware?

[Jellby]

Originally Posted by Godzil

But until now they where able to only read Mobi file, and the Mobi SDK is able to read DRMed and unDRMed Mobi file, so why bother to add another Mobi reader that will be usefull for nothing more than duplicate the code and possibly have bug on one version and bug on the other.

Because they can't use it together with Adobe SDK. It will have bugs, right, but they can fix the bugs and they can add features, which they can't with the Mobi SDK. I'm not saying they have to develop something from scratch, but they should have something they can freely modify.

That the same for ePub, now they have access to the Adobe SDK that provide well made ePub reader, why did they need to bother to make another ePub reader that will introduce bugs that the other may not have?

Because Adobe ePUB reader is not perfect and they might want (or rather we, the users, want) to add other features like custom CSS, or support for oeb-page-head and oeb-page-foot, or remove the page numbers from the margin... or just use it with Mobi DRM support.

Making a eBook format reader is not like cliking a checkbox... I don't know how much code Mobi or ePub parser need to be functional, but it surely need a lot month of man work to do them...

I don't say it's easy, I don't think it's easy, but it's not the most difficult task either. I'm sure basic (X)HTML/CSS/SVG parsers already exist that they could use for a start, and Kovid made a decent ePUB reader himself, so it should be feasible even for a small company.

But don't misunderstand me, I'm not saying they should develop an independent reading software, I just wish they'd have the time and resources to do it.

[HarryT]

I would be happy to drop Mobi in support of ePub if it were not for one thing that's very important to me - dictionary support, which Mobi has, and ePub doesn't. I use the dictionary a lot of my Gen3, and I wouldn't like to lose it. I could, of course, use the dictionary on my Windows Smartphone, and look up words that way, but I really like the dictionary integration that the Gen3 has.

[Snuffi]

Originally Posted by Jellby

But maybe they can't use Mobipocket's SDK without DRM, just as they can't use Adobe's without DRM. So they would need some alternate software for either .prc or .epub (or both) without DRM. It's possible, yes, there's no otherworldy mystery in those formats, open solutions exist or can be developed... but that needs time, work, testing, etc., which it seem's they don't have.

On the other hand, I really wish they would develop their own solutions instead of relying only on Mobipocket and Adobe, I want someone to provide more features, to fix bugs and remove limitations, I don't want the same old problems and restrictions to appear in every other reader.

That seems to be the case otherwise I suppose they would have just removed the DRM part and everything would have been fine.
I am just wondering if the MobiPocket SDK requires you to use the DRM components, where do the people who develop .prc tools get their knowledge about the format? It is, of course, possible that they reverse engineered a cart load of non-DRMed mobi files but that's a tremendous effort.

The problem for Bookeen is that they have to use the Mobipocket SDK as there is - to my knowledge - no legal alternative. And they have to use the Adobe SDK as the need the Adobe DRM for their Weltbild deal. So, using FBreader would be a third thing to work on as they could not drop either of the other two for that one.
Hope they still get around to integrate FBReader eventually, but I rather doubt it. If I were them I wouldn't do that and rather focus my scarce programming hours available on other stuff...

[wallcraft]

I can't find the reference, but the standard mobile ADE licence does not allow you to use ADE only for non-DRM ebooks. This isn't surprising, because Adobe makes money from DRMed ebooks. There must be a non-standard version of the licence that does allow this, because Amazon is using mobile ADE only for DRM-free PDFs on the Kindle DX.

It is relatively difficult to generate a MOBI/ePub viewer, depending on how faithful you want to be to the "standard". However, there are already 3rd party Open Source viewers available that may be "good enough" and being Open Source you can improve them if necessary. FBReader is the obvious example, but it isn't faithful to either the MOBI or ePub layout conventions. This isn't the only option, Calibre views MOBI ebooks by first converting them to ePub. This is the "Kindle" approach - view any DRM-free ebook so long as it is a MOBI. It would cost very little for Bookeen to setup an e-mail conversion service like Amazon's, although it obviously could not deliver ebooks directly to the device.

In fact, Bookeen could simply implement Calibre right on the Gen3. This is what Savory does on the Kindle 2. It would not have to be automatic (like Savory): when you first click on ebook.epub Calibre is invoked to produce .ebook.mobi and then the MOBI viewer is opened. The next time, .ebook.mobi is already there. I added a leading "." because such files are conventionally "hidden" under Linux. The same process would work for MOBI ebooks when ADE is the primary viewer.

[HarryT]

I used to run FBReader on my iLiad, and was not impressed by it at all - at least for Mobi books. The implementation is extremely poor, with many Mobi features not supported. The version I was using did not even implement features as basic as hard page breaks.

[wallcraft]

Originally Posted by HarryT

I used to run FBReader on my iLiad, and was not impressed by it at all - at least for Mobi books. The implementation is extremely poor, with many Mobi features not supported. The version I was using did not even implement features as basic as hard page breaks.

One of the downsides of a multi-format viewer is that individual formats are unlikely to get the attention they deserve. I agree that FBReader's MOBI support isn't optimal. Some issues are due to differences in philosophy, FBReader isn't trying to obey every whim of the publisher, but others are easily corrected and, since it is Open Source, Bookeen (say) could easily improve its MOBI support.

[MaggieScratch]

Originally Posted by Gaurnim

For those able to do it legally, liberating MobiPocket is much simpler than converting all Mobipocket to Epub.
This would allow to keep the entire MobiPocket collection and still have access to Epub.

Exactly.

I wouldn't mind much switching to ePub for my DRMed books but I would like to keep my non-DRMed Mobi books. Converting so many books would be a pain.

[Terisa de morgan]

I have no doubt. ePub offers nothing to me (no, open code with DRM doesn't matter), so I'm not interested in change.

[Jellby]

Originally Posted by Terisa de morgan

I have no doubt. ePub offers nothing to me (no, open code with DRM doesn't matter), so I'm not interested in change.

ePUB without DRM is much better than Mobipocket without DRM. (And I'm talking about the format, not the implementation.)

ePUB has embedded fonts, SVG and PNG support, better control of spacings and borders, wrapped text around images, table of contents...

[JSWolf]

Originally Posted by Michael

and be the first to be officially certified by Adobe on Adobe SDK.

I thought Sony was the first to be certified/use the Adobe ADK.

[Terisa de morgan]

Originally Posted by Jellby

ePUB without DRM is much better than Mobipocket without DRM. (And I'm talking about the format, not the implementation.)

ePUB has embedded fonts, SVG and PNG support, better control of spacings and borders, wrapped text around images, table of contents...

I only read novels, so none of these options is important for me. And Mobipocket has table of contents too, I use it. As you can see, I can keep my words

[tompe]

Originally Posted by Snuffi

I am just wondering if the MobiPocket SDK requires you to use the DRM components, where do the people who develop .prc tools get their knowledge about the format? It is, of course, possible that they reverse engineered a cart load of non-DRMed mobi files but that's a tremendous effort.

Some information is available on the MobiPocket web page but the rest of it have been reverse engineered.

[Godzil]

Originally Posted by JSWolf

I thought Sony was the first to be certified/use the Adobe ADK.

In fact, if I understand correctly, Sony didn't use the SDK, that was Adobe who made this part of the firmware, not Sony, so Bookeen may be the first to use the official SDK and get the certification. By the way, the SDK that Bookeen use is more recent than the version "used" by Sony

[pilotbob]

Originally Posted by Terisa de morgan

I only read novels, so none of these options is important for me. And Mobipocket has table of contents too, I use it. As you can see, I can keep my words

I disagree... good layout/font is just as important in a novel as anywhere else. And alot of the types of books I read, fantasy/sf, have illustrations which I want to look at good an crisp. How else will I find my way to Mordor without a map? MapQuest says "invalid address".

BOb

[Idoine]

Originally Posted by pilotbob

I disagree... good layout/font is just as important in a novel as anywhere else. And alot of the types of books I read, fantasy/sf, have illustrations which I want to look at good an crisp. How else will I find my way to Mordor without a map? Map question says "invalid address".

BOb

GPS not updated ? What a pity !
... Ok, I know the way to the door...