Closed AtomToast closed 1 year ago
hpfr
commented
2 years 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.
ryanoasis
commented
2 years ago also related #233
Theo-Steiner
commented
2 years ago 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
AtomToast
commented
2 years ago 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
Finii
commented
2 years ago Also mentions file-icons: #342
jalaziz
commented
2 years ago 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).
Snailedlt
commented
1 year ago 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 :)
Finii
commented
1 year ago 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
Snailedlt
commented
1 year ago 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!
Finii
commented
1 year ago 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.
Snailedlt
commented
1 year ago @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!
Finii
commented
1 year ago Closed because moved to https://github.com/ryanoasis/nerd-fonts/discussions/1095
github-actions[bot]
commented
10 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.
Finii
commented
1 week ago Started actively working on this one. See draft PR mentioned above.
Finii
commented
1 week ago 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
fiThis will for example reduce these 4 icons to just one, the one that makes most sense in a terminal environment:
Snailedlt
commented
1 week ago @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.