Closed AtomToast closed 1 year ago
The file-icons project might be an even better replacement. It looks to have unified styling and optimized SVG's across the old devicons, MFizz icons, and many new file-icons icons.
These can also replace most of the existing nf-custom icons, except the folder ones, I guess.
also related #233
Thank you so much for this project! 🥰 It would be great if there were a way to get the Svelte icon into the glyph set. The 3.0 roadmap hints that more glyph sets might be included in the future, but only file-icons has an icon for svelte.js (and many other quite popular file extensions), so I just wanted to show some interest for this specific library to be included
devicons/devicon does include a svelte icon. You can see all the current icons over on https://devicon.dev/ You can also look at the issues and pr's for all the icons currently requested and in progress of being added
Also mentions file-icons: #342
Hate to be this guy, but any update on this? The maintained devicons repo has a bunch of modern stuff that's currently missing (e.g. helm, kubernetes, terraform, etc).
Hi! Maintainer of devicons/devicon here. We are close to a new release of devicon which will be adding a ton of new icons. Once that's done I'd like to add the dataset to nerdfonts.
I need some clarifications first though. Since some icons have been updated since the start of the devicons fork, so it's not a complete superset.
@Finii perhaps you can answer this: When adding the fonts from devicons/devicon, should we:
devicons/devicon
to the same set as the current devicons
icon setdevicons/devicon
as a new icon set called devicons
and rename the current Devicon set as old devicons
.devicons/devicon
as a new icon set called devicons/devicon
and rename the current Devicon set as vorillaz/devicons
.I personally am leaning towards 4. where we rename both to the username/repo format, but I fear this would break backwards compatibility which wouldn't be good. That is unless there's some way to indicate renamed sets somewhere.
Anyways, let me know what you think, and hopefully I can take a look at adding the set in soon :)
Hej @Snailedlt, thank you for the input.
Switching from vorillaz/devicons to devicons/devicon is in fact on the Nerd Fonts Roadmap.
What I wonder first, and just tried to check (for some seconds, superficially), is if there is any codepoint 'guarantee' at devicons/devicons. This means that the codepoint for a given symbol stays 'constant' over updates: If for example the Github glyph is E000
today, it will be E000
also tomorrow and next year. This is needed for people who use the Nerd Fonts Font in some font-ish way locally. As shell prompt, as symbol in polybar, whatever. Noone wants to fear updates, when one has to search for the beloved icon's codepoint again and again.
It seems that this is not guaranteed. When I look at the not long ago commit Build preparation for release v2.15.0
it seems to me that the codepoint of for example devicon-devicon-line
has been E90C
before and EA3A
after the commit (according to devicon-base.css
). On the other hand some codepoints stayed the same with that commit. And there seem to be added codepoints, which is fine of course.
Some icon sets seem to be aimed (solely) at web usage, where it might be of no relevance (people reference the glyphs via IDs). For desktop use as font this is rather strongly needed.
This are the first few glyphs in the (ttf) font:
There are empty slots. So you do not 'pack' all available icons in consecutive codepoint slots. But you still move? Maybe you can explain how the icons get their codepoints and what the strategy is.
And there seems to be some icons not really suited for font use, like the left side Node-webkit ones (with the tiny text below), or Angular icon, which you could hardly read in any (un-scaled) text environment. But other people might find them useful.
There seem to be 504 icons in the set (at the moment). The old devicons have 202 (both numbers including unusable meta glyphs). Would it fit into the 'old' space? If we look here https://github.com/ryanoasis/nerd-fonts/wiki/Glyph-Sets-and-Code-Points#overview it seems we have E700
- EA59
(864 codepoints). This seems ok, even for further growing, if the icons would be packed.
For me personally, your Plan 1 is the neatest. People already using devicons get refreshed icons, and we have less symbol duplication and naming chaos ;) Also options are always bad, because the majority of Nerd Font users (I assume) use the prepatched fonts distributed over several (3rd party) packages, and can not choose anyhow.
So if devicons/devicons does not have a native codepoint guarantee (which I would assume right now), WE could of course introduce one here. Create a (manually updated after each update) glyph-to-codepoint assignment, and even assign the first codepoints in a way that the current glyph-to-codepoint mapping is kept intact (just same symbol updates).
On the other hand is it strange to sort and allocate slots for another project. But in fact we do so already for some other icon sets. Well, not handle the guarantee but shift all existing glyphs to remove codepoint gaps. Which is in itself ... bad :grimacing: (I mean the 'foreign' gap filling is bad, but alas...)
where we rename both to the username/repo format
I guess you talk about the CSS
IDs here.
This is getting too long :-) Let me know what you think.
Fini
Hi @Finii, Thank you for the really long, detailed and insightful response!
I honestly don't know too much about fonts since I haven't been working on devicons for very long, and I've mostly been working on automation tasks. So pardon my inexperience.
As I understand it codepoints
are sort of a font set's ID (or index), which you need in order to retrieve fonts in some cases (especially desktop by the sound of it). If that's the case, then it makes sense that it should stay the same between versions.
I'm not sure if there's any strategy to how we create the font codepoints, or if it's an entirely externally automated process by Icomoon, which we use for font generation. I'm guessing that the codepoints might change depending on the order of the icons, but I'm not sure about that. It's worth taking a closer look at it though. I took a look at Icomoon's documentation for making a font, and it looks like the font can be changed manually. Therefore it should be possible to automate it via a Selenium script given a list of mappings between icons and their codepoints.
You're correct in your assumption that devicons/devicon is more tailored towards web development, but I think we should strive to improve the experience for off-web usage too. Every web developer also uses local tools after all.
Because of this, and the fact that we might integrate with other font collections who require so called "codepoint guarantee", I'd prefer it if it was implemented in the devicon project, and not nerd-fonts.
Looking further into the devicon source code it looks like we might be able to just insert all the right codepoints into the icomoon.json
file, which it seems like gets generated in the icomoon_build.py
script, which again is triggered on every PR through the build_icons.yml
workflow script.
I took the time to convert a single icon into a font using icomoon. This is the resulting .zip file: devicon-v1.0.zip
, which contains among other things a devicon.ttf
file and a selection.json
file, which corresponds to the icomoon.json
file I mentioned earlier. Upon inspecting the devicon.ttf
file I could see that the codepoint was E90B
, which converts to the integer 59659
. Now this value can be found inside icons.icon.properties.code
property in the selection.json
file. So now I'm thinking it's just a matter of manually adding the icons.icon.properties.code
attribute based on if an icon is new or not. It seems like something like that is already done here and here though, so maybe we can use that?
Anyways, I'm blabbering. Let me know what you think, and if the solution is obvious to you, and seems easy enough to implement, please feel free to do so. If not, I'll probably spend a week or so trying to figure this out 😅
I'll just throw in the complete selection.json
file here for good measure, so you can take a look at it and see for yourself :)
selection.json
file!
About codepoints.
You might know ASCII, which assignes numbers to certain 'letters', often used in code (examples). The letter 'A' has code 41
for example (in hexadecimal). As more and more 'letters' were needed the coding scheme has been extended in various directions and predominant today is the unicode system. Where still A
has code 41
.
Codepoints are usually expressed via hex numbers.
So if you have a text document, or a word/writer file or a web site, if you want to have a A
displayed there is usually one byte that stores 41
. That number is transferred to the font renderer, that looks up in the font file how to render/draw it on the screen.
This might sound obvious. But it is the same with all glyphs. For example (from your image above) the "Openal Plain" (whatever that is) should be displayed. You can insert the 'letter' with the code E90B
in your text document, writer file or web site, and it will be rendered correctly, if the font contains the instructions how to draw it. Reference is via the code / number / index / codepoint.
Web developers often do not do it this way. They like to insert not a 'letter' "Openal Plain" which might or might not be displayed correctly in the text editor, they want to insert openal-plain
or devicons-openal-plain
or whatever. A symbolic name / ID.
The html renderer then searches for that ID, and you have the translation to codepoint in your CSS
document. There the ID is given and the actual 'letter' as 'code'. The web renderer then hands off the letter-code to the font renderer, that looks into the font file, etc pp.
The trick/need for the CSS
file is that it also references usually a specific font file. So devicons-openal-plain
is referenced to font1.ttf with code E90B
in one CSS
file and after devicons updated the same ID references font2.ttf with a potentially different code. You just do not care. The codepoint-font relationship is abstracted away.
But if you have a text file, a writer document, a presentation, and you want to use the devisons there, no CSS
file is ever looked up. You are left with pure codes. This is why it is desirable to have codepoints not change (what I call codepoint guarantee or codepoint stability). Of course they might change from time to time (on major upgrades), but that should be very very seldom and deliberate, because it breaks existing documents.
As there are ways to enter the code 41
(just hit the keyboard key labeled A
(with shift), IF you do not have a Greek or Cyrillic keyboard that is), there are also ways to enter devicons-openal-plain
- IF it has a stable codepoint. With Linux you can type ctrl
-shift
-u
\<code> enter
. On Windows I remember something with holding alt
and typing on the digits block?
Here an example CSS
file, you see the code is inserted as 'letter' directly, linking it with a symbolic name:
For the way to ensure constant codepoints, that of course depends on how your whole workflow is, and that can be more or less complex. I personally (for my projects) prefer a very obvious way, so that other maintainers, even first timers will be pushed with their noses to the solution. At Nerd Fonts it is a special plain text file that just does that: Map codepoints to actual outlines and add symbolic IDs to it: https://github.com/ryanoasis/nerd-fonts/blob/master/src/svgs/icons.tsv The system used here allows multiple IDs to point to the same outline / codepoint. It is encoded in teh font only once. The aformentioned Font-Logos does not support that (i.e. aliases). You might want to consider if you need aliases or not.
@Finii Thanks for the added info, and sorry for the super late response!
I think we can use the same approach that you used with a file indicating which icon belongs to which codepoint.
Something as simple as this should do for our project, since the folders and names can be derived from the filenames. Aliases can be gathered from the aliases object in devicon.json
.
# Codepoint: filename
0: "svelte-original"
1: "typescript-plain"
2: "typescript-original"
3: "svelte-plain"
Then we can use the yaml file above when generating the font with Icomoon.
I think we have enough to get started now. I hope to see codepoints added soon, but we have some other features that take priority atm, so might not be until next year.
Thank you for all your help @Finii!
Edit: Come to think of it, the new file can even be automatically updated when a new PR is merged, so no extra stuff to add for new contributors! Now I might just have to implement this before the new year!
Closed because moved to https://github.com/ryanoasis/nerd-fonts/discussions/1095
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.
Started actively working on this one. See draft PR mentioned above.
Dear @Snailedlt
I am about to add / switch over to your devicons :tada:
Looked at the repo and the recent (v2.16.0
) release font, and it seems that all icons are just added alphabetically on consecutive codepoints. That of course means that any addition will shift the codepoints of the later icons by one (or more).
That again is the topic codepoint guarantee. I believe you wrote above somewhere you would rather like to introduce the codepoint assignment on your side - albeit you are tailored to web usage where codepoints do not really matter at all.
I would suggest that you leave your repo and font creation as it is; and I introduce the (fixed) codepoints on our side. This has two pros for me:
If you (ever) drop icons the free slots (codepoints) will be reused by newly added icons. Other new icons will be added behind the existing ones. We will have a mapping (codepoint to your svg filename) here and create an intermediate font that will then be used by Nerd Fonts to patch fonts. That mapping will be automatically updated when devicon updates are (manually) pulled here.
What do you think? More details while work progresses can be seen in the linked PR (#1691).
From all the icon variants I would just pull one (1) per directory, here is a snipped from my yesterday's code.
That script ran in your icons/
directory to collect while svgs could be used. See how it prefers non-wordmark over wordmark and plain over original ;)
for d in $(find ${folder} -mindepth 1 -maxdepth 1 -type d | sort); do
candidate=$(find "${d}" -name "*plain.svg" -print)
if [ -z "${candidate}" ]; then
candidate=$(find "${d}" -name "*original.svg" -print)
fi
if [ -z "${candidate}" ]; then
candidate=$(find "${d}" -name "*plain-wordmark.svg" -print)
fi
if [ -z "${candidate}" ]; then
candidate=$(find "${d}" -name "*original-wordmark.svg" -print)
fi
if [ -z "${candidate}" ]; then
echo "NO HOPE for ${d}"
exit 1
fi
This will for example reduce these 4 icons to just one, the one that makes most sense in a terminal environment:
@Finii Thanks for reaching out again, this sounds good to me! We've had trouble finding active maintainers for the devicons project, so we've had enough work just reviewing PR's and adding new icons, which is why codepoint guarantee and other features haven't been a priority. Adding it on your end now that I think about it would actually be preferred. We haven't heard of any other icon sets needing codepoint guarantee from us, so keeping it less complex is better for us, especially now that we have too few active maintainers. I think preferring the non-wordmark versions is a good choice. Like you said wordmark versions aren't very useful for terminal users unless there's no non-wordmark version available.
Let me know if you have any questions, or if I can help with anything else :)
I'm pretty sure this is fine for the other maintainers of devicons too, but I'll just tag them here in case they have any input :)
@lunatic-fox @Panquesito7 @canaleal @weh @conX take a look at finii's last suggestion, and see if you have any input :)
At the moment nerd-fonts seems to be based off of vorillaz/devicons. As it is what is linked everywhere on the website as well as here on GitHub. This repository is heavily outdated and unmaintained. The last commit was in 2017 and the last official release in 2015. The devicons.ttf in this repo has also last seen a change in 2016.
Since then a lot of new projects came to life and new popular icons got added, that are not supported on there now. However there appears to be a fork of that repository, that actually still has regular updates. It also has about a third more GitHub stars in case that is any indicator of popularity.
Now this project may already somehow be used inside of nerdfonts. I can actually find the
nf-dev-ruby_on_rails (e73b)
icon on the cheatsheet which seems to be part of a commit from this April.However if this already is the case at least the links and documentation in this project should be updated to reflect this. As it may be confusing for people (like me) to figure out where to go to propose an icon that they would want to see inside of nerdfonts.