Re: I'm back

[Nikolaus Waxweiler]

(oops, forgot to send to the list)

---------- Forwarded message ----------
From: Nikolaus Waxweiler <address@hidden>
Date: Thu, 30 Apr 2020 09:28:34 +0100
Subject: Re: I'm back
To: David Turner <address@hidden>

> Can you clarify what that means exactly? I think I lack context and/or
> examples :-)

See https://www.freetype.org/freetype2/docs/text-rendering-general.html :)

>> Then Qt can go all in on stem
>> darkening and rendering fonts correctly. And hopefully everyone else.
>>
>> What do you mean by "going all in on stem darkening", especially for QT?
> Are you advocating for UIs with darker / bolder fonts or something like
> that?
> Just trying to understand.

To correctly render fonts, you need to linearly alpha blend FreeType's
output onto a surface and then gamma correct it. This necessarily
lightens text, so you stem-darken to counter the thinning. The Adobe
CFF renderer introduced that functionality and Qt 5.9+ will use linear
alpha blending and gamma correction plus stem darkening on CFF fonts.
I implemented stem darkening for the autohinter, but quality at
smaller sizes where it matters most does not match the CFF driver :(
Providing good stem darkening for all drivers would enable Qt (and
hopefully Skia and others) to use correct font rendering regardless of
the underlying font format.

>> Also, the build system generation thing sounds very meta. I'd prefer
>> settling on a single build system (either CMake or Meson and nothing
>> else) 😁
>>
>> I was thinking about something much simpler at first. For example, I have
> some local changes to considerably simplify the content of the rules.mk /
> module.mk.
> This uses a few custom GNU Make functions but that's a hidden /
> implementation detail. The point is to make these .mk files easily
> parseable by something else.
>
> The current build system was designed in a very different time, and there
> is definitely value in changing it more drastically. I'll start a different
> thread to discuss the idea though.

I suppose a simplification would be a good start in any case.

Maybe a single build system like Meson that also generates Makefiles
for other platforms while assembling a release would do the job?
Werner said he'd like a bare git checkout to just work with `make`,
but maybe it's good enough to provide that just in release tar balls?

> Is there a specific corpus of font files being used currently for
> regression testing? Should we try to create one or improve the existing
> one?

I don't know of any test fonts, outside of maybe Armin's fuzzing collection.

BTW, one idea for a regression test I had here would be to have some
fonts like the Noto fonts in OTF and TTF format compiled from the same
source and ensure that e.g. advance width and other metrics match
exactly between drivers (also slight autohinting that should not mess
with various metrics).