How do I prevent Sigil from removing iTunes Artwork?
 

When opening an ePub file Sigil shows a dialog box:

Files exist in epub that are not listed in the manifest, they will be ignored

iTunesMetadata.plist
iTunesArtwork
iTunesMetadata-original.plist

There isn't anyway to stop this action. I can separately add a cover of course, but the issue is that the Apple book cover is removed.

Is Apple artwork not supported through Sigil?

After editing metadata and adding missing covers with Sigil, I can no longer see the covers when browsing a folder using the Files app on my iPad.

I assume that is because Sigil removed them. Is there some issue with Sigil only being able to support it's own covers and not Apple covers?

None of these files are necessary to see or to have a cover on an epub in any spec epub reader I have ever used. I read epubs in iBooks/Books all of the time created with Sigil and see covers with no problems. And none of them are listed by the opf manifest. So these are not normal epub files that meet any epub specification.

So what are they?

Have you tried unzipping your epub and looking at them? The .plist files are macOS proprietary xml-like property list files. As for the Artwork, it has no image extension so it could be anything.

So not sure why iOs needs or adds these files but they are not required for an epub to have or show a cover.

You might try running your epub through stanadalone epubcheck to see what it says.

Here is an interesting link on MR about these iTunes only "additions".

https://www.mobileread.com/forums/sh...d.php?t=321523

And here is another one from 11 years ago that helps ...

https://www.mobileread.com/forums/sh...5&postcount=13

So it appears these files are generated by iTunes as a cache of sorts. iTunes should properly read the epub opf and generate the plist and properly read the opf metadata to find the cover.

They are not epub spec and must be removed when editing the epub so that if the cover image is changed or metadata in general is changed, they will be properly recreated by iTunes and of course these extras are never needed anyplace else.

So if your cover goes away, that means either your opf metadata to identify the image is incorrect, or you somehow did not properly fully delete the older version of the epub when adding in your new edited version.

Either way, these need to be deleted when editing an epub since they are never updated by iTunes only created by iTunes when an epub is first added.

Just fix your opf metadata to properly identify the cover, make sure these non-spec files are truly gone from the edited epub, delete the original epub from iTunes completely before adding the edited version, and all should work just fine as iTunes will recreate these files properly when they are first added.

A another idea might be to get or use a specification compliant epub reader for iPad. There are many. You might want to try the BlueFire reader or the Kobo reader for example.

Either way, since those files are not spec but hold extractions from the opf that are never updated only created when first added to iTunes they must be deleted to get them to be recreated with updated information.

Thanks for explaining why Sigil is removing the Apple artwork. After reading your research and other posts I've found I did some more testing. This is what I found:

Apple's Books app uses the iTunesArtwork cover. If I import an epub that has it then the Books app will display that cover.

If I replace the cover but do not remove the iTunesArtwork the Books app will prioritize the Apple artwork and the cover that I added manually will show up as the first page of the book.

If I replace the cover AND remove the iTunesArtwork then the Books app will correctly show the new cover.

However, Books is not the only place where a cover appears. iCloud Files will not show covers from ePubs, it ONLY uses the iTunesArtwork as the preview cover.

I found this post: https://www.mobileread.com/forums/sh...5&postcount=13

which explains how Calibre (and Sigil?) were updated with a workaround but I don't think this will help with the preview cover in the Files App as I think the Files App is simply looking for the AppleMetadata.

If you are wondering why the Files app preview is important, it's because that's where I download all my ePubs to. Then I look at them in Files to decide which ones to import to Books. This works well because I have lots of iCloud storage but not as much on my device.

I know I could use OPDS or other solutions to view my library, but all I really need is to view the book cover to decide which ones to import.

Would it be possible to add a setting to Sigil that would write the cover as iTunesArtwork?

Then the ePub files would be viewable in the Files app.

I do understand that I'm asking to have Sigil to be compliant with Apple's extended ePub standard and that it's an extra step above the open ePub standard, but the reality is that a lot of users have iPads and use iCloud storage.

If it helps at all, I'd be open to contributing financially to the project to have this.

It's not possible for Sigil to keep unmanifested files. Unmanifested files are not supported by the epub spec. We could potentially special-case certain proprietary files, but I'm not really that inclined to help Apple ignore standard epub specifications. Plus I'm not a fan of any epub reading system that purposely chooses to modify the contents of an epub archive.

Neither of us are currently accepting any kind of compensation for our work on Sigil.

You might be able to find someone willing to write a python output plugin that could add the Apple artwork file to the epub, but we're not going to make it an inherent feature of Sigil.

In complete agreement with DiapDealer here. Nothing should be storing things (especially unmanifested things) inside the epub's zip folder.

Have you tried simply importing your files into iTunes first just to create those non-spec files for you and then exporting then from iTunes into the Cloud or Files.app for overflow storage?

A better solution would be to File a bug report with Apple to ask it to follow the spec and manifest any additions properly in the opf.

Apple moved books from iTunes to the Books app a few years ago but I think you are asking if a solution might be found within the Books app.

If I strip out the Apple Metadata of an ePub with Sigil, copy that file to the Books app, copy the file to my desktop and then open the file with Sigil I get the extra files warning but only for a .plist file. Apple Books is not creating a cover file named iTunesArtwork.

I didn't expect this to work but thought I would try it. For some reason it doesn't seem that Apple wants to upgrade non-Apple ePubs to Apple ePubs.

The problem unfortunately doesn't end with covers not appearing for non-Apple ePubs in iCloud.

As an alternative, if I view Apple ePubs on my NAS using an iPad File Manager other than Files, I can't see covers either.

So either I can't view Apple metadata or I can't view ePub metadata.

What do ePub publishers do? They are obviously including the Apple Metadata. Are none of them using Sigil? How is that possible?

I understand that Sigil needs to remove these two files as they are considered non-spec:
iTunesMetadata.plist
iTunesMetadata-original.plist

But how do I prevent Sigil from removing the artwork file?
iTunesArtwork

Shouldn't I be allowed to use whatever artwork name I want?

Does this mean that Sigil cannot make a file with the iTunesArtwork?

Add the iTunesArtwork to the OPF manifest. Then Sigil won't remove it.

Technically, it means Sigil won't make/save an epub with iTunesArtwork file. Just like it won't make/retain any other unmanifested files in an epub.

As I mentioned before, your best solution here is to use a third-party output plugin to add the iTunesArtwork file to your epubs whenever you're done editing them in Sigil.

According to what I read in those links I posted earlier, if you have the metadata to properly identify the cover image in your opf and if your cover image is a jpg or png, the iTunesArtwork file should automatically be added by Books.

I am a mac user and created an epub3 ebook using Sigil and once all the normal ways to identify the cover in the opf metadata and guide were set, Books had no trouble recognizing the cover and creating that thumbnail file so that my epub showed the cover thumbnail in Finder.

So my guess is something that Books is looking for in the opf to indicate the cover is missing.

So we need to track this down. Is this an epub2 or an epub3?

Can you copy your opf and post it here? If not, how about a couple of screen shots showing the contents of the opf, so we can see why this works for my testcase epub3 but not for you.

In case this helps, here is what I have in my epub3 opf that allows the cover thumbnail to show in Finder. Also when I add this epub to Books on my iPad, the cover shows on the Books library shelf.

In my OPF, I have named the cover image as "cover.jpg" and have the following related entries:

In the OPF metadata section I have:

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

Note that in the above line "cover.jpg" is identifying the "id" in the manifest for the cover image, not the path to the cover image file itself.

In the OPF manifest section I have two entries related to the cover. The first is to the xhtml file that shows the cover:

<item id="cover.xhtml" href="Text/cover.xhtml" media-type="application/xhtml+xml" properties="svg"/>


and the second is for the cover image file itself. Notice that the id matches what is in the metadata for cover and that the manifest "cover-image" property is set.

<item id="cover.jpg" href="Images/cover.jpg" media-type="image/jpeg" properties="cover-image"/>



With these in place, macOS has no issue creating a thumbnail of the cover so that is shows in the Finder without any need for an iTunesArtwork file at all.

If I then e-mail this to my iPad and load it into Books, the same cover image is identified properly and those extra files are properly created. I did have to remove an older version of that same book from Books first, since it used an older cover which seemed to take precedence.

If your epub is an epub3, does it have these exact same pieces?

As soon as I import the epub containing the iTunesArtwork I get the "Files exist in epub that are not listed..." dialog from Sigil due to the iTunesMetadata-original.plist, iTunesMetadata.plist, iTunesArtwork files.

I want to try editing the opf to set the image property, but how can I prevent Sigil from deleting the artwork before I have had a chance to edit the opf?

I seem to be in a catch-22 as I can't fix the opf file before the image is removed.

The iTunesArtwork file is being created from an image file called "cover.jpg" that is properly manifested and *already* in the epub. It just needs the epub opf to have the proper metadata set. It is not an "new or extra file". It is found and duplicated and then stored in the epub by Books.

So unless you have downloaded this image file from someplace (like you could with old iTunes Album covers) , the file that is the cover is one of the images already in the epub.

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.

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

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?

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

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?

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.

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:


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

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.

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.

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.

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?

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...

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

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.

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.

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.

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.

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".

Unfortunately, on macOS, when double-clicking on an epub renamed to .zip to automatically open it will just try to compress it again as it appears the mimetype file of the epub is confusing it.

It looks at the first entry (the mimetype) and sees it is uncompressed and so thinks the entire file is uncompressed and so "smartly" tries to compress instead of uncompress. Stupid really as you can add uncompressed files to any zip and they might come first.


Either the command line tool unzip or pdurrants applet will work.

I have attached a very very simple test case with a cover png file. I created this as an epub3 in Sigil. On my macOS Desktop the cover image does show up. It passes epubcheck.

Please use it for your testing.

See attached test_books.epub

lol - something Windows does better than Mac....that doesn't happen often!

It happens a lot more then you think. Apple doesn't care what they break when they release a new OS version. Microsoft wants to try to keep compatibility. Apple doing away with 32-bit software was done for no good reason. Some of the underlying settings choices Apple makes for their defaults are really stupid. Worse then most of Microsoft's default settings.

JSWolf, This is not the place for debating macOS vs Windows or to express unrelated opinions. Please stick to the thread topic which it to help the original thread poster, if you are going to post.

Two out of 3 of your posts in this thread are unrelated to helping.