6

I am formatting an ebook for a client who is quite particular about how it looks and displays on the device he uses, a newer iPad with Retina display. One of which I, unfortunately, do not have.

The current version of the ePub seems to display correctly in Calibre and ADE, my test apps, and it validates in my XML editor and the IDPF ePub validator. However, there are two glitches that show up only on the iPad: an extra blank page or two before a new chapter (sometimes but not always) and a cover image that works as a cover but is not picked up by the thumbnail-generating software. The book shows up on his iBook shelf with a generic cover.

One formatter over at Mobileread insists that he has tried many schemes to get rid of the blank pages and has given up. I think I give up too. I don't see what in my code, in the page-break-before:always that is part of the chapter .css, should be problematic. The client is willing to accept that the iPad just does that but ...

He wants the cover to be resized for a thumbnail. He sent me an InDesign epub that he said displayed properly as a thumbnail and a cover. So far as I can tell, my code is the same, save that I use a .jpeg file extension rather than .jpg for the image. The .jpg would not pass the IDPF validator. Also, I kept my cover .jpeg rather modest. It's 689x1000; his is 1890x2775. I think that is much larger than generally recommended.

(Peeve: ebook cover size recommendations are all over the place. I cannot figure out who to trust on this. I do not want to craft for one device and mess up the cover for other devices.)

I would appreciate hearing from someone else who has run into these problems, or at least one of them, and has come up with solution(s).

|improve this question
  • Are you making an epub 2 or an epub 3? – Tom Jun 3 '14 at 16:03
  • I edit by emptying an existing epub inside the Oxygen XML editor, tweaking the structure to fit the book I'm currently doing, and filling the chapters with XHTML I've edited in another program. I think I must have started with an epub 2 book. Hard to tell. Code for the xml container contains this: xmlns:opf="idpf.org/2007/opf. The date suggests to me that I'm dealing with epub2. Should I update all my code to reference epub3? I hear that not all readers use it. – Zora Jun 4 '14 at 0:10
  • That date won't actually tell you much; the thing to look at is later on that line. It should say version="2.0" or version="3.0" as appropriate. Anthon's answer here sums it up pretty well. I've been making exclusively epub 3 for about three years now & I've never seen a reading system unable to display it, though obviously bells & whistles (like video) are device-dependent. – Tom Jun 4 '14 at 0:16
  • I should perhaps also add that though I have been reading and making ebooks for eleven years (volunteer at Distributed Proofreaders) I only started doing the actual epub formatting a year ago. I am still learning! I charge my clients less than a pro would charge. However, I think I am doing better than the folks who export to epub from InDesign and consider the ebook done. Never even look at the code. – Zora Jun 4 '14 at 0:18
  • Aha, version 2.0. Just change to 3.0 globally? – Zora Jun 4 '14 at 0:19
1

For iBooks issues, your best bet is to go straight to the iBooks Asset Guide, which is available when you log in to your iTunes Connect account. As far as cover size goes, the guide says:

The book’s cover art must use RGB color mode and should be at least 1400 pixels along the shorter axis. For best results, a good rule of thumb is to use an image that is a minimum of 300 dpi.

This applies to the cover art that is submitted along with the book, not the cover in the book itself. For the cover in the book (and for any other image in the book, for that matter):

Images (within the EPUB) cannot exceed 3.2 million pixels. Apple recommends providing images that are at least 1.5 times the intended viewing size up to a maximum of 3.2 million pixels. You can calculate whether an image inside the book file exceeds 3.2 million pixels by multiplying the height of the image with the width.

Assuming that you're creating an epub 3.0 file, if you add properties="cover-image" to the <manifest> entry for the cover image file, the cover will show up in iTunes.

As far as extra blank pages go: you shouldn't need any page-break-before: always statements to break your chapters, assuming that you've followed best practices and broken the content into one xhtml file per chapter. iBooks and all other reading systems I've seen will automatically break pages for each new file.

What errors specifically did you get that went away when you changed the extension of the cover image? Without seeing anything, my guess would be that there was a difference between how the file was named and what it was called in the <manifest>.

Finally: if you're going to be doing ebook conversions, you really need to have the devices you're converting for—every reading system has strange quirks, and you're doing your clients a disservice if you don't test, particularly on devices that you know they're really interested in.

|improve this answer
  • I cannot buy all the devices I would need to test. I'm too @#$@#$ poor. Not lazy, just old, crippled, alone, over-educated, Aspie. Your reply suggests that I cannot make a one-size-fits-all epub that will work on all ereaders (frex, other ebookstores request much smaller covers). I suppose I can make my client happy with an iPad only version, and generate another, more generic version for other readers. Shades of early web and different versions of web pages for different browsers :( – Zora Jun 3 '14 at 19:49
  • I should add that I do sort my chapters out into separate files. I was going to remove the page-break-before:always from my .css, but another formatter at Mobileread assured me that this would break the epub for everyone except iOS users. Was this person wrong? Mobileread attracts hobbyists who are tweaking ebooks for their device only, so I'm never sure how much to believe of what they say. – Zora Jun 3 '14 at 19:53
  • Sorry, I didn't mean to suggest that a one-size-fits-all epub is impossible. You can certainly do that--it's just difficult, which is why I think it's important to have the devices for testing. Your best bet if you don't have the devices available is to make things as simple as possible--minimal CSS, semantic markup for as much layout as you can. It's definitely like the Browser Wars in #eprdctn land, yes. And yes, I share your opinion of Mobileread--sometimes good advice, mostly hobbyists. If you're on Twitter, check the #eprdctn hashtag for ebook production professionals. – Tom Jun 3 '14 at 19:57
  • I subscribed to the eprdctn Twitter feed briefly, and was overwhelmed by the volume. Some technical stuff, lots of chatter about formatters' personal lives. I follow sf writers Scalzi and Stross on Twitter and that's all I can manage. I already spend too many hours a day keeping up on several email lists, FB, Pinterest, MIT Technology Review, Scientific American, Ars Technica, Slashdot, BoingBoing, and oh, about a few dozen other news sites and blogs. More info, more, more! – Zora Jun 3 '14 at 20:43
  • Agree re simple as possible. My usual .css file (tweaked as necessary for each project) is 120 lines long .. and that's longer than it would be if I didn't insist on putting curly brackets on their own lines. Makes it easier to notice if I miss one. – Zora Jun 3 '14 at 20:49

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.