Font can not be found after update to 3.1.0 (name for config changed)

[joseds]

Hi, thanks a lot for maintaining this ❤️ Today I noticed that my font does not look right.

I am on EndeavourOS and have installed the ttf-iosevka-nerd package. After yesterday's update to ttf-iosevka-nerd 3.1.0-1 the font did not look like Iosevka at all, much rounder, and for example the letter y looks different, see below. So I froze the version locally to the previous release 3.0.2-1. I am using kitty btw and I have changed nothing except the ttf-iosevka-nerd package between taking these screenshots in the terminal:

Version 3.0.2-1 (looks like Iosevka, e.g. the y and the overall narrower characters):

Version 3.1.0-1 (more like a generic monospaced font):

[michaelbeaumont]

Having the same issue with Source Code Pro for 3.0.2-1 to 3.1.0-1

[deckstose]

I think your configuration broke with the update. The bottom font seems to be the fallback font for your terminal.

Looking at the output of fc-list, all nerd fonts are now called <Font Name> NF instead of <Font Name> Nerd Font. So you just need to edit your config.

I'm not sure if silently breaking configurations was intended.

[michaelbeaumont]

Changing to <Font Name> NF fixed it for me, thanks!

[deckstose]

The release notes should probably get a big fat warning for this as I imagine more folks will run into this

[joseds]

Thank you @imwints! The renaming looks to be the root of the issue.

After changing in my kitty configuration from font_family IosevkaTerm Nerd Font Mono to
font_family IosevkaTerm NF (leaving out the Mono, too!), the newest version of the current package is picked up correctly.

There should be something in the release notes for this or maybe a revert to the old naming scheme, but there may have been good reasons to change the names.

[Finii]

Oops, sorry to hear of the problems.

Yes, the implications have been overlooked. Sorry to create the hassle.

but there may have been good reasons to change the names

In fact, yes, and as often the case it is just one client who has problems, in this case it is VisualStudio2022 that seems to be the only application that had special requirements that resulted in the name change.

• (Caskaydia Code and) Visual Studio 2022 #1242
• Bugfix for Visual Studio 2022 #1406

Before the change one font could have two different family names, one verbose ('Nerd Font Mono') and one abbreviated ('NFM'). The reason was that there are different name-length limits on different parts that use different naming systems; and the one that could live with the longer names takes the long family and the older systems which require shorter families take the short name.
That worked wounderfully, also with VisualStudio2019.

Enter VisualStudio2022. Somehow now fonts with not-identical family names are ... broken. You can select them, see them in the preview, but ... used in the editor is some other font (??!).

Anyhow. Having two different names (one long and one short) seemed to have been a 'too smart' idea anyhow. (If you examine the 3.0.1 fonts with fc-list you will see that they have two family names.) When people talk about a font some call it Something NF and other Something Nerd Font, which is a bit ... awkward.

On the other hand, there are more (also commercial) fonts out there that have more than one family name.
Maybe it's just a bug in VisualStudio2022 and we should not care. But ... what about people using VS2022? Will that be fixed by MS, and when?

But I will add a comment in the release notes etc.

---

Addendum:
VisualStudio2022 is more strange with fonts... If the selected font's name is Cascadia it will use one specific rendering engine and for all (?) fonts with a different name it uses a different font renderer. That means that you can not at all change the name on patching if patched and unpatched Cascadia shall look the same. Or if you just hex-edit the original CascadiaCode font's name and use that in VS2022 it uses a different font renderer than the unrenamed one.
How can anyone intruduce such kind of code?! 😢

Edit: typo, add addendum

[joseds]

Thanks a lot for the background information, @Finii ! As expected, there was a reason. Naming can be hard when there are no default names. Reading your comments I get the impression that maybe it would be good not to try to satisfy all the (new) quirks of VS at some point in the future.

[Finii]

Affected fonts

./src/unpatched-fonts/SourceCodePro/config.cfg:config_patch_flags="--makegroups 4"
./src/unpatched-fonts/IntelOneMono/config.cfg:config_patch_flags="--makegroups 4"
./src/unpatched-fonts/CascadiaCode/config.cfg:config_patch_flags="--makegroups 4"
./src/unpatched-fonts/Noto/config.cfg:config_patch_flags="--makegroups 5"
./src/unpatched-fonts/Iosevka/config.cfg:config_patch_flags="--makegroups 4"
./src/unpatched-fonts/VictorMono/config.cfg:config_patch_flags="--makegroups 4"
./src/unpatched-fonts/JetBrainsMono/config.cfg:config_patch_flags="--makegroups 4"
./src/unpatched-fonts/IosevkaTerm/config.cfg:config_patch_flags="--makegroups 4"

Edit: Remove new fonts, they are of course not changed ;)

[Finii]

would be good not to try to satisfy all the (new) quirks

Yes, certainly. On the other hand, as I pointed out, having two different names for one font is also for users sometimes a source of confusion, so I thought that the change is in kind of a general interest. Regardless of the client you use and which family you can enter in the client config, all people use the same string.

[Finii]

I'm really not too sure myself.

Roll back that PR and release 3.1.1, or force people to change configs.

I switch font names all the time in my clients - for tests, so it didn't occur to me 😒

---

Otoh, rolling back makes the fonts above unusable for VS2022 users, that is probably also not nice. And while changing the config is a hassle it is possible. Using the two-family-names-fonts in VS2022 is just plain impossible (to my knowledge).

[Finii]

Release notes changed. Lets see and wait for input ;)

Later: Ah some are new, I can remove them from the list.

[csrakowski]

As "requested in release notes", my 2cents on the matter:

I use Caskaydia, and have been changing my configs several times over the past year to follow along with the various (preview) releases that updated the font. (eg related to the issues mentioned in: #1434 (comment))
Whilst anoying, it's not too bad for me personally as I choose this pre-release lifestyle, and am aware of the changes due to the more active following of the in between tickets.

However, in general, I do think it would be best if we could pick a name and stick to it, and as @imwints put it here: #1434 (comment), be clear about breaking changes during release notes. (Like you have done now, as a result of this ticket)

Now, I get my releases from Github, so I see even these release notes to begin with, and this notification works fine for me.
But, as a further discussion point/open question: Are there (many) people who get their fonts updated via a package manager or similar?
If there are, they probably have no good way of being informed about these changes, and a breaking change such as this in a minor or point release is not a good experience.
If this is a big enough group, I can imagine you going for a hotfix release that rolls back the naming changes, and a 4.x release that then does include the naming changes.
It won't be ideal, but it would be more in line with semver, and help manage people's expectations.