View Single Post
Old 02-02-2024, 12:12 PM   #59
nabsltd
Evangelist
nabsltd ought to be getting tired of karma fortunes by now.nabsltd ought to be getting tired of karma fortunes by now.nabsltd ought to be getting tired of karma fortunes by now.nabsltd ought to be getting tired of karma fortunes by now.nabsltd ought to be getting tired of karma fortunes by now.nabsltd ought to be getting tired of karma fortunes by now.nabsltd ought to be getting tired of karma fortunes by now.nabsltd ought to be getting tired of karma fortunes by now.nabsltd ought to be getting tired of karma fortunes by now.nabsltd ought to be getting tired of karma fortunes by now.nabsltd ought to be getting tired of karma fortunes by now.
 
Posts: 419
Karma: 6913952
Join Date: Aug 2013
Location: Hamden, CT
Device: Kindle Paperwhite (11th gen), Scribe
Quote:
Originally Posted by JSWolf View Post
For a large first letter, a line height of 0 works. No need to have to figure anything out.
This causes problems if the letter has a descender. Using (1 / font-size) causes the renderer to deal with descenders correctly.

Quote:
But on a Kindle, you cannot use a line height as small as you are saying as it won't work.
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;
}
Quote:
Maybe. But for most Kindles a line height small enough to fix a large first letter won't work. It will be ignored.
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.

Quote:
Padding works if you insist on having blank space for a section break. Margins can get swallowed. There's no visual difference except if the padding falls at the bottom/top of the screen. If it does, then you do see the space.
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.

Quote:
The thing with em is that I have my Libra 2 and you can have your scribe and the indents will be exactly the same at the same font size. With %, we'd have different indents.
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.
Attached Thumbnails
Click image for larger version

Name:	KindleLargeFirstLetter.png
Views:	51
Size:	8.3 KB
ID:	206170  
nabsltd is offline   Reply With Quote