Search Issue Tracker
By Design
By Design in 6000.5.X
Votes
0
Found in
6000.0.63f1
6000.2.15f1
6000.3.0f1
6000.4.0a5
6000.5.0a2
Issue ID
UUM-128941
Regression
Yes
The text font falls back on a different font depending on the fallback font used
How to reproduce:
- Open the “TMPBugReport.zip“ project
- Open the “BugRepro“ Scene
- Observe the second line of text in the Game view (it is a bolded “Inter” font)
- Find “Assets/Fonts/Latin/Inter/Inter400Regular SDF.asset” in the Project tab and select it
- In the Inspector, change the fallback Font from “NotoNaskhArabic-Bold SDF“ to “NotoNaskhArabic-Regular SDF“
- Observe the second line of text in the Game view
Actual result: it becomes a bolded “NotoNaskhArabic-Regular SDF” font
Expected result: It stays the same, bolded “Inter“ font
Reproducible in: 6000.0.63f1, 6000.1.0a9 (0115cb901a32), 6000.2.15f1, 6000.3.0f1, 6000.4.0a5, 6000.5.0a2
Not reproducible in: 6000.1.0a8
Reproduced on: Windows 11 Pro (25H2)
Not reproduced on: No other environment tested
Add comment
All about bugs
View bugs we have successfully reproduced, and vote for the bugs you want to see fixed most urgently.
Latest issues
- Font character thickness does not adjust properly in UI Toolkit text when changing Bold Weight in Font Asset
- Multiple "[...] is inaccessible due to its protection level" errors are thrown when opening project with Unity Version Control installed
- Sorting icons are tiny and misaligned in Import Activity window
- The Undo system does not record HideFlags.HideInHierarchy changes
- [Linux] Bug Reporter window is in Light mode when the Editor theme is Dark mode
Resolution Note:
The reason for this behavior is due to the primary font asset not having any Bold font weight font asset assigned to it while the local fallback (NotoNaskhArabic) has a bold weight fallback assigned and also happen to contain the requested character.
If the primary font asset (Inter) had a bold font weight assigned to it then the bold text would come from that font asset.
If the local Arabic fallback, didn't have a bold weight font asset assigned then the bold character would come from the primary Inter and be synthesized.
If the Arabic font didn't contain overlapping characters, then the behavior would also not occur.
Resolution Note (6000.5.X):
The reason for this behavior is due to the primary font asset not having any Bold font weight font asset assigned to it while the local fallback (NotoNaskhArabic) has a bold weight fallback assigned and also happen to contain the requested character.
If the primary font asset (Inter) had a bold font weight assigned to it then the bold text would come from that font asset.
If the local Arabic fallback, didn't have a bold weight font asset assigned then the bold character would come from the primary Inter and be synthesized.
If the Arabic font didn't contain overlapping characters, then the behavior would also not occur.