View Single Post
Old 02-03-2024, 05:21 PM   #69
JSWolf
Resident Curmudgeon
JSWolf ought to be getting tired of karma fortunes by now.JSWolf ought to be getting tired of karma fortunes by now.JSWolf ought to be getting tired of karma fortunes by now.JSWolf ought to be getting tired of karma fortunes by now.JSWolf ought to be getting tired of karma fortunes by now.JSWolf ought to be getting tired of karma fortunes by now.JSWolf ought to be getting tired of karma fortunes by now.JSWolf ought to be getting tired of karma fortunes by now.JSWolf ought to be getting tired of karma fortunes by now.JSWolf ought to be getting tired of karma fortunes by now.JSWolf ought to be getting tired of karma fortunes by now.
 
JSWolf's Avatar
 
Posts: 74,455
Karma: 129358310
Join Date: Nov 2006
Location: Roslindale, Massachusetts
Device: Kobo Libra 2, Kobo Aura H2O, PRS-650, PRS-T1, nook STR, PW3
Quote:
Originally Posted by nabsltd View Post
This causes problems if the letter has a descender. Using (1 / font-size) causes the renderer to deal with descenders correctly.
I've never had a problem with a line height of 0. But not matter which line height you use, it won't work on a Kindle. They get ignored. KFX even ignores the metadata in a font for the line height.

Quote:
For eBooks that use the "small-caps for enough of the first line to fill a 6-inch screen, but look stupid on a Scribe because the intent is to affect the entire first line", I use the following all the time and it works perfectly on my Scribe:
Code:
.para-firstinchapter {
	text-align: justify;
}
.para-firstinchapter::first-line {
	font-variant: small-caps;
	font-size: 120%;
	line-height: 0.8;
}
.para-firstinchapter::first-letter {
	font-size: 200%;
	line-height: 0.5;
}

This is absolutely not true. You don't understand how line-height works in an inline element. It's not an absolute. It tells the renderer "use this when computing what this inline element does to the absolute line height of the entire line". You can't reduce the absolute line height of body text below 1.2 on a Kindle, but you can make sure that a character or two of a larger font does not contribute to the calculation to make it larger.

You can see in the attached screenshot that the Kindle renders the same space between each line, despite the large first character, and overall larger font size that my code uses. Note that the "H" in "He" is 13 pixels high, while the "E" in "English" on the next line is only 11 pixels. The whole first line uses a larger font, but the line spacing is 25 pixels (baseline to baseline). This is actually 2 pixels less than the line spacing in the rest of the page, likely due to the exact way Kindle determines the value.
It looks like the first line has less space then the rest second line. Is this KFX or KF8? Does it work on Kindles other then the Scribe or PW5? What does it look like without the line-height in CSS?

Quote:
I don't need to see a blank space at the top of a page...it's a new page, and the paragraph isn't indented. That enough cue for me to know it's a section break.
a non-indented paragraph may not be enough to know it's not a continuation of the paragraph from the previous page. There needs to be a way to differentiate. So space or something in between such as (what I use) a 2px 40% wide line.

Quote:
Again, you don't understand how this has been done for years. Physical books do use an first line indent based on em, so the indent is the same on a hardback or a paperback. That's one case where "em" is the right way to state a length. A margin change, on the other hand (like for a blockquote), is the same size relative to the page (i.e., smaller absolutely in a paperback), so it's better to use percent.
I understand fully. I also understand that % is wrong. With em, the indent is exactly the same no matter the screen size. That's what's correct. What's correct is to keep the indent the same no matter the screen size. Amazon uses a 7% indent and that's awful. If you find a % that;s the size I use now on a 7" screen, it's going to be too large on a 10.3" screen. In ALL cases % is no good on an indent and in most cases a % is no good for a margin.
JSWolf is offline   Reply With Quote