[Development] about the Cocoa/Freetype fontengine

[Nikolaus Waxweiler]

> This is in the eye of the beholder, to some extent. Ideally you will 
> hardly notice a difference as a casual user.
> [...]
> Well, that's up to the application developer to decide, no? Qt 
> evolves in a universe where it's considered normal to ship copies of 
> the required libraries with(in) each and every application. That 
> includes the FreeType library if that font engine is to be
> supported, and the FontConfig library could be included just as
> easily. With or without patches.

I think you have to carefully match the rendering of CoreText (and its'
darkening algorithm) for users not to notice. At that point, you might 
as well use CoreText, unless you have something very specific in mind.

People notice different font rendering. Just recall the fuzz over 
browsers switching to DirectWrite for text rendering.

> The Infinality patches aren't mainlined (what's left of them) for 2 
> reasons that I'm aware of. The FT developers are overly cautious 
> about possible licensing issues and claim there are performance 
> implications. I can only comment from personal experience and 
> expertise on the latter: humbug.

The performance hit is measurable in the rendering benchmark tool, not 
sure how much it carries over when you use caches, but it's still iffy. 
Rendering glyphs multiple times for subpixel positioning might make that 
even worse.

Can't remember something being about licenses.

The part of the left-over patchset I sifted through contained 
post-processing hacks that in their form were not acceptable for mainlining.

> Is that longer than about 6 years ago? I've been using the patch set 
> for that long, with the accompanying FC and Cairo patches of course, 
> and the only specific circumstance where I had jagged (pun intended) 
> fonts was when an application shipped its own FreeType (wine!) or I 
> tried a new distro. Plus possibly a very rare occasion where the 
> patch maintainer slipped up.

Can't remember, but followed the patchset for at least as long as 
Infinality was active. It's not about being jagged, it's rendering 
consistency. Sit a Core Web font next to some random Google Font font on 
the internet and they'll look jarringly different, like each used a 
different rendering framework. The same happens on Windows, by the way.

> OTOH I get frequent requests to upgrade my Trusty PPA with the 
> patched FT, FC and Cairo libraries, and if you look at the number of 
> forks around and the activity around the various packaging 
> implementation you'll realise that there are a lot of people who
> care and consider the gain in quality is significant enough to mess
> around with system libraries. That's certainly not for nothing.

Understandable, because the starting point is crappy.

>> The entire patch is tailored to a platform that never rendered 
>> fonts correctly.
> 
> Shall we say optimally and make it dependent on point size?

No, incorrectly hits the mark. As soon as your rendered glyph image 
contains shades of gray, you MUST use linear alpha blending and gamma 
correction. Everything else is incorrect. The Windows and Mac platform 
have been doing that for decades, X11 libs never did to my knowledge. 
Or, Qt4 or 5 once did and was immediately called back by users 
complaining about thinner looking text. That is why you need some form 
of darkening on top, at least on LoDPI screens.

>> The fuzziness FT > CoreText > FT X11 is because on X11, some form 
>> of hinting is usually turned on and there is no linear alpha 
>> blending plus gamma correction, leading to harsher rendering that 
>> only appears less fuzzy.
> 
> That's the whole trick, isn't it? Exploiting specifics of human 
> vision so things look sharp while in reality they aren't and even if 
> they were we wouldn't perceive them as such (read up on how fresco 
> painters from the Renaissance worked around that, for fun :))

The "sharpness" is bought with overall harsh- and blotchyness and weaker 
rendering of lighter text on darker backgrounds. It's a bad trade and 
makes people flock to band-aid solutions like the Infinality patchset :)

>> CoreText ignores hints but darkens stems (overly so by default) to 
>> counter the effects of gamma correction, FT will only do that when
>>  told so.
> 
> Which only means that both platforms have there own suboptimal way
> of doing things. Font developers provide hinting for a reason and
> spend inordinate amounts of time getting it right. Ignoring it is
> just stupid, at least on devices with traditional and affordable
> display densities.

Apple could do with a lighter darkening algorithm, yes, but it's okay, I 
usually turn it down one notch. The CFF darkener delivers the best 
looking results so far, as it only counters the thinning such that the 
font looks as meaty as before gamma correction.

There is not always a good reason behind a certain hinting decision 
(just look at all the fixing Infinality has to do; hinting can be a very 
seat-of-the-pants business) and it is perfectly acceptable to ignore it 
all and do something else (autohinter) or nothing at all (CoreText). 
Remember that it's the design of a font, not the hinting that is canonical.

One of my pet peeves with TrueType hinting is that the designer decides 
the final look, which can clash with the decision of the designer of the 
font right next to it. Compare the hinted look of Source Sans Pro, 
Ubuntu or https://acumin.typekit.com/ to what's on Google Fonts which 
its' many ttfautohint'ed fonts. Or compare it to CFF fonts.

Background: (hintslight) autohinter and CFF engine only snap horizontal 
stems to pixel boundaries but do not change their width. TrueType fonts 
like those mentioned snap the entire width to pixels and may change 
vertical stems and bearings. Sounds like a small difference, can make a 
font look very different however.

>> You probably shouldn't enable stem darkening when using the 
>> Infinality set or turn off hacks for CFF fonts until there are no 
>> more issues.
> 
> I probably would if I knew how.

export FREETYPE_PROPERTIES=cff:no-stem-darkening=1