[GUI Plugin] Modify ePub

[JSWolf]

Originally Posted by kiwidude

Re the line-height, don't get me started. A construct that should be completely banned from epubs for the utter stupidity with which they are frequently overused to the detriment of allowing the epub to be displayed under the control of the ereader device defaults. I already floated the idea of having it as an option for this plugin on the development thread for it not so long ago.

However there are two edge cases I am aware of/was reminded of where arguably they appear to be "needed" - one is when you have dropcaps on an opening paragraph (or else you get a slight additional margin under the first line). The other is for some particular embedded fonts which otherwise will leave the lines too spaced out (unless you remove the font-family).

So in 99.9% of cases they can and should be removed, but the virtually impossible to automatically detect edge cases put it in the same bucket as indents, margins, justification, font families and font sizes as crap that we have to manually manipulate on every frigging epub because there is no standard for styles and the overly complex flexibility offered with css/html.

For the line-height, all we do is let the buyer beware and if it makes a problem, so be it. I would not mind taking the risk. Besides, the ePub can be viewed ahead of time to check. Besides, if I need line-height, it's not what the publisher puts in and were it's put in. I only use line-height wen a font used is too spaced apart. For the dropcaps, if the CSS style has the words drop and/or cap in it, don't remove the line height as that is usually correct to leave it in.

As for the text-indent, do you think that can be done using my idea?

[kiwidude]

As I said I floated the line-height removal idea previously but no-one else came out in support of it so it went on the back-burner. Now that the covers stuff is done and working well it might find itself back in as a candidate one day.

As for the text-indent stuff, I'm afraid it isn't anywhere near that simple. In my original reply to you I had typed a whole paragraph discussing how if I was showered with money I might dabble with a fuzzy logic based approach, which would do things like using frequency and position to infer probabilities of styles being for certain purposes etc. But that might make it sound like I was contemplating attempting it - which I'm not. There are so many issues without aggregating/rewriting the css styles it isn't funny. So I removed the text from my post... but since you persist you get it now

[44reader]

Originally Posted by kiwidude

Re the line-height, don't get me started. A construct that should be completely banned from epubs for the utter stupidity with which they are frequently overused to the detriment of allowing the epub to be displayed under the control of the ereader device defaults. I already floated the idea of having it as an option for this plugin on the development thread for it not so long ago.

Firstly thanks for the update and all your amazing, free, generous hard work on this and all your plugins.

Just a quick question - a cheeky one because it's not really for this thread...

I've often wondered why the default in Calibre's convert dialogue (Look & Feel) is "minimum line height 120%".

Is that too introducing something unnecessary? Can I make it 100% instead?

[DoctorOhh]

Originally Posted by 44reader

I've often wondered why the default in Calibre's convert dialogue (Look & Feel) is "minimum line height 120%".

If you hover over this item you will be able to read the explanation for exactly what this item does. Assuming the font size is 100% this ensures a 20% spacing between the lines.

I have converted over 9000 books with this as the setting and they are all exactly what I desire.

Originally Posted by 44reader

Is that too introducing something unnecessary? Can I make it 100% instead?

You can make it 100% but your lines might just butt up against each other.

[44reader]

Originally Posted by dwanthny

If you hover over this item you will be able to read the explanation for exactly what this item does. Assuming the font size is 100% this ensures a 20% spacing between the lines.

I have converted over 9000 books with this as the setting and they are all exactly what I desire.



You can make it 100% but your lines might just butt up against each other.

D'oh! I get it completely. Thanks.

[Toxaris]

Is it possible to add a feature to remove the 'height: 100%' from the CSS? In most readers this will probably do nothing, but in at least the PRS-T1 this causes that an advance to the next page will not work when the text is not filling a page.
I think it is quite an unnecessary attribute, but I do find it in various stylesheets.

[JSWolf]

Originally Posted by Toxaris

Is it possible to add a feature to remove the 'height: 100%' from the CSS? In most readers this will probably do nothing, but in at least the PRS-T1 this causes that an advance to the next page will not work when the text is not filling a page.
I think it is quite an unnecessary attribute, but I do find it in various stylesheets.

It is used to make a graphic size to the screen. I am not sure how well it works in ADE, but using height="100%" in an img statement does work as intended as long as the margins are set to 0.

[Toxaris]

The problem arises when the height:100% is set in the body and/or html class.

[JSWolf]

I've found an issue with inserting covers. I am surprised I never noticed this before. The thing is, I don't want the cover image resized to be 775 lines. That means the same ePub on say an iPad won't look good as it will be too small. cover images do work on a Sony if they are larger then 775 lines. Can this either be removed or made yet another check option to resize?

Rescaling cover image from 921x1400 to 510x775

[jackie_w]

Originally Posted by JSWolf

I've found an issue with inserting covers. I am surprised I never noticed this before. The thing is, I don't want the cover image resized to be 775 lines. That means the same ePub on say an iPad won't look good as it will be too small. cover images do work on a Sony if they are larger then 775 lines. Can this either be removed or made yet another check option to resize?

Rescaling cover image from 921x1400 to 510x775

I'll also be interested in kiwidude's comments on this.

I think the cover size, and all other book content images are scaled, during a conversion, depending on what you have set in Convert - PageSetup - Output profile. That image size you quoted looks like it could be the standard Sony output profile. For the iPad the 'Tablet' profile is probably more suitable (no image resizing) I wonder if Modify Epub also uses your Prefs default output profile to decide on whether to scale cover size or not?

I don't have a tablet, but my phone has a fairly high resolution (1280x800). I haven't yet figured a way (if there is one) to create a single epub whose images are going to be optimal on both devices. Internal images either flow off the side of my PRST1 or fill less than half of the phone screen. But at least an epub with an SVG cover will stretch to fill the screen (in one or both dimensions) on both devices simultaneously.

So far I've kept my default as 'Sony' rather than 'Tablet', but if anyone has any creative ideas, I'm all ears. I know it can be done by having 2 book entries for the same title but I don't think I'd want to do that.

It would be quite nice to have the calibre library 'master' epub always having full-size images and an option to rescale as part of the Send-to or Save-to transfer process, where the output device is known. But I suppose this would be a lot of work, not to mention significantly slowing down the transfer.

[kiwidude]

Jackie has it right. This plugin follows the same approach as calibre of resizing the cover image to your device output profile. It resizes because (a) some legacy devices don't do resizing very well and (b) it results in a smaller ePub. If you want a larger image, set the appropriate device profile for that.

And no there is no elegant way to handle multiple device image sizes for your books. Personally it doesn't bother me because while I have both iPads and a Kindle I only use the Kindle for reading on - I would never bother trying to read an ePub on an iPad. It is only PDFs I read on the iPads and they are not put through the calibre conversion pipeline. However I can understand that if you were trying to put the same books on a phone and a larger ereader it could cause you some headaches. Just carry your reader around and stop trying to read on your phone

[JSWolf]

The solution is not to resize at all. In an SVG container, the images get resized properly. So a larger sized image then the screen will fit on the screen. So please, either make resizing an option or take it out altogether.

[kiwidude]

Not resizing at all is not a "solution" - it solves neither of the two reasons which I clearly stated as to why calibre resizes images. Not resizing is a possible "option" I may consider one day but it is not a "solution" to anything.

[JSWolf]

Originally Posted by kiwidude

Not resizing at all is not a "solution" - it solves neither of the two reasons which I clearly stated as to why calibre resizes images. Not resizing is a possible "option" I may consider one day but it is not a "solution" to anything.

It is a solution. It is THE solution. I don't want tiny cover images. I want cover images that if originally large enough, I get future compatibility with. Let's say that high resolution eink panels where to replace the ones we have now so that instead of 800x600, the resolution becomes 1024x768. The cover images then would be too small and have to be sized UP. That would not look as good as being sized down. What you are doing is limiting us on the size of the cover when we don't need to be. Futre devices (IMHO) will have higher resolution be it larger scree eink reader or ones with a high resolution screen or be it a tablet.

Buy resizing the image, you make the being able to change/add in a cover image useless.

[kiwidude]

@JSWolf - it is *YOUR* solution which while it might make you happy is not necessarily *THE* appropriate decision to be made for every other user out there. As you well know calibre has in excess of 6 million users. If enough users felt that strongly about it Kovid would have changed calibre's conversion behaviour - there are reasons for why it does what it does which are just as important to other users. Personally I find large covers a complete and utter waste of time and disk space. All this drama for something that users immediately skip past on their way to reading the book (Kindle users don't even have to skip it?).

Without this option in Modify ePub if you want a bigger cover you can change your output profile and just run the plugin again. There is no end of the world doomsday scenario here, the plugin can be re-run perfectly safely for those who now want bigger covers.

As I said above I will consider an option to not resize for a future release, but it isn't important enough that I am going to sacrifice a rare sunny evening in london for. And if your world will end without it, feel free to go back to using Tweak ePub to substitute your covers like you used to do. I'll get over it, honest.