Quote:
Originally Posted by ownedbycats
...
I hope this was detailed enough information to replicate the issue.
|
Yes, thank you.
Okay, here's what is going on:
When deciding whether there is an existing image or not before generating a new one,
the code looks at the internal metadata entry
cover_image for values 'specific', 'first', or 'default' indicating if a cover is an explicit cover image, the first image in story or a default cover setting respectively. It's
not, however, looking for the value 'old', for a cover image from the existing epub.
If you have 'Update EPUB Cover?' unchecked, FFF literally injects
[overrides] never_make_cover:true into INI settings behind the scenes. (It's actually one of the oldest options in the FFF plugin.) That prevents
cover_image from being 'specific' or 'first'.
It's debatable whether 'old'
should be considered in this case. Because a cover previously created from Generate Cover (or cal equiv) will
also have
cover_image='old'. So if you wanted to generate a new cover from updated metadata to replace a previously generated cover, it wouldn't; because there's already
a cover.
There's additional possible complexity when using a GC setting that also uses the existing image as part of the generated cover, just to muddy the waters some more.
Right now, the only solution I see for a case where you don't want the site cover
and want your own cover
and don't want a generated cover is: turn 'Update EPUB Cover?' back on and set
never_make_cover:true for that specific story URL in INI. Or unclicking 'Update EPUB Cover?' while updating that particular story.
This is all more complicated than it looks: FFF
maybe putting a cover in the epub, then
maybe setting calibre's cover from the epub, then
maybe generating a new cover (
maybe using the existing calibre cover), then
maybe injecting it back into the epub again. While several of the
maybes can also be significantly configured as well. And then all the complexities of coming back around to update it later.
It is admittedly a bit of a mess and you've wandered into a corner case that is probably ill served. But I don't see a good solution right now.