Fictionwise explains ePub delays

[pilotbob]

Originally Posted by HarryT

But who runs these "open" DRM servers? If you want to have the situation where any bookstore can sell you a DRM-protected book that can be used on any device, they all need to use a common DRM server. Who operates it? What happens if it goes down?

I think "open" would mean the algorithms are known but not the key. The key would be something known to the user... it could be something like eReader users where the key is the credit card number. Or, it could be that a user creates a private/public key pair and provides their public key to the book stores. The problem here is that there is nothing tieing the user to that key pair, so they could just publish the private key with the ebook.

The advantage to using an "open" algorythm like AES or Blowfish or whatever is that no one owns it. Any reader software can implement that algorythm to read the book/file... all they would need would be for a way for the user to provide their key, either as a file or input in the UI.

BOb

[MishaS]

Originally Posted by llasram

Mmm. There's no compliance test suite for EPUB yet, but I'd be quite surprised if FBReader could pass one. Last time I checked it had little CSS support to speak of and no SVG support, both of which are required by the specs of an EPUB reader system.

I haven't seen it in action, but my understanding is that the OS X / iPhone reader Stanza does a pretty decent job.

It's a bit disappointing to see that while you are expecting certain applications to be very much standard compliant, while it's enough for others to just do a "decent job".

[wallcraft]

FBReader's ePub support is limited at present, but I don't think "compliance" should be its goal. FBReader is based on the idea that the reader controls how text is displayed on the screen, in contrast to ePub where the publisher has almost total control. The "easy" things for FBReader to fix in its ePub support (TOC and SVG graphics) will typically be "good enough" for the average ePub document.

[Zevs]

Originally Posted by Zevs

... and they also say:

"Our preference internally is for the ePub format because of the
flexibility it offers for our customers. We are encouraging the
industry to provide more ePubs, but at the moment, the number of titles
is very small. Of our publishers, only Hachette and Abbey House Press
have yet produced product in any quantity. Both have been working
through usability issues now that the Sony firmware is finally
available, and both plan to offer many more titles in the autumn."

Zevs

...oooops, not that it matters so much perhaps, but right should be right... this response was from BooksOnBoard... sorry for the misquote!!

Zevs

[JeffElkins]

Originally Posted by MishaS

Thanks to JeffElkins for mentioning FBReader

There's a list of readers reviewed at: http://jedisaber.com/ebooks/Readers.asp

I pray for the day when it runs on my 505

[DMcCunney]

Originally Posted by MishaS

Thanks to JeffElkins for mentioning FBReader

There's a list of readers reviewed at: http://jedisaber.com/ebooks/Readers.asp

Thank you. Good stuff. I'd looked at Openberg Lector before, but wasn't aware of dotReader.

However, I'd like to know where JediSaber gets the idea Mobi supports OS/X.
______
Dennis

[llasram]

Originally Posted by acidzebra

While you are obviously more well-versed in the whole backend/format side of things, when you say "better" do you mean better because publishers appear to accept it, or better because it is 'technically' better?

I don’t know much more versed I actually am, but I meant that EPUB is the “best” e-book format publishers are actually producing books in. I see at the best for three reasons:

• Technical superiority. And specifically, technical superiority through existing standards. The current state of XHTML+CSS represents decades of experience with the largest collection of “reflowable content” information ever assembled by the human species. HTML may not be perfect, but the odds that a competing “book-specific” format will do a better job are pretty slim. Adding vector graphics with SVG just cinches the deal.
• Openness. Sans the keying aspects of DRM, all of EPUB is openly documented. Anyone has all the information they need to produce tools which both produce and consume EPUB documents, making possible much richer ecosystem surround EPUB content. Moreover, because EPUB leverages existing open standards, many tools to work with and produce e.g. the XHTML+CSS of the OPS already exist.
• Existing tooling. An EPUB book is just OPS+OPF in an OCF container (a ZIP archive with some metadata). Most commercial e-book generation tools can/primarily produce the formats publishers sell from OPS+OPF (or the older OEBPS) as source. I don’t have direct experience here, but my anecdotal understanding is that publishers’ e-book production pipelines thus generally involve producing OPS+OPF then converting that to the various saleable forms. Because EPUB ultimately is the same format as what the publishers are converting from, it has the highest fidelity to what the publisher is producing in the first place.

Originally Posted by acidzebra

When I was looking into what makes BBeB, I stumbled over a blog post by Bill McCoy, the General Manager of ePublishing Business with Adobe Systems Incorporated.

It had this interesting tidbit:

...

He goes on to predict "in the long run I believe the momentum behind interoperable XML-based formats is unstoppable." but still, I thought his views on BBeB were interesting.

Yeah... I’m not sure what exactly he’s getting at there. I’m not sure how interesting the choice of archive format and “compiling” XML into a binary representation really is, beyond the fact that it doesn’t seem to save much/any space vs. just using DEFLATE. LIT’s markup-encoding at least amounts to little more than attempted compression and perhaps some limitted amount of pre-parsing – I must confess I haven’t stared at the BBeB internals enough to know how similar it is.

As for capabilities, I think what he says next in that post is spot on:

Assume the industry successfully establishes an XHTML-based reflowable document format based on the evolution of OEB, with an associated single-file container package with pluggable DRM, then I see no strong raison d'etre for Mobi, BBeB, or any of the other OEB-derivative eBook formats to hang around forever.

[mauibay]

I must be missing something obvious. I looked at their format list and I don't see epub available as a format at BooksOnBoard. Which format on their site is epub? The only PRS505 compatible format I see is PDF.

[igorsk]

Originally Posted by mauibay

I must be missing something obvious. I looked at their format list and I don't see epub available as a format at BooksOnBoard. Which format on their site is epub? The only PRS505 compatible format I see is PDF.

Looks like they didn't update all pages yet.
Click here for the list of EPUB books.

[mbovenka]

Originally Posted by DMcCunney

However, I'd like to know where JediSaber gets the idea Mobi supports OS/X.

Or Linux, for that matter.

[HarryT]

Originally Posted by mbovenka

Or Linux, for that matter.

A number of Linux-based devices have versions of the Mobi Reader available for them - eg the iLiad and the CyBook Gen3.

[mbovenka]

Originally Posted by HarryT

A number of Linux-based devices have versions of the Mobi Reader available for them - eg the iLiad and the CyBook Gen3.

Oof. Of course. I need more coffee

I have a Cybook myself I was thinking about a desktop Linux application. That doesn't exist as far as I'm aware.

[acidzebra]

Originally Posted by mbovenka

I have a Cybook myself I was thinking about a desktop Linux application. That doesn't exist as far as I'm aware.

And personally, I read it as such - referring to a desktop application. I have had some limited success running the windows version under WINE on linux, though. But since I have the prs-505 and Calibre, I haven't put effort into it recently.

[MishaS]

Originally Posted by JeffElkins

I pray for the day when it runs on my 505

We'd be happy to make FBReader available on the Reader (505) as well. But it seems that development for it is not really straightforward: I checked the forums here and beside "you'd need a toolchain" did not really find anything...

[delphidb96]

Originally Posted by MishaS

We'd be happy to make FBReader available on the Reader (505) as well. But it seems that development for it is not really straightforward: I checked the forums here and beside "you'd need a toolchain" did not really find anything...

Ummm... I *thought* that Wenjie (over at GSoC and OI) had come a long way towards porting both OI as well as userspace (Madshelf and FBReader) to the PRS505. Not sure about whether the same could be done for the PRS500 - but I'd be interested if it is done as I still have a 500 lurking around the house.

Derek