IDPF Screws Up ePub eBook Covers For Everyone!

In an earlier post, Barnes & Noble Nook Vs. Archos 5 Internet Tablet: Round Two, I closed with this:

One flaw in that video: Aldiko did not create a thumbnail of the cover; it’s using a generic placeholder. I will ask about that and report back.

I doubt anyone but me would have even noticed that. But I did and it bugged me.

I had to know what was going on here.

So I contacted Aldiko and this is what they said:

The epub format does not mandate a specific syntax for defining what image file, if any, corresponds to the book’s cover. We have to resort to using a heuristic to try to guestimate which files would be a good candidate to use as a cover image (e.g. a png file containing ‘cover’ in its filename would be usually be a good candidate). Over time we’ve tweaked our algorithm to handle most major sources (Feedbooks, O’Reilly…), but I would not expect it to work all the time. My guess is that the ‘Michael Jackson’ file probably defines it’s cover image in a way that is not recognized by our algorithm. Again, if only the epub format had a standard way to indicate cover images, we wouldn’t have that issue.

So this led me to look at the files that comprise the Michael Jackson book.

This is what I found:

Instead of seeing a JPEG file called COVER.JPG, there’s that XML file.

And this is its code:

Click = big

The cover is inside the Images folder and is called 9780446565684.jpg!

Yeesh!

This led me to investigate the structure of several other commercial ePubs — ones people are likely to buy or borrow from libraries — and it’s all a mess!

Every structure is different. How the cover image is called is different. What the cover is called is different.

What a frikkin mess!!

Prior to this, I’d been used to seeing ePubs that sensibly had an image called COVER.JPG. That made everything straightforward and uncomplicated for everyone.

Now I’m seeing that chaos has erupted in the so-called “ePub standard” and no one can count on anything working properly, period!

So ePub covers not showing up on the Nook’s color LCD screen? That turns out not to be a flaw of the Nook at all.

It’s a flaw of the underlying ePub “standard.”

What this means is that any software that generates thumbnails of pretty covers is destined to run into problems and likely FAIL, substituting a generic cover as Aldiko did in that test.

As if we weren’t already being cheated with eBook covers as it is! Now we’re also being cheated out of proper thumbnails!

This is just incredible.

How can a so-called “standards body” allow this mess to continue all these years? Isn’t there anyone at the IDPF who has a brain and could see this mess coming? Srsly?

What happens now? Do publishers revise all of these files to permit easy thumbnail generation? Will people have to pay twice for that — for something that should have worked to begin with?

This is even more evidence that Apple digital books will wipe out ePub.

Apple wouldn’t let crap like this happen.

Dig it, IDPF:

It’s called CoverFlow. Have any of you ever heard of it?

14 Responses to IDPF Screws Up ePub eBook Covers For Everyone!

  1. Moriah Jovan says:

    O.M.G.

    I never thought about a standard naming convention. I call mine theprovisocover.jpg or stay.jpg.

    I wonder what mine would look like. Should I be switching to cover.jpg? (Aside: Ah, the joys and advantages of independence.)

  2. Alan Wallcraft says:

    It is a mess, and what you get when committees design a format. The cover page of an ePub is whatever gets displayed on the first page. This does not have to be an image or a SVG – it could be an image and some text overlay or just some text formatted to look nice on the screen.

    So the only safe method to get a thumbnail is to actually render the 1st page. This could work, e.g. with cached thumbnails, but I am not aware of any Reader doing this.

    The entire ePub is just a ZIP with standard metadata approach cries out for a standard method of including a thumbnail. Even if some ePubs did not include them, a program like Calibre could add them easily to any DRM-free ePub.

  3. barbara says:

    ACK! data and metadata. I have multiple ereader programs because there are multiple formats and I hate it. Mike, why are you not on the IDPF committee…well, I know why…committees suck. But they should freakin’ listen to you.

  4. I’ve just implemented an ePub reader for my eBook to Audiobook application, Text2Go. I use the cover image the Audiobook Coverflow image in iTunes/iPod.

    If I can’t find a cover image using the opf file, I look for any image in the ebook with the word ‘cover’ in it’s name. Although this is really crude and depends on a naming convention, it does allow me to locate a few additional cover images.

    So yes, as Mike has recommended, name your cover image ‘cover.jpg’ or ‘cover.png’, etc.

  5. Social comments and analytics for this post…

    This post was mentioned on Twitter by mikecane: NEW POST: IDPF Screws Up ePub eBook Covers For Everyone! http://tinyurl.com/yl3lygj @jafurtado @aldiko @tiffanycmw @TaxMan45…

  6. Dave Cramer says:

    The IDPF is working on a standardized way of pointing to the cover file now. There’s a defacto standard based on what Amazon wants, using

    to point at the manifest item that is the cover image.

  7. Wayzgoose says:

    Okay. Let’s suppose IDPF is omniscient and all-powerful. Let’s have it dictate the names of everything that you can put in your ePub. Your book has to have cover.png. What about cover.jpg, cover.bmp, cover.svg, and the cover standard that will come out next year that no has thought of yet? And while we’re at it, you should have to name each chapter of your book as a separate file chapter1.xhtml, chapter2.xhtml, and so on. Can you just imagine publishers who can’t even agree on a drm solution agreeing to have all the files in their document named the same as the files in everybody else’s? Or screwing their entire (let’s talk in the millions) library of book elements and database that they developed for their specific books just so they can match IDPF’s or Apple’s standard? Ain’t gonna happen. Now if you’d like to suggest that a “thumbnail” file should be included in the opc package, that might fly. But it couldn’t be mandated. You could make that suggestion by contacting one of the VOLUNTEERS who make up the IDPF at http://www.idpf.org/idpf_groups.htm.

    • mikecane says:

      Oh stop it. The ultimate filename is the ePub filename: book.epub. Within that zip, there CAN be COVER.XXX without it screwing things up. Stop it already!

      • Journeyman_of_Publishing says:

        Wayzgoose has a point. If we try to open a lot of ePub files and then all the cover images have “cover.xxx” for a filename, we might have a hard time finding the appropriate cover image on a find search if they’re all of the same filename and file type.

        • mikecane says:

          No. Covers are within folders and the folders have the filenames.

          • Caesius says:

            With my first eReader, a Pandigital Novel, I got lucky (or so I thought). It had a folder called “Books” which held all my actual ePub and PDF files AND another folder (inside “Books”) called .thumbnails. Each cover was stored in .thumbnails as jpeg or other image file format and had to have the identical name as the ePub for it to display. The image file also had to be less than 10KB.
            Unfortunately, I have had 3 other eReaders ever since and JUST bought a Nook Tablet, and I am guessing that the format which applied with my PDN is NOT applicable ANYWHERE else. In fact, I found this blog while searching for an answer to the Nook ePub cover format.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: