Thread: Adjustable line spacing not proportional to font size
View Single Post
Old 07-18-2013, 04:29 AM   #11
Rev. Bob
Wizard
Rev. Bob ought to be getting tired of karma fortunes by now.Rev. Bob ought to be getting tired of karma fortunes by now.Rev. Bob ought to be getting tired of karma fortunes by now.Rev. Bob ought to be getting tired of karma fortunes by now.Rev. Bob ought to be getting tired of karma fortunes by now.Rev. Bob ought to be getting tired of karma fortunes by now.Rev. Bob ought to be getting tired of karma fortunes by now.Rev. Bob ought to be getting tired of karma fortunes by now.Rev. Bob ought to be getting tired of karma fortunes by now.Rev. Bob ought to be getting tired of karma fortunes by now.Rev. Bob ought to be getting tired of karma fortunes by now.
 
Rev. Bob's Avatar
 
Posts: 1,760
Karma: 9918418
Join Date: Feb 2013
Location: Here on the perimeter, there are no stars
Device: Kobo H2O, iPad mini 3, Kindle Touch
Quote:
Originally Posted by tshering View Post
From looking a little bit into libnickel during the last days, I have got the impression, that there line-height is primarily set in em. Even if readingLineHeight=1.3 seems to suggest a unit-less value, it might perhaps be handled internally as 1.3em.
That's exactly how it should work. A unitless line-height value of 1.3 should be identical to a percentage value of 130%. Since both of those are relative values that depend on the current font size (which is always 1em, by definition - more on that in a minute), both of those values should be equivalent to 1.3em.

Quote:
Originally Posted by GeoffR View Post
This means that there is a way to effectively reduce the Kobo's minimum line spacing from 1.3 to 1.0 while still leaving it adjustable: just scale up all the font sizes in the book so that the size of the main text is 1.3em (removing any existing line-height directives if necessary).
That shouldn't work, and if it does, there's something wrong with either the book's CSS or the inheritance processing of the CSS.

See, an em unit is defined by the current size of the font. Consider the following CSS, assuming it's the only styling in effect:
Code:
body { font-size: 10pt; line-height: 1.2; }
h1 { font-size: 30pt; }
Within an h1, the default line-height is 36pt - because 1em in that setting is 30pt, and 30 x 1.2 = 36. In a standard paragraph in that context, the line-height should be 12pt.

It should therefore be obvious that setting a font-size to 80% should have no effect on line-height; all it does is make your text smaller. Since the line-height is* dependent on the current font size, the proportions won't change.

* In properly-written CSS, of course. Nobody should ever, ever, EVER define text-related values in an ebook - such as line-height - as absolute units. This is VERY STRONG BAD EVIL practice. There are some cases where doing so in a very limited scope can be useful, such as to match a text caption to an embedded image, but such cases are so incredibly rare that I feel comfortable with ignoring them as statistically insignificant.

Quote:
Originally Posted by GeoffR View Post
This is my guess about what is going on with the font size and line spacing:

As tshering noted above, the Kobo readingLineHeight set by the slider is in units of em. But it does this based only on the font size at body level, and does not scale the value properly properly at lower levels.

For example if the CSS font-size at body level is the default 1.0em and readingLineHeight is at its minimum setting of 1.3, then the line-height at paragraph level is the inherited value 1.0em*1.3 = 1.3em instead of the unitless value 1.3, which I think is a Kobo bug.
If you're right, that is a rather serious bug that should be squashed with extreme prejudice, as it contradicts fundamental CSS inheritance rules.
Last edited by Rev. Bob; 07-18-2013 at 04:32 AM.
Rev. Bob is offline   Reply With Quote