Fix #105388: Default Font Accidentally Kerning #105415

Harley Acheson · 2023-03-03T22:14:33+01:00

Harley Acheson commented

2023-03-03 22:14:33 +01:00

Move the code that disables kerning for the default font so it can't be
re-enabled by the cache subsystem.

TL;DR: If I'm going to disable kerning for our default font, it needs to be done where it can't be turned back on by the FreeType cache subsystem. This just moves the location of such disabling without any other changes.

Long version:

We are using the FreeType caching submodule, with settings that are quite constrained. We are currently only allowing 4 faces to be used and loaded by FreeType at a time (BLF_CACHE_MAX_FACES). That is a bit mean but it is nice to have this at a setting where we can see these kinds of errors, since we haven't been using the cache system for long. If this were set to some large amount it might hide errors that only become visible when users use a lot of fonts at once.

With this set to 4, we initially load the main font, then the mono font twice (for reasons), for a total of three. At this point kerning is properly turned off for the default font. But then you select an object and click "G" to move it. We then have to find a font that has a character we need on the status bar: "⭾" (horizontal tab key).

This causes us to look through our font stack, guessing where it might be. We guess well and only look in NotoEmoji, NotoSansSymbols, and then find it in NotoSansSymbols2. But this causes our first font to unload since we are over 4, and when it is reloaded the flag that I tried to disable is reenabled. For any readers unfamiliar, this glyph is then cached so we don't have to do anything the next time we need it; in fact the font containing it can even be released and never touched again.

This might actually be caused by changed behavior by the cache subsystem in FreeType version 2.12.1 because I have not seen this happen prior. The older version might have had a different algorithm for what it kept and discarded. No matter though as it showed that this code was in the wrong place.

Move the code that disables kerning for the default font so it can't be re-enabled by the cache subsystem. --- TL;DR: If I'm going to disable kerning for our default font, it needs to be done where it can't be turned back on by the FreeType cache subsystem. This just moves the location of such disabling without any other changes. **Long version:** We are using the FreeType caching submodule, with settings that are quite constrained. We are currently only allowing 4 faces to be used and loaded by FreeType at a time (BLF_CACHE_MAX_FACES). That is a bit **mean** but it is nice to have this at a setting where we can see these kinds of errors, since we haven't been using the cache system for long. If this were set to some large amount it might hide errors that only become visible when users use a lot of fonts at once. With this set to 4, we initially load the main font, then the mono font twice (for reasons), for a total of three. At this point kerning is properly turned off for the default font. But then you select an object and click "G" to move it. We then have to find a font that has a character we need on the status bar: "⭾" (horizontal tab key). This causes us to look through our font stack, guessing where it might be. We guess well and only look in NotoEmoji, NotoSansSymbols, and then find it in NotoSansSymbols2. But this causes our first font to unload since we are over 4, and when it is reloaded the flag that I tried to disable is reenabled. For any readers unfamiliar, this glyph is then cached so we don't have to do anything the next time we need it; in fact the font containing it can even be released and never touched again. This might actually be caused by changed behavior by the cache subsystem in FreeType version 2.12.1 because I have not seen this happen prior. The older version might have had a different algorithm for what it kept and discarded. No matter though as it showed that this code was in the wrong place.

Harley Acheson requested review from Brecht Van Lommel 2023-03-03 22:14:56 +01:00

Brecht Van Lommel approved these changes 2023-03-03 22:20:11 +01:00

Brecht Van Lommel requested changes 2023-03-03 22:21:18 +01:00

Brecht Van Lommel left a comment

Actually, should this be for 3.5?

Harley Acheson commented

2023-03-03 22:25:56 +01:00

Actually, should this be for 3.5?

Yikes. Will check

> Actually, should this be for 3.5? Yikes. Will check

Harley Acheson changed title from ~~Fix #105388: Default Font Accidentally Kerning~~ to WIP Fix #105388: Default Font Accidentally Kerning

2023-03-03 22:56:32 +01:00

Harley changed target branch from main to blender-v3.5-release

2023-03-03 22:56:46 +01:00

Harley Acheson force-pushed DefaultKerning from 1a42a93eca to ac51d6cdcd

2023-03-03 23:03:27 +01:00

Compare

Harley Acheson changed title from ~~WIP Fix #105388: Default Font Accidentally Kerning~~ to Fix #105388: Default Font Accidentally Kerning

2023-03-03 23:03:45 +01:00

Harley Acheson commented

2023-03-03 23:04:55 +01:00

Actually, should this be for 3.5?

Yes, and sorry for not thinking of that.

I redid this PR for blender-v3.5-release.

> Actually, should this be for 3.5? Yes, and sorry for not thinking of that. I redid this PR for blender-v3.5-release.

Brecht Van Lommel approved these changes 2023-03-03 23:09:06 +01:00

Harley Acheson merged commit 89c3ead7c6 into blender-v3.5-release

2023-03-03 23:17:32 +01:00

Harley Acheson referenced this issue from a commit

2023-03-03 23:17:32 +01:00

Fix #105388: Default Font Accidentally Kerning

Harley Acheson deleted branch DefaultKerning

2023-03-03 23:17:34 +01:00

Sign in to join this conversation.

No reviewers

No Label

Download

What's New

Blender Studio

Manual

Developers Blog

Documentation

Benchmark

Blender Conference

Development Fund

One-time Donations

Fix #105388: Default Font Accidentally Kerning #105415