UI: Possible Change of Interface Font #112209

New Issue

Harley Acheson · 2023-09-10T23:47:51+02:00

Harley Acheson commented

2023-09-10 23:47:51 +02:00

With Blender 4.0 I am hoping that we can consider upgrading our interface font to something...

More modern
Easy to read
Supports variable design axes
Is actively maintained.

Of these the first is quite subjective. But our current font, Deja Vu Sans Book came out in 2006, based on Bitstream Vera which was released in 2003. It has a look of its time and this look can cause our program to look similar dated.

Being "easy to read" can also be subjective. But I'm looking for good proportions, a good use of whitespace, etc. But also ideally avoid confusions like lowercase L and 1, "clear / dear", "turn / tum", etc

Support variable design axes is important to me because it allows the one font to support different weights, widths, tracking, slant, etc. Most will also tailor their feature sizes to output size. The majority of our fallback font stack consists of variable fonts, so this would complete that.

Most fonts are designed and become static. I want a font that is actively maintained. Bugs fixed, glyphs added, and features improved by an active designer and community. The current version of our current font was released in 2016 and has had no changes for more six years.

With the above in mind I can only find two fonts that meet my requirements: Inter and Roboto Flex. I would love to hear of any other suggestions.

For testing the suitability of fonts I would prefer to do so with the following PR applied: BLF: Subpixel Positioning, Anti-aliasing, Hinting #105441. This PR enables typographically-correct sizing, placement, and rendering.

Of these two fonts "Inter" is my favorite and has been the best-regarded interface font for a while now. However there is one way where it falls short for us.

Inter is kerned meticulously by its creator. Unfortunately the large amount of kerning corrections does not allow it to support the old style of kerning table that we use. It does not use the "KERN" table, but only the new style "GPOS" table. The former is supported by FreeType alone, while the latter requires a shaper like Harfbuzz (which also does complex languages, ligatures, etc). So in Blender, for now, Inter might show occasional kerning issues not shown in other applications or by Roboto. Whether anyone really cares though is up for debate - we have been using Deja Vu without kerning for years now.

Inter Variable V4.0 (Currently beta9h)

Roboto Flex 3.200

With Blender 4.0 I am hoping that we can consider upgrading our interface font to something... * More modern * Easy to read * Supports variable design axes * Is actively maintained. Of these the first is quite subjective. But our current font, Deja Vu Sans Book came out in 2006, based on Bitstream Vera which was released in 2003. It has a look of its time and this look can cause our program to look similar dated. Being "easy to read" can also be subjective. But I'm looking for good proportions, a good use of whitespace, etc. But also ideally avoid confusions like lowercase L and 1, "clear / dear", "turn / tum", etc Support variable design axes is important to me because it allows the one font to support different weights, widths, tracking, slant, etc. Most will also tailor their feature sizes to output size. The majority of our fallback font stack consists of variable fonts, so this would complete that. Most fonts are designed and become static. I want a font that is actively maintained. Bugs fixed, glyphs added, and features improved by an active designer and community. The current version of our current font was [released in 2016](https://dejavu-fonts.github.io/) and has had no changes for more [six years](https://github.com/dejavu-fonts/dejavu-fonts). With the above in mind I can only find two fonts that meet my requirements: Inter and Roboto Flex. I would love to hear of any other suggestions. For testing the suitability of fonts I would prefer to do so with the following PR applied: [BLF: Subpixel Positioning, Anti-aliasing, Hinting #105441](https://projects.blender.org/blender/blender/pulls/105441). This PR enables typographically-correct sizing, placement, and rendering. Of these two fonts "Inter" is my favorite and has been the best-regarded interface font for a while now. However there is one way where it falls short for us. Inter is kerned meticulously by its creator. Unfortunately the large amount of kerning corrections does not allow it to support the old style of kerning table that we use. It does not use the "KERN" table, but only the new style "GPOS" table. The former is supported by FreeType alone, while the latter requires a shaper like Harfbuzz (which also does complex languages, ligatures, etc). So in Blender, for now, Inter might show occasional kerning issues not shown in other applications or by Roboto. Whether anyone really cares though is up for debate - we have been using Deja Vu without kerning for years now. ### Inter Variable V4.0 (Currently beta9h) ![image](/attachments/284d3f1d-b463-4f72-b321-15c25330b36b) ![image](/attachments/958940fb-ced0-4990-adb1-f6c8db2bc2c9) ### Roboto Flex 3.200 ![image](/attachments/ab112fc5-7508-436f-8110-f939bc1e0835) ![image](/attachments/774c0313-1206-4f8f-9a60-81cb38445233)

image.png

21 KiB

image.png

319 KiB

image.png

21 KiB

image.png

318 KiB

image.png

319 KiB

image.png

318 KiB

image.png

18 KiB

Harley Acheson added the

Type

Design

label 2023-09-10 23:47:51 +02:00

Harley Acheson added this to the User Interface project 2023-09-10 23:47:53 +02:00

Feng commented

2023-09-11 03:33:05 +02:00

If want support variable font... We need to add the api of weight of font(If you don't, then support for variable fonts won't make sense）
Also the font feature or varian: ligature (likes “ﬁ”or“ﬄ” ）kerning
Even ClearType render of Windows(Somebody likes this font render...But many user think this is shit?)

Should we provide pixel font adaptation for low-resolution screens?（likes unifont when font size min than 12px）

Fallback font?
Noto sans and Noto sans CJK may be the best choice for the unicode of other language

If want support variable font... We need to add the api of weight of font(If you don't, then support for variable fonts won't make sense） Also the font feature or varian: ligature (likes “ﬁ”or“ﬄ” ）kerning Even ClearType render of Windows(Somebody likes this font render...But many user think this is shit?) Should we provide pixel font adaptation for low-resolution screens?（likes unifont when font size min than 12px） Fallback font? Noto sans and Noto sans CJK may be the best choice for the unicode of other language

Harley Acheson commented

2023-09-11 04:35:37 +02:00

If want support variable font... We need to add the api of weight of font(If you don't, then support for variable fonts won't make sense

Our text output code does support variable font axes, like weight, width, slant, spacing, and optical size. We just don't really use it or expose it to users yet. But we can do so when our main font is a variable font.

Also the font feature or varian: ligature (likes “ﬁ”or“ﬄ” ）kerning

Supporting Ligatures requires a shaping engine like HarfBuzz. We do have that library as part of our project now, but are not yet using it. Here is a PR that uses it: #104662

Even ClearType render of Windows(Somebody likes this font render...But many user think this is shit?)

We could have that as an option feature. That would require supporting multiple FreeType render formats at once, I have a patch that does this here: https://archive.blender.org/developer/D14422, but then it would require someone who is good with shaders to implement one for subpixel display.

Should we provide pixel font adaptation for low-resolution screens?（likes unifont when font size min than 12px）

I'm not sure what you mean. Could you explain this more? We are quite often outputting strings with sizes down to about 9px.

Fallback font?
Noto sans and Noto sans CJK may be the best choice for the unicode of other language

Yes, Blender currently ships with a stack of fonts to support different languages and Unicode ranges, almost entirely from the Noto Sans Family, and including Noto sans CJK.

Quite a few fonts match nicely with Noto fonts. Even the Android OS itself uses Roboto as its main font and falls back to Noto Fonts.

> If want support variable font... We need to add the api of weight of font(If you don't, then support for variable fonts won't make sense Our text output code does support variable font axes, like weight, width, slant, spacing, and optical size. We just don't really use it or expose it to users yet. But we can do so when our main font is a variable font. > Also the font feature or varian: ligature (likes “ﬁ”or“ﬄ” ）kerning Supporting Ligatures requires a shaping engine like HarfBuzz. We do have that library as part of our project now, but are not yet using it. Here is a PR that uses it: https://projects.blender.org/blender/blender/pulls/104662 > Even ClearType render of Windows(Somebody likes this font render...But many user think this is shit?) We could have that as an option feature. That would require supporting multiple FreeType render formats at once, I have a patch that does this here: https://archive.blender.org/developer/D14422, but then it would require someone who is good with shaders to implement one for subpixel display. > Should we provide pixel font adaptation for low-resolution screens?（likes unifont when font size min than 12px） I'm not sure what you mean. Could you explain this more? We are quite often outputting strings with sizes down to about 9px. > Fallback font? > Noto sans and Noto sans CJK may be the best choice for the unicode of other language Yes, Blender currently ships with a stack of fonts to support different languages and Unicode ranges, almost entirely from the Noto Sans Family, and including Noto sans CJK. Quite a few fonts match nicely with Noto fonts. Even the Android OS itself uses Roboto as its main font and falls back to Noto Fonts.

YimingWu commented

2023-09-11 05:04:23 +02:00

They do look pretty nice, I guess especially on higher dpi screens (From the screenshot, the text might want to be a little bit bigger related to the interface button size, but that's adjustable I guess).

To me I'm thinking of a somewhat slender font which can save screen real estate, or giving a glyph-advance distance adjustment, so if there's a font that have a good shape but characters are spaced apart too far (which happens in a ton of Chinese fonts), it's not gonna be very useful to be used on the UI.

Also, we need boldness selection if user have selected fonts that have multiple variants packaged together.

There are hardly any free/maintained Chinese fonts out there due to the number of glyphs. 🤔 and I agree Noto sans CJK is probably gonna stay for a long time. (I think it is the same as current blender font?)

I'm guessing kerning like "ffl" is probably harder to achieve in the current font rendering mechanism... but could be possible.

They do look pretty nice, I guess especially on higher dpi screens (From the screenshot, the text might want to be a little bit bigger related to the interface button size, but that's adjustable I guess). To me I'm thinking of a somewhat slender font which can save screen real estate, or giving a glyph-advance distance adjustment, so if there's a font that have a good shape but characters are spaced apart too far (which happens in a ton of Chinese fonts), it's not gonna be very useful to be used on the UI. Also, we need boldness selection if user have selected fonts that have multiple variants packaged together. There are hardly any free/maintained Chinese fonts out there due to the number of glyphs. 🤔 and I agree `Noto sans CJK` is probably gonna stay for a long time. (I think it _is_ the same as current blender font?) I'm guessing kerning like "ffl" is probably harder to achieve in the current font rendering mechanism... but could be possible.

Feng commented

2023-09-11 15:51:29 +02:00

If want support variable font... We need to add the api of weight of font(If you don't, then support for variable fonts won't make sense

Our text output code does support variable font axes, like weight, width, slant, spacing, and optical size. We just don't really use it or expose it to users yet. But we can do so when our main font is a variable font.

So... It will use the weight switch bar instead of the old font style list for variable font?

I likes this scroll bar：
Of course, we could also add a text box for user to custom the value of weight if the font is variable font.

It will be better if we also add the value of weight to font of Geometry nodes.[future]

> > If want support variable font... We need to add the api of weight of font(If you don't, then support for variable fonts won't make sense > > Our text output code does support variable font axes, like weight, width, slant, spacing, and optical size. We just don't really use it or expose it to users yet. But we can do so when our main font is a variable font. So... It will use the weight switch bar instead of the old font style list for variable font? ![image](/attachments/8d44f810-0aeb-42c7-8ed4-82130d4cd02c) I likes this scroll bar： Of course, we could also add a text box for user to custom the value of weight if the font is variable font. It will be better if we also add the value of weight to font of Geometry nodes.[future] ![image](/attachments/468b4197-0560-43df-ab8e-a032923034c2) ![image](/attachments/8a7f058e-6ea7-470d-81f6-b48e27f2f060)

image.png

34 KiB

image.png

176 KiB

image.png

28 KiB

Julian Eisel commented

2023-09-13 13:15:45 +02:00

I have to say I quite like the look of Inter. A font specifically designed for UIs? Interesting!

Now, it's probably not a high priority, but it would be nice to use 4.0 to change the font, if we want to do it anytime soon. But also a nice to give Blender a fresh look then, without another big theme upgrade or such. So maybe we can put this on the 4.0 agenda as a nice-to-have.

Does that mean we should look into #105441? Also, because of differences in spacing, this may require some small tweaks throughout the UI to avoid cut off text and to keep things look polished. So good to calculate in some time for that.

I have to say I quite like the look of Inter. A font specifically designed for UIs? Interesting! Now, it's probably not a high priority, but it would be nice to use 4.0 to change the font, if we want to do it anytime soon. But also a nice to give Blender a fresh look then, without another big theme upgrade or such. So maybe we can put this on the 4.0 agenda as a nice-to-have. Does that mean we should look into #105441? Also, because of differences in spacing, this may require some small tweaks throughout the UI to avoid cut off text and to keep things look polished. So good to calculate in some time for that.

Harley Acheson closed this issue

2023-09-25 20:20:37 +02:00

Blender Bot added the

Status

Archived

label 2023-09-25 20:20:39 +02:00

Mikamiel commented

2023-10-04 18:00:57 +02:00

Kerning support is definetely a desired feature here. For example look at "Triangles" ("Tr"), "Window" ("ow").

Harley Acheson commented

2023-10-04 18:49:52 +02:00

Kerning support is definetely a desired feature here. For example look at "Triangles" ("Tr"), "Window" ("ow").

Yes, it is mentioned in the first comment that we can't currently do the type of kerning ("gpos") used in modern fonts like Inter. We can only do the old-style ("kern") kerning, which is not in Inter, and we actually had that turned off for our old font DejaVuSans.

To do modern kerning we'd need to add a shaper like HarfBuzz, which also does things like OpenType features, ligatures, right-to-left and complex languages. That is on our to do list, but I wouldn't expect that any time soon.

> Kerning support is definetely a desired feature here. For example look at "Triangles" ("Tr"), "Window" ("ow"). Yes, it is mentioned in the first comment that we can't currently do the type of kerning ("gpos") used in modern fonts like Inter. We can only do the old-style ("kern") kerning, which is not in Inter, and we actually had that turned off for our old font DejaVuSans. To do modern kerning we'd need to add a shaper like HarfBuzz, which also does things like OpenType features, ligatures, right-to-left and complex languages. That is on our to do list, but I wouldn't expect that any time soon.

👍 1

Julian Eisel commented

2023-10-05 13:37:45 +02:00

To do modern kerning we'd need to add a shaper like HarfBuzz, which also does things like OpenType features, ligatures, right-to-left and complex languages. That is on our to do list, but I wouldn't expect that any time soon.

Can't we include HarfBuzz and use it for kerning without making it a big project to also bring these other features? I would hope (expect even) that this can be a reasonably small task, while features like right-to-left and complex languages seem like big efforts. Honest question, I never worked with HarfBuzz and have no idea how many changes in BLF would be necessary.

> To do modern kerning we'd need to add a shaper like HarfBuzz, which also does things like OpenType features, ligatures, right-to-left and complex languages. That is on our to do list, but I wouldn't expect that any time soon. Can't we include HarfBuzz and use it for kerning without making it a big project to also bring these other features? I would hope (expect even) that this can be a reasonably small task, while features like right-to-left and complex languages seem like big efforts. Honest question, I never worked with HarfBuzz and have no idea how many changes in BLF would be necessary.

Harley Acheson commented

2023-10-05 17:35:12 +02:00

@JulianEisel - Can't we include HarfBuzz and use it for kerning without making it a big project to also bring these other features?

Yes, that would be a series of small tasks using code that is already written.

Both Harfbuzz and Fribidi have been included in our libs for a while now. The first step is to just make them each optional components of the build so devs can choose to enable them in CMakeCache.txt. I could post those changes in half an hour as that has already been done and worked out with Ray for all platforms.

Using Harfbuzz there is one fundamental change even if using it only for typographic things like gpos and OpenType features. It works on a block of text at a time while our current code works character-by-character. But this has all be worked out in code that works well.

So just fixing the kerning would take a day and would probably be something that we could turn on at first using an experimental feature.

With just this in place we could also choose to allow users to select OpenType features. So they could turn on slashed zero or turn off the ambiguation set. These things can be enabled with a single line once Harfbuzz is in.

The next step is only ensuring that our code can handle getting back more or less glyphs than the number of characters in the output string. This too is code already done. But this allows ligatures. Typographically it is nice even for our regular Latin output because most fonts have specialized versions of combinations of letters like "fi", "fl", etc.

With support for ligatures then we could also allow users to turn them on in the text editor to support fonts like "Fira Code". So a checkbox, off by default, for "programming ligatures" that turns -> into →. I have already demonstrated this. There are small changes needed to the text output code to make that easier though: #110174.

With the above we would actually see some benefit for some foreign languages, those that need complex shaping yet are left-to-right. For example where now an accent might always be a set distance from the start of a character, it would now be centered on the character regardless of its width. And multiple accents on a single character will work much better.

Again, the above has largely been thought through, coded, and tested. A very small subset that can be plucked out of #104662.

The next step of allowing right-to-left is the hard part because of the reordering. At that point text caret insertion and movement has to be done by the output glyphs, and we have arrays that map input to output position that we have to consult. Similar happens with mouse selection. Some of this is done but it is complex to get to a point where RTL text can be edited well. This is the type of thing that I could get us close and usable, but really needs improvement by outside volunteer devs who use RTL languages. But I imagine having just "RTL language support" as an experimental feature on its own for a while.

Once that is working then it is quite surprising how much pressure there is for UI mirroring, to allow the various parts of the interface have a right-to-left flow. Editing RTL text while having it left-aligned is odd. Basically all that text needs to be right-aligned and so then you need to move dropdown arrows to the right, etc. I played with that and there weren't too many changes to make a big difference: https://archive.blender.org/developer/D15984

> @JulianEisel - Can't we include HarfBuzz and use it for kerning without making it a big project to also bring these other features? Yes, that would be a series of small tasks using code that is already written. Both Harfbuzz and Fribidi have been included in our libs for a while now. The first step is to just make them each optional components of the build so devs can choose to enable them in CMakeCache.txt. I could post those changes in half an hour as that has already been done and worked out with Ray for all platforms. Using Harfbuzz there is one fundamental change even if using it only for typographic things like gpos and OpenType features. It works on a block of text at a time while our current code works character-by-character. But this has all be worked out in code that works well. So just fixing the kerning would take a day and would probably be something that we could turn on at first using an experimental feature. With just this in place we could also choose to allow users to select OpenType features. So they could turn on slashed zero or turn off the ambiguation set. These things can be enabled with a single line once Harfbuzz is in. The next step is only ensuring that our code can handle getting back more or less glyphs than the number of characters in the output string. This too is code already done. But this allows ligatures. Typographically it is nice even for our regular Latin output because most fonts have specialized versions of combinations of letters like "fi", "fl", etc. With support for ligatures then we could also allow users to turn them on in the text editor to support fonts like "Fira Code". So a checkbox, off by default, for "programming ligatures" that turns -> into →. I have already demonstrated this. There are small changes needed to the text output code to make that easier though: #110174. With the above we would actually see some benefit for some foreign languages, those that need complex shaping yet are left-to-right. For example where now an accent might always be a set distance from the start of a character, it would now be centered on the character regardless of its width. And multiple accents on a single character will work much better. Again, the above has largely been thought through, coded, and tested. A very small subset that can be plucked out of #104662. The next step of allowing right-to-left is the hard part because of the reordering. At that point text caret insertion and movement has to be done by the output glyphs, and we have arrays that map input to output position that we have to consult. Similar happens with mouse selection. Some of this is done but it is complex to get to a point where RTL text can be edited well. This is the type of thing that I could get us close and usable, but really needs improvement by outside volunteer devs who use RTL languages. But I imagine having just "RTL language support" as an experimental feature on its own for a while. Once that is working then it is quite surprising how much pressure there is for UI mirroring, to allow the various parts of the interface have a right-to-left flow. Editing RTL text while having it left-aligned is odd. Basically all that text needs to be right-aligned and so then you need to move dropdown arrows to the right, etc. I played with that and there weren't too many changes to make a big difference: https://archive.blender.org/developer/D15984

Sign in to join this conversation.

No Label

Download

What's New

Blender Studio

Manual

Developers Blog

Documentation

Benchmark

Blender Conference

Development Fund

One-time Donations

UI: Possible Change of Interface Font #112209

Inter Variable V4.0 (Currently beta9h)

Roboto Flex 3.200