Bulk CSS Edit?

[BetterRed]

Please post evidence that replacing a cover with calibre's built-in Polish feature changes more code than the Modify EPUB plugin changes to do the same thing.

BR

[HFM1101]

Originally Posted by JSWolf

You do not need to convert ePub > ePub. Retail ePub has the cover at the correct aspect ratio. However, if you get a generic cover or want to change the cover, use Modify ePub by first replacing the cover in Edit metadata.

Thank you

[BetterRed]

@JSWolf - this shows they are structurally identical:



I don't know why Modify EPUB shrunk the cover from 1200x1920 to 741x1186 and Polish didn't?

I know the plugin can do more than Polish, I use it to remove the non Dublin Core metadata… but if all I wanted was to inject covers in bulk I would use Polish… avoids having to install/update a plugin, and its faster.

BR

[JSWolf]

Originally Posted by BetterRed

@JSWolf - this shows they are structurally identical:

Attachment 221900

I don't know why Modify EPUB shrunk the cover from 1200x1920 to 741x1186 and Polish didn't?

I know the plugin can do more than Polish, I use it to remove the non Dublin Core metadata… but if all I wanted was to inject covers in bulk I would use Polish… avoids having to install/update a plugin, and its faster.

BR

Because it's true. Current book is polish and the other is Modify ePub. Why did Polish edit the ToC? And as for Modify ePub changing the cover size, it did not do it here.

[DNSB]

Originally Posted by JSWolf

You do not need to convert ePub > ePub. Retail ePub has the cover at the correct aspect ratio. However, if you get a generic cover or want to change the cover, use Modify ePub by first replacing the cover in Edit metadata.

Ummm... I have had several retail ePubs where the cover did not have the correct aspect ratio. Some stretched/shrank the image to fill the entire screen using img elements, others used incorrect (from my point of view) settings for the preserveAspectRatio ranging from none to xMaxYMax and one publisher which used xMidyMid (does not have the y in upper case which caused a couple of renderers to barf) and another that used slice instead of the default meet for the second option to preserveAspectRatio).

My default for that part of the svg wrapper is:

width="100%" height="100%" viewBox="0 0 1125 1500" preserveAspectRatio="xMidYMid meet">

The 1125x1500 is my default for 3x4 images with 1000x1500 used for 2x3 images.

[JSWolf]

Originally Posted by DNSB

Ummm... I have had several retail ePubs where the cover did not have the correct aspect ratio. Some stretched/shrank the image to fill the entire screen using img elements, others used incorrect (from my point of view) settings for the preserveAspectRatio ranging from none to xMaxYMax and one publisher which used xMidyMid (does not have the y in upper case which caused a couple of renderers to barf) and another that used slice instead of the default meet for the second option to preserveAspectRatio).

My default for that part of the svg wrapper is:

width="100%" height="100%" viewBox="0 0 1125 1500" preserveAspectRatio="xMidYMid meet">

The 1125x1500 is my default for 3x4 images with 1000x1500 used for 2x3 images.

What I have seen for some retail ePub is where the cover was not sized so it was larger then the screen size. I've not seen a retail ePub where the cover was at the wrong aspect ratio. However, if I had one, Modify ePub should take care of that.

[DNSB]

Originally Posted by JSWolf

What I have seen for some retail ePub is where the cover was not sized so it was larger then the screen size. I've not seen a retail ePub where the cover was at the wrong aspect ratio. However, if I had one, Modify ePub should take care of that.

Jon, try for some consistency. Either you have retail ePubs with the covers displaying with the correct aspect ratio or you don't.