View Single Post
Old 08-03-2023, 11:16 AM   #9
nabsltd
Fanatic
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: 524
Karma: 8500000
Join Date: Aug 2013
Location: Hamden, CT
Device: Kindle Paperwhite (11th gen), Scribe, Kindle 4 Touch
Quote:
Originally Posted by Sirtel View Post
The things I nuke outright are embedded body font, body margins, line height, atypical body font size - those just go via the mass Find & Replace.
Sounds very familiar, although I have found that I need to actually look at the line-height values to see if I should keep them. An example is that in most readers, a larger-font for the first letter in a paragraph (initial cap) will cause the line height to expand and leave a lower margin that is too large. This can be fixed by applying line-height: 1; to the span.

But, since any value less than the actual computed line height will end up with the correct display, I have seen all values from zero to one, using both bare numbers and percentages. I couldn't come up with a regex that kept those while destroying things like line-height: 1.5;, so I fix them manually.
nabsltd is offline   Reply With Quote