View Single Post
Old 01-31-2024, 03:07 PM   #30
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,585
Karma: 130140792
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
You gave lots of styling opinions. For example, you don't like a line-height greater than 1.1, yet many people find that too tight. This results in your "never use line-height", which is wrong.
A lot of software these days allows you to set a line height. But some do not completely override and you can only go larger. That's why not to use line height. It's nothing to do with my preference. If you like a large line height and oyu use a program that allows you to set a line height, set it as you like and I'll set it as I like. Put in a line height and we may not be able to set it as we like.

Quote:
I use the line-height attribute whenever it is appropriate. I use it on multi-line headings to reduce or increase the spacing between lines. This allows it to change along with font size, instead of remaining fixed. It also allows me to change the space between lines that are part of the same paragraph, split with a <br />.
Use a margin instead of a line height.

Quote:
I have absolutely no problem using line-height of less than 1 so that the span holding larger characters is not used to compute the overall line height. It works perfectly on my Kindle Scribe. I also use it on sub and sup (or anything else that moves text up or down and would often cause a larger computed line height).
Maybe it works on your Scribe, but I know for sure that older Kindles would not work with a line height of 1. You could not normalize the large letter and the line it is in was offset because the line height changed,

Quote:
I'll bet you didn't know that this happened all the time on physical books too. You just never noticed it because you didn't get to see the "code" underneath. If a section break without a decoration fell at a page break, it often basically disappeared, and the only indicator was the non-indented paragraph.
That's because the section break space was a margin and not padding. Padding works as the space does not disappear. But overall, it's easier to see the section break if it falls at the end/beginning of a page if there is something other then just space.

Quote:
This is not universally true. I've got printed books where there is a mixture of "space only" and "decoration" for section breaks, and sometimes the "decoration" falls in the middle of the page, and sometime the "space only" gets swallowed and a new page starts with a non-indented paragraph.
Maybe it's not always true, but it's mostly true. I've read a lot of pBooks where there was blank space for a section break except for when it falls at the end of a page.

Quote:
Embedded fonts should only be used for something that is not the base reading font. The user gets to pick the base reading font. Using this principle, all embedded fonts work perfectly.
Have you ever read the eBook The Martian by Andy Weir? It was made with free-serif, free-sans, and free-mono as embedded fonts. These are terrible fonts. There are bits in the book that are supposed to be monospace and free-mono is very hard to read on an eInk screen because it's very much too lightweight. The next worse is free-sans followed by free-serif. Overall it's a reading experience that would make you stop reading the book even if you are enjoying it.

Quote:
Choosing "publisher font" is only necessary if the eBook tries to replace the default reading font with an embedded font. When that happens, Kindle ignores it and uses the user-chosen default font. For fonts that are not used to replace the default reading font, embedded fonts display perfectly on Kindle. I have books where entire chapters are a different font from my chosen, and it still works.
Does this appy to KF8 or just KFX?

Quote:
% and em are identical for font size, so you can use either in that case. For actual lengths (margins, padding, indents, etc.), both em and % have times when they work better to create the desired look. In general, though, an eBook creator needs to be aware that "em" scales with the font size scaling the device offers while "%" does not. This means that if a user picks a really huge font, "em" for margins can make things very silly (two words per line, or a handful of lines per page), while you can keep your layout somewhat closer to your ideal by using "%" instead.
I'm not meaning font size. I've seen many cases where the margin uses % and that changes based on the screen. So using em will be consistent regardless of the screen.
JSWolf is offline   Reply With Quote