View Single Post
Old 05-03-2024, 03:56 PM   #36
NiLuJe
BLAM!
NiLuJe ought to be getting tired of karma fortunes by now.NiLuJe ought to be getting tired of karma fortunes by now.NiLuJe ought to be getting tired of karma fortunes by now.NiLuJe ought to be getting tired of karma fortunes by now.NiLuJe ought to be getting tired of karma fortunes by now.NiLuJe ought to be getting tired of karma fortunes by now.NiLuJe ought to be getting tired of karma fortunes by now.NiLuJe ought to be getting tired of karma fortunes by now.NiLuJe ought to be getting tired of karma fortunes by now.NiLuJe ought to be getting tired of karma fortunes by now.NiLuJe ought to be getting tired of karma fortunes by now.
 
NiLuJe's Avatar
 
Posts: 13,480
Karma: 26012494
Join Date: Jun 2010
Location: Paris, France
Device: Kindle 2i, 3g, 4, 5w, PW, PW2, PW5; Kobo H2O, Forma, Elipsa, Sage, C2E
As was mentioned earlier, KOReader implements a tiny subset of micro-typography magic to contract/expand inter-word ("Word Spacing" in the settings) and inter-letter ("Word Expansion") whitespace.

That's in addition to using a modern harfbuzz, which should yield proper (or at least, "as intended by the font foundry") kerning. Where you might see larger divergences in terms of kerning are outside of LGC, for complex scripts that only fairly recently got better support in harfbuzz.

That's not to say I wouldn't expect *any* kerning differences even on LGC, simply because text rendering is *hard*, and everyone kind of does its own thing, so unless you *know* the stack is *also* FT + HB, you're kind of comparing apples to oranges (which is not always uninteresting in this context, mind you ). (spoiler alert: I'm not sure anything actually uses FT + HB outside of the Qt UI on Nickel, RMSDK does its own thing, and Access is using Monotype's iType font engine)

On that front, Adobe tends to do its own thing (and to do it rather well, I might add. It's been a while, but I distinctly remember Acrobat Reader being something that rendered text exceedingly well, even on low DPI screens (i.e., an LCD monitor), even on systems with *very* opinionated native font rendering (i.e., macOS and Windows).

I also vaguely remember that you had to be very persistent to get one or both of these to handle kerning properly, at the expense of possible rendering bugs (the whole prefer-speed or prefer-legibility css property or something. Might be only for Access, though).

Last edited by NiLuJe; 05-03-2024 at 04:06 PM.
NiLuJe is offline   Reply With Quote