How do I prevent Sigil from removing iTunes Artwork?

[KevinH]

So take your epub, open it is Sigil (and yes your iTunesArtWork file goes away). Use Sigil's BookBowser to get a list of all images files in the epub. One of them must be the original epub's cover. Just identify which one it is by opening each one by double-clicking onit in BookBrowser. Then properly set the metadata in the opf so that Books and every other reader can find that file and determine it is the cover image.

When you add this edited epub to Books with the proper pieces in place, it will copy the indicated cover.jpg file and create a new iTunesArtwork file.

These iTunes extra pieces are just caches (copies) and extracts stored inside the epub zip archive of things that were already there in the epub from the very beginning. They do this for speed reasons once, so they do not have to search for these pieces again and again.

[KevinH]

Again, as I wrote before, I created an epub3 using Sigil. I added a cover image file and properly manifested it and properly identified it in the opf metadata. No iTunesArtWork file exists.

This cover nicely shows in the Finder on macOS, and when I e-mailed it to my iPad and stored it in Books, the Books library shelf shows the cover. On the iPad Books read my epub the first time it was added and it created the iTunesArtwork file copying my epub's specified cover image. The same image file is there under two names. One the original image name manifested properly in the opf, and the second a iTunesArtwork file created and added to the epub to make accessing that image again and again much faster.

I tested this from scratch with my own epub created in Sigil on my macOS machine, and transferred to my iPad and opened in Books.

If you are seeing something else, then I am not sure how or why. The iTunesArtwork file is created based on what you tell it the cover image is, the very first time you load it in Books. Removing that file hurts nothing, as it will be properly recreated by Books the next time. If yours is not being recreated, then the issue is probably in the original epub missing something in the opf.

[Hitch]

Originally Posted by KevinH

Again, as I wrote before, I created an epub3 using Sigil. I added a cover image file and properly manifested it and properly identified it in the opf metadata. No iTunesArtWork file exists.

This cover nicely shows in the Finder on macOS, and when I e-mailed it to my iPad and stored it in Books, the Books library shelf shows the cover. On the iPad Books read my epub the first time it was added and it created the iTunesArtwork file copying my epub's specified cover image. The same image file is there under two names. One the original image name manifested properly in the opf, and the second a iTunesArtwork file created and added to the epub to make accessing that image again and again much faster.

I tested this from scratch with my own epub created in Sigil on my macOS machine, and transferred to my iPad and opened in Books.

If you are seeing something else, then I am not sure how or why. The iTunesArtwork file is created based on what you tell it the cover image is, the very first time you load it in Books. Removing that file hurts nothing, as it will be properly recreated by Books the next time. If yours is not being recreated, then the issue is probably in the original epub missing something in the opf.

Caveat: I COULD BE WRONG HERE and misremembering.

However, my recollection is that the iTunesArtwork file is the cover (the marketing image, displayed on the iBooks website/app), that is uploaded by the publisher, with other metadata, the ePUB file, etc., via iTunes Producer and/or the in-browser upload to The App Formerly Known as iBooks.

And that if there is an in-ePUB cover, in the usual ePUB2 way, and the iTunesArtwork cover, the latter takes precedence for display on the bookshelf.

Anyway...I could SWEAR that's the thing here. And that you can then utterly ignore the iTunesArtwork file, if you simply manifest the "real" cover.

Tex? Are you around? Quoth? Ruben? One of these guys will know better than I, as my "mechanical" bookmaking days are a bit past. I mostly send emails these days, but...I could swear that's what that is.

And BTW, we make ebook files with unmanifested iTunes crap all the time. Finish the ebook, slap it in there and Bob's-yer-uncle. Apple makes this nonsense unavoidable, esp. around fonts. (They swore, 6 years ago, "nooo, you don't need this for fonts to work any longer," but they (Apple) lie like Catholic school-age altar boys caught with the Sacramental Wine on their lips.)


Anybody else here remember this?

Hitch

[KevinH]

Originally Posted by Hitch

And that you can then utterly ignore the iTunesArtwork file, if you simply manifest the "real" cover.

Yes that is what my tests show as well. I started with a fresh epub with a cover and marked it as the cover properly in the opf and then e-mailed that epub to my iPad and added it to Books. Books then created the iTunesArtwork from my cover image on the fly so it would not have to parse the entire opf just to figure out the cover.

Are you saying that commercial epubs are being generated that have no cover image file in them and people add an iTunesArtwork file to act as the cover?

Why on earth do that if one is being auto generated for you as a cache file? Also any book bought from the Apple bookstore typically has DRM that prevents you with messing with it anyway right?

So
- if there is no cover image in the epub as determined by the opf settings

- and if the iTunesArtwork file comes from outside (somehow) (ie. does not exist inside the epub anyplace else)

- and if the epub did not have DRM on it

Then you should be able to:

1. export the epub to your Desktop

2. run unzip to unpack the files in the epub

3. grab the iTunesArtwork file from that unpacked epub and examine it in Apple's Preview to see if it is jpg, gif, png, etc.

4. rename iTunesArtWork properly with the right extension, ie. cover.jpg, cover.png, etc

5. Use Sigil to properly add that image and mark it as the cover in the opf so that you never have to go through this again, and the epub will work properly on all readers.

But I can not imagine that people would not put a proper cover in an epub and mark it in the opf properly since Apple's Books app will nicely create the required cache pieces for all normal epubs.

Is this some old holdover before Books properly created the needed cache files?

[JSWolf]

In real terms, Books is meh at best and it's rarely at it's best.

[robwired]

Im going to try your process tonight. Hopefully it will automagically create the cover for me as well. I think Apple is creating the cover as you state but storing it in their caches and not in the ePub.

If you drag the file from Books app back to your desktop and open it are you seeing the ITunesArtwork still?

Could you tell if if the cover is appearing as a preview thumbnail in the iOS Files app for both files on your device and in iCloud?

[KevinH]

I do not use icloud as networked file storage (for security reasons) but when I e-mailed my file to
my iPad and Added it to Books the cover appeared in Book's shelves. When I copy that file to my iPad's Files.app it shows there as well.

I will see if this holds true on the Desktop as well.

[KevinH]

Okay, it took some digging but I added my epub to Books.app on macOS and the cover appeared nicely on the BookShelf.

Then had to dig for the book in

~/Library/Containers/com.apple.BKAgentService/Data/Documents/iBooks/Books/

And then they had changed the name and unzipped it so it took some searching to find the book I wanted:

~/Library/Containers/com.apple.BKAgentService/Data/Documents/iBooks/Books/F7D7F8CBFC7F4D758B7DA0F1189703B3.epub

And that was a FOLDER and not an epub file. But inside that folder there was created:

iTunesMetadata.plist

and that file specified the cover image path:

<?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>Gerhard Wiedmann</string>
	<key>book-info</key>
	<dict>
		<key>cover-image-hash</key>
		<string>1D8E173E5E63BB1ED6D5BE87D439D0C0</string>
		<key>cover-image-path</key>
		<string>OEBPS/Images/cover.jpg</string>
		<key>mime-type</key>
		<string>application/epub+zip</string>
		<key>package-file-hash</key>
		<string>F7D7F8CBFC7F4D758B7DA0F1189703B3</string>
		<key>publisher-unique-id</key>
		<string>urn:uuid:3851b112-6f3b-405e-bdba-2c00553c740d</string>
		<key>unique-id</key>
		<integer>8183410303695295555</integer>
		<key>update-level</key>
		<integer>2</integer>
	</dict>
	<key>genre</key>
	<string>Non-Fiction</string>
	<key>itemName</key>
	<string>Memoirs</string>
	<key>playlistName</key>
	<string>Memoirs</string>
</dict>
</plist>

I would assume that Books.app on your iPad is doing something similar.

[KevinH]

So on the Desktop, Books.app add this cache material as well. No iTunesArtWork was needed because the plist they created points directly to the cover of the epub.

[Hitch]

Originally Posted by KevinH

Yes that is what my tests show as well. I started with a fresh epub with a cover and marked it as the cover properly in the opf and then e-mailed that epub to my iPad and added it to Books. Books then created the iTunesArtwork from my cover image on the fly so it would not have to parse the entire opf just to figure out the cover.

Which is at it should be. When I test-load ePUB on my latest iPad, which is 1 OS cycle old, sure, the cover displays just fine.

Are you saying that commercial epubs are being generated that have no cover image file in them and people add an iTunesArtwork file to act as the cover?

Not ours, but have I seen it? Oh, yes. We seem to get a fair number of ePUBs "for fixing" that don't have covers. If you ask me WHY, I cannot tell you.

However, I do know that you can, for example, upload coverless ePUBs at B&N, too and yes, effectively prepend the uploaded product image cover.

Amazon does the same bloody thing and if you do have a mobi or ePUB with a cover in it, in fact, they literally yank the damn thing out and prepend the uploaded cover (product image). On the one hand, it gives publishers the ability to easily change their covers, without having to go back to their bookmakers, so that's a good thing, but, then you get this exact sort of confusion.

Why on earth do that if one is being auto generated for you as a cache file? Also any book bought from the Apple bookstore typically has DRM that prevents you with messing with it anyway right?

AFAIK, but I think they're simply thinking about it differently. I am not sure that they (Apple) are thinking about the cover inside the ePUB inasmuch as they are thinking about how the cover appears on the Books-f/k/a-iBooks Bookshelf on the device(s). Seriously, let's not forget--this is APPLE we're talking about here. Appearance is all. I think that the interior cover is...an unintended side effect?

So
- if there is no cover image in the epub as determined by the opf settings

<snippage for brevity>

But I can not imagine that people would not put a proper cover in an epub and mark it in the opf properly since Apple's Books app will nicely create the required cache pieces for all normal epubs.

Well, that's how I would think about that, and your last paragraph--except I seem to see an awful lot of cover-less ePUBs. It's weird, I'm the first to agree, but...

Is this some old holdover before Books properly created the needed cache files?

I'm sorry, I don't know. It's entirely possible, given that the goddamned plist is still in there.I honestly do not recall this "from the early days" with iBooks' Book Asset Guidelines. I do know that the latest Asset Guidelines I've seen still calls for the cover to be manifested with "cover-image" as the property.

I also know that they very specifically and separately refer to the "marketing image" (cover) and the internal cover, as two different things. They refer to the marketing image as being delivered "alongside" the book asset. And as far as I know, the language used in their Asset Guide hasn't changed in..7 years, give or take? https://help.apple.com/itc/booksasse...oj/static.html

Hitch

[robwired]

Assuming you havent deleted the ePub test file, could you attach it here so I can narrow down to working off the same file? If that doesn’t work then there is some other issue.

[KevinH]

Have you just tried just unzipping your epub to get to those files:

1. create a folder on your Desktop called junk
2. your epub to your Desktop into the junk folder you just created
3. In Terminal.app run the following commands:

cd
cd Desktop
cd junk
unzip YOUR_EPUB_FILE_NAME_HERE

then exit out of Terminal.app and go to the unpacked epub inside the junk folder and look for your iTunesArtWorkfile.

My test epub is copyrighted. I will create an even simpler one with non-copyright files tomorrow and post it if the above does not work.

[odamizu]

If you don't want to use Terminal, you can also download pdurrant's ePub Zip/Unzip AppleScript applet from here: https://www.mobileread.com/forums/sh...ad.php?t=55681

Put the applet on your desktop then drag your epub onto the applet and it will unzip it for you.

You can also drag an unzipped epub folder onto the applet to re-zip it up into an epub again.

[KevinH]

I will create a very simple two xhtml (one for the cover.xhtml), two image (one cover.jpg plus another) for you to test with later today and post it.

You never said if this was supposed to be epub2 or epub3.

I will make an epub3.

[Turtle91]

You could also just rename the file extension from ".epub" to ".zip" and then work with the zip file with whatever software you wish (windows treats it as a normal folder) then, when you are done, rename the extension back to ".epub".