Answers.Body: <p>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:</p>
  
  <blockquote>
    <p>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.</p>
  </blockquote>
  
  <p>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):</p>
  
  <blockquote>
    <p>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.</p>
  </blockquote>
  
  <p>Assuming that you're creating an epub 3.0 file, if you add <code>properties="cover-image"</code> to the <code>&lt;manifest&gt;</code> entry for the cover image file, the cover will show up in iTunes.</p>
  
  <p>As far as extra blank pages go: you shouldn't need any <code>page-break-before: always</code> 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.</p>
  
  <p>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 <code>&lt;manifest&gt;</code>.</p>
  
  <p>Finally: if you're going to be doing ebook conversions, you really need to have the devices you're converting for&mdash;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.</p>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2014-06-03T19:49:59.093Z
Answers.Text: 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 :(
Answers.UserDisplayName: Zora
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2014-06-03T19:53:22.223Z
Answers.Text: 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.
Answers.UserDisplayName: Zora
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2014-06-03T19:57:17.087Z
Answers.Text: 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.
Answers.UserDisplayName: Tom
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2014-06-03T20:43:14.633Z
Answers.Text: 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!
Answers.UserDisplayName: Zora
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2014-06-03T20:49:17.240Z
Answers.Text: 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.
Answers.UserDisplayName: Zora
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2014-06-03T20:57:54.097Z
Answers.Text: Well, best of luck with it. I hope the above answers were useful; if not, drop a comment and we'll see what we can figure out.
Answers.UserDisplayName: Tom
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2014-06-03T18:46:39.137Z
Answers.LastActivityDate: 2014-06-03T18:46:39.137Z
Answers.UserDisplayName: Tom
Body: <p>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.</p>
  
  <p>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. </p>
  
  <p>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 ...</p>
  
  <p>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. </p>
  
  <p>(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.) </p>
  
  <p>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). </p>
  
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2014-06-03T16:03:50.487Z
Comments.Text: Are you making an epub 2 or an epub 3?
Comments.UserDisplayName: Tom
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2014-06-04T00:10:13.193Z
Comments.Text: 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="http://www.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.
Comments.UserDisplayName: Zora
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2014-06-04T00:16:46.377Z
Comments.Text: 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](http://ebooks.stackexchange.com/questions/205/can-epub-3-0-be-viewed-on-epub-2-devices) 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.
Comments.UserDisplayName: Tom
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2014-06-04T00:18:39.417Z
Comments.Text: 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.
Comments.UserDisplayName: Zora
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2014-06-04T00:19:59.630Z
Comments.Text: Aha, version 2.0. Just change to 3.0 globally?
Comments.UserDisplayName: Zora
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2014-06-04T00:25:05.123Z
Comments.Text: Slightly more complicated than that, I'm afraid. epub 3.0 takes a new toc structure which replaces the old toc.ncx, and there are some more content.opf changes, as well as some changes to namespacing in the header. My business partner and I did a presentation a few years back; the slide deck is [here](http://www.slideshare.net/digitalbindery/down-and-dirty-epub-3).
Comments.UserDisplayName: Tom
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2014-06-04T00:26:39.277Z
Comments.Text: Thanks, will look at slides. I appreciate your spending the time with this comparative newbie.
Comments.UserDisplayName: Zora
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2014-06-04T00:27:51.117Z
Comments.Text: always happy to help! FYI, epub 2 should work just fine in iBooks as well; it's just been long enough that I don't know how to make the cover show up in it. The `properties` tag might work, but I suspect it would cause epubCheck to freak out in an epub 2 file
Comments.UserDisplayName: Tom
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2014-06-04T00:36:57.440Z
Comments.Text: Have never used chat, don't have your email but ... looked up your company. You are my homie. I grew up in Beaverton and went to Reed. Perhaps you know my brother, Keith Lofstrom.
Comments.UserDisplayName: Zora
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2014-06-04T00:44:18.880Z
Comments.Text: Oh, nice! Small world. I'm a transplant; been here about 5 years. I don't know your brother, I'm afraid!
Comments.UserDisplayName: Tom
Tags: <epub><cover>
Title: Problems with ePub for iPad
UserDisplayName: Zora
ThreadText: # Problems with ePub for iPad
  
  (Asked by: username_0 on 2014-06-03)
  
  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).
  
  **Tags:** epub, cover
  
  > **Comments:**
  > **username_1**: Are you making an epub 2 or an epub 3?  
  > **username_0**: 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="http://www.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.  
  > **username_1**: 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](http://ebooks.stackexchange.com/questions/205/can-epub-3-0-be-viewed-on-epub-2-devices) 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.  
  > **username_0**: 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.  
  > **username_0**: Aha, version 2.0. Just change to 3.0 globally?  
  > **username_1**: Slightly more complicated than that, I'm afraid. epub 3.0 takes a new toc structure which replaces the old toc.ncx, and there are some more content.opf changes, as well as some changes to namespacing in the header. My business partner and I did a presentation a few years back; the slide deck is [here](http://www.slideshare.net/digitalbindery/down-and-dirty-epub-3).  
  > **username_0**: Thanks, will look at slides. I appreciate your spending the time with this comparative newbie.  
  > **username_1**: always happy to help! FYI, epub 2 should work just fine in iBooks as well; it's just been long enough that I don't know how to make the cover show up in it. The `properties` tag might work, but I suspect it would cause epubCheck to freak out in an epub 2 file  
  > **username_0**: Have never used chat, don't have your email but ... looked up your company. You are my homie. I grew up in Beaverton and went to Reed. Perhaps you know my brother, Keith Lofstrom.  
  > **username_1**: Oh, nice! Small world. I'm a transplant; been here about 5 years. I don't know your brother, I'm afraid!  
  
  ---
  
  ## 1 answers
  
  ### Answer by username_1 on 2014-06-03. Score: 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  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 .
  
  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.
  
  > **Comments:**
  > **username_0**: 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 :(  
  > **username_0**: 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.  
  > **username_1**: 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.  
  > **username_0**: 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!  
  > **username_0**: 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.  
  > **username_1**: Well, best of luck with it. I hope the above answers were useful; if not, drop a comment and we'll see what we can figure out.  
  
  ---
  
  