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
- Texture Import Warnings are obscured by other Terrain Layer options in the Inspector
- Burst Inspector middle divider is jittering when resized with the Burst Inspector window docked
- JsonConvert conversion fails trying to call GetCallbackMethodsForType when [OnDeserialized] is used in a class
- Different text alignment in the column header in Entities "System" window
- Objects with Universal Render Pipeline/Particles/Lit shader are always lit up when changing their Rendering Layer Mask
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.