Weird fonts on Windows Server 2022 #14957

@j4james commented on GitHub (Aug 26, 2021):

This looks it might be the same thing as #11017.

@j4james commented on GitHub (Aug 26, 2021): This looks it might be the same thing as #11017.

claunia commented

@zadjii-msft commented on GitHub (Aug 26, 2021):

This is wild that we got the same report 3 times in a week. @faxx1080 what font are you using in the Terminal? What DPI scaling?

@zadjii-msft commented on GitHub (Aug 26, 2021): This is wild that we got the same report 3 times in a week. @faxx1080 what font are you using in the Terminal? What DPI scaling?

claunia commented

@faxx1080 commented on GitHub (Aug 26, 2021):

Hi Mike!

I was using the default font that comes with Windows Terminal, Cascadia
Code, and did not change any settings.

I was using 100% DPI scaling; unchanged from out of box defaults (in a
VMWare VM, running on a 96 DPI physical monitor).

@faxx1080 commented on GitHub (Aug 26, 2021): Hi Mike! I was using the default font that comes with Windows Terminal, Cascadia Code, and did not change any settings. I was using 100% DPI scaling; unchanged from out of box defaults (in a VMWare VM, running on a 96 DPI physical monitor).

claunia commented

2026-01-31 04:24:16 +00:00

@faxx1080 commented on GitHub (Aug 26, 2021):

**I'm not 100% sure it was Cascadia Code; it was whatever font is the default after installing the Appx package.

Note that I did this on the out of box Administrator account which has UAC turned off.

@faxx1080 commented on GitHub (Aug 26, 2021): **I'm not 100% sure it was Cascadia Code; it was whatever font is the default after installing the Appx package. Note that I did this on the out of box Administrator account which has UAC turned off.

claunia commented

@zadjii-msft commented on GitHub (Aug 30, 2021):

Okay this is wild. If you go into something like Microsoft Word, or anything that has a font picker, and go through that list, does "Cascadia Code" appear in that list? And does it appear in the dropdown list in the Terminal? We just got an internal report of the same thing that suggested that the font was uninstalled?

@zadjii-msft commented on GitHub (Aug 30, 2021): Okay this is wild. If you go into something like Microsoft Word, or anything that has a font picker, and go through that list, does "Cascadia Code" appear in that list? And does it appear in the dropdown list in the Terminal? We just got an internal report of the same thing that suggested that the font was uninstalled?

claunia commented

2026-01-31 04:24:16 +00:00

@rmbolger commented on GitHub (Sep 2, 2021):

I'm having the same issue on a recently installed, non-domain joined, Windows Server 2022 Standard (version 21H2, build 20348.202) VM. It sure seems like whatever the default font is just doesn't get installed.

The Font face field in the Terminal appearance settings is just empty for the profile. It's also not listed in the picker. I haven't tried to make any settings changes yet.

WordPad doesn't show any Cascadia related fonts in the list.

I installed the Microsoft.WindowsTerminal_1.10.2383.0_8wekyb3d8bbwe.msixbundle via Add-AppxPackage. The only other things I currently have installed on this box are Pwsh 7.1.4, the latest VS Code (user install), and VMware Tools 11.1.

One more note. I had previously accidentally installed the Microsoft.WindowsTerminalPreview_1.11.2421.0_8wekyb3d8bbwe.msixbundle package which I uninstalled after realizing it was the preview instead of the release.

@rmbolger commented on GitHub (Sep 2, 2021): I'm having the same issue on a recently installed, non-domain joined, Windows Server 2022 Standard (version 21H2, build 20348.202) VM. It sure seems like whatever the default font is just doesn't get installed. The `Font face` field in the Terminal appearance settings is just empty for the profile. It's also not listed in the picker. I haven't tried to make any settings changes yet. ![terminal-settings-no-fontface](https://user-images.githubusercontent.com/2327255/131880540-fe0148c0-2f4a-4a23-853f-4bd2e9b519b9.png) WordPad doesn't show any Cascadia related fonts in the list. ![wordpad-no-cascadia](https://user-images.githubusercontent.com/2327255/131880597-ccec4f05-65ca-4789-a0ab-90ed8b969df8.png) I installed the `Microsoft.WindowsTerminal_1.10.2383.0_8wekyb3d8bbwe.msixbundle` via Add-AppxPackage. The only other things I currently have installed on this box are Pwsh 7.1.4, the latest VS Code (user install), and VMware Tools 11.1. One more note. I had previously accidentally installed the `Microsoft.WindowsTerminalPreview_1.11.2421.0_8wekyb3d8bbwe.msixbundle` package which I uninstalled after realizing it was the preview instead of the release.

claunia commented

2026-01-31 04:24:16 +00:00

@zadjii-msft commented on GitHub (Sep 2, 2021):

The Font face field in the Terminal appearance settings is just empty for the profile. It's also not listed in the picker.

WordPad doesn't show any Cascadia related fonts in the list.

WHAT THE

That's WILDLY unexpected, but definitely explains why you're seeing what you're seeing. It doesn't make sense, but that at least explains it. The Cascadia family of fonts should be shipping in our package:
6268a4779c/src/cascadia/CascadiaPackage/Package.appxmanifest (L140-L149)

But if they're not getting installed when you install the Terminal, then a bunch of stuff will break. We pretty consistently rely on those fonts existing.

@zadjii-msft commented on GitHub (Sep 2, 2021): > The `Font face` field in the Terminal appearance settings is just empty for the profile. It's also not listed in the picker. > WordPad doesn't show any Cascadia related fonts in the list. WHAT THE That's WILDLY unexpected, but definitely explains why you're seeing what you're seeing. It doesn't make sense, but that at least explains it. The Cascadia family of fonts should be shipping in our package: https://github.com/microsoft/terminal/blob/6268a4779c9b3f49b7f3c30471bda7ae292ac423/src/cascadia/CascadiaPackage/Package.appxmanifest#L140-L149 But if they're not getting installed when you install the Terminal, then a bunch of stuff will break. We pretty consistently rely on those fonts existing.

claunia commented

6268a4779c/src/cascadia/CascadiaPackage/Package.appxmanifest (L29-L31)

@rmbolger commented on GitHub (Sep 2, 2021):

I notice in that same file, there's a Dependencies section that seems to only target Windows.Desktop. Might that be part of the problem? (I know zero about MSIX, just grasping at straws)

@rmbolger commented on GitHub (Sep 2, 2021): I notice in that same file, there's a Dependencies section that seems to only target `Windows.Desktop`. Might that be part of the problem? (I know zero about MSIX, just grasping at straws) https://github.com/microsoft/terminal/blob/6268a4779c9b3f49b7f3c30471bda7ae292ac423/src/cascadia/CascadiaPackage/Package.appxmanifest#L29-L31

claunia commented

@j4james commented on GitHub (Sep 2, 2021):

Something interesting I noticed about the SharedFonts extension: the documentation here suggests it's in the uap7 namespace, the linked article here claims it's in the uap2 namespace, and the example package in that article uses the uap4 namespace. It also lists uap4 in the IgnorableNamespaces attribute, which seems like a good idea, because clearly nobody knows what namespace it really belongs to! 😉

I also noticed that example includes the extension at the Application level rather than the Package level, which might make a difference.

I too know zero about MSIX, so maybe none of this matters.

@j4james commented on GitHub (Sep 2, 2021): Something interesting I noticed about the `SharedFonts` extension: the documentation [here](https://docs.microsoft.com/en-us/uwp/schemas/appxpackage/uapmanifestschema/element-uap7-sharedfonts) suggests it's in the `uap7` namespace, the linked article [here](https://docs.microsoft.com/en-us/windows/apps/desktop/modernize/desktop-to-uwp-extensions#share-fonts-with-other-windows-applications) claims it's in the `uap2` namespace, and the example package in that article uses the `uap4` namespace. It also lists `uap4` in the `IgnorableNamespaces` attribute, which seems like a good idea, because clearly nobody knows what namespace it really belongs to! 😉 I also noticed that example includes the extension at the `Application` level rather than the `Package` level, which might make a difference. I too know zero about MSIX, so maybe none of this matters.

claunia commented

@zadjii-msft commented on GitHub (Sep 2, 2021):

That seems unlikely to me - #11041 looks like the same thing, and that wasn't on a Server SKU, and the internal report we had of this wasn't either. But I like where your head is at!

We've had some notorious difficulty with the MSIX platform and our font in the past. In the last release, this actually just caused the Terminal to crash on startup if the font wasn't found. Now I suppose we survive, but find ourselves in a state where the font can't be found in XAML. We'll need to think about this.

@zadjii-msft commented on GitHub (Sep 2, 2021): That seems unlikely to me - #11041 looks like the same thing, and that wasn't on a Server SKU, and the internal report we had of this wasn't either. But I like where your head is at! We've had some notorious difficulty with the MSIX platform and our font in the past. In the last release, this actually just caused the Terminal to crash on startup if the font wasn't found. Now I suppose we survive, but find ourselves in a state where the font can't be found in XAML. We'll need to think about this.

claunia commented

2026-01-31 04:24:18 +00:00

@zadjii-msft commented on GitHub (Sep 2, 2021):

Something interesting I noticed about the SharedFonts extension: the documentation here suggests it's in the uap7 namespace, the linked article here claims it's in the uap2 namespace, and the example package in that article uses the uap4 namespace. It also lists uap4 in the IgnorableNamespaces attribute, which seems like a good idea, because clearly nobody knows what namespace it really belongs to! 😉

What the heck. That's a great observation

@zadjii-msft commented on GitHub (Sep 2, 2021): > Something interesting I noticed about the `SharedFonts` extension: the documentation [here](https://docs.microsoft.com/en-us/uwp/schemas/appxpackage/uapmanifestschema/element-uap7-sharedfonts) suggests it's in the `uap7` namespace, the linked article [here](https://docs.microsoft.com/en-us/windows/apps/desktop/modernize/desktop-to-uwp-extensions#share-fonts-with-other-windows-applications) claims it's in the `uap2` namespace, and the example package in that article uses the `uap4` namespace. It also lists `uap4` in the `IgnorableNamespaces` attribute, which seems like a good idea, because clearly nobody knows what namespace it really belongs to! 😉 What the _heck_. That's a great observation

claunia commented

@DHowett commented on GitHub (Sep 2, 2021):

So, shared fonts I believe were actually introduced with uap4, as an application extension. You couldn't have a font package that didn't have an application, so things like "Arial Nova" shipped with . . . a web app. An empty web app. As their application. 🤦🏻‍♂️

uap7 came around and promoted it to a package extension, so it didn't need to be tied to an application. It kept uap4:Font entries inside it for manifest validation purposes, but moved somewhere else and needed a new namespace to hold it.

@DHowett commented on GitHub (Sep 2, 2021): So, shared fonts I believe were actually introduced with `uap4`, as an _application_ extension. You couldn't have a font package that didn't have an application, so things like "Arial Nova" shipped with . . . a web app. An empty web app. As their application. 🤦🏻‍♂️ uap7 came around and promoted it to a _package_ extension, so it didn't need to be tied to an application. It kept `uap4:Font` entries inside it for manifest validation purposes, but moved somewhere else and needed a new namespace to hold it.

claunia commented

2026-01-31 04:24:18 +00:00

@DHowett commented on GitHub (Sep 2, 2021):

I notice in that same file, there's a Dependencies section that seems to only target Windows.Desktop. Might that be part of the problem? (I know zero about MSIX, just grasping at straws)

6268a4779c/src/cascadia/CascadiaPackage/Package.appxmanifest (L29-L31)

I believed that Windows.Desktop covered "all things where Windows presents as a normal desktop OS" (including Server), but we can validate that. That dependency, however, blocks installation if it is not present...

@DHowett commented on GitHub (Sep 2, 2021): > I notice in that same file, there's a Dependencies section that seems to only target `Windows.Desktop`. Might that be part of the problem? (I know zero about MSIX, just grasping at straws) > > https://github.com/microsoft/terminal/blob/6268a4779c9b3f49b7f3c30471bda7ae292ac423/src/cascadia/CascadiaPackage/Package.appxmanifest#L29-L31 I believed that Windows.Desktop covered "all things where Windows presents as a normal desktop OS" (including Server), but we can validate that. That dependency, however, blocks _installation_ if it is not present...

claunia commented

2026-01-31 04:24:18 +00:00

@DHowett commented on GitHub (Sep 2, 2021):

Would one of you mind collecting a recursive export of the registry key HKEY_CURRENT_USER\Software\Microsoft\Windows NT\CurrentVersion\Fonts?

@DHowett commented on GitHub (Sep 2, 2021): Would one of you mind collecting a recursive export of the registry key `HKEY_CURRENT_USER\Software\Microsoft\Windows NT\CurrentVersion\Fonts`?

claunia commented

@rmbolger commented on GitHub (Sep 2, 2021):

That key exists, but is empty on my Server 2022 VM. Here's the export and a view from the regedit GUI.

Windows Registry Editor Version 5.00

[HKEY_CURRENT_USER\Software\Microsoft\Windows NT\CurrentVersion\Fonts]

The HKLM equiv path has plenty of font entries in it. Though none appear to be Cascadia related.

@rmbolger commented on GitHub (Sep 2, 2021): That key exists, but is empty on my Server 2022 VM. Here's the export and a view from the regedit GUI. ``` Windows Registry Editor Version 5.00 [HKEY_CURRENT_USER\Software\Microsoft\Windows NT\CurrentVersion\Fonts] ``` ![hkcu-fonts](https://user-images.githubusercontent.com/2327255/131909737-aa815140-53ef-4f71-8755-a26e547401a7.png) *The HKLM equiv path has plenty of font entries in it. Though none appear to be Cascadia related.*

claunia commented

@DHowett commented on GitHub (Sep 2, 2021):

A-HA!

It looks like the "Shared Font" deployment helper (a deployment helper is something that runs when an MSIX is installed) isn't built into Windows Server. That's great for us to know. Thanks!

@DHowett commented on GitHub (Sep 2, 2021): A-HA! It looks like the "Shared Font" deployment helper (a deployment helper is something that runs when an MSIX is installed) isn't built into Windows Server. That's _great_ for us to know. Thanks!

claunia commented

@DHowett commented on GitHub (Sep 2, 2021):

The thing I don't totally understand is why our side-by-side font loader didn't load it. @miniksa might know more, or be able to troubleshoot it from here. We explicitly look for fonts in our own package and try to load them...

This might suggest a root cause for the weird letter selection, if it's not working totally properly, or if we're doing font fallback with a collection that doesn't contain Cascadia.

@DHowett commented on GitHub (Sep 2, 2021): The thing I don't totally understand is why our side-by-side font loader didn't load it. @miniksa might know more, or be able to troubleshoot it from here. We explicitly look for fonts in our own package and try to load them... This might suggest a root cause for the weird letter selection, if it's not working totally properly, or if we're doing font fallback with a collection that doesn't contain Cascadia.

claunia commented

@ianjoneill commented on GitHub (Sep 7, 2021):

I was intrigued by this, so I span up a Windows Server 2022 VM and deployed the code from main to it using the VS remote debugging tools.

The DxFontInfo class is successfully finding the font files next to the application. The first time it deployed it didn't copy the Cascadia fonts into the remote deployment directory, which lead to the font falling back to Consolas and the fallback font dialog being displayed.

I then copied the font into the remote deployment directory and got the weird font rendering.

Adding in some simple OutputDebugString() statements to DxFontInfo::_FindFontFace(), I found that _NearbyCollection() is successfully finding the fonts, and _FindFontFace() is successfully loading the font family and creating the font face.

Unfortunately I haven't had time to do any further debugging, but it looks like the issue is higher up in the application than the font loading.

@ianjoneill commented on GitHub (Sep 7, 2021): I was intrigued by this, so I span up a Windows Server 2022 VM and deployed the code from `main` to it using the VS remote debugging tools. The `DxFontInfo` class is successfully finding the font files next to the application. The first time it deployed it didn't copy the Cascadia fonts into the remote deployment directory, which lead to the font falling back to Consolas and the fallback font dialog being displayed. I then copied the font into the remote deployment directory and got the weird font rendering. Adding in some simple `OutputDebugString()` statements to `DxFontInfo::_FindFontFace()`, I found that `_NearbyCollection()` is successfully finding the fonts, and `_FindFontFace()` is successfully loading the font family and creating the font face. Unfortunately I haven't had time to do any further debugging, but it looks like the issue is higher up in the application than the font loading.

claunia commented

@ianjoneill commented on GitHub (Sep 9, 2021):

I've got it working in a very bodgy way - need to work out how to do this properly.

@ianjoneill commented on GitHub (Sep 9, 2021): I've got it working in a _very_ bodgy way - need to work out how to do this properly. ![image](https://user-images.githubusercontent.com/5821575/132647819-948ecdfc-7eb8-4ad5-b1f8-56a0182b9c52.png)

claunia commented

@zadjii-msft commented on GitHub (Sep 9, 2021):

@ianjoneill woah, great progress on this! I'm glad someone's got a beat on fixing this, because I was fairly lost on where to go next.

@zadjii-msft commented on GitHub (Sep 9, 2021): @ianjoneill woah, great progress on this! I'm glad someone's got a beat on fixing this, because I was fairly lost on where to go next.

claunia commented

@miniksa commented on GitHub (Sep 9, 2021):

I've got it working in a very bodgy way - need to work out how to do this properly.

Can you show the branch with the bodgy fix? What was the underlying problem?

@miniksa commented on GitHub (Sep 9, 2021): > I've got it working in a _very_ bodgy way - need to work out how to do this properly. > > ![image](https://user-images.githubusercontent.com/5821575/132647819-948ecdfc-7eb8-4ad5-b1f8-56a0182b9c52.png) Can you show the branch with the bodgy fix? What was the underlying problem?

claunia commented

@ianjoneill commented on GitHub (Sep 9, 2021):

@miniksa the very bodgy fix is here - 6427bf8424 - it is just a proof of concept to show the problem.

I made _nearbyCollection public, and updated DxFontRenderData::_BuildTextFormat() to use _nearbyCollection rather than the system font collection.

With regards to doing this properly, I don't know if there's some way of creating a view over both the system font collection and the nearby collection, or whether a custom "container" would need to be created and stored in a field. Unfortunately I have zero knowledge of DirectWrite.

@ianjoneill commented on GitHub (Sep 9, 2021): @miniksa the _very_ bodgy fix is here - https://github.com/ianjoneill/terminal/commit/6427bf842408b1a4fad1de1628ca3b1414eeade1 - it is just a proof of concept to show the problem. I made `_nearbyCollection` public, and updated `DxFontRenderData::_BuildTextFormat()` to use `_nearbyCollection` rather than the system font collection. With regards to doing this properly, I don't know if there's some way of creating a view over both the system font collection and the nearby collection, or whether a custom "container" would need to be created and stored in a field. Unfortunately I have zero knowledge of DirectWrite.

claunia commented

@miniksa commented on GitHub (Sep 9, 2021):

I have non-zero knowledge and access to the OS source behind it. Let me noodle on this a bit.

@miniksa commented on GitHub (Sep 9, 2021): I have non-zero knowledge and access to the OS source behind it. Let me noodle on this a bit.

claunia commented

@ianjoneill commented on GitHub (Sep 9, 2021):

On a related note, the settings UI won't show the Cascadia font either, because it only loads the fonts from the system font collection.

@ianjoneill commented on GitHub (Sep 9, 2021): On a related note, the settings UI won't show the Cascadia font either, because it only loads the fonts from the system font collection.

claunia commented

@miniksa commented on GitHub (Sep 9, 2021):

Nnnnnnnnnnnnnnnnnnnnn. OK. Thanks.

@miniksa commented on GitHub (Sep 9, 2021): Nnnnnnnnnnnnnnnnnnnnn. OK. Thanks.

claunia commented

@miniksa commented on GitHub (Sep 9, 2021):

OK I think I've got it. We need to change the way we handle the fallback to the font in the package.

Instead of running this process where we check the system collection and then fallback and check the nearby collection... I believe we need to make it so there's just one merged collection of both and then use that ANYWHERE in the application where a collection is needed.

So the _nearbyCollection is probably no longer a property of DxFontInfo as it has little to do with the chosen font and is more just a representation of the world.

We just need to... on startup of the rendering pipeline... use ::GetSystemFontCollection on one of the IDWriteFactory levels to get the system collection. (Probably IDWriteFactory3 so it gives us a IDWriteFontCollection1 straight up.) Then we need to use IDWriteFontCollection1::GetFontSet to get the underlying IDWriteFontSet from it. We then follow most of the contents of DxFontInfo::_NearbyCollection to create an IDWriteFontSetBuilder and use IDWriteFontSetBuilder::AddFontSet to put the system font set into the set builder first. Then we continue to use IDWriteFontSetBuilder2::AddFontFile to append the files next to our binary into the collection. Then we return that as a IDWriteFontCollection/1 and use that anywhere in the application where we're currently passing nullptr and having it load the system collection like for creating the IDWriteTextFormat and probably somehow exposing it to TerminalSettingsModel so it can pick it up and use it in ProfileViewModel::UpdateFontList().

EDIT: Oh and if we're not on Windows 10... then we have our _terminalCollection pointer as nullptr and dutifully pass that into all locations that ask for a collection and they'll resolve the system one since the fallback only works on 10+ anyway.

@miniksa commented on GitHub (Sep 9, 2021): OK I think I've got it. We need to change the way we handle the fallback to the font in the package. Instead of running this process where we check the system collection and then fallback and check the nearby collection... I believe we need to make it so there's just one merged collection of both and then use that ANYWHERE in the application where a collection is needed. So the _nearbyCollection is probably no longer a property of DxFontInfo as it has little to do with the chosen font and is more just a representation of the world. We just need to... on startup of the rendering pipeline... use `::GetSystemFontCollection` on one of the `IDWriteFactory` levels to get the system collection. (Probably `IDWriteFactory3` so it gives us a `IDWriteFontCollection1` straight up.) Then we need to use `IDWriteFontCollection1::GetFontSet` to get the underlying `IDWriteFontSet` from it. We then follow most of the contents of `DxFontInfo::_NearbyCollection` to create an `IDWriteFontSetBuilder` and use `IDWriteFontSetBuilder::AddFontSet` to put the system font set into the set builder first. Then we continue to use `IDWriteFontSetBuilder2::AddFontFile` to append the files next to our binary into the collection. Then we return that as a `IDWriteFontCollection/1` and use that anywhere in the application where we're currently passing `nullptr` and having it load the system collection like for creating the `IDWriteTextFormat` and probably somehow exposing it to TerminalSettingsModel so it can pick it up and use it in `ProfileViewModel::UpdateFontList()`. EDIT: Oh and if we're not on Windows 10... then we have our _terminalCollection pointer as nullptr and dutifully pass that into all locations that ask for a collection and they'll resolve the system one since the fallback only works on 10+ anyway.

claunia commented

@DHowett commented on GitHub (Sep 9, 2021):

If you do this, is it possible to ensure that the system fonts win over the nearby ones? Eventually, when we decouple Cascadia, we will be able to freeze down a "backup" version and we don't want it to defeat the system-installed version if it is newer.

@DHowett commented on GitHub (Sep 9, 2021): If you do this, is it possible to ensure that the system fonts win over the nearby ones? Eventually, when we decouple Cascadia, we will be able to freeze down a "backup" version and we don't want it to defeat the system-installed version if it is newer.

claunia commented

@miniksa commented on GitHub (Sep 9, 2021):

If you do this, is it possible to ensure that the system fonts win over the nearby ones? Eventually, when we decouple Cascadia, we will be able to freeze down a "backup" version and we don't want it to defeat the system-installed version if it is newer.

I am 78% sure that putting the System Font Set in first and then appending the package one next will make that be the order of priority.

@miniksa commented on GitHub (Sep 9, 2021): > If you do this, is it possible to ensure that the system fonts win over the nearby ones? Eventually, when we decouple Cascadia, we will be able to freeze down a "backup" version and we don't want it to defeat the system-installed version if it is newer. I am 78% sure that putting the System Font Set in first and then appending the package one next will make that be the order of priority.

claunia commented

@miniksa commented on GitHub (Sep 9, 2021):

@fdwr... opinion on my shenanigans?

@miniksa commented on GitHub (Sep 9, 2021): @fdwr... opinion on my shenanigans?

claunia commented