what have new the firmware 5.12.3?

[NiLuJe]

@rtiangha: Don't rely on old documentation.

Freetype's behavior re: hinting has changed recently (-ish), and how it was built can affect the results anyway. (And even on desktop Linux, where you mostly control the full rendering chain, getting stuff to do what you want can be a bit maddening).
Because the autohinter can be configured in a couple different ways, and the defaults and how some settings interact with that have changed recently (again, -ish).

Amazon, at least, is using a heavily patched FreeType build, so, who knows what's happening there. The font hack used to be able to override it with a custom build with more control over the hinting settings being used, but that's no longer possible.

As for Kobo, they may be using Monotype's iType in some instances, and/or Adobe's own rendering engine, so, also murky.

----

On recent, default Freetype builds, the priority is indeed BCI > autohint > no hinting. And you do explicitly need to request no hinting.

ttfautohint will just bake FT's own autohinting into the font as truetype instructions, which is dubiously useful if the final renderer is also FT (it's basically only useful for old fonts with bytecode that FT doesn't deal with properly, when targeting low dpi rendering).

On high-dpi devices such as ours, you'll generally vastly prefer unhinted rendering to autohinted rendering.

Random related plug: KOReader will allow you to try all three rendering types (with the autohinter set to the new defaults, slight hinting, with a grayscale target screen).

For instance, I am happily using Bookerly rendered unhinted on my Forma, and it doesn't look like crap .

----

TL;DR: Yeah, Amazon fucked up on that one. They should have enforced unhinted rendering, too.

(Fun fact: this is what's done on Android. And iOS. [Roughly]).

[rtiangha]

Originally Posted by NiLuJe

@rtiangha: Don't rely on old documentation.

Well, I quoted QT 4.6 because that's where the system fonts are stored on Kobo. But I also see directories for QT 4.8 and QT 5 and the documentation for that section essentially say the same thing about behaviour on all the versions. But yeah, I have no idea if things are patched to behave differently or what version of Freetype is being used (on Kobo, I assume it's ancient like the kernel and most other things). I just think that it might be funny if the entire font hints vs no hints on eink thing becomes moot in practice after all because of default renderer settings.

[NiLuJe]

@rtiangha: Used to be Qt 4.x, is now 5.2. They kept the filenames as-is to make updates less painful (since it's basically a tarball with no scripting capabilities, so migrating folders & filenames was not easily doable post-install).

FWIW, wonky stem heights is typical of FT autohinting going awry, so, it all tracks . You'd get "fuzzier" rendering if truly unhinted, but with "perfect" (as in, honoring the font's design) shapes. The higher the DPI, the sharper the rendering. Plus, eInk has a tendency to make that fuzziness much less noticeable than on LCD to begin with.

[rtiangha]

Originally Posted by NiLuJe

Random related plug: KOReader will allow you to try all three rendering types (with the autohinter set to the new defaults, slight hinting, with a grayscale target screen).

I'm blind as a bat; where is this setting? In theory then, it should be visibly obvious that explicitly setting no hinting should make the new Bookerly version at the smallest font size look normal, correct?

Edit: Ah, never mind; found it. Bottom menu. I was looking through the top menu bar options, lol.

[JSWolf]

Originally Posted by rtiangha

I noticed the same problem on my Glo HD at the smallest font sizes. It's less noticeable at higher font sizes. I normally read at one size higher than when the problem starts to become more visible which is why I've never noticed.

It's interesting to read the documentation on QT embedded and fonts (I believe that's what Kobo uses; not sure about Kindle). Since it uses Freetype, if a font has no hinting information, default behaviour is that it'll default to using the Freetype autohinter. The only way to disable that (I believe) is for the renderer to turn it explicitly off with FT_LOAD_NO_HINTING. I don't know if Kobos or Kindles do that or not.

I don't know if I'm interpreting this correctly, but does that mean it's possible that all of these fonts are getting autohinted despite some of us explicitly removing hinting information from our sideloaded fonts? Would it be better to rely on a font's default hints or things like ttfautohint to update fonts with crappy (or old) hinting information after all in order to avoid Freetype's autohinter?

Here is the link to ttfautohint. It's great for adding hinting to a font.

https://www.freetype.org/ttfautohint/index.html

And here is the link to the source on Github so it can be built for Linux.

https://github.com/source-foundry/ttfautohint-build

[NullNix]

Originally Posted by JSWolf

Here is the link to ttfautohint. It's great for adding hinting to a font.

https://www.freetype.org/ttfautohint/index.html

And here is the link to the source on Github so it can be built for Linux.

https://github.com/source-foundry/ttfautohint-build

But that's just embedding the result of FreeType's autohinter in the font as explicitly-specified hints. How will that help with a font for which the autohinter is producing bad output? It'll just embed the bad output into the font...

[JSWolf]

Originally Posted by NullNix

But that's just embedding the result of FreeType's autohinter in the font as explicitly-specified hints. How will that help with a font for which the autohinter is producing bad output? It'll just embed the bad output into the font...

I've seen hinting using ttfautohint look better at small sizes under Windows. So why would it not work?

[NiLuJe]

You kind of answered that all on your own already.

Originally Posted by NiLuJe

which is dubiously useful if the final renderer is also FT

Originally Posted by JSWolf

under Windows.

[rtiangha]

I'm curious: The renderer in the Kobo Desktop app is essentially nickel and I don't know how Kindle Previewer works, but would they use Freetype like their eink counterparts or would they use whatever Windows uses? It would be nice to test fonts on the desktop without having to set up an emulator (I know one exists for koreader, but I'm not aware of similar for Kobo and Kindle proper; correct me if such things exist), especially to find out if they ever get around to fixing the current weirdness with Bookerly (and yeah, I understand the final output is an LCD so it'd still be comparing apples to oranges, but oh well).

[xl743]

Originally Posted by jhowell

Bookerly text size 8 bold 1 showing "i" next to "w". The relative heights look good to me.

Size 8 it looks good, but it's a way too big to me. I usually use 3 or 4. And you are lucky you (probably) don't need to read Cyrillic or Greek books! Just take a look at the screenshot I took:

https://i.imgur.com/NhiNjNn.png

On the top it's the new Bookerly, and on the bottom is the old.

It's not a problem to upload the old Bookerly font and continue to read with it, but again, if you only need Latin characters. With any UTF-8 like Cyrillic, Greek, etc. there's a nasty error with custom fonts which makes it almost impossible to use them (sometimes device even crashes and you have to reboot your Kindle). I reported this error many times to Amazon, but it's still not fixed.