Modify ePub plugin dev thread

[kiwidude]

Originally Posted by JSWolf

Or make it if one is checked, it unchecks the other.

Indeed, that is another way of doing it. In actual fact this dialog has three cases like this:

- Remove existing cover / Insert or Replace cover
- Remove margins from Adobe .xpgt files / Remove Adobe .xpgt files and links
- Remove legacy metadata jackets / Remove all metadata jackets

In all these cases if you choose the latter option, then the former option is redundant and should not be chosen by the user.

I'm up for feedback from people about this. The options are:
(1) Treat those three pairs of options above as checkboxes that when checked will uncheck their "partner".
(2) If the first option is checked, do nothing. If the second option is checked, uncheck and disable the first option. You must uncheck the second option to enable the first option.
(3) Do nothing. Behind the scenes I will ignore the fact that you chose the first option if the second is checked.

Suggestions please

[theducks]

In the direction of Mutually exclusive.
(M)DI groupings
tick a D box, and all the appropriate I's get excluded (disabled)

In this case the D tick box was you second item, not ticked allows the your first item
(Backwards logic here )

[kiwidude]

I will add one more thing rather than edit my post yet again. My concern about options (1) & (2) is the lack of visual queues to the user that the checkboxes are linked. It is kind of using checkboxes like radio buttons and is a bit secret squirrel. There would have to be some sort of graphic added so the user would know visually, otherwise if they aren't careful they start wondering why some things uncheck themselves and others don't. Which makes me sway towards option (3)...

[JSWolf]

Originally Posted by kiwidude

Indeed, that is another way of doing it. In actual fact this dialog has three cases like this:

- Remove existing cover / Insert or Replace cover
- Remove margins from Adobe .xpgt files / Remove Adobe .xpgt files and links
- Remove legacy metadata jackets / Remove all metadata jackets

In all these cases if you choose the latter option, then the former option is redundant and should not be chosen by the user.

I'm up for feedback from people about this. The options are:
(1) Treat those three pairs of options above as checkboxes that when checked will uncheck their "partner".
(2) If the first option is checked, do nothing. If the second option is checked, uncheck and disable the first option. You must uncheck the second option to enable the first option.
(3) Do nothing. Behind the scenes I will ignore the fact that you chose the first option if the second is checked.

Suggestions please

1 and 3 are OK. I don't like 2. But for my vote, I'd go with 1. I prefer the idea of having the correct options checked based on what I've checked.

[kiwidude]

I was very tempted to just push this live already but given my recent track record with it some additional testers welcomed...

Changes for this beta version:

• When choosing Remove existing cover, ensure any NCX and internal TOC links are removed.
• If a user chooses one of the redundant options, don't run it.

I've chosen option (3) of those I presented in the posts above. It doesn't preclude me from also implementing option (1) of the checkboxes unticking themselves at a later date if people say they want it, but right now it stops the plugin from doing extra work or having unfortunate side-effects.

[JSWolf]

Now the cover links are fixed even when I have both exclusive options checked.

[jackie_w]

Originally Posted by JimmXinu

Well, if there's a vote going on, I'd say cover.xhtml is even less ambiguous.

Well, yes, I couldn't disagree with that But as it's not what calibre conversions currently do, I suppose it's out of the question.

[kiwidude]

@JSWolf - Marvellous, thanks.

I'll give folks another 24 hours to see if anything else comes up and then it will be released. If anyone does notice anything that is related to a particular ePub, please just PM or email me with a link as soon as you do, it saves a whole lot of guessing and time on my part.

As a heads up I am also intending to move all of the posts related to this beta version into the Modify ePub development thread in the Development subforum. I was in two minds about whether to put the beta on that thread in the first place to keep this thread clean, but was worried I might not get enough people seeing it there. It is now 75 posts later, and once I release those posts are of no real interest/relevance to anyone in future browsing this thread, so some cleanout is on the cards.

[sherman]

kiwidude:

When I use the modify epub plugin to update the cover in an epub, I notice that the resolution specified in the SVG does not change to match the size of the new cover. Not being an expert in SVG, does this matter at all?

<div>
    <svg xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink" version="1.1" width="100%" height="100%" viewBox="0 0 x y" preserveAspectRatio="xMidYMid meet">
        <image width="x" height="y" xlink:href="cover"/>
    </svg>
</div>

I'm talking about the 'x' and 'y' above.

[kiwidude]

@sherman - that is a limitation in how the Save to Disk/Send to Device logic in calibre works (which is what this plugin calls if you use that "Update metadata" option).

IIRC calibre has fairly simple logic that is implemented when you save to disk/send to device for updating covers, it doesn't change the contents of the html page and just replaces the cover image itself if it can identify it.

If you want the height and width to be updated, then you would either reconvert, or even better use the insert/replace cover option that is in the beta version of this plugin due for release later today.

As to whether it matters or not... it probably depends on whether you have preserve aspect ratio set? Maybe Kovid can enlighten us...

[kovidgoyal]

IIRC it does not matter. Those number establish the "viewbox" of the svg and since the image's width and height are set to the same numbers, its basically telling the renderer that the image should occupy the entire viewbox. The actual size of the image is irrelevant.

[sherman]

Thanks for the replies.

I had just noticed it while poking around inside my epubs, and wasn't sure if it mattered or not.

[Claghorn]

Here's an idea for a brand new feature I just did manually on one epub: An option to detect grayscale images in the book and change them to .png images instead that are black blocks with different transparency levels. This would make all the little chapter decorations and such look much better when you use a reader that has a non-white background set.

[Hoods7070]

Originally Posted by Claghorn

Here's an idea for a brand new feature I just did manually on one epub: An option to detect grayscale images in the book and change them to .png images instead that are black blocks with different transparency levels. This would make all the little chapter decorations and such look much better when you use a reader that has a non-white background set.

That'd be nice ...

[IDtheTarget]

I just updated Calibre to 0.9.34, and I can't seem to "Modify ePub" any longer. I'd added three tags and added a cover to each of six books I'd bought from bn.com (and imported using the DeDRM tool), and now I just get "failed" when I try to "modify ePub". I've tried it with only the "update metadata" check box, and both that one and "remove broken image pages" checked.

Could you look at it?

Thanks!