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

Cascadia Mono font not found #16058

Closed
HunterZ opened this issue Sep 29, 2023 · 10 comments · Fixed by #16196
Closed

Cascadia Mono font not found #16058

HunterZ opened this issue Sep 29, 2023 · 10 comments · Fixed by #16196
Labels
Area-Fonts Related to the font In-PR This issue has a related PR Issue-Bug It either shouldn't be doing this or needs an investigation. Needs-Tag-Fix Doesn't match tag requirements Product-Terminal The new Windows Terminal.

Comments

@HunterZ
Copy link

HunterZ commented Sep 29, 2023

Windows Terminal version

1.18.2681.0

Windows build number

10.0.22621.2283

Other Software

winget v1.6.2701

Steps to reproduce

Install an older version of Terminal. Upgrade to 1.18.2681.0 using winget.

Expected Behavior

Upgrade succeeds.

Actual Behavior

Terminal says it can't find a font named Cascadia Mono, and falls back to Consolas

@HunterZ HunterZ added Issue-Bug It either shouldn't be doing this or needs an investigation. Needs-Triage It's a new issue that the core contributor team needs to triage at the next triage meeting labels Sep 29, 2023
@HunterZ
Copy link
Author

HunterZ commented Sep 29, 2023

I know this has been reported a million times, but it just happened to me and all of the previous issues on it seem to be closed, so I've written this to capture the fact that it clearly isn't resolved.

I do not see Cascadia Mono in the Windows Fonts UI or in C:\Windows\Fonts or in %localappdata%\Microsoft\Windows\Fonts, so something either uninstalled it, or it is not included in Windows 11 Home.

I tried doing a Repair, but it didn't accomplish anything.

Edit: Seems like someone should make a Cascadia Mono winget package and make Windows Terminal's package depend on it. Ironically, Chocolatey has a Cascadia Code package that probably includes this font.

Edit 2: Downloading the font from https://github.com/microsoft/cascadia-code and installing it manually for all users, then resetting Terminal works, but it seems like Terminal shouldn't depend on the user to do this.

@zadjii-msft
Copy link
Member

This is wacky and very unexpected. The other issues are all closed, because we thought we fixed this a few releases ago. We added a final fallback to try and load the font directly from a file in our package (not from the font cache).

What rendering engine are you using (could you share your settings.json file)? (we're pretty sure the rendering engine shouldn't matter here.)

Our only theory right now is that the way we detect a failure to load the font might not be working anymore?

23d45a7 was the last touch here, which only shipped in 1.18 preview. That we might need to revert 😞

@zadjii-msft zadjii-msft added Area-Fonts Related to the font Product-Terminal The new Windows Terminal. and removed Needs-Triage It's a new issue that the core contributor team needs to triage at the next triage meeting labels Oct 4, 2023
@zadjii-msft zadjii-msft added this to the Terminal v1.20 milestone Oct 4, 2023
@duckinator
Copy link

I just encountered this after upgrading using winget.

  • Windows Terminal version (after upgrading): 1.18.2822.0
  • Windows build number: 10.0.19045.0
  • winget version: v1.6.2771

@vpal12

This comment was marked as spam.

@HunterZ
Copy link
Author

HunterZ commented Oct 14, 2023

This is wacky and very unexpected. The other issues are all closed, because we thought we fixed this a few releases ago. We added a final fallback to try and load the font directly from a file in our package (not from the font cache).

What rendering engine are you using (could you share your settings.json file)? (we're pretty sure the rendering engine shouldn't matter here.)

Here it is: settings.json

Reminder that Cascadia Mono did not seem to be installed in Windows 11 for some reason (which is weird because I was using an old version of Terminal without having ever seen that error), so it seems to be Terminal depending on something which isn't guaranteed to be present?

@duckinator
Copy link

Here's my settings.json, too.

I've not reconfigured anything related to rendering engines, fonts, or anything like that.

@duckinator
Copy link

The plot thickens: I have C:\Windows\Fonts\CascadiaMono.ttf, and I was also able to use the Cascadia Mono font in Notepad without issue.

image

image

@microsoft microsoft deleted a comment from Summerh15 Oct 16, 2023
@microsoft-github-policy-service microsoft-github-policy-service bot added the In-PR This issue has a related PR label Oct 19, 2023
@RedTail72
Copy link

I'm not sure if this is what #16196 is addressing, but I decided to run Process Monitor while starting up Terminal and saw it was trying to load C:\Program Files\WindowsApps\Microsoft.WindowsTerminal_1.17.11461.0_x64__8wekyb3d8bbwe\CascadiaMono.ttf, but I'm currently running v1.18.2822.0. Just thought I'd share incase the PR doesn't address this.

image
image

@RedTail72
Copy link

I'm not sure if this is what #16196 is addressing, but I decided to run Process Monitor while starting up Terminal and saw it was trying to load C:\Program Files\WindowsApps\Microsoft.WindowsTerminal_1.17.11461.0_x64__8wekyb3d8bbwe\CascadiaMono.ttf, but I'm currently running v1.18.2822.0. Just thought I'd share incase the PR doesn't address this.

I should have waited to post until I did this, but after restarting my machine, I am no longer having issues with the Cascadia Mono font not found message. My font is still set to Cascadia Mono, just no more error messages.

@eduarddejong
Copy link

eduarddejong commented Oct 28, 2023

I'm not sure if this is what #16196 is addressing, but I decided to run Process Monitor while starting up Terminal and saw it was trying to load C:\Program Files\WindowsApps\Microsoft.WindowsTerminal_1.17.11461.0_x64__8wekyb3d8bbwe\CascadiaMono.ttf, but I'm currently running v1.18.2822.0. Just thought I'd share incase the PR doesn't address this.

I should have waited to post until I did this, but after restarting my machine, I am no longer having issues with the Cascadia Mono font not found message. My font is still set to Cascadia Mono, just no more error messages.

I can confirm your experience. I haven't booted this Windows system frequently the last days. So my system started updating several "things".
After a while I opened the Terminal and god this strange error message. So I checked Github here.

Before rebooting, I could enter the exact directory that you mention in my Explorer. The font files where vissible there, but not possible to open at all.
Double click failed.
But also trying to open it with Notepad failed, which I often do to see what happens. It gave me a permissions related error.

After rebooting, this entire directory path did not exist anymore, but the Terminal was working fine again and the font just loads without any issues.

So my conclusion is that the Terminal still tried to load the font from an old directory that was being uninstalled by the update. But somehow that process was not fully complete until reboot (the Store showed that the update was completed a couple of minutes ago though).

Which may not be strange at all though, but it's not what you expect from an App Store based app in general.

So it seems that some kind of proper warning system warning the user that he really needs to reboot is missing here.

@microsoft-github-policy-service microsoft-github-policy-service bot added the Needs-Tag-Fix Doesn't match tag requirements label Nov 6, 2023
zadjii-msft pushed a commit that referenced this issue Nov 6, 2023
I still don't know how to reproduce it properly, but I'm slowly
wrapping my head around how and why it happens. The issue isn't that
`FindFamilyName` fails with `exists=FALSE`, but rather that any of the
followup calls like `GetDesignGlyphMetrics` fails, which results in an
exception and subsequently in an orderly fallback to Consolas.
I've always thought that the issue is that even with the nearby font
collection we get an `exists=FALSE`... I'm not sure why I thought that.

This changeset also drops the fallback iteration for Lucida Console and
Courier New, because I felt like the code looks neater that way and I
think it's a reasonable expectation that Consolas is always installed.

Closes #16058
DHowett pushed a commit that referenced this issue Nov 7, 2023
I still don't know how to reproduce it properly, but I'm slowly
wrapping my head around how and why it happens. The issue isn't that
`FindFamilyName` fails with `exists=FALSE`, but rather that any of the
followup calls like `GetDesignGlyphMetrics` fails, which results in an
exception and subsequently in an orderly fallback to Consolas.
I've always thought that the issue is that even with the nearby font
collection we get an `exists=FALSE`... I'm not sure why I thought that.

This changeset also drops the fallback iteration for Lucida Console and
Courier New, because I felt like the code looks neater that way and I
think it's a reasonable expectation that Consolas is always installed.

Closes #16058

(cherry picked from commit 9e86c98)
Service-Card-Id: 90885610
Service-Version: 1.18
DHowett pushed a commit that referenced this issue Nov 7, 2023
I still don't know how to reproduce it properly, but I'm slowly
wrapping my head around how and why it happens. The issue isn't that
`FindFamilyName` fails with `exists=FALSE`, but rather that any of the
followup calls like `GetDesignGlyphMetrics` fails, which results in an
exception and subsequently in an orderly fallback to Consolas.
I've always thought that the issue is that even with the nearby font
collection we get an `exists=FALSE`... I'm not sure why I thought that.

This changeset also drops the fallback iteration for Lucida Console and
Courier New, because I felt like the code looks neater that way and I
think it's a reasonable expectation that Consolas is always installed.

Closes #16058

(cherry picked from commit 9e86c98)
Service-Card-Id: 90885607
Service-Version: 1.19
DHowett pushed a commit that referenced this issue Nov 7, 2023
I still don't know how to reproduce it properly, but I'm slowly
wrapping my head around how and why it happens. The issue isn't that
`FindFamilyName` fails with `exists=FALSE`, but rather that any of the
followup calls like `GetDesignGlyphMetrics` fails, which results in an
exception and subsequently in an orderly fallback to Consolas.
I've always thought that the issue is that even with the nearby font
collection we get an `exists=FALSE`... I'm not sure why I thought that.

This changeset also drops the fallback iteration for Lucida Console and
Courier New, because I felt like the code looks neater that way and I
think it's a reasonable expectation that Consolas is always installed.

Closes #16058

(cherry picked from commit 9e86c98)
Service-Card-Id: 90885610
Service-Version: 1.18
radu-cernatescu pushed a commit to radu-cernatescu/terminal that referenced this issue Nov 8, 2023
I still don't know how to reproduce it properly, but I'm slowly
wrapping my head around how and why it happens. The issue isn't that
`FindFamilyName` fails with `exists=FALSE`, but rather that any of the
followup calls like `GetDesignGlyphMetrics` fails, which results in an
exception and subsequently in an orderly fallback to Consolas.
I've always thought that the issue is that even with the nearby font
collection we get an `exists=FALSE`... I'm not sure why I thought that.

This changeset also drops the fallback iteration for Lucida Console and
Courier New, because I felt like the code looks neater that way and I
think it's a reasonable expectation that Consolas is always installed.

Closes microsoft#16058
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Area-Fonts Related to the font In-PR This issue has a related PR Issue-Bug It either shouldn't be doing this or needs an investigation. Needs-Tag-Fix Doesn't match tag requirements Product-Terminal The new Windows Terminal.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

6 participants