ryanoasis / nerd-fonts

Iconic font aggregator, collection, & patcher. 3,600+ icons, 50+ patched fonts: Hack, Source Code Pro, more. Glyph collections: Font Awesome, Material Design Icons, Octicons, & more
https://NerdFonts.com
Other
54.12k stars 3.64k forks source link

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

Closed joseds closed 10 months ago

joseds commented 10 months ago

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): image

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

michaelbeaumont commented 10 months ago

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

imwints commented 10 months ago

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 commented 10 months ago

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

imwints commented 10 months ago

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

joseds commented 10 months ago

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 commented 10 months ago

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.

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?! :cry:

Edit: typo, add addendum

joseds commented 10 months ago

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 commented 10 months ago

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 commented 10 months ago

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 commented 10 months ago

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 :unamused:


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 commented 10 months ago

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

image

image

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

csrakowski commented 10 months ago

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: https://github.com/ryanoasis/nerd-fonts/issues/1434#issuecomment-1822752797) 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: https://github.com/ryanoasis/nerd-fonts/issues/1434#issuecomment-1822696676, 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.

neochrome commented 10 months ago

@Finii one thing that you could do to help notify people about breaking changes is to create a pinned & locked issue called something like: "breaking changes" and post to that one when something like this is planned. That way pepople can subscribe to that issue and get a nice notification :heart: See https://github.com/hrsh7th/nvim-cmp#readme for an example on how it can be done :)

Finii commented 10 months ago

Thanks for your inputs.

Well, I thought I did a more or less good job on informing about breaking changes. In the 2.3.3 release I already warned about pending breaking changes that came with 3.0.0, and we had and still have the pinned issue about that.

With the current problem the situation is different because I was too dump to forsee the breaking itself :-(

BBaoVanC commented 10 months ago

But, as a further discussion point/open question: Are there (many) people who get their fonts updated via a package manager or similar?

That would be me, I just updated the official Arch Linux ttf-jetbrains-mono-nerd package and noticed the font changed, and had to search to find this issue. Not sure how else you could warn for it though, other than just not changing the name again.

Finii commented 10 months ago

Thanks @BBaoVanC .

So I agree with @csrakowski that the change is a breaking change and thus should have been a major version number increase. And for normal software packages I would just do what he said and what is right for semver, roll out a 3.1.1 and a 4.0.0 immediately afterwards.

But the quesion is ... how many people would help this? People updating the fonts via package manager just update to "newest", which would be 4.0.0 which is identical to 3.1.0. They might or might not notice the major increase, and even if they would have to look up here which change has been introduced and how to fix their setup.

Websites that use Nerd Fonts via CSS will also not benefit at all.

The only ones that could in principle are other packages that depend on a Nerd Font package and who have set the dependency to be 3.x.x. Dependents I have looked at do not do this, they just want Nerd Font.

And then, I really hate the change. We waited with all the naming changes for 3.0.0, for exactly these reasons, and that should have been a once and never again change. All clients were happy with the names. WHY is this VS2022 breaking it. Maybe maybe it is better to undo that one commit and just break it for all VS2022 users. Microsoft should fix their application. It is not unheared of that fonts have different family names. I need to investigate that. Maybe the bugfix by changing the family names was not the best, maybe there is a different way to fix it (maybe by additionally setting the 3rd kind of family names, that at the moment we keep unset.

So my preferred solution would not be 3.1.1 and 4.0.0 but rather a 3.1.1 that undoes the family name change and either solves the VS2022 problem differently or just does not solve it.

But that needs some time to investigate. Unfortunately time is limited and I had no time to dive into this the previous week. I already took one complete day off of work (Tuesday) to do the release and despite all the automatism it really took that full day. I will try to find something out this weekend.

real-or-random commented 10 months ago

Unfortunately time is limited and I had no time to dive into this the previous week. I already took one complete day off of work (Tuesday) to do the release and despite all the automatism it really took that full day.

Let me just say thank you for maintaining this!

irixaligned commented 10 months ago

Just dropping in to say that given proper forewarning I think this is a positive change, especially considering how confusing it can get (at least for me) trying to distinguish fonts with multiple Monos; having a simple NF or NFM is much easier for me personally That being said, upping the major version is probably a good idea, because this is going to (and has already started to) break like every configuration on planet earth lol

SuperTux88 commented 10 months ago

So my preferred solution would not be 3.1.1 and 4.0.0 but rather a 3.1.1 that undoes the family name change

That would also be my solution ... but the 3.1.1 with the undo should have been released as soon as this was detected. The longer you wait, the more people now update to 3.1.0 and change their config, and now a rollback wouldn't just be a rollback anymore, but 3.1.1 with the undo is a breaking change to the current 3.1.0 again.

So I'm waiting with updating at the moment because I don't want to change configs and then need to change it again once 3.1.1 or 4.0.0 or whatever version releases.

Finii commented 10 months ago

Sorry for the name change, a Nerd Fonts bugfix release (3.1.1) is underway.

https://github.com/ryanoasis/nerd-fonts/actions/runs/6996412186

Finii commented 10 months ago

Closed via #1439

h0adp0re commented 10 months ago

The word "revert" makes me think I have to revert the change in my config as well but the new name seems to work still — reverting SauceCodePro NFM to SauceCodePro Nerd Font Mono does not seem to affect anything?

@Finii could you please shed some light on this?

Finii commented 10 months ago

I have a new attempt for fixing the VisualStudio 2022 bug.

that undoes the family name change and either solves the VS2022 problem differently

After that PR the fonts will have both names in them, SauceCodePro NFM and SauceCodePro Nerd Font Mono (etc). Well, they already have that now. The short form is in ID1 and the long one in ID16.

After the PR the short form is in ID1 and both the short and the long form are in ID16 - so in principle the font has then three family names. That seems to work with the problematic Windows applications, and for sure should work for all of your application.

It would be nice if you can check the font set out and report any problems: Caskaydia_3.1.1-6.tar.xz.zip (1.7M) If there are no problems that will be the new 3.2.0.

shed some light on this

Yes, see above, at 3.0.2 and 3.1.1 the short family name is in ID1 and the long in ID16. Systems like fontconfig list them all indiscriminately. See the examples of the many naming fields in https://github.com/ryanoasis/nerd-fonts/pull/1442#issuecomment-1827937632 that should answer your question with a nice overview.

The fix is some kind of a kludge, but I guess that is in order, esp as the family name in the 'unexpected' place is the one intended for / used by VisualCode ;-D My first idea was the other way around, but this is maybe best.

So please, test the test-fonts and report back. :-) Thank you.

(Windows users' comments on the new solution here: https://github.com/ryanoasis/nerd-fonts/issues/1242#issuecomment-1828444554)

JounQin commented 9 months ago

After reading, I still don't understand how to enable Monaspace in VSCode...? Maybe I'm too stupid.


Finally I found the correct VSCode font family setting value: "editor.fontFamily": "MonaspiceNe Nerd Font":

https://github.com/ryanoasis/nerd-fonts/pull/1405/files#diff-38d3c2744cebc218f2ff45a8705efe449b80f7c4487e3df8daf001a2e9acb1b0R415

Finii commented 9 months ago

You mean Monaspice NF, I guess? Please open a new Issue with the details filled in and I can check...

Sent from Nine


From: JounQin @.***> Sent: Saturday, December 9, 2023 10:52 To: ryanoasis/nerd-fonts Cc: Fini; Mention Subject: Re: [ryanoasis/nerd-fonts] Font can not be found after update to 3.1.0 (name for config changed) (Issue #1434)

After reading, I still don't understand how to enable Monaspace...? — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you were mentioned.Message ID: @.***>

JounQin commented 9 months ago

Finally I found the correct VSCode font family setting value: "editor.fontFamily": "MonaspiceNe Nerd Font":

https://github.com/ryanoasis/nerd-fonts/pull/1405/files#diff-38d3c2744cebc218f2ff45a8705efe449b80f7c4487e3df8daf001a2e9acb1b0R415

@Finii

github-actions[bot] commented 3 months ago

This issue has been automatically locked since there has not been any recent activity (i.e. last half year) after it was closed. It helps our maintainers focus on the active issues. If you have found a problem that seems similar, please open a new issue, complete the issue template with all the details necessary to reproduce, and mention this issue as reference.