iBooks doesn't show book covers at full screen

[ghost]

The book cover (specified with <meta name="cover">) just shows as a tinny unreadable thumbnail in the "bookshelf". I think it should be part of the reading experience, being shown when starting to read book.

[dvschultz]

One solution for this is to create an html page that has the cover image referenced in it.

Kindle handles covers the way you mention. This could probably be standardized and save us all headaches.

[ghost]

Well, I try to make one EPUB file that works well everywhere. Then adding a html page with the cover makes it to be shown twice in some platforms.

[dvschultz]

what platforms will show it twice when you include an html version?

[ghost]

Kindle will do if you import from an EPUB into KDP.

[dvschultz]

hmmm...it shouldn’t. kindle removes the cover.html if you use any recent kindlegen.

check out 3.2.3 in this: http://kindlegen.s3.amazonaws.com/AmazonKindlePublishingGuidelines.pdf if you assign the correct tags as listed there, kindle will remove it when run through kindlegen so you can create one EPUB file for all vendors.

[elmimmo]

This is not a valid issue IMHO.

Inside an EPUB, the cover typically exist in two forms:

1. As an image
2. As an XHTML document (or in EPUB 3.0.1 potentially as an SVG document), which may itself link to the image above or not (and use XHTML or SVG instead for text).

The EPUB 2 spec does not contemplate a way to declare the existence of the 1st type inside the ebook, but a way to do so is nevertheless a necessity for ereaders to be able to display the book's thumbnail in book lists, as having to process the XHTML version just for that would probably be too costly for some. So while the unofficial <meta name="cover" content="cover-image"/> arose as the undeclared-but-still-standard method to identify such cover-as-an-image, the sort-of agreed-upon intended use of said image is to serve as a visual identification method of the book in book lists, i.e. when closed (this is my perception of its function, I do not have a source to back this; this is indeed not the case of how Kindle makes use of it), not as its first page.

Once you open the book, the ereader should display what is declared in the spine in the order it is declared. If you want the cover as the first item (which is the natural thing IMHO) nothing forbids you to simply have the 2nd type (i.e. a cover as an XHTML document) as the 1st item in the spine. That is the way the spec intends you to do. Hopefully EPUB will one day accept images as content documents, at which point you will be able to simply declare the 1st type of cover also as 1st item in the spine.

Note that EPUB 2 does contemplate a way to declare that such XHTML document is specifically a cover

<guide>
    <reference href="001.xhtml" type="cover"/>
    …
</guide>

(which you can do regardless of 001.xhtml having a spine position other than 1st, but doing so is delving into deliberate non-sense IMHO even if the spec allows for it). So an ereader could use the guide to infer whether it should give a special presentation to that document. Some do, but not quite in the way one could guess:

• Kindlegen uses that (or the corresponding landmarks syntax in EPUB 3), with the added requisite that such spine item is the 1st and has the attribute linear="no", to infer that such spine item is indeed the XHTML rendition of the cover. If that is the case, it will move the document to the end of the book contravening the order declared in the spine, in order to avoid displaying the cover twice—as whatever the case it will nevertheless display the cover-as-an-image first—).
• iBooks uses that to omit the cover from its native TOC. Apple decided for you that you do not want it there, even when you explicitly add it (gotta love ereader overrides) to the NCX document in EPUB 2 or the Navigational Document's TOC in EPUB 3.

EPUB 3 does contemplate a way to declare in a standard way the existence of a cover-as-an-image, by providing that image's entry in the manifest block the attribute properties="cover-image". Still, even if you do that, you would do good to still keep the old non-standard-but-still-standard <meta name="cover" content="cover-image"/> if only for backwards compatibility or for ereaders that are not fully EPUB 3 compliant even when they say they are. But again, that image is specifically intended to serve as thumbnail, not first page of the book.

[ousia]

The cover from this ePub2 document is displayed fine by Adobe Reader Mobile (in a Sony PRS-T1), mupdf-1.10a and ebook-viewer from calibre.

iBooks doesn’t seem to be able to recognize it. In fact, iBooks adds a cover page and then it shows the SVG image. The book was automatically generated with pandoc-1.18.

@elmimmo, do you know whether iBooks is able to display SVG images in cover pages?

I’m interested in fixing the problem in pandoc itself.