Adjustable line spacing not proportional to font size

[GeoffR]

Does anyone know how the line spacing set via the slider on the font menu relates to the line-height CSS directive, if at all?

If I set the line spacing to minimum on the sider, readingLineHeight=1.3 is set in the device's configuration file. So I thought this would mean the same thing as if I had set line-height:1.3 in the CSS.

But it seems Kobo's readingLineHeight and the CSS line-height value only correspond when font-size:medium is active in the book's CSS. If I have the main text set to font-size:xx-large, then the lines overlap with the slider at minimum (i.e. line-height is less than 1.0), and if I have it set to font-size:x-small then the lines are about double spaced.

However if I set line-height:1.3 in the books CSS then the line height remains proportional regardless of the font-size, the lines are never overlapping or double-spaced.

So this means that the line spacing set via the font menu slider is not changing the line-height in the same way as setting it in the CSS. Hence my question: how to they relate?

Personally I find the minimum slider-set line spacing (readingLineHeight=1.3) comfortable if the book is using a medium font-size, but some books, for reasons I cannot figure out, use font-size:small or x-small for the main text, which causes the actual line spacing to appear proportionally much larger.

This also means that scaling up all the font-size directives in a book's CSS (medium to large, small to medium, etc.) would make the minimum slider-set line spacing much closer, which would probably be more useful (because the slider-set range would be shifted, it could be set near the middle of the range with room to adjust both ways, instead of always at the minimum).

Edit: The cause of the problem was exactly as tshering speculated in post #2. See post #31 for a firmware patch that fixes the problem.

[tshering]

I offer a wild speculation. 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. This difference between the internal line-height setting in em and your css setting might produce differences in elements that inherit the line-height.

[davidfor]

From what I have seen, I thing tshering is right. If I edit a book, I either remove any font sizes, or set them in em's. The basic paragraph will be 1em if I set it. I have done a test in the past where I set various line-heights in CSS and 1.3em seem to match using 1.3 in the reading settings.

[GeoffR]

Thanks tshering and davidfor, that doeslook like what is happening.

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).

I have tried this with one book and it works well. From my Glo's font menu I just reduce the font size slider to bring the oversize fonts back to my normal preferred size, and I can now adjust the line spacing right down to the point where the lines start to overlap using the slider.

[GeoffR]

OK it looks like the font rescaling is not always as straight forward as I thought, but I found a very simple way to reduce the minimum line spacing (while still leaving it adjustable via the line spacing slider) that works for the books I have tried which have font sizes set in terms of "font-size:small", "font-size:medum:", etc., the main text being set to font-size:medium):

All I did was remove any occurrence of "line-height" from the CSS stylesheet, then added the following line to the top of the stylesheet:

body {font-size:80%}

Now I can adjust the line spacing down to the point of being almost unreadibly close on the minimum setting (line height 1.3*0.8 = 1.04 I think), and with the slider on the 4th notch from the left the line spacing is about the same as the prevoius minimum (line height 1.6*0.8 = 1.28, close to the original minimum of 1.3).

(The left-most slider notches set readingLineHeight to 1.3, 1.35, 1.4, 1.6, ..., etc. It seems that if I set the body font-size to 80% then the line spacing for fonts of size medium becomes 0.8*1.3, 0.8*1.35, 0.8*1.4, 0.8*1.6, ..., etc.)

[GeoffR]

As an example, try this book from the MobileRead library: https://www.mobileread.com/forums/showthread.php?t=97675.

Compare with the version attached, which has two lines added to the top of the stylesheet, setting the font size to medium at the paragraph level and to 75% at the body level.

With the attached version the line spacing is still adjustable, but the lines are much closer at the minimum slider setting.

[ewphoenix123]

Interesting, doesn't seem to work with the stylesheet I use in my books, time for some comparison work.

[GeoffR]

Originally Posted by ewphoenix123

Interesting, doesn't seem to work with the stylesheet I use in my books, time for some comparison work.

Another approach I have used with books where the font size is set in em at the paragraph level is to set the font size to 1em at the body level, and then scale up the other font sizes.

E.g. say you have font sizes set like this:

p {font-size:1em}
h1 {font-size:2em}

then change it to:

body {font-size:1em}
p {font-size:1.3em}
h1 {font-size:2.6em}

This should result in the paragraph level line spacing being 1.3/1.3 = 1.0 at the minimum slider setting.

[GeoffR]

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.

Thus if font-size is set at paragraph level to a value different to the body level, then the inherited line-height is incorrect. For example if font-size is 1.0em at body level and 1.2em at paragraph level then the inherited line-height should be 1.3*1.2em = 1.56em, but because of the bug it is actually just 1.3em. This is the bug we can exploit to reduce the minimum line spacing without resorting to setting line-height expliitly in CSS (which would make it non-adjustable).

[DNSB]

Originally Posted by GeoffR

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.

Thus if font-size is set at paragraph level to a value different to the body level, then the inherited line-height is incorrect. For example if font-size is 1.0em at body level and 1.2em at paragraph level then the inherited line-height should be 1.3*1.2em = 1.56em, but because of the bug it is actually just 1.3em. This is the bug we can exploit to reduce the minimum line spacing without resorting to setting line-height expliitly in CSS (which would make it non-adjustable).

Strictly speaking, line-height can be used several ways. If it is unitless, it is used with the current font size so line-height: 1.2 and font-size: 1em would give 1.2em as the line height. Percentage line-heights work the same way as a multiplier for the font size. If the line height is set with a unit (em, cm, px, pt, etc.), it becomes an absolute value regardless of the font size so you get to see large font sizes overlap and small font sizes look lonely in a sea of white space. You can also set line-height as normal which generally is equivalent to line-height: 1.2/120% or 1.3/130% depending on the implementation.

My preference is for using an unitless setting so when I change the font size, the line height automatically changes.

Regards,
David

[Rev. Bob]

Originally Posted by tshering

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.

Originally Posted by GeoffR

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:

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.

Originally Posted by GeoffR

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.

[Rev. Bob]

Originally Posted by DNSB

If the line height is set with a unit (em, cm, px, pt, etc.), it becomes an absolute value regardless of the font size so you get to see large font sizes overlap and small font sizes look lonely in a sea of white space.

While I agree with the rest of your message, I have to point out that "em" does not belong on that list, being a relative rather than absolute unit. It's still a good rule of thumb to say "no units on line-height," but ems should be okay due to their relative nature.

[tshering]

Originally Posted by Rev. Bob

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.

What I meant to say is that "readingLineHeight=1.3" is maybe translated by the software to "body { line-height: 1.3em; }", and that this results in different absolute values in elements that inherit it, if one compares it with "body { line-height: 1.3; }". Whether readingLineHeight is handlet in this way, I don't know. Therefore it is a speculation.

[Rev. Bob]

Originally Posted by tshering

What I meant to say is that "readingLineHeight=1.3" is maybe translated by the software to "body { line-height: 1.3em; }", and that this results in different absolute values in elements that inherit it, if one compares it with "body { line-height: 1.3; }". Whether readingLineHeight is handlet in this way, I don't know. Therefore it is a speculation.

Trouble is, those two CSS statements are equivalent. They both mean, in English, "the total height of a line should be 130% of the font size used on that line." If the font size in a given paragraph is 10 points, that means a line height of 13 points. If there's a 20-point header, its height will be 26 points. That's because an "em" isn't a static value; it always reflects the current font size.

I think what you mean to say is that your theory is that the software calculates the baseline font size in terms of rendered pixels or some other absolute final value, and then mistakenly multiplies that by the line-height - such that line-height gets converted to an absolute unit instead of the relative value it ought to carry. At least, that would explain the results you report.

[tshering]

Originally Posted by Rev. Bob

Trouble is, those two CSS statements are equivalent. They both mean, in English, "the total height of a line should be 130% of the font size used on that line." If the font size in a given paragraph is 10 points, that means a line height of 13 points. If there's a 20-point header, its height will be 26 points. That's because an "em" isn't a static value; it always reflects the current font size.

There is supposed to be a difference (cf. for instance here). In the case of { line-height: 1.3em; } child elements inherit the computed value, whereas in case of { line-height: 1.3; } they inherit the ratio that is used for the calculation. I took this for true without testing and thought it may explain what GeoffR reported.