How do I prevent Sigil from removing iTunes Artwork?

[robwired]

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?

[KevinH]

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.

[KevinH]

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.

[KevinH]

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.

[robwired]

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.

[DiapDealer]

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.

[KevinH]

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.

[robwired]

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?

[robwired]

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?

[JSWolf]

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

[DiapDealer]

Originally Posted by robwired

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

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.

[KevinH]

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.

[KevinH]

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?

[robwired]

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.

[KevinH]

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.