-
Notifications
You must be signed in to change notification settings - Fork 8.3k
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
Terminal suddenly can't find the font Cascadia Mono #11648
Comments
I added a comment on Cascadia Code font repo for a solution on the font installation, for Windows Terminal and VS Code: Please check there, I have discovered "Cascadia Mono" to be missing (can't even get it reinstalled currently), but show there how to update Windows Terminal and VS Code to use "Cascadia Mono PL" |
This comment has been minimized.
This comment has been minimized.
this is the threadWe've tracked this in other threads in the past, and we've done work to mitigate this before, but we didn't get all of it. Every time we push an update, more folks start running into this again. We've got an idea of what's wrong here - one of the code paths does the right thing for the SxS font lookup, and the other path doesn't, and that leads to this warning. In the past, we used #9375 to track this. #9734 attempted to mitigate. #10305 tracked the version of this that caused a crash on startup. So this was the first thread for the issue during this update, congrats. IF YOU'RE HITTING THISTry "Repairing" the Terminal app, by going to "Settings > Apps > {whatever Terminal Install you have} > Advanced Options > Repair". This shouldn't delete your settings. (But "Reset" will, so be careful!) If you comment some variation of "me too" in this thread, |
I worked around by installing Cascadia manually. (Hopefully this message isn't marked as spam :) |
I would also like to confirm this issue is now present in the Windows 11 Version after a windows update but I'm not sure if that is related or not I did not have this issue until a couple of days ago after a windows update, I'm currently running Terminal version 1.11.2921.0, I'm on the Insider program on the Beta Channel, so whatever this issue is it's now coming through to Windows 11 versions... Windows 11 is currently on: I do have a Windows Update pending will update this message if this update resolves the problem for me... |
In general: We don't really need to know anything more about OS version and Terminal version for this one. We've got a good idea of what's causing this. The Windows 11 data point is a little interesting, we thought that the underlying bug in the OS for migrating the font files from one version to the next was fixed, but alas, it seems it also regressed since when it was first fixed in Windows 11. So this will continue to plague users at random till we fix this. |
#11032's mitigation will likely mitigate this too. |
This commit is a minimal fix in order to pass the `IDWriteFontCollection` we create out of .ttf files residing next to our binaries to the `IDWriteFontFallback::MapCharacters` call. The `IDWriteTextFormat` is used in order to carry the font collection over into `CustomTextLayout`. ## Validation * Put `JetBrainsMono-Regular.ttf` into the binary output directory * Modify `HKCU:\Console\*\FaceName` to `JetBrains Mono` * Launch OpenConsole.exe * OpenConsole uses JetBrains Mono ✔️ Closes #11032 Closes #11648
This commit is a minimal fix in order to pass the `IDWriteFontCollection` we create out of .ttf files residing next to our binaries to the `IDWriteFontFallback::MapCharacters` call. The `IDWriteTextFormat` is used in order to carry the font collection over into `CustomTextLayout`. ## Validation * Put `JetBrainsMono-Regular.ttf` into the binary output directory * Modify `HKCU:\Console\*\FaceName` to `JetBrains Mono` * Launch OpenConsole.exe * OpenConsole uses JetBrains Mono ✔️ Closes #11032 Closes #11648 (cherry picked from commit 131f5d2)
This commit is a minimal fix in order to pass the `IDWriteFontCollection` we create out of .ttf files residing next to our binaries to the `IDWriteFontFallback::MapCharacters` call. The `IDWriteTextFormat` is used in order to carry the font collection over into `CustomTextLayout`. ## Validation * Put `JetBrainsMono-Regular.ttf` into the binary output directory * Modify `HKCU:\Console\*\FaceName` to `JetBrains Mono` * Launch OpenConsole.exe * OpenConsole uses JetBrains Mono ✔️ Closes #11032 Closes #11648 (cherry picked from commit 131f5d2)
By replacing `IDWriteFontSetBuilder2::AddFontFile` with `IDWriteFactory5::CreateFontFileReference` and `IDWriteFontSetBuilder1::AddFontFile` we add nearby font loading support for Windows 10, build 15021. This commit also fixes font fallback for AtlasEngine, which was crashing during testing. Finally it fixes a bug in DxEngine, where we only created a "nearby" font collection if we couldn't find the font in the system collection. This doesn't fix the bug, if the font is locked or broken in the system collection. This is related to #11648. ## PR Checklist * [x] Closes #12420 * [x] I work here * [x] Tests added/passed ## Validation Steps Performed * Build a Debug version of Windows Terminal * Put Jetbrains Mono into the writeable AppX directory * Jetbrains Mono is present in the settings UI ✅ * DxEngine works with Jetbrains Mono ✅ * AtlasEngine works with Jetbrains Mono ✅ (cherry picked from commit f84ccad)
By replacing `IDWriteFontSetBuilder2::AddFontFile` with `IDWriteFactory5::CreateFontFileReference` and `IDWriteFontSetBuilder1::AddFontFile` we add nearby font loading support for Windows 10, build 15021. This commit also fixes font fallback for AtlasEngine, which was crashing during testing. Finally it fixes a bug in DxEngine, where we only created a "nearby" font collection if we couldn't find the font in the system collection. This doesn't fix the bug, if the font is locked or broken in the system collection. This is related to #11648. * [x] Closes #12420 * [x] I work here * [x] Tests added/passed * Build a Debug version of Windows Terminal * Put Jetbrains Mono into the writeable AppX directory * Jetbrains Mono is present in the settings UI ✅ * DxEngine works with Jetbrains Mono ✅ * AtlasEngine works with Jetbrains Mono ✅ (cherry picked from commit f84ccad)
This is not fixed on Windows 10 in 1.13.10983.0 |
Reopening because I found a flaw in my implementation. |
I'm not sure if it helps but the issue seems to be system-wide when it happens. This causes crashes in gVim when attempting to load "Cascadia Code" after Windows Terminal has updated on my Windows 11 box. I worked around using @Mindfulplays' suggestion to install manually. I suspect the issue is less with loading the font incorrectly and something to do with installing the font incorrectly. I tend to be using the font somewhere at all times so perhaps there's some kind of issue with replacing it when it's being used in some way. |
@tylerszabo Yes, we know that the actual underlying issue certainly isn't our fault. I'm not sure what the current state of an fix for that is (I can faintly remember hearing it's fixed in a newer Windows 11 build?), but in the meantime we'd of course want to fix it ourselves as quickly as possible. |
Happened for me again on 1.13.10983.0 on Windows 10 21H2, making for roughly the fourth time in a year I had this. Some additional data points:
|
The original research for a solution all the way back in #11032 contained an unfortunate flaw. The nearby font loading code was written under the assumption that Cascadia is missing in the system font collection, leading to our issues. Adding nearby fonts last into the collection would thus ensure that we use the system fonts whenever possible, but only have nearby fonts as a fallback. This didn't work and we figured that we'd have to always prefer loading nearby fonts over system fonts. #12554 tried to achieve this, but failed to change the order in which the font set is built. In order to prefer nearby fonts over system ones, we have to add the system font collection last. ## PR Checklist * [x] Closes #11648 * [x] I work here * [x] Tests added/passed * [x] Embarrassment for my incompetence ## Validation Steps Performed * Put Jetbrains Mono into the AppX directory of the Debug build * Jetbrains Mono shows up in the font selector and is useable Additionally a more complex mini-test was built: Using FontForge I've cloned arial.ttf and removed all characters except for the letter "0". Afterwards I've build a custom font collection the same way we do it in Terminal, extracted a `FontFace` named "Arial" and called `IDWriteFont::HasCharacter` for the letter "1". Loading the system font collection first results in `TRUE` and loading it last results in `FALSE` (since my custom arial.ttf doesn't have the letter "1"). This confirms that we need to load the system font collection last.
The original research for a solution all the way back in #11032 contained an unfortunate flaw. The nearby font loading code was written under the assumption that Cascadia is missing in the system font collection, leading to our issues. Adding nearby fonts last into the collection would thus ensure that we use the system fonts whenever possible, but only have nearby fonts as a fallback. This didn't work and we figured that we'd have to always prefer loading nearby fonts over system fonts. #12554 tried to achieve this, but failed to change the order in which the font set is built. In order to prefer nearby fonts over system ones, we have to add the system font collection last. ## PR Checklist * [x] Closes #11648 * [x] I work here * [x] Tests added/passed * [x] Embarrassment for my incompetence ## Validation Steps Performed * Put Jetbrains Mono into the AppX directory of the Debug build * Jetbrains Mono shows up in the font selector and is useable Additionally a more complex mini-test was built: Using FontForge I've cloned arial.ttf and removed all characters except for the letter "0". Afterwards I've build a custom font collection the same way we do it in Terminal, extracted a `FontFace` named "Arial" and called `IDWriteFont::HasCharacter` for the letter "1". Loading the system font collection first results in `TRUE` and loading it last results in `FALSE` (since my custom arial.ttf doesn't have the letter "1"). This confirms that we need to load the system font collection last. (cherry picked from commit eeb8970) Service-Card-Id: 80641214 Service-Version: 1.13
The original research for a solution all the way back in #11032 contained an unfortunate flaw. The nearby font loading code was written under the assumption that Cascadia is missing in the system font collection, leading to our issues. Adding nearby fonts last into the collection would thus ensure that we use the system fonts whenever possible, but only have nearby fonts as a fallback. This didn't work and we figured that we'd have to always prefer loading nearby fonts over system fonts. #12554 tried to achieve this, but failed to change the order in which the font set is built. In order to prefer nearby fonts over system ones, we have to add the system font collection last. ## PR Checklist * [x] Closes #11648 * [x] I work here * [x] Tests added/passed * [x] Embarrassment for my incompetence ## Validation Steps Performed * Put Jetbrains Mono into the AppX directory of the Debug build * Jetbrains Mono shows up in the font selector and is useable Additionally a more complex mini-test was built: Using FontForge I've cloned arial.ttf and removed all characters except for the letter "0". Afterwards I've build a custom font collection the same way we do it in Terminal, extracted a `FontFace` named "Arial" and called `IDWriteFont::HasCharacter` for the letter "1". Loading the system font collection first results in `TRUE` and loading it last results in `FALSE` (since my custom arial.ttf doesn't have the letter "1"). This confirms that we need to load the system font collection last. (cherry picked from commit eeb8970) Service-Card-Id: 80641213 Service-Version: 1.12
🎉This issue was addressed in #12904, which has now been successfully released as Handy links: |
🎉This issue was addressed in #12904, which has now been successfully released as Handy links: |
Unfortunately, this issue still exists with completely updated system. I also did the reset as mentioned in the second post of this thread. |
@lhecker You wrote:
Perhaps the steps below will help reproduce the issue. (Although @zadjii-msft mentioned you don't really need to know anything more about OS version, I should say I use Windows 11 ARM in a Parallels virtual machine on an M1 Mac). STEP 1: Download and unzip Cascadia Mono PL: # Download the archive file
$downloadsPath = "$Env:USERPROFILE\Downloads"
$zipFileName = "CascadiaCode-2111.01.zip"
$zipFilePath = "$downloadsPath\$zipFileName"
$url = "https://github.com/microsoft/cascadia-code/releases/download/v2111.01/$zipFileName"
Invoke-WebRequest -Uri $url -OutFile $zipFilePath
# Expand, then delete, the archive file
$expandedDirectoryPath = "$downloadsPath\CascadiaCode-2111.01"
Expand-Archive -Path $zipFilePath -Destination $expandedDirectoryPath
Remove-Item -Force -Path $zipFilePath STEP 2: Copy and register the font such that it causes the issue in Windows Terminal: # Ensure destination directory exists
$fontsDirectoryPath = "$Env:LOCALAPPDATA\Microsoft\Windows\Fonts"
if (-not (Test-Path $fontsDirectoryPath))
{
$directory = New-Item -Force -ItemType Directory -Path $fontsDirectoryPath
}
# Copy font file
$fontFileName = "CascadiaMonoPL.ttf"
$fontFileSourcePath = "$Env:USERPROFILE\Downloads\CascadiaCode-2111.01\ttf\$fontFileName"
$fontFileDestinationPath = "$fontsDirectoryPath\$fontFileName"
Copy-Item -Path $fontFileSourcePath -Destination $fontFileDestinationPath
# Ensure the registry key exists
$fontsKey = "HKCU:\Software\Microsoft\Windows NT\CurrentVersion\Fonts"
if (-not (Test-Path -Path $fontsKey))
{
$key = New-Item -Force -ItemType Directory -Path $fontsKey
}
# Add the registry key for the font file
$value = New-ItemProperty -Force -Name "Cascadia Mono PL Regular (TrueType)" -Path $fontsKey -PropertyType $type -Value $fontFileDestinationPath STEP 3: Verify that Windows Terminal is not able to find the font. STEP 4: Properly install the font such that it does not cause the issue in Windows Terminal: (The Windows Shell should ask if you want to replace the 'Cascadia Mono PL Regular' font when you run the script below. You should answer Yes.) # Create the Windows Shell's automation object and use the fonts namespace
$shell = New-Object -ComObject "Shell.Application"
$fonts = $shell.Namespace(0x14)
# Copy font file
$fontFileName = "CascadiaMonoPL.ttf"
$fontFileSourcePath = "$Env:USERPROFILE\Downloads\CascadiaCode-2111.01\ttf\$fontFileName"
$fonts.CopyHere($fontFileSourcePath, 20) STEP 5: Verify that Windows Terminal is able to find the font. STEP 6: Restart Windows. STEP 7: Verify that Windows Terminal is again not able to find the font. Hope this helps! |
If any poor soul has found their way here wondering why Windows Terminal can't find their font, let me assure you that this is actually not a Windows Terminal bug, or even a Windows bug. This behavior is caused by not having the font installed for all users. Follow these steps to remedy the problem... https://answers.microsoft.com/en-us/windows/forum/all/solution-installed-fonts-disappearing-after/146f4039-47c3-4017-a9b1-76f72badce39 |
This was an issue on Windows 10 that Terminal had worked around. We recently (accidentally) broke our workaround. Stay tuned. 😄 |
Glad to hear it is a known issue and not just something wrong with my PC. |
@DHowett i believe there is a specific term for that it's called a Regression :D |
If anyone needs a temporary fix, uninstalling then reinstalling the Terminal app solved it for me. Neither repair or reset worked. |
I fixed this issue by making sure that the font being used was installed for all users instead of locally just for my user. |
Windows Terminal version (or Windows build number)
10.0.19043.1288
Other Software
No response
Steps to reproduce
Just starting the Terminal on Windows 10. Not running as admin.
Expected Behavior
A new terminal window
Actual Behavior
Got this error
`Unable to find the selected font "Cascadia Mono".
"Consolas" has been selected instead.
Please either install the missing font or choose another one.`
The text was updated successfully, but these errors were encountered: