You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Describe the bug
Specifying a font family has two issues.
The first is that embedded fonts must currently be specified before any system fonts.
The second is that if a system font is specified prior to other system fonts, and that higher priority system font happens to be the default font on the system, it is skipped in priority and the next available font in priority is chosen instead.
To Reproduce
Add this XAML:
<TextBlock x:Name="textBlock" Text="Test" />
Add this code to reproduce the issue with embedded font order:
textBlock.FontFamily = new FontFamily("Segoe UI, Consolas, fonts:Inter#Inter, $Default");
Here we want the control to have Segoe UI font if available, eventually falling back to the embedded font Inter as needed. But the code above yields a System.NotSupportedException: 'BaseUri can't be null.' exception in FontManager.TryGetGlyphTypeface when measuring the TextBlock.
Use this code instead to reproduce the default font name skipped issue:
textBlock.FontFamily = new FontFamily("Segoe UI, Consolas, $Default");
Here we say that we want Segoe UI to be our top pick for a font, falling back to Consolas, and then whatever system default is available. While the for loop in FontManager.TryGetGlyphTypeface that scans for system font matches does successfully locate Segoe UI, it then does a test to see if it's the default font (which it is on Windows systems) and then skips to the next entry. The end result is that the TextBlock ends up rendering in Consolas incorrectly, even though we specified we wanted Segoe UI as the top pick.
Expected behavior
The first issue with embedded font order should be supported without any exceptions. It shouldn't matter if a lower priority font is an embedded or system font.
The second issue with supporting font priority properly when a specified font may be the default font for a system (as Segoe UI is for Windows) needs to be supported. Otherwise, we can't effectively use the top picks for fonts on any system since they will always resolve to using a lesser pick.
Desktop (please complete the following information):
OS: Tested on Windows, but applies to all.
Version 11.0.4
The text was updated successfully, but these errors were encountered:
Describe the bug
Specifying a font family has two issues.
To Reproduce
Add this XAML:
Add this code to reproduce the issue with embedded font order:
Here we want the control to have Segoe UI font if available, eventually falling back to the embedded font Inter as needed. But the code above yields a
System.NotSupportedException: 'BaseUri can't be null.'
exception inFontManager.TryGetGlyphTypeface
when measuring theTextBlock
.Use this code instead to reproduce the default font name skipped issue:
Here we say that we want Segoe UI to be our top pick for a font, falling back to Consolas, and then whatever system default is available. While the
for
loop inFontManager.TryGetGlyphTypeface
that scans for system font matches does successfully locate Segoe UI, it then does a test to see if it's the default font (which it is on Windows systems) and then skips to the next entry. The end result is that theTextBlock
ends up rendering in Consolas incorrectly, even though we specified we wanted Segoe UI as the top pick.Expected behavior
The first issue with embedded font order should be supported without any exceptions. It shouldn't matter if a lower priority font is an embedded or system font.
The second issue with supporting font priority properly when a specified font may be the default font for a system (as Segoe UI is for Windows) needs to be supported. Otherwise, we can't effectively use the top picks for fonts on any system since they will always resolve to using a lesser pick.
Desktop (please complete the following information):
The text was updated successfully, but these errors were encountered: