Closed MizardX closed 2 months ago
The "en-gb" locale should use the same naming rules ("Nerd Font" vs "NF") as "en-us". Or the "en-gb" locale should not be included at all.
Can you elaborate a bit on your expectation? In which way does it impact the usability or make the fonts unusable? Are there any things you can't do due to the naming?
The different names are on purpose, and the names in en-gb exist for the sole purpose to fix broken behaviour of MS VisualStudio 2022.
The PR that introduced these names with links to other relevant discussions is
We have 3 options
I close this for now, and I do not believe we will change the naming any time soon, but please give more details and why you think "consistent" font names are more important than the reasons for the introduction of the "inconsistent" ones.
P.S. More scripts for examining the fonts names are in bin/scripts/name_parser/
Depending on how the names impact you... I believe we can stuff the VS2022 names into any language, so if it is specifically the GB language that is an Issue, we can use any other, less likely to interfere with normal behaviour.
Win32FamilyNames = $font.Win32FamilyNames;
FamilyNames = $font.FamilyNames;
Why does MS introduce new names for the different naming parts in the font? There is no "Win32" whatsoever in the font specification. They should probably read their own documentation about the name properties of open type fonts: https://learn.microsoft.com/en-us/typography/opentype/spec/name
I don't know if you use VS2022, but that has another ... strange behavior:
If a font's name is "Cascadia" it renders it differently than other fonts. So if you want to have the patched font (i.e. "Caskaydia") in VS2022 and have it rendered identically to stock Cascadia, you need to rename it to "Cascadia". They really use the font's name. That is the reason why there is the no-renaming option with the patcher, so that people can self-patch a fully functional "Caskaydia" for VS2022.
Scripts that show different aspects of font names are bin/scripts/name_parser/query_name*
in this repo.
fini@Air nerd-fonts % fontforge bin/scripts/name_parser/query_name patched-fonts/CascadiaCode/Regular/CaskaydiaCoveNerdFont-Regular.ttf 2>/dev/null
Examining 1 font files
======== CaskaydiaCoveNerdFont-Regular.ttf ========
SFNT Fullname ID 4 CaskaydiaCove NF Regular
SFNT Family ID 1 CaskaydiaCove NF
SFNT SubFamily ID 2 Regular
SFNT Pref Family ID 16 ('CaskaydiaCove Nerd Font', 'CaskaydiaCove NF')
SFNT Pref Styles ID 17 -
SFNT PS Name ID 6 CaskaydiaCoveNF-Regular
SFNT Compatible ID 18 -
SFNT CID findfont ID 20 -
SFNT WWS Family ID 21 -
SFNT WWS SubFamily ID 22 -
PS fontname CaskaydiaCoveNF-Regular
PS fullname CaskaydiaCove NF Regular
PS familyname CaskaydiaCove NF
fondname None
fini@Air nerd-fonts %
I'll only look at FamilyNames['en-us']
instead of FontFamily.Source
/GlyphTypeface.Win32FamilyNames['en-us']
in the future, when searching fonts. I was just surprised, since those are the only fonts on my system where FontFamily.Source
didn't match the displayed font name.
Requirements
Experienced Behavior
The displayed font-names of "CaskaydiaCove" and "VictorMono" differ depending on the application used.
In some, the named is "CaskaydiaCove NF", and in others it is "CaskaydiaCove Nerd Font".
I believe this is due to the font having differencing names in "en-gb" and "en-us" locales.
Here is a PowerShell script to display the names:
Output:
It seems to be consistent on fonts with only one locale, but "CaskaydiaCove" and "VictorMono" have both "en-gb" and "en-us" locales, which seems to have different naming rules. The
Win32FontFamily
seems to pick the first name.Expected Behavior
The "en-gb" locale should use the same naming rules ("Nerd Font" vs "NF") as "en-us". Or the "en-gb" locale should not be included at all.
Example Symbols or Text
No response
Font Used
CaskaydiaCove, VictorMono
Source of Font File
Github
Terminal Emulator (and the title of the terminal window)
Windows Terminal
Operating System and Version
Windows 11
Screenshots