Apple: PLEASE Kill The IDPF And ePub!

Those wunderkinds who gave us broken covers, no fractions, and no photo captions in “industry standard” electronic books — the International Digital Publishing Forum (aka IDPF) — has just issued a slew of proposals trying to play catchup with basic things the spec should have supported out of the box.

This is the paper [web page link] being passed around.

Looking at that list, after each item I did a Dilbertesque head desk.

What the hell have those people been doing all this time that it’s only now — after the appearance of the iPad — that such a proposal has been issued?!

And do you notice it’s a list of things? Yeah, that’ll be fun to do — a whole bunch of things all at once. And via committees! Is that a recipe for success or what? Nope!

And how soon will they have even a working agreement, in order to simply move forward? I quote:

The Working Group is chartered through May 2011. The Working Group will target an initial working draft (not feature complete) published in September, 2010 that can be a basis for experimental implementations, and aim for a public draft in December 2010 followed in January 2011 with a draft standard for trial use. Final standard recommendation submitted to the Board by May 15, 2011.

Boldfaced emphasis added by me.

May 2011!! Over a year from now! Are they insane?! What timeflow do they live in, where such leisurely ignore-the-world action can be taken?

This is Apple’s opportunity to free us from these ePub perpetrators.

Just days after the iPad has been released, I have people asking me how they can make their current books into ePub files with an eye to getting them in the iBookstore (my answer, right now, is Smashwords).

Does the IDPF really think these people will sit on their thumbs, waiting for a decent — not complete, merely decent! — spec from them before proceeding?

Let me open the eyes of everyone out there who has invested time and money in ePub: The world does not need ePub.

The world needs a way of creating digital books that is easy; that can do things like fractions, photo captions, video insertions, and can display across a broad variety of devices.

It does not matter what that file format is.

Apple helped overthrow the existing pre-press system with the Macintosh and desktop publishing.

This is no different from back then.

Printing people didn’t care what the hell the file format was, as long as it outputted something their machinery could use to go to press.

The IDPF is akin to Linotype and Atex and all the rest from back then: destined for extinction.

And Apple has the chance to do that.

iWork’s Pages should be the basis for a digital book creation tool. At the heart of it isn’t any proprietary technology: it’s XML. But unlike ePub, it can do video insertions and other wonderful things.

Apple needn’t grow Pages to be a digital book creation tool. It could spin it off into another program specifically for that. Pages (even Pages, alas!, Lite on the iPad) could be used for writing and seamlessly transfer its content to let’s call it PublishPages.

PublishPages would not only create a standalone digital book file, but could also render a digital book that could be streamed online. In one swoop, Apple could create a universal digital book standard which could be read by anyone within a web browser.

Apple could also add such digital book reading to iTunes, encompassing all desktop Mac and Windows users. (All those people hepped up for Chrome OS, you can stream books via the Chrome browser. So can Linux users.)

The IDPF thinks everyone is going to sit around doing nothing for more than a year.

And even then, can we expect anything actually useful from them?

Look at their lack of attention to detail on their website alone. This screensnap was taken today, April 6th:


Click = big

The advantage here is Apple’s. Steve Jobs: take it!

About these ads

10 responses to “Apple: PLEASE Kill The IDPF And ePub!

  1. Is Pages a publically specced XML format? I found some speculation online that it is similar to ODF but if the complete ruleset cannot be divined, then it can’t be relied upon, just being stored internally in XML does not make it open. And what if we transfer everything to Pages and then Apple decides tomorrow to store their documents differently and then just one generation later (Apple is impatient about this sort of thing, losing ‘old cruft’), they decide to cut off backwards compatibility?

    What format it is stored in is less important than Apple’s published intentions on describing the spec and whether they will try to legally oppose or demand licence fees from anyone else who wants to make a reader for the spec…

  2. Without getting technical — mainly because I can’t! — I’d say look at what they have done with WebKit. Is there anything they’ve done with that which has prevented Google, Nokia, and others from basing browsers on it?

  3. Have you had a look at an epub file?

    You can download some free – e.g.

    http://www.feedbooks.com/book/52

    Change the file extension from .epub to .zip. Now you can double-click it to open it and look inside. It’s not dissimilar to some formats used for word-processing documents. You’ve got a folder structure with zip-compression. Inside there are various xml documents and resources (such as graphics files).

    However, whereas wp formats have been purpose-designed for word-processing, epub has been designed for the specific purpose of displaying books (and a range of tasks around that). It’s horses for courses, and a wp format isn’t a good place to start when there’s already a format around intended for the particular need.

    There are a range of tried technologies in there – such as CSS for formatting and layout purposes. It also looks to me like the metadata uses Dublin Core. That kind of thing is important – the reader has to look at the metadata to know whether it can handle a particular document. And, of course, in WebKit Apple has a world-class rendering engine to display these documents.

  4. >>>Have you had a look at an epub file?

    Is this question a joke?

  5. Apple was forced to open WebKit because it was based in the first place on share-alike open source software. If they hadn’t distributed it freely they’d have been in contravention of the law.

  6. And as it has turned out, after I mentioned WebKit, I learned there are apparently private APIs within it too.

  7. I totally agree with you.
    ePubs are almost a laughing matter. I said “almost laughing”, since it’s more something that makes you cry.

    The many ways to produce an ePub file it (and the many ways to do it wrong), are incredible. Those stupid nerdy apps that throw a myriad of technical stuff at you, the silly TOC issues, the “loose” e-reader implementations against the super-strict XHTML specs – it’s all too much for someone who likes clear and elegant tools.

    Even Adobe’s own ePubs (generated by InDesign CS5) don’t comply with the standards, when validating them. And did you ever try to actually use their Digital Editions e-reader? It wants to behave like iTunes, but the interface is terrible! (I hate these AIR apps…)

    After 500 years of book-making and 25 years of DTP, this is supposed to be the digital equivalent of the book? These are the tools to build on to? PDF was just a step-stone into the digital era, but if this is the “next step” then please hand me a gun.

    I hope Apple will be able to teach this bunch of nerds a lesson. The dumpster is big enough to fit Flash and this ePub stuff as well…

  8. I(pad) come not to praise epub, but to bury it.

  9. For publishers with complex layouts / interactive aspirations, it seems to be a choice between either Epub books with all their limiations and an 18 month waiting list for improvement or apps where the book buying market is likely to be smaller now the iBook channel is launched…where is the middle ground?

  10. Waiting for Apple to do the right thing. Besides, we don’t yet have the kind of large market that’s enjoyed by the iPhone/Touch combo. That will come. In the meantime, everyone should be telling Apple we need a digital book creation tool.