[GUI Plugin] Generate Cover

[hobnail]

Using Sigil's metadata editor I added a second title metadata element and added to it the attribute subtitle. When I ran the Generate Cover plugin it used the subtitle. Back in Sigil's metadata editor I used the arrows to move the subtitle below the main title and that fixed it.

    <dc:title>Fishpingle</dc:title>
    <dc:title id="tle">A romance of the countryside</dc:title>
    <meta refines="#tle" property="title-type">subtitle</meta>

[JimmXinu]

To the best of my knowledge, the GC plugin only uses Calibre's metadata.

I don't know what impact Sigil has on Calibre's metadata. I wouldn't have expected it to have any.

[theducks]

Jimm has it
Generate cover uses Calibre, not the book
I add {Series} to my generated covers, and {#subtitle} <<my custom column
That uses the Custom Text block in Generate Cover

[hobnail]

Originally Posted by JimmXinu

To the best of my knowledge, the GC plugin only uses Calibre's metadata.

I don't know what impact Sigil has on Calibre's metadata. I wouldn't have expected it to have any.

So are you saying that calibre is using the first title metadata it finds? The subtitle was first in the content.opf file.

[hobnail]

Yes, Calibre is using the first title it finds in the metadata. When I posted about the order problem with this plugin I hadn't noticed that Calibre's Title column was using the subtitle.

[Tetchystar]

I really like this plugin, but was wondering. Is there a way to have a random image chosen when you generate a cover? For example, if I choose generate cover for multiple books at once, can it randomly select an image?

[JimmXinu]

Generate Cover plugin does not do random images.

Calibre built-in cover generate can do random styles, but I don't think you can choose images for it?

[compurandom]

Originally Posted by JimmXinu

Generate Cover plugin does not do random images.

Calibre built-in cover generate can do random styles, but I don't think you can choose images for it?

The built in metadata editor will let you select PDF and it will generate thumbnails for the first 10 or so pages and let you pick one. For epubs, it looks for the book's designated cover, I think. But it would be neat if it had an option to pull the first 10 images in the book.

I can see generating covers from a random image in an epub, that might be interesting.
When I do it by hand for epubs, I typically use the book editor, and browse the images, usually picking the second or third one (or first one after the current cover), copy it, set it as cover in the metadata editor, and then use generate covers using the current cover as image.

This is a bit tedious, but luckily only has to be done once per book. If I import a big batch, I end up poking at them over a couple of weeks until they all have useful covers.

[JimmXinu]

New Test Version Attached

2020-10-26
- Translation enabling code changes
- Translations for French & Spanish

@dunhill popped up in my PMs with a (mostly) translatable enabled version of GC, along with a couple (partial) translations:

Frances by un_pogaz
Spanish by Dunhill

Unfortunately, Dunhill's version didn't get all the translatable strings. I had to add or fix ~1/3 of the total, so the fr & es versions dunhill gave me are incomplete.

A few important notes:

1. Unlike my own plugins, this is *not* in Transifex. The 'default.pot' file and translation .po files is in GitHub only. Ideally, translation contributors will submit their .po files by GitHub Pull Request, same as code contributions.
2. The Field Order settings are not translated. They are the same as the saved values, so translating them will break existing settings for translation users without a lot more work. It's certain possible, but I don't have the energy right now.

You can use the CALIBRE_OVERRIDE_LANG environment var to test different languages. I use the fake language 'zz' for testing translation code. (Google it if you need help with CALIBRE_OVERRIDE_LANG. )

[dunhill]

Originally Posted by JimmXinu

New Test Version Attached

2020-10-26
- Translation enabling code changes
- Translations for French & Spanish

@dunhill popped up in my PMs with a (mostly) translatable enabled version of GC, along with a couple (partial) translations:

Frances by un_pogaz
Spanish by Dunhill

Unfortunately, Dunhill's version didn't get all the translatable strings. I had to add or fix ~1/3 of the total, so the fr & es versions dunhill gave me are incomplete.

A few important notes:

1. Unlike my own plugins, this is *not* in Transifex. The 'default.pot' file and translation .po files is in GitHub only. Ideally, translation contributors will submit their .po files by GitHub Pull Request, same as code contributions.
2. The Field Order settings are not translated. They are the same as the saved values, so translating them will break existing settings for translation users without a lot more work. It's certain possible, but I don't have the energy right now.

You can use the CALIBRE_OVERRIDE_LANG environment var to test different languages. I use the fake language 'zz' for testing translation code. (Google it if you need help with CALIBRE_OVERRIDE_LANG. )

First of all I want to thank un_pogaz for the French translation of the plugin.
And another thing that I wanted to clarify is that with the intention of not hurting the plugin code, I was translating the text that I was seeing simultaneously on the plugin screens.
Thank you in advance for your comments.

[un_pogaz]

Ah... Yes... there is "somes" missings strings, I will complete this.

For the "Field Order" problem, during the first translation I encountered a similar problem for the iterator:

for name, display_name in DIC_name_font:

Originally 'Title', 'Author', 'Series' and 'Custom' as hard coded in a table, so I created the DIC_name_font, to translate all of them and keeping the keywords (it's not a dictionary because it tended to send the words in alphabetical order, and I need the both values at the same time)

If the texts for "Field Order" are fixed and determinate (which seems to be the case), a similar solution could be applied.

EDIT: I just took a look: It's going to be a bit more complicated >_>

[JimmXinu]

New Test Version Attached

2020-10-27
- Update Spanish translation - thanks dunhill!

2020-10-26
- Translation enabling code changes
- Translations for French & Spanish

[JimmXinu]

New Test Version Attached

2020-10-28
- Add a missed string for translation - thanks un-pogaz!
- Update French translation - thanks un-pogaz!

2020-10-27
- Update Spanish translation - thanks dunhill!

2020-10-26
- Translation enabling code changes
- Translations for French & Spanish

[worstje]

Hi,

Back in June 2019, on post 639 in this thread, I submitted a bugfix for a centering issue when having a certain combination of settings activated. Unfortunately it was not incorporated yet.

Can it (or some other suitable fix) be included so I can stop manually patching draw.py whenever a new version comes out?

Thanks for updating this plugin for Calibre v5 however; it means I can finally make the upgrade plunge.

[JimmXinu]

New Test Version Attached

2020-10-31
- Fix for border causing img to move horz.
- Remove draw_old.py, not needed in Cal v2+ - min valid calibre is v2.85.1

2020-10-28
- Add a missed string for translation - thanks un-pogaz!
- Update French translation - thanks un-pogaz!

2020-10-27
- Update Spanish translation - thanks dunhill!

2020-10-26
- Translation enabling code changes
- Translations for French & Spanish

worstje: Sorry, I don't remember anything about that.

Your change corrects the left-right shift, but in turn introduces a similar up-down shift.

Instead, the issue is that the code didn't use the available size for width. See github commit