Improper geometry after stem-darkening with some fonts

[maximilionus]

For some yet to be defined reasons, some glyphs in specific fonts, or to be precise, some combinations of glyphs in them, get rendered with improper geometry after stem-darkening.

The great example of such would be Google's search engine default font - Google Sans. On the screenshot below, the highlighted area showcases the improper rendering of "rt" glyphs in the word "Short":

While adding the space between "r" and "t" seemingly fixes the problem:

This may have something to do with FreeType stem-darkening implementation for autofitter driver, or the Google Sans font just being broken.

[maximilionus]

One more thing to add. This also happens even with default darkening values for autofitter driver. Tweaking them also doesn't seem to change anything. Trully bizarre 😢.

[Empika1]

This issue is also happening to me in Firefox. I theorize it has something to do with font ligatures, but my attempts at messing around with ligature settings have so far failed. Here are some examples of weird rendering:

The reason I suspect ligatures is because the most common issues are with f and t, which are letters with cross beams that are often turned into ligatures when combined with other letters. However, I got no idea what's happening with G or y.

All of these examples were captured on google search or Discord's web app. I am on Kubuntu 25.10, KDE Plasma 6.45, Wayland, Firefox 147.0.3.

If you could figure out a way to resolve this issue, I would greatly appreciate it!

[maximilionus]

@Empika1 that seems more of an issue with font kerning, not ligatures. It looks like the stem-darkening implementation in freetype is a bit flawed in this direction, but that's still just my assumption for now.

To further prove my point, setting the custom spacing value in Firefox for Google Sans seems to completely fix the glyphs:

I'm trying to experiment with different fontconfig rules, but to be quite honest, I'm not even sure if fontconfig can work with web-delivered fonts like Google Sans, and it looks like it doesn't since I can't even blacklist the font completely.

[maximilionus]

One nasty hack around this for now can be going to about:config in Firefox, searching for gfx.downloadable_fonts.enabled and setting it to false, which will disable the web fonts completely and make the browser rely only on the existing system fonts.

[maximilionus]

@Empika1 I'm getting strange mixed results testing the possible fix and would really appreciate the feedback. Download the latest archive from the master branch and install it the same way as you would do with a release version. After rebooting, try visiting anything with problematic fonts.

The result from Google Search now should look like this:

System:

• Debian 13
• Firefox 147.0.3
• libfreetype6 2.13.3+dfsg-1

[Empika1]

Hello! On my system at least, that appears to have fixed the issue. I can no longer replicate any of my earlier problems. However, the inspector in google search shows Arial and Roboto under "All Fonts on Page", not just Google Sans. Is this intended?

[Empika1]

Actually, after looking closer, I have noticed that on big enough text, the problematic combinations of glyphs from earlier can sometimes look slightly over-boldened?

[maximilionus]

@Empika1 nope, it should use Google Sans. Sometimes Firefox can use system fonts instead of the web one. Reloading the page should fix it.

There might be slight emboldening changes (causing this over-emboldening from your second reply) since I modified the darkening parameters. I will look into that.

What system are your running lucidglyph on? Distro and FF version.

[maximilionus]

I suppose I have no choice but to keep the full stem-darkening for a correct rendering. This will inevitably reintroduce the #9 issue with icon fonts, but since the affected software, like Visual Studio Code, runs on Chromium, which no longer supports FreeType at all, this should not be a problem.

[maximilionus]

It also may be some kind of the recent regression in the rendering stack itself, since I'm getting different results in Debian and Fedora, with the issue being completely unfixable on Fedora even with full stem-darkening without any x1,y1 hacks from #9.