Problem with delete unused media files

[jwes]

Load the attached epub and select tools/delete unused media files. It says that cover.jpeg is unused even though I can see it in the preview window. If I set it as the cover image, it works. This happens on Sigil 2.6.2 and 2.7.0

[KevinH]

Using exact (case sensitive) matching?

Not a bug.

cover.jpg is not equal to Cover.jpg

<div><div><img src="cover.jpeg" alt="" style="width:100%;"/></div>

But BookBrowser shows the file is actually called "Cover.jpg"

All urls use case sensitive paths. This is the spec. Are you on Windows with a case insensitive file system?


Epubcheck should easily detect this case and report it.

[Turtle91]

I see this all the time when I use an image fleuron in a chapter/scene break. html: <hr class="ChDiv"/>

Sigil won’t detect an image that is used via css. Eg. background src. So watch out for those. Reports show the fleuron used 0 times.

[KevinH]

Sigil should detect if an image is only used in background src in css if the case is an exact match when "deleting unused media" is run. If it doesn't that is a bug!

Or is this issue only happen in Reports?

Either way, please post a short epub test case and I will try to track this bug down and fix it for the next release.

Thanks!

[KevinH]

Okay, I checked the Images Reports code and the count value in that Report is only for direct usage by html files not css files. I will expand that count to include direct usage in css files as well in the Images report.

Deleting Unused Media does not use the Reports values in any way. As long as your css includes a proper url() in its property value, it should be handled properly by delete unused media.

Either way a test case would help.

[jwes]

Originally Posted by KevinH

Using exact (case sensitive) matching?

Not a bug.

cover.jpg is not equal to Cover.jpg

<div><div><img src="cover.jpeg" alt="" style="width:100%;"/></div>

But BookBrowser shows the file is actually called "Cover.jpg"

All urls use case sensitive paths. This is the spec. Are you on Windows with a case insensitive file system?


Epubcheck should easily detect this case and report it.

That leaves the question "Why does Sigil display the image in the preview window"? I would be more likely to see it if the image didn't show. I am on windows 11.

[KevinH]

Windows (all versions) uses a case insensitive but case preserving file system. Linux is case sensitive and MacOS can easily be either depending on how you format the drive.

So on Windows when Sigil asks for "cover.jpg" the file name returned by the OS could be any of the following as all these names map to the exact same file:

cover.jpg
Cover.jpg
COVER.JPG
CoVeR.jPG
...
etc.

The spec for interpreting a url that resolves to a file path is that it must match in a case sensitive manner: "cover.jpg" only matches to "cover.jpg" and no other variations.

So Windows sees Cover.jpg as the same file as cover.jpg but this is specific to Windows and may not happen in most standalone e-reading devices that are Linux based.

Again, epubcheck checks for mismatches like this to alert you to fix it.

Many developers hate case insensitive file systems and try to avoid them to prevent inadvertant overwriting of files. In my opinion, Windows still being case-insensitive is a real point of aggravation, and something Windows 11 should have finally fixed, but did not. If you ever format a drive in Windows, there must be a way to create a real case-sensitive file system. It is really easy to do on a Mac.

I use a case sensitive file system on my Mac and the "cover.jpg" in your epub does not appear in Preview since it does not exist. It also would break under other e-readers. So stick to case sensitive file names and never use a filename that only differs by case (upper vs lower) of some of the letters, if you want your epub to work everyplace.

[DNSB]

After cleaning up all the errors around id values in the toc.ncx, epubcheck returned the following:

main.xhtml	10	338	Col: 61: ERROR(RSC-007): Referenced resource "cover.jpeg" could not be found in the EPUB.

I then looked at the contents of Images where the file was named Cover.jpeg. As mentioned multiple times, case sensitivity matters. On a Linux install, Preview did not show the cover image since the file system is case sensitive. A quick and dirty test on two ereaders (Kobo and Kindle) showed neither would display the cover image unless the case matched (both use Linux as the underlying OS).