Page MenuHome

Upgrade freetype to 2.9.1
AbandonedPublic

Authored by LazyDodo (LazyDodo) on Aug 4 2018, 8:44 PM.

Details

Summary

This contains the windows portion, since there will need to be some coordination between the different platform teams, (although this lib is easy/safe with no changes on the blender side) I say just commandeer the patch, make your changes and we'll land all platforms at the same time? and we keep this format for future lib upgrades?

  • Windows cmake
  • Mac cmake
  • Linux cmake
  • Linux install_deps.sh

No idea who is responsible for the linux stuff nowdays

  • Needed additional patch to generate ftconfig.h on windows

Diff Detail

Repository
rB Blender
Branch
arcpatch-D3581
Build Status
Buildable 1877
Build 1877: arc lint + arc unit

Event Timeline

Just went through the whole cmake and seems that there is many errors on newest xcode. Mostly on libraries that need updating anyway.
But for this diff, needs just to take the patch away and remove POSTFIX settings to work on macOS. Working on it, will update this diff later on.

The patch is cherry picked from freetype git (and should be in 2.9.2 or whatever the next version may be) i didn't expect it to cause issues on other platforms?

  • make the diff apply cleanly.

Hi,

The change to 2.9.1 (v40) would adversely affect the font hinting.

https://www.freetype.org/freetype2/docs/subpixel-hinting.html

It looks like v40 has been designed solely around subpixel RGB rendering. Unfortunately, full hinting is no more. It now only aligns on the vertical axis (aligning font horizontals) and ignores all horizontal hinting.

From the linked article:
"The v40 code does not use any whitelist or other means to handle certain fonts differently. It focuses on ignoring horizontal hinting..."
...
"Times changed, LCDs came along and Microsoft rediscovered subpixel rendering that exploits the physical structure of LCD subpixels, usually RGB stripes, to increase the horizontal resolution approximately three times (not quite actually since you need to apply a blurrying filter to lessen color fringes)"

Also, from discussions on IRC, it sounds like Blender's UI text is rendered monochrome, so we're not going to see any benefits from subpixel RGB anyway.

This matches what I'm seeing in the latest Blender builds. Example of 2.6.3 (v35) vs 2.9.1 (v40) in 2.79:


(thanks to bzztploink for the screenshots)

Is there a possibility of staying with 2.6.3 or at least a version which uses the v35 interpreter?

Is there a possibility of staying with 2.6.3 or at least a version which uses the v35 interpreter?

I don't see the difference. The difference in clarity 2.6.3(hinted) vs 2.9.1 (hinted) is not so expressive so that it does not update to the latest version.

In that page from that Freetype I don't see any indication that the new hinting relies more on subpixel RGB hinting than before, rather it says there is no subpixel hinting.

The Blender hinting patch was tested with a more recent Freetype version, which is why fonts looks so different now on some systems. This was not an intentional change, and that's part of the reason we need to upgrade Freetype to the latest version, to fix that bug.

To me current text hinting with Freetype 2.6.3 looks really bad on Linux, both on standard and high DPI displays. I understand some people might prefer that style with less antialiasing, but I rather trust the Freetype developers to do the right thing than trying to do something custom in Blender. To me it seems the 2.9.1 hinting strikes a good balance.

the main difference is the old hinter did both horizontal and vertical hinting, the new one only does vertical, hence a little more horizontal blur. selecting the old interpreter is literally a one liner but i'm gonna leave it up to the UI guys to decide what they want here, regardless this shouldn't hold up any lib upgrade.

In that page from that Freetype I don't see any indication that the new hinting relies more on subpixel RGB hinting than before, rather it says there is no subpixel hinting.

Yep, you could well be correct - which makes v40 more of a mystery since it wouldn't be taking advantage of the horizontal resolution increase.

The Blender hinting patch was tested with a more recent Freetype version, which is why fonts looks so different now on some systems. This was not an intentional change, and that's part of the reason we need to upgrade Freetype to the latest version, to fix that bug.

The current 2.79 and 2.80 Linux builds on buildbot (which still use the older libs?) show good hinting when enabled. I wouldn't call it a rendering bug.

What seems clearer from the article is that the v40 examples show no hinting (pixel alignment/snapping) horizontally, which affects font ascenders and stems.

To me current text hinting with Freetype 2.6.3 looks really bad on Linux, both on standard and high DPI displays. I understand some people might prefer that style with less antialiasing, but I rather trust the Freetype developers to do the right thing than trying to do something custom in Blender. To me it seems the 2.9.1 hinting strikes a good balance.

I personally think it now looks great on my regular 1920x1200 24" display. Crisp for the first time, after years of slightly soft and furry AA text. Much is personal taste, but if there's a hinting option in the user prefs, v40 renders that largely ineffective. Have a look at the right vertical on the M character compared to the following i and t:


What's worse, is that the stems and ascenders are sometimes spread over pairs of pixels or align with them at random:

But I'll wait to see how it looks when 2.9.1 is rolled out to all builds.

At any rate, it'd be good to get feedback from @Tommi Hyppänen (ambient) who wrote the hinting patch and from contributors in D3201

@Paul R (intracube)

The current font rendering with the default font on 2.8 in Linux uses noticeably more horizontal space, and changes the look of the font itself if hinting is enabled compared to leaving it off.

Maybe I'm not reading this correctly, but in ttinterp.h from Freetype 2.9.1 on line 278:

FreeType's minimal subpixel hinting code (interpreter version 40) employs a small list of font-agnostic hacks loosely based on the public information available on Microsoft's compatibility mode[2].The focus is on modern (web)fonts rather than legacy fonts that were made for monochrome rendering. It will not match ClearType rendering exactly. Unlike the `Infinality' code (interpreter version 38) that came before, it will not try to toggle hacks for specific fonts for performance and complexity reasons. It will fall back to version 35 behavior for tricky fonts[1] or when monochrome rendering is requested.

Doesn't Blender render all text monochrome/greyscale? If so, shouldn't the v35 interpreter be used?

"Monochrome" here corresponds to turning off the "Text Antialiasing" option, where there is only black and white. Grayscale vs. RGB is something different.

@Paul R (intracube)
The current font rendering with the default font on 2.8 in Linux uses noticeably more horizontal space, and changes the look of the font itself if hinting is enabled compared to leaving it off.

Yep, that's a known tradeoff with hinted text and not really avoidable. Also the weight/boldness of the text won't be accurately represented. But you trade those things for sharp font edges. For desktop publishing, graphic design, you definitely wouldn't want it. But it's good for raw clarity (code markup, UI text, terminal/shell sessions, etc). I use both depending on the job.

After getting excited by this new feature, I'd hoped the intention was to offer two distinct text rendering options:

  • hinting off: for those that want standard AA text. Much like 2.5 has had from the start.
  • hinting on: for those that want clarity above all else.

It seems we're moving to two almost indistinguishable settings.

Is there a possibility of staying with 2.6.3 or at least a version which uses the v35 interpreter?

I don't see the difference. The difference in clarity 2.6.3(hinted) vs 2.9.1 (hinted) is not so expressive so that it does not update to the latest version.

Some people notice the different font rendering hacks more than others (hinting, subpixel rendering, etc). It's a set of subjective compromises refined over the years.

Just to recap:
It still seems that the v40 interpreter does no hinting horizontally. Since latin/western characters have a lot of straight verticals, it's an interesting design decision... Need to find out more to understand the reasoning behind this.

There are several good hinting options which I think are part of the v35 interpreter:

  • full hinting, which some people might not like due to the extra character spacing or exaggerated sharpness
  • medium hinting, which strikes a compromise between plain anti-aliased text (accurate but soft) and fully hinted

Ideally, there would be a hinting toggle and also some control over the strength. But if some medium hinting is the target, it's not clear to me if v40 can do this.

Blender needs to update libraries over time so this is unavoidable. Isn't it better to raise these concerns about hinting with the Freetype (https://www.freetype.org/) peeps?

Blender needs to update libraries over time so this is unavoidable. Isn't it better to raise these concerns about hinting with the Freetype (https://www.freetype.org/) peeps?

It should be possible to upgrade 2.9.1 libs but still use v35. Specific design decisions went into v40, so it's up to projects to choose the interpreter and settings as required.

Maybe Blender could switch on the fly between 35/40 via a setting in the prefs?

Also, Blender isn't reading the desktop font configuration (at least not on Linux) and ignores settings like the preferred hinting level and subpixel modes. So we just get the defaults. Possibly this area could also be looked at?