Font Symbol Cleanup #73419

Open
opened 2020-01-26 23:28:26 +01:00 by Harley Acheson · 7 comments
Member

This document is my attempt to justify my proposed changes to the font glyphs by adding some more details.

The Fonts

Blender currently ships with four different fonts. Two are fixed width (for text editor and few other places) and two are variable width (used in most places of the interface). For each of these two types there is one small version containing mostly lower Latin characters (and therefore only working well for English) and an optional larger version that contains characters from multiple languages. By default the two minimal fonts are used, but you can enable the use of the larger international fonts by selecting the "Translation" checkbox in Preferences / Interface.

The Keyboard Glyphs

Fonts can contain symbols and we make use of some when indicating some keypresses. Some keys, like "←" are easier to describe with a single symbol, rather than writing a more verbose "left arrow". Some keys, like "⌘" on Mac are more often shown as a symbol than written out as text as "command" (has been called "Apple key", "clover key", etc).

Do we need to show these as symbols? At least sometimes. Many Mac users would prefer nothing but symbols, while many Windows users would prefer nothing text descriptions so we at least have to support the use of symbols, even if their use differs by platform.

Do they have to be shown as font symbols? Yes. Although there are some times when we could have used icons for these, there are many times when these symbols need to used within text content. And in those cases it is important that they be scaled with the text to any size.

Font Type Reconciliation

There are some glyphs that are in the fixed-width versions of the fonts but are not in the variable-width version. The Event Icons (shown in the footer) deal with this by selecting glyphs from one font versus another. But this does not help for other uses. For example, Mac users would like to see "⇧" used to indicate "Shift". Currently we can see this symbol in the footer but cannot see it in the menus for keyboard shortcuts because the symbol is not in the variable-width small font used in the UI by default.

By ensuring these symbols are all in the UI font, not only can we then see them properly in the UI to indicate shortcuts, but it also allows us to simplify the Event Icon code since it no longer has to select from multiple fonts depending on glyph.

International Font Reconciliation

There are some symbols that are in the minimal (English) font that are not in the larger international font, and vice versa. It is very important that the international font be a complete superset of the smaller font. That is required for us to eventually use only the international fonts .

Size and Alignment

Our four fonts are all meta-fonts, containing characters from a number of different fonts. Over time each has gained new glyphs as they were needed, from a variety of donor fonts. Because of this the keyboard symbols we use do not share common sizes or alignment. Had they all be taken from the same font then each would work together harmoniously, with the same width, bearings, and vertical alignment.

By making these symbols share common sizes and alignment they can be placed by each other and still be readable. So if we need to use "⇧⌘" together we want them to be harmonious.

And by making these gylphs similar size and alignment it also means we can further simplify the code in Event Icons that has to currently deal with per-character adjustments.

Future Work

Once these glyph changes are accepted we can then use these characters where we want. For Macs this is important for shortcuts, but it also comes in handy for Windows users too. Although Windows users prefer text over symbols for things like "Ctrl" and "Alt", it would still be nice to use symbols for "Windows key" and "Menu key" since those two are never shown as text on keyboards.

Once we are able to swap out our minimal font for the international version without errors, we can consider making the international font the only fonts used. And at that point we can use a subset of the smaller font as a fallback font. That way if a user replaces the main UI font with something else they can still see these characters even if that font does not contain them.

This document is my attempt to justify my [proposed changes to the font glyphs ](https://developer.blender.org/D6055) by adding some more details. **The Fonts** Blender currently ships with *four different fonts*. Two are fixed width (for text editor and few other places) and two are variable width (used in most places of the interface). For each of these two types there is one small version containing mostly lower Latin characters (and therefore only working well for English) and an optional larger version that contains characters from multiple languages. By default the two minimal fonts are used, but you can enable the use of the larger international fonts by selecting the "Translation" checkbox in Preferences / Interface. **The Keyboard Glyphs** Fonts can contain symbols and we make use of some when indicating some keypresses. Some keys, like "←" are easier to describe with a single symbol, rather than writing a more verbose "left arrow". Some keys, like "⌘" on Mac are more often shown as a symbol than written out as text as "command" (has been called "Apple key", "clover key", etc). *Do we need to show these as symbols?* At least sometimes. Many Mac users would prefer nothing but symbols, while many Windows users would prefer nothing text descriptions so we at least have to support the use of symbols, even if their use differs by platform. *Do they have to be shown as font symbols?* Yes. Although there are some times when we could have used icons for these, there are many times when these symbols need to used within text content. And in those cases it is important that they be scaled with the text to any size. **Font Type Reconciliation** There are some glyphs that are in the fixed-width versions of the fonts but are not in the variable-width version. The Event Icons (shown in the footer) deal with this by selecting glyphs from one font versus another. But this does not help for other uses. For example, Mac users would like to see "⇧" used to indicate "Shift". Currently we can see this symbol in the footer but cannot see it in the menus for keyboard shortcuts because the symbol is not in the variable-width small font used in the UI by default. By ensuring these symbols are all in the UI font, not only can we then see them properly in the UI to indicate shortcuts, but it also allows us to simplify the Event Icon code since it no longer has to select from multiple fonts depending on glyph. **International Font Reconciliation** There are some symbols that are in the minimal (English) font that are not in the larger international font, and vice versa. It is very important that the international font be a complete superset of the smaller font. That is required for us to eventually [use only the international fonts ](https://developer.blender.org/D3705). **Size and Alignment** Our four fonts are all meta-fonts, containing characters from a number of different fonts. Over time each has gained new glyphs as they were needed, from a variety of donor fonts. Because of this the keyboard symbols we use do not share common sizes or alignment. Had they all be taken from the same font then each would work together harmoniously, with the same width, bearings, and vertical alignment. By making these symbols share common sizes and alignment they can be placed by each other and still be readable. So if we need to use "⇧⌘" together we want them to be harmonious. And by making these gylphs similar size and alignment it also means we can further simplify the code in Event Icons that has to currently deal with per-character adjustments. **Future Work** Once these glyph changes are accepted we can then use these characters where we want. For Macs this is important for shortcuts, but it also comes in handy for Windows users too. Although Windows users prefer text over symbols for things like "Ctrl" and "Alt", it would still be nice to use symbols for "Windows key" and "Menu key" since those two are never shown as text on keyboards. Once we are able to swap out our minimal font for the international version without errors, we can consider making the international font the only fonts used. And at that point we can use a subset of the smaller font as a **fallback font**. That way if a user replaces the main UI font with something else they can still see these characters even if that font does not contain them.
William Reynish was assigned by Harley Acheson 2020-01-26 23:28:26 +01:00
Author
Member
Added subscribers: @Harley, @Enoch11223, @xdanic, @jc4d, @CandleComet, @RosarioRosato, @semaphore, @mendio, @0o00o0oo, @T.R.O.Nunes, @Ehab, @BartekMoniewski, @DuarteRamos, @MaciejJutrzenka, @Znio.G, @brecht, @Sergey, @dfelinto, @mont29, @ideasman42

Added subscriber: @ThatAsherGuy

Added subscriber: @ThatAsherGuy

D6055 was accepted back in November, right? I'd been wondering what happened to it.

I'm in favor of a move towards intentional typography and this feels like a good place to start.

[D6055](https://archive.blender.org/developer/D6055) was accepted back in November, right? I'd been wondering what happened to it. I'm in favor of a move towards intentional typography and this feels like a good place to start.
Author
Member

@ThatAsherGuy - D6055 was accepted back in November, right?

No, not enough to commit yet. I think mostly because I didn't do a good job of explaining the reasons behind changes. I'm hoping this will help.

> @ThatAsherGuy - [D6055](https://archive.blender.org/developer/D6055) was accepted back in November, right? No, not enough to commit yet. I think mostly because I didn't do a good job of explaining the reasons behind changes. I'm hoping this will help.

Changed status from 'Needs Triage' to: 'Confirmed'

Changed status from 'Needs Triage' to: 'Confirmed'

And at that point we can use a subset of the smaller font as a fallback font. That way if a user replaces the main UI font with something else they can still see these characters even if that font does not contain them.

I'm going to remove the smaller font entirely, since I don't think it's needed for this. Users should not replace the font file in the Blender installation folder. We have a preference where a user can specify a file path to a custom font. Then if that font is missing a character, we can fall back to the international font.

If someone changes the installation folder and breaks Blender, that's not something we have to prepare for. Many other things can be broken by doing that, it's just not something we recommend anyone to do.

> And at that point we can use a subset of the smaller font as a fallback font. That way if a user replaces the main UI font with something else they can still see these characters even if that font does not contain them. I'm going to remove the smaller font entirely, since I don't think it's needed for this. Users should not replace the font file in the Blender installation folder. We have a preference where a user can specify a file path to a custom font. Then if that font is missing a character, we can fall back to the international font. If someone changes the installation folder and breaks Blender, that's not something we have to prepare for. Many other things can be broken by doing that, it's just not something we recommend anyone to do.
Author
Member

@brecht - we can fall back to the international font.

Ah. I didn't realize that was the plan. That is perfect.

> @brecht - we can fall back to the international font. Ah. I didn't realize that was the plan. That is perfect.
Philipp Oeser removed the
Interest
User Interface
label 2023-02-10 09:24:51 +01:00
Sign in to join this conversation.
No Label
Interest
Alembic
Interest
Animation & Rigging
Interest
Asset Browser
Interest
Asset Browser Project Overview
Interest
Audio
Interest
Automated Testing
Interest
Blender Asset Bundle
Interest
BlendFile
Interest
Collada
Interest
Compatibility
Interest
Compositing
Interest
Core
Interest
Cycles
Interest
Dependency Graph
Interest
Development Management
Interest
EEVEE
Interest
EEVEE & Viewport
Interest
Freestyle
Interest
Geometry Nodes
Interest
Grease Pencil
Interest
ID Management
Interest
Images & Movies
Interest
Import Export
Interest
Line Art
Interest
Masking
Interest
Metal
Interest
Modeling
Interest
Modifiers
Interest
Motion Tracking
Interest
Nodes & Physics
Interest
OpenGL
Interest
Overlay
Interest
Overrides
Interest
Performance
Interest
Physics
Interest
Pipeline, Assets & IO
Interest
Platforms, Builds & Tests
Interest
Python API
Interest
Render & Cycles
Interest
Render Pipeline
Interest
Sculpt, Paint & Texture
Interest
Text Editor
Interest
Translations
Interest
Triaging
Interest
Undo
Interest
USD
Interest
User Interface
Interest
UV Editing
Interest
VFX & Video
Interest
Video Sequencer
Interest
Virtual Reality
Interest
Vulkan
Interest
Wayland
Interest
Workbench
Interest: X11
Legacy
Blender 2.8 Project
Legacy
Milestone 1: Basic, Local Asset Browser
Legacy
OpenGL Error
Meta
Good First Issue
Meta
Papercut
Meta
Retrospective
Meta
Security
Module
Animation & Rigging
Module
Core
Module
Development Management
Module
EEVEE & Viewport
Module
Grease Pencil
Module
Modeling
Module
Nodes & Physics
Module
Pipeline, Assets & IO
Module
Platforms, Builds & Tests
Module
Python API
Module
Render & Cycles
Module
Sculpt, Paint & Texture
Module
Triaging
Module
User Interface
Module
VFX & Video
Platform
FreeBSD
Platform
Linux
Platform
macOS
Platform
Windows
Priority
High
Priority
Low
Priority
Normal
Priority
Unbreak Now!
Status
Archived
Status
Confirmed
Status
Duplicate
Status
Needs Info from Developers
Status
Needs Information from User
Status
Needs Triage
Status
Resolved
Type
Bug
Type
Design
Type
Known Issue
Type
Patch
Type
Report
Type
To Do
No Milestone
No project
No Assignees
4 Participants
Notifications
Due Date
The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: blender/blender#73419
No description provided.