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

Terminal suddenly can't find the font Cascadia Mono #11648

Closed
johan-byggtjanst opened this issue Oct 29, 2021 · 26 comments · Fixed by #11764, #12554 or #12904
Closed

Terminal suddenly can't find the font Cascadia Mono #11648

johan-byggtjanst opened this issue Oct 29, 2021 · 26 comments · Fixed by #11764, #12554 or #12904
Assignees
Labels
Area-Fonts Related to the font Issue-Bug It either shouldn't be doing this or needs an investigation. Priority-1 A description (P1) Product-Terminal The new Windows Terminal. Resolution-Fix-Committed Fix is checked in, but it might be 3-4 weeks until a release.

Comments

@johan-byggtjanst
Copy link

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.`

@ghost ghost added Needs-Triage It's a new issue that the core contributor team needs to triage at the next triage meeting Needs-Tag-Fix Doesn't match tag requirements labels Oct 29, 2021
@ChameleonDevil
Copy link

ChameleonDevil commented Oct 29, 2021

I added a comment on Cascadia Code font repo for a solution on the font installation, for Windows Terminal and VS Code:

microsoft/cascadia-code#594 (comment)

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"

@Peru-S

This comment has been minimized.

@zadjii-msft
Copy link
Member

this is the thread

We'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 THIS

Try "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, you will be removed from the selfhost program your comment will be minimized as spam, thanks.

@zadjii-msft zadjii-msft added Area-Fonts Related to the font Issue-Bug It either shouldn't be doing this or needs an investigation. Priority-1 A description (P1) Product-Terminal The new Windows Terminal. labels Nov 1, 2021
@ghost ghost removed the Needs-Tag-Fix Doesn't match tag requirements label Nov 1, 2021
@zadjii-msft zadjii-msft added this to the Terminal v1.13 milestone Nov 1, 2021
@zadjii-msft zadjii-msft added zPreview-Service-Queued-1.13 A floating label that tracks the current Preview version for servicing purposes. zStable-Service-Queued-1.12 A floating label that tracks the current Stable version for servicing purposes. labels Nov 1, 2021
@Peru-S
Copy link

Peru-S commented Nov 1, 2021

I worked around by installing Cascadia manually. (Hopefully this message isn't marked as spam :)
I searched for this issue before (opening a new one ) / commenting here btw. So if possible please sticky this.
Also I wasn't sure if it was a Terminal issue or a Cascadia issue, so juggling between those two github repos as well.
This could avoid unintentional 'spam' comments.

@barkermn01
Copy link

barkermn01 commented Nov 2, 2021

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:
Edition Windows 11 Pro
Version 21H2
Installed on ‎27/‎08/‎2021
OS build 22000.258
Experience Windows Feature Experience Pack 1000.22000.258.0

I do have a Windows Update pending will update this message if this update resolves the problem for me...

@zadjii-msft
Copy link
Member

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.

@miniksa
Copy link
Member

miniksa commented Nov 3, 2021

#11032's mitigation will likely mitigate this too.

@ghost ghost added the In-PR This issue has a related PR label Nov 15, 2021
@ghost ghost closed this as completed in #11764 Nov 16, 2021
@ghost ghost added Resolution-Fix-Committed Fix is checked in, but it might be 3-4 weeks until a release. and removed In-PR This issue has a related PR labels Nov 16, 2021
ghost pushed a commit that referenced this issue Nov 16, 2021
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
DHowett pushed a commit that referenced this issue Dec 13, 2021
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)
DHowett pushed a commit that referenced this issue Dec 13, 2021
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)
@DHowett DHowett reopened this Dec 14, 2021
@DHowett DHowett removed the Resolution-Fix-Committed Fix is checked in, but it might be 3-4 weeks until a release. label Dec 14, 2021
DHowett pushed a commit that referenced this issue Mar 10, 2022
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)
DHowett pushed a commit that referenced this issue Mar 15, 2022
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)
@srdjanjovcic
Copy link
Member

This is not fixed on Windows 10 in 1.13.10983.0

@lhecker lhecker reopened this Apr 14, 2022
@lhecker
Copy link
Member

lhecker commented Apr 14, 2022

Reopening because I found a flaw in my implementation.
In case people wonder how we're failing so hard at fixing this: It's partially my inability in figuring this out, but also partially because we're simply unable to repro this issue. All fixes are purely theoretic. Even my new fix is just made on an assumption (a pretty good one this time if I may say so). I'm really sorry about this! ☹️

@tylerszabo
Copy link

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.

@lhecker
Copy link
Member

lhecker commented Apr 14, 2022

@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.

@ilor
Copy link

ilor commented Apr 14, 2022

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:

  • I've rebooted a few hours ago to install Windows updates
  • This didn't break right on startup. In fact I have two shell tabs open where the font is okay, and only now (a few hours later) opening a new tab of the same type complains about the Cascadia Mono being MIA.

@ghost ghost closed this as completed in #12904 Apr 14, 2022
ghost pushed a commit that referenced this issue Apr 14, 2022
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.
@ghost ghost added Resolution-Fix-Committed Fix is checked in, but it might be 3-4 weeks until a release. and removed In-PR This issue has a related PR labels Apr 14, 2022
DHowett pushed a commit that referenced this issue Apr 21, 2022
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
DHowett pushed a commit that referenced this issue Apr 21, 2022
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
@ghost
Copy link

ghost commented May 24, 2022

🎉This issue was addressed in #12904, which has now been successfully released as Windows Terminal v1.13.1143.:tada:

Handy links:

@ghost
Copy link

ghost commented May 24, 2022

🎉This issue was addressed in #12904, which has now been successfully released as Windows Terminal Preview v1.14.143.:tada:

Handy links:

@AlpineWeezl
Copy link

Unfortunately, this issue still exists with completely updated system. I also did the reset as mentioned in the second post of this thread.

@ghost
Copy link

ghost commented Feb 25, 2023

@lhecker You wrote:

because we're simply unable to repro this issue

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!

@cmschlenke
Copy link

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

@psxlover
Copy link

I just run into this issue. Version 1.18.2822.0. Windows 10. According to the Microsoft Store Terminal was updated today.

The previous comment does not apply in my case, there is no Fonts folder in %appdata%..\Local\Microsoft\Windows.

What's even more confusing is that in "Fonts" they are "there" but are invisible until I hove over them with the mouse in which case only the names appear:
image
image

@DHowett
Copy link
Member

DHowett commented Oct 23, 2023

This was an issue on Windows 10 that Terminal had worked around. We recently (accidentally) broke our workaround. Stay tuned. 😄

@psxlover
Copy link

Glad to hear it is a known issue and not just something wrong with my PC.

@barkermn01
Copy link

@DHowett i believe there is a specific term for that it's called a Regression :D

@stevenwong
Copy link

stevenwong commented Nov 30, 2023

If anyone needs a temporary fix, uninstalling then reinstalling the Terminal app solved it for me. Neither repair or reset worked.

@IMB11
Copy link

IMB11 commented Sep 7, 2024

I fixed this issue by making sure that the font being used was installed for all users instead of locally just for my user.

This issue was closed.
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 Issue-Bug It either shouldn't be doing this or needs an investigation. Priority-1 A description (P1) Product-Terminal The new Windows Terminal. Resolution-Fix-Committed Fix is checked in, but it might be 3-4 weeks until a release.
Projects
None yet