Nerd Fonts 3.0 Roadmap

[ryanoasis]

Nerd Fonts 3.0 Target Features

Remap non-PUA glyphs

• Remap all non-PUA glyphs so that they do not conflict with official unicode:
  • To use a new PUA? #346
  • [Suggestion] Fix invalid code points for some glyphs #365
  • Material Design Icons from the Community conflicts with CJK Compatibility Ideographs #574
  • Discord icon is replaced with Urdu / Arabic symbol #614
  • merged into one issue: TBD
  • the leading consensus seems to be: Supplementary Private Use Area-A F0000-FFFFF

Fix and standardize font naming

• There are several open issues that all stem from font naming issues, some of these are easily fixed others are way more subversive.
  • Introduce a font name parser #717
• Drop the 'complete' portion of the name and also remove the complete/ sub directory as 90% of users are going to use already patched fonts and the remaining 9.99% are going to patch with the --complete option.

Repo organization and maintenance

There have been a lot of issues and confusion around using the font-patcher, mostly because it requires additional files: #659, #495, #484, #666, #245

Actions

• Provide the font-patcher in the release (from 2.2.0 onwards) Add font patcher in release #484
• Download source files when using the patcher (WIP: font-patcher: Check if glyph source is available (--glyphdownload) #741)
• Move font-patcher and source files to separate repository (Extract the patched fonts into separate repository? #73) ? Maybe not... if it's provided in the release?
• Update the readme so it is clear that the source files are also required

Upgrade glyphs

• Upgrade glyph set packages from upstream sources or switch to alternative versions
  • Devicons
    • Consider replacing with something actively maintained (refs Switch to the popular, maintained devicons/devicons repo from unmaintained vorillaz/devicons #615)
  • Font Awesome
    • either we find an alternative like fork awesome or make the jump to FA 5+ free (refs #/241, Request: FontAwesome 5 & FontAwesome Pro #221)
  • Font Awesome Extension
    • project seems to be dead/un-maintained
  • Font Logos - active project, just need to keep up with upstream
  • IEC Power Symbols - likely nothing to do, just verify
  • Material Design Icons - we are using a super old version with around 2k+ icons, latest has 6k+ (ref Material Design Icons missing some icons #279)
    • can we just grab the font from the font file ?
  • Original Source (Seti-UI but modified) - from seti-ui at one point but added a few in-house glyphs. check if seti-ui added any?
  • Octicons - update to new? license still looks ok (MIT) ref feat: update Octicons to latest #490
  • Pomicons - likely has no change, nothing to do here
  • Powerline Extra Symbols - we have the latest, nothing to do here
  • Powerline Symbols - no action required?
  • Weather Icons - is it maintained or not? some conflicting signals here...
    • we may want to change out as project is not maintained but switch to what? the mentioned fork also seems inactive. edit: update, the repo does seem to have some recent activity so maybe it's still being maintained??

Add new glyphs

Explore new additional glyph sets

set	ref	number of glyphs	active repo
feather icons	#665	287	yes (Mar 2022)
game-icons	#655	4151	yes (Jan 2022)
Mfizz or even Mfixx	#615	107	probably (Jan 2019)
Siji	#173	215	probably (Feb 2019)
AIGA	#153	69	no repo
Academicons	#616	149	yes (Mar 2022)
file-icons	#615 #342	931	probably (Jun 2021)
ionicons	#465	1332	yes (Jan 2022)
Simple Icons	#818	2236	yes (Apr 2022)

Edit: Fini: Restructure and add more information to new-glyph-set paragraph

[Finii]

I would like to see the naming fixed, as it is hit-or-miss at the moment. That is just an issue for people who install multiple fonts styles of a family, but we should get that right.
At least not make it worse then the original fonts (some have issues).

If the FontnameParser #717 would be a too big change (or not ready in time), we could at least correct the SFNT table modification that is now broken because of fontforge. That would be a smallish change, that fixes at least the most severe cases (#690 (comment)).

[ryanoasis]

I agree yeah. #717 would mostly be for 3.0 unless we go with your idea of having it used in limited capacity/special cases (e.g. Cascadia Code)

I will add this to the list

Also, seems like #690 isn't going to be needed?

[Finii]

Yes, 690 is more like a stub. When setting the names to what-we-want-to-set would succeed the result would be not better but worse, maybe.

Without fixing what we want to set it does not make much sense to fix the setting itself.
This is why I added the example naming in well ... #717 (comment)

I guess 690 should be closed, but then, if the code stays as it is, is looks like it is doing something that it does not. And that will confuse maintainers again in the future...

[NuraliMedeu]

Hello! I've read that there are plans to split this repo into nerd-fonts and font-patcher to reduce confusion about which files are necessary for patching fonts.

Instead of splitting this repo into two, and thus introducing more maintenance burden, I suggest to edit the font-patcher script to automatically download the necessary files from this repo. That way, all a user will have to do is to download one script file from the website.

Also, both the README.md and the website need to explicitly state that currently. for the font patcher to work, the user needs to download the entire repo, not just the script file.

[Finii]

Laugh... See my answer in other thread.
Will check that out.

[ryanoasis]

#495 (comment)

[Finii]

I see the action Move font-patcher and source files to separate repository? Maybe not... if it's provided in the release?

The question is rather: Why are the patched fonts committed into the repository and not just available as artifacts download? The release page looks very nice and has the patched fonts conveniently listed 👍

All the histories can be kept, but why not just throw out the patched fonts (i.e. artifacts). Ok, some people would need to change how they fetch the patched fonts, but if we remove that big binaries also in the history/past, that would make the repository so much more hand-able (still big because of the source fonts, but that has at least some merits).

@earboxer's hint #73 (comment) is excellent. Why not drop the patched fonts out of all the git history and rely solely on releases and a perpetual RC to keep the current developments' patches available?

[ryanoasis]

The question is rather: Why are the patched fonts committed into the repository and not just available as artifacts download? The release page looks very nice and has the patched fonts conveniently listed +1

I'm willing to make that change and it would solve some frustrations with such a large repo as well. I know if/when I want to quickly download I usually use the releases now rather than drilling down into the folder structure on Github. Obviously a decent chunk of users still get their fonts this way so they'd have to adjust. Commented here: #495 (comment)

[leaxoy]

Any update on this, it's awesome to add newly icons.

[alsimoneau]

file-icons would cover #925

[tjapro]

IEC Power Symbols - likely nothing to do, just verify

When I was searching another icons, I came accross the https://unicodepowersymbol.com/ website.
They tell that their symbols are now part of Unicode 9.0

How this change will affect Nerd Fonts?

[Finii]

Unicode just specifies which logical symbol has which codepoint, not a specific way to 'draw' it (which is called 'glyph' and resides in fonts).

now part of Unicode 9.0

Current is 15 or so 😬

How this change will affect Nerd Fonts?

Every change here needs (is not happening without) a conscious decision.

[tjapro]

Ok, I understand now the difference. Thanks!

[Finii]

In fact, these exact glyphs are already part of the Nerd Fonts patchset, at the correct codepoints.

The "power off" symbols is also there, it's just far far down.

[markonop93]

is all characters now going to be UTF-16 XXXXX?

[Finii]

No.

The Material Design Icons move (and update).
From the current release's page:

Material Design Icons

The Material Design Icons have to move codepoints. Historically we patch them in between F500 - FD46; but part of that range is needed for Chinese and other glyphs. With #773 and Plan 5+ of #365 their new home will be after F0001. And they grow considerably.

The v2.3.x release has both, the 'old' and the 'new' codepoints to enable you an easier transision. Please change already now your prompts and other uses to the new codepoints. Release v3.0.0 will finally drop the old codepoints (F500 - FD46).

Replacement list (old to new codepoint) is here (open 'details').

Note that they do not only more move, they are also updated. That means there are now 6800 or so Material Design Icons, up from 2200.

On the cheat sheet you also see old and new codepoints side by side:

fbbb moved to f06bd

Further information maybe here:

• How to print the 5-digit icons #1077
• Add UTF16 to cheat sheet #1059
• Add New Material Design Icons to its own region #773
• [Suggestion] Fix invalid code points for some glyphs #365

[unphased]

I have concerns relating to moving the codepoints.

• My terminal emulator side investigation: Is it possible to force alacritty to draw all glyphs in true monospace? "謹" character appears as double width alacritty/alacritty#6750 (comment)
  conclusion: Fix the font. Consistent with moving the codepoints.
• Moving the codepoints in the Nerd Font means now applications that specify those codepoints would need to all individually update. If there is a mismatch between application and font version, the output is garbage. I care about this because I use stuff like https://github.com/nvim-neo-tree/neo-tree.nvim

This is rather unfortunate to have to update a whole bunch of software and carefully sync font version with software version to handle this transition. Is there no better way?

[Finii]

Well, imagine some font patcher overwrites the glyph u and you in fact can never write unphased anymore, because it comes out like @nphased. This is the case for people that want to use 謹 if we patch over their codepoints. It was just a mistake to use codepoints for symbols that already had other characters attached to it. So there is no way around it, if you are not completely western-centric the symbols and codepoints must abide to the rules set forth by the unicode consortium.

For sure it is inconvenient, but there is not really a way around this. But not all codepoints are moved, just a small fraction of all the symbols we patch in.

conclusion: Fix the font. Consistent with moving the codepoints

Well, yes. Fix the font means do not occupy codepoints that are already assigned a different meaning.

I care about this because I use stuff like

...where the codepoint move is no problem at all, you can just install a different configuration file. I'm sure there will come up prepared files for the projects, as there are already some that did exactly this.

Is there no better way?

Well. This discussion started in like 2018? A lot people contributed over the years but there seems to be no magic solution that makes the unicode consortium free the codepoints for us 😬
But if you have a good idea how to solve this, please tell us :-)

Edit: Correct last citation

[unphased]

Fonts allowing for a transition period supporting the new codepoints is pretty clever, and definitely works for me! Now we'll put the broken TUI rendering behind us more or less. Yeah these plugins and tools are so much more customizable than in the past too. Thank you so much!

[Strahinja]

About the font patcher, the nerd-fonts repository is huge and very impractical to download. It is much more convenient to provide just the font patcher, so people can choose their own fonts to patch with Nerd Font glyphs.

This is reminiscent of the old story about teaching a man to fish vs only giving him fish - "teaching a man to fish" would be having a separate font patcher.

I'm not convinced that keeping a separate repository for just the patcher would be that much more complicated, when features such as git submodules exist.

[Finii]

Yes, the repo ist big, but there is nothing I can do about that (*)

It is much more convenient to provide just the font patcher

Correct. That is the reason why we just do that - provide just the font-patcher. As zip archive (release and HEAD) and as docker image. People do not even need to know git. Not without reason are these the recommended self patch methods.

I also believe that a separate repo would be better. (*) Although I think a submodule is not the right solution here (I use submodules a lot at work, but here the relationship is different), but that is just a detail. In principle I agree.

There are several warnings NOT TO clone the repo, and what to do instead. I guess people who do not read that will also have problems if people teach them to fish. See images further down.
And then, what I experience is people can not even install ttf files themselves, they rely on package managers to get these fonts.

(*) The problems are access rights mainly. I personally have only a limited set of rights here (for example no force push, which would be needed to make this repo leaner), and also limited rights in the NerdFonts organization. Of course I could create something somewhere else, but is that a solution? I believe it is not too bad at the moment and would prefer to only act with Ryans approvement. At the moment he is too busy.

There are several thinks I think have to be done here

• Release v3.0.0
• Imrove monolitic patcher code
• Drop fontforge and patch VF
• Split repo

Each of the items has several sub-items that each take time. The list above is - apart from bug fixes - my current priority list.

---

---

---

https://github.com/ryanoasis/nerd-fonts#option-9-patch-your-own-font

[Strahinja]

Ah, I see now that bit has changed since I last checked the Readme.

Still, if the intended purpose of the main nerd-fonts repository is to only be cloned and interacted with by a select group of developers, perhaps it should be made private? At the same time, having a patcher in a separate repository as opposed to just having it in a zipfile allows for that repository to be forked and used to collaborate, potentially submit PRs and issues targeting just the patcher.

Alternative take would be that perhaps everything should be turned upside-down, as you mentioned ("relationship is different"), patcher should be the main focus and source files for the fonts patched with the patcher split into separate repositories, and the end results offered simply as extra archives for download on the releases page (as they are now)?

[Finii]

Yes, I believe the current "release cycle" is not the best way to handle the prepatched fonts. In fact I believe users want a new patched fonts when a sourcefont is updated - immediately. Regardless of Nerd Fonts Release Versions. Nerd Fonts Releases are bloated if they were triggered by any source update without a patcher update.

So in fact the best way (in my eyes) is to have a stand alone patcher repository. Then there has to be a cluster of prepatched fonts, that are just release blobs. There is no need to keep the sourcefont in the repo if it can be fetched on updates. This is a bit how we have set up the Delugia repo. It automatically creates a new patched Cascadia Code release within hours when a new upstream release is issued.
Like your alternative take.

One additional problem is that a considerable about of download occur to the files directly in this repo (and not the release zips). There are even 3rd party packagers that scrape this repo and create a new package automagically when the patched font is updated in HEAD.

If it would not be limited by 'can not force push' I would clean up this repo and (automatically) remove all old patched fonts - which make up the main part of this repo's size. And they are not really needed at all.

Ripping out the patcher and putting it into a new repo (https://github.com/NerdFonts/patcher) has the downside that the connected Issues and PRs are lost, or at least harder to get together.

I personally do not see a problem with collaboration and PR creation here in this repo. PRs are here from time to time and are merged. But you are right in general of course, Just to find a solution given the restrains we have is hard.