Feature Request: Mechanism To Update Cover Image on Thorium Where Cover is Not Displayed for Some Epubs

[mbennette68]

Hello,

I've found that fir a good number of epubs, Thorium Reader does not correctly render the cover page.

Here is an example of one from Addison-Wesley/Pierson as it appears in Thorium Reader after import:

I've opened the book up in Calibre Editor which seems to display the Cover correctly:

I am using Thorium 2.0.0 and 2.2.0 on a Windows 10 64-bit machine but the issue persists on both versions:

I've found this issue with epubs from Pierson/Addison-Wesley, McGraw-Hill, No Starch Press, OReilly, etc.
The above do seem to work in Calibre.

It would be helpful if there was mechanism or function to manually update the cover of imported epubs and then resave the epub as well as export the repaired version to another folder or a PDF version all from within Thorium.

It would also be a great addition if dark mode functionality were implemented when viewing PDFs without the images being corrupted and displayed with the colors inverted.

Thank you,
MB

[danielweck]

Thorium Reader does not correctly render the cover page.
The above do seem to work in Calibre

Hello, Thorium follows the EPUB specification, so if the cover image is not declared correctly in the publication package, Thorium cannot find it and we display a plain solid colour instead.
You Calibre screenshot shows cover.xhtml which is not the standardised method for authoring cover images in EPUB.

Now, it is in fact possible that there is a bug in Thorium's implementation :) Could you please privately share EPUBs with me, so I can investigate further? ( [email protected] )

[danielweck]

In reply to @jmamcrg from #1928

Link to the EPUB 3 specification: https://w3c.github.io/epub-specs/epub33/core/#example-item-properties-cover-image

Basically, just make sure that your bitmap (raster) or vector image is correctly declared in your OPF package XML, (manifest section). For example:

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

[diegosucaria]

Experiencing the same issue with PDFs... in the past, the covers were displayed properly, but now they are not..

PDFs are DRM protected

[mbennette68]

I understand,

I've sent a sample ebook that does not display the cover correctly on Thorium to the email you specified. I looked at that section, via Calibre's Book Editor, you specified and there does seem to be a similar entry but perhaps it is not being picked up correctly by Thorium or it might be incorrectly set up in the manifest section of the content.opf file.

This is what is present in that section:

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

The problem is that big book publishers themselves are not following the ePub standard, thus increasingly this error is showing up on Thorium. Basically, in the case of the book that I send, it is an ePub 2.0 standard back. Calibre allows to upgrade the book to ePub 3.0 but that does not seem to help.

We can't count on publishers adherence to the ePub standard as they don't even want to make an effort to make ePubs accessible to the disabled, believe me I know, I used to work as an Alternate Media Specialist for a post-secondary institution and was constantly trying to get them to provide accessible versions of their digital contents but they hardly ever helped or resolved any issues.

It would be great if there were a mechanism to detect a cover.jpg, cover-image.png, or something similar in the book and if install that snippit of code in that section when cover is not properly displayed in thorium, as well as an undo feature in case one messes up.

Thank you,
MB

[danielweck]

Hello, <item properties="cover-image" ... /> is the EPUB3 way of declaring the cover image in the package OPF XML. The EPUB2 format uses a different method: <meta name="cover" content="MY_ID" /> where MY_ID is any valid XML identifier that references the manifest item XML element which points to the cover image resource (e.g. JPEG file with media-type="image/jpeg"). For example in your example above there is id="cover-image" you would need <meta name="cover" content="cover-image" /> in your package OPF.

[mbennette68]

Hello,

Anyway to make the software backward compatible with earlier epub standards?

Thank you,
MB

[danielweck]

Thorium supports both EPUB2 and EPUB3 cover images.
However Thorium does not attempt to repair broken or incorrectly-authored publications.

[mbennette68]

Ok I understand.

I appreciate the feedback.

Thank you,
MB

[danielweck]

if you think that there is a cover image bug in Thorium when you look at other publications, please feel free to report again. as far as we know everything is implemented correctly as per the epub specifications, but we may have missed something :)

[mbennette68]

Yes, I understand.
There probably is not a bug in Thorium. As I mentioned earlier, the issue is on the Publisher side. They refuse to adhere to certain practices, as you noted earlier regarding the schema of the EPUB standard. They will never fix this issue.

Basically, I have approximately 130 books on Thorium, some PDFs and some EPUBs. Out of those, there are 14 EPUBs that behave in the same fashion, where the cover is not displayed and a default blue, green, brown cover is shown.

Somewhere in the book pages, there usually exists a cover file. It would be nice if there was away to just have a feature to override the default behavior on individual books so that a particular cover image could be shown rather than the vanilla default that is shown.

Thank you,
MB

[diegosucaria]

Adding to @mbennette68 comment and use-case, even if EPUB2 or EPUB3 standards are not followed by the publishers, having a fall-back mechanism to find the cover using non-standard tags is a good usability feature.

As an user, the expectation is to have the covers displayed

[danielweck]

thank you for your suggestions. based in your experience, what heuristics do you think Thorium should implement in order to find the missing publication cover image? filename or XML unique identifier containing the term "cover"? what about other languages? what if several files match? (what resource should be elected? should image dimensions be considered too?)

[mbennette68]

Hello Daniel,

That's hard to say as most publishers do what they want with their books.

With that being said, when I open the book inside Thorium and start reading the pages, I often see the Cover Page shown as part of the pages of the book. For example, the following book displays the cover as the first image but I know from looking at Amazon or even the publisher's site that the second image is the cover that they use. I prefer the second image as the cover than the first.

Maybe there could be function that would allow a reader to browse the pages of the book and choose an image on that page as the cover. This is better than having to guess what the publisher is using inside their book. One would think that O'Reilly would adhere to these standards but it often is not the case. Either way, since every publisher is different, and potentially uses different schemas, I'd say my approach could be a better option. Another option is to retrieve meta data from the internet similar to Calibre's method where possible cover images are retrieved and the user can download the one they would prefer. It'd be good to have an undo feature just in case the user makes an error.

The option to add a cover page could be done from this location...

Thank you,
MB

[danielweck]

The original issue has now morphed into a discussion about userland workarounds for when a publication lacks a discoverable cover image (missing / incorrect metadata). The proposal is not for Thorium to automatically take a "best guess" but to allow the user to choose an appropriate candidate image from a shortlist of resources presented in Thorium's user interface. Technical note: Thorium would not modify the original EPUB v2 or v3 publication to add the missing cover image declaration in the OPF package XML file, instead Thorium would store the cached image file outside the ZIP archive as usual, and would patch its cached RWPM Readium Web Pub Manifest JSON file also stored alongside the original ZIP container. This way, Thorium would pick the cover image from its own definition of the publication, not from the original EPUB.