Adding epubs to iTunes with cover images

[charleski]

Just so it's clear -

If the epub doesn't have an iTuneMetadata.plist in its root, then iTunes will always generate one automatically on importing the file. In this process it scans the opf and extracts certain metadata elements as well as generating a couple of hashes and an ID number whose purposes are currently unclear.

If the epub does have a plist file in its root, then iTunes won't scan the opf metadata and won't generate the hashes or ID. It will simply use the plist as-is and ignore the metadata in the opf.

Any changes to metadata made in iTunes are written only to the plist file.

At the moment epubs do not appear to be included in the xml data created on exporting the iTunes library.

[phearlez]

Originally Posted by charleski

At the moment epubs do not appear to be included in the xml data created on exporting the iTunes library.

I'm not surprised by that. The AppleScript/COM interfaces and the export always have seemed to lag behind features.

[paulpeer]

I've just added

 <meta name="cover" content="img0001.jpg" />

to 30 of my ePubs, dragged them to iTunes, and they all appear perfectly with cover page and the following meta data: title, creator and subject.

[MichaelCampbell]

Originally Posted by kovidgoyal

Identifying the actual raster image that is the cover rather than just the HTML wrapper.

Dr. Goyal: I noticed InDesign uses the "cover" metatag in its ePub creation, referencing the XHTML cover page in the manifest. Like this:
<reference type="cover" title="Book Cover" href="Cover.xhtml" />

I've struggled to get the cover art to appear properly in Stanza for iPhone. Is there an advantage to referencing the original CoverArt.jpg rather than the "Cover.xhtml", if when the XHTML file is, as you say, only a wrapper?

I study your posts and those of Valloric. I greatly appreciate your availability on this forum.

[pdurrant]

Originally Posted by MichaelCampbell

<reference type="cover" title="Book Cover" href="Cover.xhtml" />

This is different to the meta data that iTunes uses. The <reference> element appears in the <guide> element of content.opf, and should indeed reference the xhtml file for the cover.

The meta data needs to appear in the <metadata> element, usually near the start of the .opf file, and would be something like

<meta name="cover" content="cover-image"/>

Note that name="cover" is required, but the "cover-image" bit is arbitrary, and just needs to match the id given in the manifest for the bitmap version of the cover. So, using the above, in the <manifest> element of the .opf file there would also need to be a line

<item id="cover-image" href="images/img0032.png" media-type="image/png"/>

where the id must match the 'content' bit of the meta data, and the href and media-type must correctly identify the cover bitmap.

HTH

[nixwinter]

Originally Posted by charleski

You're surprised???

I was hoping they'd break the standard in a more interesting way. All of this info can be specified using the current OPF techniques. Presumably books bought from their store will have additional fields.

Looks like the cover image doesn't need to be extracted before adding the book to iTunes. The <dict> field contains a cover-image-path child, producing:

	<dict>
		<key>cover-image-hash</key>
		<string>ALLTHESEHASHESAREQUITEINTERESTING</string>
		<key>cover-image-path</key>
		<string>cover.jpg</string>
        </dict>

Which then shows as the cover in iTunes. It seems that iTunes looks for a metatdata element named "cover" and then uses the image with the corresponding id.

Thus, if your book has the following in its .opf file it will automatically find the cover:

<metadata xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:opf="http://www.idpf.org/2007/opf">
...
      <meta name="cover"  content="cover-image" />
...
</metadata>
<manifest>
...
    <item href="[path to cover image within epub structure]" id="cover-image" media-type="image/jpeg"/>
...
</manifest>

Good Lord...
How do I do that in Sigil?

Thank you for any help!!

Nix

[kovidgoyal]

@MichaelCampbell: Referencing the raster image directly is of advantage in the scenario where a library app like calibre, or iTunes or Stanza needs to extract a cover from the EPUB.

If such a reference is present calibre will use it to efficiently extract the cover image. If it is absent calibre will render the first html file to get the cover. Other software, like iTunes is less capable and in the absence of the reference will simply fail to extract the cover.

[Valloric]

Originally Posted by kovidgoyal

If such a reference is present calibre will use it to efficiently extract the cover image. If it is absent calibre will render the first html file to get the cover.

Had I known this before, I would have added the functionality to Sigil a long time ago. You should have said something Kovid.

[kovidgoyal]

no big deal, actually in the absence of the reference, calibre first scans the first html file, if it looks like a wrapper (i.e. no text and only one <img> or <svg:image> element it figures out the raster cover from that

[Vintage Season]

Hmm... for those of us able to properly script an iTunesMetadata.plist file, in order to batch customize our files without worrying about those hashes iTunes insists on generating, would it be possible to give Sigil or Calibre the ability to properly add that file to the root of the *.epub so that the file will still pass epubcheck?

Currently, if I use 7-Zip to simply add the file in the proper location, iTunes accepts it and uses the meta tagging I've specified for grouping and sorting, but epubcheck spits out the following:

ERROR: test.epub: length of first filename in archive must be 8, but was 20

Simply editing an iTunesMetadata.plist file in place, within the *.epub, also produces the same epubcheck error.

iTunes appears to be adding the iTunesMetadata.plist file without setting any file attributes, if that helps.

(If it would help more, I could also generate some quick xhtml and a couple of test files showing specific examples.)

- M.

[charleski]

Originally Posted by Vintage Season

Currently, if I use 7-Zip to simply add the file in the proper location, iTunes accepts it and uses the meta tagging I've specified for grouping and sorting, but epubcheck spits out the following:

ERROR: test.epub: length of first filename in archive must be 8, but was 20

Just checked this, and 7-zip rewrites the archive in a way that moves the mimetype file away from its required position at the start of the archive.
No of characters in 'mimetype': 8. No of characters in 'iTunesMetadata.plist': 20.

The problem lies with 7zip re-ordering the file, and there's not much that can be done unless the 7zip team decides to change it. It looks like 7zip simply isn't suitable for editing epubs unless you're very careful in recreating the archive after edits. I use WinRAR, largely because it allows you to open internal files straight into an editor of your choice. Unfortunately it's not free, but it's never shown this problem.

[Vintage Season]

Originally Posted by charleski

No of characters in 'mimetype': 8. No of characters in 'iTunesMetadata.plist': 20.

That much, I had figured out.

Thanks for verifying the behavior I encountered, though.

- M.

[Vintage Season]

Originally Posted by charleski

The problem lies with 7zip re-ordering the file, and there's not much that can be done unless the 7zip team decides to change it. It looks like 7zip simply isn't suitable for editing epubs unless you're very careful in recreating the archive after edits. I use WinRAR, largely because it allows you to open internal files straight into an editor of your choice. Unfortunately it's not free, but it's never shown this problem.

Solved... and for anyone interested in doing what I described (manually adding an iTunesMetadata.plist file), you can use Info-Zip's free Zip 3.0 utility to properly add the file, without messing up the order, via the following command line:

zip "path to my.epub" "iTunesMetadata.plist"

- M.

[Vintage Season]

... and if it really matters to anyone (iTunes doesn't seem to care) whether or not the Archive bit is cleared (which is iTunes' current manner of handling the task, although the resultant filesize seems to be the same either way), that can be accomplished by using this line instead of the earlier one:

zip -AC "path to my.epub" "iTunesMetadata.plist"

... which allows one to include specific iTunes tags and sorting structure, such as this, in a custom iTunesMetadata.plist:

<?xml version="1.0" encoding="UTF-8"?>
<plist version="1.0">
<dict>
	<key>artistName</key>
	<string>AuthorFirstName AuthorLastName</string>
	<key>book-info</key>
	<dict>
		<key>cover-image-path</key>
		<string>OEBPS/Images/cover.jpg</string> <-- make sure this is correct for your book!
	</dict>
	<key>genre</key>
	<string>Genre</string>
	<key>itemName</key>
	<string>Title</string>
	<key>releaseDate</key>
	<string>yyyy-mm-dd</string>
	<key>sort-artist</key>
	<string>AuthorLastName, AuthorFirstName</string>
	<key>work</key>
	<string>Grouping/Series (if applicable)</string>
	<key>sort-name</key>
	<string>Grouping/Series (if applicable) Number (if applicable): Title</string>
</dict>
</plist>

Assuming your *.epub passed validation before you added the iTunesMetadata.plist, and you follow this method, it should still pass after you add the file.

- M.

[JSWolf]

Just take a look at how Calibre does the cover. It works fine in iBooks.