Adding epubs to iTunes with cover images

[sartori]

While preparing some of my books for the upcoming iPad I noticed that when importing them into iTunes the metadata and cover image were not coming up correctly.

This data can be added directly in iTunes using the Get Info option but it would be nice if this information was added by people creating books.

After a bit of investigating I think I have the solution.

For the cover image :

Place a jpg or png image in the root folder of your epub before compressing. The image must be named iTunesArtwork with no file extension.

For the meta data :

Create a file called iTunesMetadata.plist in the root folder of your epub. This file contains a lot of information but below seems to be the minimum to get what is needed for sorting and grouping books in iTunes :

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
	<key>artistName</key>
	<string>***AUTHOR FIRST LAST***</string>
	<key>book-info</key>
	<dict>
	</dict>
	<key>comments</key>
	<string>***COMMENTS***</string>
	<key>genre</key>
	<string>***GENRE***</string>
	<key>itemName</key>
	<string>***BOOK TITLE***</string>
	<key>sort-artist</key>
	<string>***AUTHOR LAST, FIRST***</string>
	<key>sort-artist-status</key>
	<integer>1</integer>
	<key>sort-name</key>
	<string>***BOOK TITLE***</string>
	<key>sort-name-status</key>
	<integer>1</integer>
	<key>year</key>
	<integer>1923</integer>
</dict>
</plist>

Once you have added these two file, any epub dragged into iTunes will show all the correct metadata and cover image.

Would be really nice if Calibre or Sigil created these files when exporting an epub.

Sartori

[kovidgoyal]

Are you kidding me? Apple decided to break the EPUB metadata standard?

[sartori]

Hmmm, after playing around it seems iTunes does pull the metadata from the original content.opf file when importing - it then adds it's own iTunes metadata file if you do the Get Info thing in iTunes.

Not sure if this overrides the content.opf file if you make changes to it then re-import.

[kovidgoyal]

Lets give it a couple of weeks until the picture becomes clearer.

[charleski]

Originally Posted by kovidgoyal

Are you kidding me? Apple decided to break the EPUB metadata standard?

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>

[kovidgoyal]

I wouldn't call adding non existing features breaking a standard. calibre for instance adds series and rating info to the OPF, but in a way that's compatible with the OPF spec.

I wished they'd used the <guide> for the cover instead.

[Valloric]

So let me get this straight... iTunes will pull the metadata from the OPF in the epub and then do... whatever, but to get the cover image to show up you need a <meta> element identifying the ID of the cover image element in the manifest? Is that it?

I agree with Kovid, they really should have gone with the <guide> cover, but I guess I can live with this.

[kovidgoyal]

Of course the scheme they chose is rather calibre friendly, since IIRC calibre generated EPUBs already have that metadata element set.

[Valloric]

Originally Posted by kovidgoyal

Of course the scheme they chose is rather calibre friendly, since IIRC calibre generated EPUBs already have that metadata element set.

So calibre currently adds a meta element referencing a cover image ID? What was the use case for that before the iPad/iTunes epub import?

[kovidgoyal]

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

[charleski]

AFAIK, the guide entry for cover is what ADE uses to generate its thumbnail, so obviously Apple have to do it differently...

[Jellby]

Originally Posted by Valloric

So calibre currently adds a meta element referencing a cover image ID? What was the use case for that before the iPad/iTunes epub import?

If I remember correctly, Mobipocket also relied on the <meta name="cover"> tag (among other things) for identifying a cover in ePUB files. I use it in my ePUBs, it does not harm and I hoped it could be used some day...

[Valloric]

Originally Posted by Jellby

If I remember correctly, Mobipocket also relied on the <meta name="cover"> tag (among other things) for identifying a cover in ePUB files. I use it in my ePUBs, it does not harm and I hoped it could be used some day...

I plan on adding that to Sigil, since it could be generally useful even if you're not using an iPad. Something like a right-click menu option on an image in the Book Browser: "Mark as cover image". It would also mark an image automatically if the first chapter file is "small" and contains just one image (this would naturally be overridable).

The "plist" used by the iPad/iTunes will not be added to epubs by default, but Sigil will add them if an option is selected, either on export or in an options screen.

But we still have to wait a couple of weeks to see how all this turns out. I'll be getting an iPad so I'll be waiting to get some first hand experience with the thing before I start making any iPad-specific changes.

Needless to say, iPad support is very high on my list. Sigil is used by a surprising number of ebook publishers and I'm pretty sure they care deeply about this.

[charleski]

Originally Posted by Valloric

The "plist" used by the iPad/iTunes will not be added to epubs by default, but Sigil will add them if an option is selected, either on export or in an options screen.

It might be safer to let iTunes generate the plist. It contains a couple of hashes for the cover image and package as well as a unique ID that seems to be generated by iTunes. If you import an epub which already has a plist file in it then the ID and hashes are not regenerated, but iTunes will use the data from the plist rather than that from the opf.

I would presume that the hashes and Apple-assigned ID are important for books that are going to the iBookstore.

If Apple remains consistent with their past approach to iTunes data, then it's safe for 3rd-party apps to read iTunes-generated xml, but best not to try to write it.

BTW, iTunes will recognise the dc:creator opf:file-as attribute and use it to set the artist sort field. I tested a couple of the opf:role codes, but iTunes seems to ignore them. The first dc:creator entry is used as the artist name, no matter what the assigned role is.

[Valloric]

Originally Posted by charleski

It might be safer to let iTunes generate the plist.

From the OP's post I gathered that iTunes will not generate the plist. You say it will. Which one is it? Does it read the OPF for the metadata, or does it need special consideration?

I guess I'll have to go and install iTunes...

EDIT: Ah, it seems I missed the OP's subsequent clarification. My bad.