Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Font family name parsing bugs #12806

Closed
billhenn opened this issue Sep 6, 2023 · 0 comments · Fixed by #12871
Closed

Font family name parsing bugs #12806

billhenn opened this issue Sep 6, 2023 · 0 comments · Fixed by #12871
Assignees
Labels

Comments

@billhenn
Copy link
Contributor

billhenn commented Sep 6, 2023

Describe the bug
Specifying a font family has two issues.

  1. The first is that embedded fonts must currently be specified before any system fonts.
  2. 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
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants