Another attempt at fixing nearby font loading #12904
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
ghost
added
Area-Fonts
|
Here's the source code for the "mini-test": #define UNICODE
#define NOMINMAX
#define WIN32_LEAN_AND_MEAN
#include <Windows.h>
#include <dwrite_3.h>
#include <cstdio>
int main() {
IDWriteFactory7* factory;
DWriteCreateFactory(DWRITE_FACTORY_TYPE_SHARED, __uuidof(factory), reinterpret_cast<IUnknown**>(&factory));
IDWriteFontCollection1* systemFontCollection;
factory->GetSystemFontCollection(false, &systemFontCollection);
IDWriteFontSet* systemFontSet;
systemFontCollection->GetFontSet(&systemFontSet);
IDWriteFontSetBuilder2* fontSetBuilder;
factory->CreateFontSetBuilder(&fontSetBuilder);
// !!!! Change this order around to see the results !!!!
fontSetBuilder->AddFontFile(L"arial1.ttf");
fontSetBuilder->AddFontFile(L"arial2.ttf");
fontSetBuilder->AddFontSet(systemFontSet);
IDWriteFontSet* fontSet;
fontSetBuilder->CreateFontSet(&fontSet);
IDWriteFontCollection1* fontCollection;
factory->CreateFontCollectionFromFontSet(fontSet, &fontCollection);
UINT32 index;
BOOL exists;
fontCollection->FindFamilyName(L"Arial", &index, &exists);
IDWriteFontFamily1* fontFamily;
fontCollection->GetFontFamily(index, &fontFamily);
IDWriteFont* font;
fontFamily->GetFirstMatchingFont(DWRITE_FONT_WEIGHT_NORMAL, DWRITE_FONT_STRETCH_NORMAL, DWRITE_FONT_STYLE_NORMAL, &font);
BOOL has0;
BOOL has1;
BOOL has2;
font->HasCharacter(L'0', &has0);
font->HasCharacter(L'1', &has1);
font->HasCharacter(L'2', &has2);
printf("0: %d\n1: %d\n2: %d\n", has0, has1, has2);
return 0;
} |
|
|
DHowett
approved these changes
Apr 14, 2022
|
|
||
| for (const auto& file : nearbyFontFiles) | ||
| { | ||
| LOG_IF_FAILED(fontSetBuilder->AddFontFile(file.get())); | ||
| } | ||
|
|
||
| // IDWriteFontSetBuilder ignores any families that have already been added. |
There was a problem hiding this comment.
Critically, this is true on Windows 10, Right?
lhecker
added
the
AutoMerge
|
Hello @lhecker! Because this pull request has the p.s. you can customize the way I help with merging this pull request, such as holding this pull request until a specific person approves. Simply @mention me (
|
ghost
merged commit 
DHowett
pushed a commit
that referenced
this pull request
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 pull request
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
|
🎉 Handy links: |
ghost
mentioned this pull request
|
🎉 Handy links: |
|
Funny enough, I got back from a two week vacation today and the live start menu icon for Terminal showed like it was stuck on a partial upgrade or something. Opened Terminal and it seemed to work (showing version 1.13.11431.0) and correctly used Cascadia Mono, however my Visual Studio Code install could no longer find that font. Additionally, looking in my installed fonts within Windows Settings I could not find either Cascadia Code or Cascadia Mono. Repairing the Terminal install fixed the issue. Sadly, that's what I've had to do with the last two upgrades of Terminal as well. Perhaps 1.14 will finally be the version where that no longer occurs. Who knows, maybe my situation was just a fluke thing. |
This pull request was closed.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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
Validation Steps Performed
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
FontFacenamed "Arial" and calledIDWriteFont::HasCharacterfor the letter "1".Loading the system font collection first results in
TRUEand loading it lastresults 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.