Page MenuHome

UI: Bold and Italics
ClosedPublic

Authored by Harley Acheson (harley) on Jun 1 2020, 1:46 AM.
Tokens
"Like" token, awarded by Kronk."Like" token, awarded by EAW."Like" token, awarded by Imaginer."Like" token, awarded by duarteframos."Pterodactyl" token, awarded by LazyDodo."Love" token, awarded by HooglyBoogly."Like" token, awarded by Tetone.

Details

Summary

This patch allows us to print text in bold or italics (or both) when desired. It synthesizes these variations from a single UI font file, using Freetype's "embolden" routine for bold and obliquing transform (slanting) to simulate italics. The results aren't quite as good as if we used separate font files made specifically as bold or italic variations, but it is definitely good enough for occasional emphasis. Without requiring us to quadruple the number of fonts we maintain (four variations of each of our two fonts), since each of our fonts contains more than 58,000 characters.

Note the following sample is taken from the blender Text Editor and is therefore monospaced so ignore the kerning as there is none. First column is what we have now. Second column is the typographical ideal, which uses separate font files for each variation. The third column is the result of this patch. It looks almost identical except for the slightly wider advance (letter spacing) only because our monospaced UI font is not properly informing FreeType that it is fixed-pitch.

In a comparison of variable-spaced text, the following shows two examples of the UI with bold text. The top is when using a dedicated bold font - DejaVuSans-Bold.ttf - while the bottom is using our regular font set to bold and with this patch applied. It is very hard to tell the two apart:

In order to do this there are some changes to our blf_glyph code to correct problems with our caching. Currently we have the parts in place that could cache nicely. A FontBLF has a listbase of caches and a pointer to the current one. And we can search for caches that match our intended use. But none of it is actually set right and we always just use the first cache. So in effect we only have caching the drawing of text while using a single size. Changes of size always rebuild the cache. This patch fixes that so that a font can properly cache glpyhs as they change in size or bold and italic state.

Note that I have not allowed the emboldening of fonts that are made to be bold. Nor will it oblique a font specifically made to be italic. So if you replace the UI font with some bold font you wouldn't get super-bold. Nor will an italic font show you over-italicized text.

Bold will add a bit of extra space to the glyph's advance, so slightly widening the character because of the widened features. But will not do so for fixed-pitch (monospaced) fonts, so they will still line up.

This patch slightly refactors some code in blf_glyph.c near the added code, but just to make that section a bit more readable.

To test this you can just set the existing "bold" and "italic" boolean members of the uiFontStyle struct, that currently do nothing. Or if you are dealing with a FontBLF you can BLF_enable(font_id, BLF_BOLD), etc.

For example, the following is with some parts of the tooltips window in bold. But this only illustrates what this patch can do, as this change is not included here. But it is something that could be added in a later patch.

Diff Detail

Repository
rB Blender

Event Timeline

Harley Acheson (harley) requested review of this revision.Jun 1 2020, 1:46 AM
Harley Acheson (harley) created this revision.
Harley Acheson (harley) edited the summary of this revision. (Show Details)Jun 1 2020, 2:05 AM

Adding the ability to use bold and italics is nice, but probably we should add this properly using real font variants rather than generated variations, which are almost always a lot worse that bespoke weights.

And if we do that, I think it might be a good time to actually review the UI font we use to begin with - it's quite an old font that has since ben bested by other, better UI fonts.

@William Reynish (billreynish) - we should add this properly using real font variants rather than generated variations, which are almost always a lot worse that bespoke weights.

To support that point you might want to supply some comparisons between what this patch does and a bespoke font version. Keeping in mind that this Blender project of ours has, in the past, simulated bold by simply overprinting regular text. And note that the variations in this patch aren't just "made" somehow by me but are done by calling specific functions in the FreeType library that we use for all of our font handling.

I would say that is very unlikely we would ship with bespoke variations. We are currently shipping two fonts: one is fixed-pitch (monospaced) and the other variable spaced. They each contain 58,000 characters and are therefore huge. I can’t imagine trying to manufacture even a single italic variation that would match each glyph with a specific italic version of it. Or doing that also for bold for each too. And then changing Preferences / Text Rendering so that instead of selecting two font files we require users to supply eight.

But also keep in mind that the changes in this patch wouldn't keep you from doing any of that. The main comment specifically mentions that it skips embolden and obliquing if the font in question is a specific bold or italic one.

Harley Acheson (harley) edited the summary of this revision. (Show Details)Jun 1 2020, 6:09 PM
Harley Acheson (harley) edited the summary of this revision. (Show Details)Jun 1 2020, 6:14 PM
Harley Acheson (harley) planned changes to this revision.Jun 1 2020, 10:54 PM

A couple (small) complications:

  • I made it more complex than needed as blf_glyph_add() does not to have bold and italics arguments.
  • Our current mono font does NOT have FT_FACE_FLAG_FIXED_WIDTH and I am relying on that
Harley Acheson (harley) edited the summary of this revision. (Show Details)Jun 2 2020, 3:43 AM

Simplified a bit. And now the results even more closely match dedicated bold and italic font output.

I like it. I think it looks very good, but I don't know much about the fine details of typography. Interestingly enough, something like your "example tooltip" has been proposed in the past. And I think many people would appreciate the ability to use bold or italics in tooltips (or anywhere) to differentiate sections. I hope this works out!

Back when I implemented the tooltip redesign, I added support for real bold fonts. That was rejected to avoid increasing video memory, although I'm not sure how much of an issue that is nowadays. The practical problems @Harley Acheson (harley) mentioned are indeed good points for "fake" emboldening.
Back then I was asked to make the text appear a bit stronger visually with a couple of tricks, but I never felt like that worked well. But things looked good enough, even without bold fonts, so I didn't care too much.

I need to check the implications this patch has on caching.

Either way, if this method works fine generally, I think this is totally acceptable. Somebody told me that even web browsers render bold fonts this way, I don't know if that's true (maybe it used to?).

@Julian Eisel (Severin) - ... tooltip redesign, I added support for real bold fonts...

Nice! I only remember when we (briefly I think) used simple overprinting of regular text there to simulate bold. It looked okay at larger sizes but was too blurry at small sizes since the antialiasing adds up badly.

The practical problems @Harley Acheson (harley) mentioned are indeed good points for "fake" emboldening.

This does look very good in all my testing. But I would still only use bold and italics for emphasis sparingly no matter how it is done. Not sure where we might like them - the tooltips were just an easy test. But people have brought up using bold in alert titles like QuitSave. The use of italics came up during the discussion of dynamic menu items. Some users have proposed interesting solutions for statusbar keymap info using combinations of regular and bold text. Could come in handy. I just wouldn't want to see it all over the place.

Somebody told me that even web browsers render bold fonts this way, I don't know if that's true (maybe it used to?).

Yes, if you specify a web font but don't @font-face the entire family the browser will synthesize italics and any missing weights this way. Same with Word, as it will still give you bold and italics even if you install a single font file rather than all variations. I doubt many people even notice.

In the following test, I am comparing the obliquing in this patch (the white in front) against using the italic version of the font (dark in behind). They line up very well...

Brecht Van Lommel (brecht) requested changes to this revision.Jun 2 2020, 8:44 PM

Even if we want to use specific font files for bold/italic in the future, this automatic system is something we'd need alongside it. To support cases when there are no bold/italic files for custom fonts or in case we only have bold/italic for a subset of the glyphs.

If this system is in place, shipping better fonts and using bold/italic in the user interface can be done independently.

source/blender/blenfont/intern/blf_glyph.c
184

I think we should remove font->glyph_cache. It's confusing and error-prone to have this single glyph cache pointer when there are multiple caches.

This point is only read in blf_thumbs.c and that code can be updated to use blf_glyph_cache_acquire/release.

269–293

I wouldn't flatten these if statements, I think that obscures the logic a bit. Instead keep it like this:

if (font->flags & BLF_MONOCHROME) {
  load_flags = FT_LOAD_TARGET_MONO;
  render_mode = FT_RENDER_MODE_MONO;
}
else {
  load_flags = FT_LOAD_NO_BITMAP;
  render_mode = FT_RENDER_MODE_NORMAL;

  if (font->flags & BLF_HINTING_NONE) {
  ...
source/blender/blenfont/intern/blf_internal_types.h
68–69

short -> bool

This revision now requires changes to proceed.Jun 2 2020, 8:44 PM
Harley Acheson (harley) planned changes to this revision.Jun 2 2020, 9:23 PM

@Brecht Van Lommel (brecht) - Even if we want to use specific font files for bold/italic in the future, this automatic system is something we'd need alongside it.

Yes, that was my thoughts behind not emboldening on fonts that are designed as bold, or obliquing fonts that are already italic. Otherwise I think there might be a few narrow circumstances where this could inconvenience having a full font family.

The suggested changes sound great, but it might be a day or three before I get back into this.

Alright. the examples don't look bad in practice. I agree we can use this method, at least for now. Replacing the built-in font is something we can consider separately.

@Brecht Van Lommel (brecht) - I think we should remove font->glyph_cache. It's confusing and error-prone...

Yes, that removed quite nicely.

This pointer is only read in blf_thumbs.c and that code can be updated to use blf_glyph_cache_acquire/release

I had no luck using acquire/release here as it always could cause a hang while testing. So I left it much as I found it, simply breaking out if the blf_font_size() didn't succeed and therefore did not leave a cache that fits. So basically the same test and behavior but without the need for that pointer. And doesn't hang.

Fixed the other things as you mentioned

@William Reynish (billreynish) - we can use this method, at least for now. Replacing the built-in font is something we can consider separately.

Those are all really separate issues. We need the code in this patch now and forever, whether we replace the font or add entire alternate font families later. Doing this does not keep us from doing any of those things and is actually required to do those things.

Harley Acheson (harley) marked 3 inline comments as done.Jun 3 2020, 4:47 AM

Adding the ability to use bold and italics is nice, but probably we should add this properly using real font variants rather than generated variations, which are almost always a lot worse that bespoke weights.

And if we do that, I think it might be a good time to actually review the UI font we use to begin with - it's quite an old font that has since ben bested by other, better UI fonts.

Might I suggest Inter Regular at 12 points, it is what I myself install every time for every Blender version download(ed) as well as for the GNOME Desktop, since it allows custom fonts since version 3.36, look at and download it here, Inter is free and open source:

https://rsms.me/inter/

Adding the ability to use bold and italics is nice, but probably we should add this properly using real font variants rather than generated variations, which are almost always a lot worse that bespoke weights.

And if we do that, I think it might be a good time to actually review the UI font we use to begin with - it's quite an old font that has since ben bested by other, better UI fonts.

Might I suggest Inter Regular at 12 points, it is what I myself install every time for every Blender version download(ed) as well as for the GNOME Desktop, since it allows custom fonts since version 3.36, look at and download it here, Inter is free and open source:

https://rsms.me/inter/

Although a new font has been already discussed here and marked for a later iteration, I was thinking of the exact same font and wanted to emphasize that it would be in fact a good fit.

This patch is a proposed change to allow bold and/or italics for whatever font is used. Discussions on the merits of different fonts should be elsewhere, like on devtalk or blenderartists. Note however, that any font that blender uses needs to support more than just Latin, Greek, and Cyrillic. It must also include Chinese, Japanese, Korean, Hindi, etc...

The implementation looks good now. The only remaining issue I see is that property/operator descriptions should not be in bold, only the names. I think as a general rule sentences should never be bolded as a whole.

@Brecht Van Lommel (brecht) -...property/operator descriptions should not be in bold, only the names.

Oh with the tooltip window? Actually I was hoping to remove that change from this patch entirely before committing (assuming that happened). I only stuck that change in here so that reviewers could see some visual change without further work required on their part.

I think as a general rule sentences should never be bolded as a whole.

I agree with that. And I actually prefer the tooltip window as it is right now. Although It might be nice to have bold on just the current enum value or names. Or perhaps italics for those. Not sure. Which is why I'd prefer to have this patch just about implementation and not any usage. Maybe even have William or Julian document some intended usage rules first so we don't get it sprinkled everywhere. When everything is emphasized then nothing is emphasized.

But I am quite convinced that we need this in. Used sparingly it could help solve some UI issues we've faced occasionally. But I would be equally happy if we didn't end up having to use it at all in the end. Its more of a typographical tool of last resort. LOL

I'll accept this then assuming the tooltip changes will be removed before commit (and possibly added back in another patch).

This revision is now accepted and ready to land.Jun 3 2020, 6:06 PM
Harley Acheson (harley) edited the summary of this revision. (Show Details)Jun 6 2020, 12:13 AM

Removing the bolding of some parts of the tooltip windows, which was only meant to be illustrative.

This revision was automatically updated to reflect the committed changes.