Thread: Kobo Device Driver Update
View Single Post
Old 08-03-2013, 08:38 PM   #179
davidfor
Grand Sorcerer
davidfor ought to be getting tired of karma fortunes by now.davidfor ought to be getting tired of karma fortunes by now.davidfor ought to be getting tired of karma fortunes by now.davidfor ought to be getting tired of karma fortunes by now.davidfor ought to be getting tired of karma fortunes by now.davidfor ought to be getting tired of karma fortunes by now.davidfor ought to be getting tired of karma fortunes by now.davidfor ought to be getting tired of karma fortunes by now.davidfor ought to be getting tired of karma fortunes by now.davidfor ought to be getting tired of karma fortunes by now.davidfor ought to be getting tired of karma fortunes by now.
 
Posts: 24,905
Karma: 47303824
Join Date: Jul 2011
Location: Sydney, Australia
Device: Kobo:Touch,Glo, AuraH2O, GloHD,AuraONE, ClaraHD, Libra H2O; tolinoepos
Quote:
Originally Posted by jackie_w View Post
I see it got lively whilst I've been asleep!
As they say, you snooze you lose. But, now I have to catch up.
Quote:
@Geoff, David, I have previously tried the p {line-height 1.0 !important} trick but it resulted in the whole epub being displayed as if it didn't have a css file. I've just tried again with 3 random epubs - same result for all of them. Have you tried it with success? I had assumed (perhaps wrongly) that the !important in the extra_css may be conflicting with the several !importants Kobo have hard-coded in the fw (libnickel.so.1.0.0)
I tried this last night and it did what you said. I had tried "!important" on something else without problems. I will have to try some other settings to see what happens.
Quote:
I don't see how it's possible to predict all the class names that may be assigned to any epub's 'standard paragraph' let alone every epub's standard paragraph.

Whether the plugin should allow line-height to be treated exactly the same way it does widows/orphans and @page - I'm not sure. I know I wouldn't use it because of the display problems Geoff pointed out -- but as long as users are told the pitfalls... People like me just wouldn't add a line-height setting in the extra_css and those with a strong preference the other way would.
It's a thought, but I think it is more likely to have bad side effect than the widows/orphans.
Quote:
P.S I forgot to say that the reason I included body.calibre, body.calibre1,... etc in my suggestion is that it's slightly easier to hazard a guess at the class calibre might use with the <body> tag. However, if you do conversions of conversions of conversions... maybe the calibrenn class just keeps increasing into double figures. Of course, my suggestion is only going to work if there aren't any line-heights set lower down the chain on <p>, <div> or even <blockquote> classes.
Ok, but from looking at converted books, it won't help. Each generated class is only used for one type of tag. And the number increases as you go through the book. The body for the first file is always "calibre". I'm not sure if I have seen a second class generated for the body. If the conversion is setting line-height, it is set in the class used by the paragraph. That means overriding it could be a problem. I suppose adding "p.calibreNN" for the first 10 or even 20 numbers would catch most. And it shouldn't have a bad effect on the non paragraph uses of the lass.
Last edited by davidfor; 08-03-2013 at 08:43 PM.
davidfor is offline   Reply With Quote