New IDPF format: Which software companies are aboard—and how .epub will help publishers

Moderator's note: We welcome Nick Bogaty as a contributor, in the interest of presenting a variety of views and keeping readers informed on IDPF issues. Nick will be leaving his IDPF position shortly for his new job at Adobe. - DR IDPFWhat does the IDPF's .epub format mean for the e-book industry? Does it mean that publishers can stop doing multiple conversions? For reflowable e-books, the short answer is "yes." (I say "reflowable" because publishers will still do PDF for fixed-format books if that's what they want.) The long answer is the following: In implementing .epub, software companies handle files in one of two ways: 1. The software imports .epub and converts it to an end-user proprietary format. There are a bunch of reasons why a company might do this, the main one being that it wants its format to do things that aren't covered or possible in .epub. 2. The software simply reads (or renders) .epub files that a user can use, similar to how your iPod "reads" MP3 files. Many software companies have publicly expressed support for the specifications. Some have already implemented it, some have implemented parts of it and are working on the rest, and some have said they will but haven't yet. I'm not totally in tune with everyone's development plans and release dates (some understandably don't want anyone to know), but this is roughly what I gather:

  1. Adobe Systems - full support for .epub in current release under #2
  2. eBook Technologies - full support for .epub in current release under #2
  3. OSoft - full support for .epub in current release under #2
  4. SONY - full support for .epub in next release (don't know which category, I assume #2)
  5. VitalSource - full support for .epub in current release under #1 - taking .epub as an input file from publishers in their repository
  6. LibreDigital - full support for .epub in current release under #1 - taking .epub as an input file from publishers in the LibreDigital repository
  7. iRex Technologies - future support for .epub (not sure which way iRex will implement...assume #2)
  8. Mobipocket/Amazon - future support for .epub under Category #1 (I think) - I have no knowledge of Kindle development plans; hopefully Mobipocket/Amazon will do this with the Kindle too---go here for details. Some of .epub has already been implemented in Mobi 6.0.
Notable "I don't knows" include Microsoft and eReader (former Palm Digital Media), but .epub is an open, free and patent-unencumbered standard. and I hope all software companies entering the market use .epub as their file format.

Tip for economy-minded publishers: Get partners aboard

My advice to publishers would be to begin to work with their conversion partners to fully understand .epub and how .epub can be effectively produced. I would also have conversations with my distribution and software partners about their support for .epub.

Frankly, since there are so many software companies already on board or soon to be on board with .epub, I think this is an excellent opportunity for publishers to begin to tell their partners and vendors (or set some not too distant future date) that .epub will be the only file format for reflowable e-books that they will produce and send through distribution.

Publisher and consumer benefits

Obviously this is going to reduce conversion costs and, hopefully, increase selection for consumers. Something that time and again they say they want.

.Epub provides everything publishers need (and many many software companies will support them) to demand that multiple conversions are a thing of the past.

(Adapted from an e-mail with Nick’s permission.)

Related: eReads’ helpful writeup on .epub.

9 Comments on New IDPF format: Which software companies are aboard—and how .epub will help publishers

  1. I agree with every syllable in Nick’s essay above, and I hope that the IDPF will now go on to establish an epub1 logo for nonDRMed e-books, which it can later replace with an epub2 logo covering all books.

    Meanwhile, as for Amazon/Mobipocket, one of the more important of the implementers, Nick has pointed to a Mobi forum that contains following from a Mobipocket employee:

    Our software does not handle all IDPF 2.0 features yet.

    As soon as we start implementing its native support , I will contact you from here in order to let you participate to the beta versions if any.

    Thanks for your feedback.

    Kind regards,


    The bad news is that true .epub support still isn’t available in Mobipocket Desktopfar from it. The good news is use of the phrase “native support.” Does this mean that in the future, Mobi will simply render .epub without any translation available? Like the forum poster who asked a follow-up question, I’d love to know Mobipocket’s schedule for implementation in its various flavors of e-reader software. Ditto if Mobi is actually planning to use the .epub format on its retail site. The ETA?

    Not just consumers but also publishers should lean on Amazon to use .epub on the Mobi and Amazon sites to reduce the e-book industry’s eBabel hassles for consumers. While the Mobipocket-oriented Kindle will generate revenue for Amazon, e-book sales will create more. Go where the cash is! Standards are inevitable, and Amazon should think long term if it wants a sustainable business.


  2. Let’s imagine the best case scenario where .epub becomes a standard and is widely supported on multiple devices and by multiple vendors.

    What happens to the mishmash of variously formatted ebooks that many of us have collected? Will we be able to easily convert various formats like .lit, .rtf, .htm, .prc, .imp and others into .epub?

    I assume the answer will be no for anything that is burdened with drm. I also assume that strictly formated stuff like .pdf will not be easily converted. But I sure would like to be able to at least convert all my non-DRM non-PDF ebooks into a single standard format.

  3. The current version of FBReader now supports epub. I just tried five different sample ebooks posted on the IDPF website. The only one that had a problem was “Thoughts.epub”, which only opened as a one-page document.

    Note that this is native epub support, not the trick I reported earlier of renaming the epub to “.oebzip” to get FBReader to open it.

  4. Binko, on .epub: It’s a nonproprietary format and anyone can build a converter. I’d be shocked if the open source community doesn’t step in with some freeware solutions to augment the one already offered by Adobe. Now that a nonproprietary e-book-optimized standard exists, the motive is there. Remember, too, that some readers such as Mobi will be able to read .epub. So you can still use them for legacy books.

    I totally sympathize with owners of existing books in proprietary formats, especially those infested by DRM. This is exactly what we need a standard format to prevent such problems from arising in the future. If big publishers insist on DRM, then it needs to be interoperable to avoid the creation of Tower of eBabel II. My own strong preference would be no DRM or, as a compromise, social DRM. But the DRM issue differs from the format issue.

    Meanwhile I hope you’ll support the creation of an .epub logo for nonDRMed books. A future logo could include both DRMed and nonDRMED books.


  5. Binko said:
    “What happens to the mishmash of variously formatted ebooks that many of us have collected? Will we be able to easily convert various formats like .lit, .rtf, .htm, .prc, .imp and others into .epub?”


    My understanding is that epub is backwards compatible with the OEB 1.2 standard. This means that your LIT ebooks should be easily convertable (after using ConvertLit). I would think that HTML should be easy as well. I never have found a way to take an IMP file (even without DRM) and extract anything usable from it.

    For PRC, I assume you mean Mobipocket? Or maybe not, since a PRC could be one of several different formats. There are some programs to extract the text, HTML and images from a non-DRM Mobipocket file. For one with DRM, see the recent discussion on MobleRead (not easy for the average user).

    As for PDF, that always has been a lost cause (IMHO) and will continue to be one. Even the high dollar programs don’t do a very good job of converting a PDF to anything else (I have tried most of them). PDF is made for a strictly formatted page image and trying to do anything else with it is almost impossible, unless you have an extremely simple PDF and/or spend huge amounts of time manually cleaning up the converted output. Even Abobe’s own solution of “tagging” a PDF to make it reflowable is half-a**ed at best.

    Although there are some instructions on the net about manually creating an epub book, I am waiting for someone to release an easy to use tool for us mere mortals (not just the high dollar tools for the publishers).

    I’m sure the publishers would rather that we all just gave them more money to buy all of our ebooks over again (and again), if and when they decide to standardize on a common format.

  6. “My understanding is that epub is backwards compatible with the OEB 1.2 standard. ”

    This is correct. In fact you can have a jointly compatible oeb 1.2 and .epub publication. See:

  7. We have had great results with converted RTF to .epub. Unfortunately, we dropped the idea of supporting PDF as a conversion basis. Word docs, too, are a tricky issue. RTF is supported by most word processors, better than HTML is, and has a well-documented specification. RTF is also text-based (with support for embedding binary data). It’s proven to be a very promising basis for conversion. It is, unlike PDF, both printer and screen friendly. And script friendly.

    Because OEBPS is based on open standards, many other people will be creating conversion tools. The building blocks have already been around for some time, on many platforms and in many programming languages. Unlike proprietary formats, there’s no extensive sleuthing or building from scratch to have a basic conversion tool. The real challenge comes in creating .epubs that work across systems. Systems need to be fairly fault-tolerant of the standard, especially this early in the game, or people will give up on it pretty quickly. Fortunately the standard is fairly thorough about how to provide fallback mechanisms and handle unknown or unsupported types of content.

    The best thing is that it seems to take as its basic assumption that Web technologies are perfectly suited for the evolution of books. And in line with this assumption, I think, is the notion that the Web Browser represents the ideal platform and environment for books (other than paper, which is just, really undeniably great).

    PS For those who signed up and may be wondering about our launch date, all I can say is “soon” . . . sorry about the delays, but they are typical. Over the next week or two, we’ll begin rolling people into our Private Beta, and from there . . . “very soon”!

  8. As I see it, CMS’s servers can transform webpages into a single .epub file fairly easily, (although the .css would have to be added separately/externally). I suppose a reader creation utility like mobigen/prcgen could then be used to render server-produced .epub files into mobipocket format, but that would complicate things (it puts us at the mercy of the vendor). (see this thread about lack of a linux version of mobigen .

    Then again, this hasn’t really prevented the widespread adoption/distribution of mobipocket files.

6 Trackbacks & Pingbacks

  1. FeedBooks : Blog Français » Blog Archive » DRM et Standard
  2. The e-Idiotproof Solution « .stuff
  3. FeedBooks : Blog Français » Blog Archive » Support ePub sur Feedbooks
  4. FeedBooks : Blog » Blog Archive » ePub support on Feedbooks
  5. Does Apple Want To Be King Of Ebooks? «
  6. Le format de fichier ePUB « Présentation du E-Reader

The TeleRead community values your civil and thoughtful comments. We use a cache, so expect a delay. Problems? E-mail

wordpress analytics