Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Switch to the popular, maintained devicons/devicons repo from unmaintained vorillaz/devicons #615

Closed
AtomToast opened this issue May 1, 2021 · 16 comments · Fixed by #1691
Labels
keep_unlocked Allow discuissions for extended time even after closing { ; } update glyph set
Milestone

Comments

@AtomToast
Copy link

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.

@hpfr
Copy link

hpfr commented Nov 28, 2021

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 ryanoasis added this to the v3.0.0 milestone Dec 14, 2021
@ryanoasis
Copy link
Owner

also related #233

@Theo-Steiner
Copy link

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
Copy link
Author

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
Copy link
Collaborator

Finii commented Apr 26, 2022

Also mentions file-icons: #342

@jalaziz
Copy link

jalaziz commented Jun 20, 2022

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).

@Finii Finii mentioned this issue Aug 29, 2022
3 tasks
@Snailedlt
Copy link

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:

  1. Replace the old devicon fonts with the new one?
  2. Add devicons/devicon to the same set as the current devicons icon set
  3. Add devicons/devicon as a new icon set called devicons and rename the current Devicon set as old devicons.
  4. Add 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
Copy link
Collaborator

Finii commented Oct 4, 2022

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

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 😬 (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
Copy link

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.
image

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

Click here to see the selection.json file!
{
  "IcoMoonType": "selection",
  "icons": [
      {
          "icon": {
              "paths": [
                  "M929.96 594.44h24.488c13.533-0.041 24.488-11.021 24.488-24.56 0-0.017-0-0.034-0-0.051l0 0.003h32.656c0 31.712-25.584 57.384-57.144 57.384h-57.144v-175.848h32.656v143.072zM815.672 451.4c-31.592 0-57.176 25.672-57.176 57.384v118.464h32.752c-0.058-17.089-0.091-37.334-0.091-57.586 0-3.897 0.001-7.793 0.004-11.689l-0 0.603h49v68.672h32.752c-0.064 0-0.088-35.192-0.088-68.672v-49.792c0-31.712-25.584-57.384-57.144-57.384zM815.672 484.176c13.533 0.041 24.488 11.021 24.488 24.56 0 0.017-0 0.034-0 0.051l0-0.003v17.016h-49v-17.016c-0-0.014-0-0.031-0-0.048 0-13.55 10.973-24.537 24.518-24.56l0.002-0zM260.52 508.752v61.080c0 31.712-25.584 57.384-57.144 57.384-0.023 0-0.050 0-0.076 0-8.884 0-17.291-2.037-24.782-5.668l0.339 0.148v57.144h-32.656v-215.184s13.384 1.040 21.8 0c14.488-1.768 14.968-12.288 35.368-12.288 31.56 0 57.144 25.672 57.144 57.384zM227.864 508.752c0-0.014 0-0.031 0-0.048 0-13.539-10.955-24.519-24.484-24.56l-0.004-0c-13.547 0.023-24.52 11.010-24.52 24.56 0 0.017 0 0.034 0 0.051l-0-0.003v61.080c-0 0.014-0 0.031-0 0.048 0 13.55 10.973 24.537 24.518 24.56l0.002 0c13.533-0.041 24.488-11.021 24.488-24.56 0-0.017-0-0.034-0-0.051l0 0.003v-61.080zM126.688 508.752v61.080c0 31.712-25.584 57.384-57.144 57.384s-57.144-25.672-57.144-57.384v-61.080c0-31.712 25.584-57.384 57.144-57.384s57.144 25.672 57.144 57.384zM94.032 508.752c0-13.6-10.944-24.608-24.488-24.608-13.533 0.041-24.488 11.021-24.488 24.56 0 0.017 0 0.034 0 0.051l-0-0.003v61.080c-0 0.014-0 0.031-0 0.048 0 13.539 10.955 24.519 24.484 24.56l0.004 0c13.53-0.027 24.488-11.002 24.488-24.536 0-0.025-0-0.051-0-0.076l0 0.004v-61.080zM523.824 627.216h-32.752v-118.464c0-13.6-10.944-24.608-24.488-24.608-13.533 0.041-24.488 11.021-24.488 24.56 0 0.017 0 0.034 0 0.051l-0-0.003 0.088 118.464h-32.752v-118.464c0-31.712 25.584-57.384 57.144-57.384s57.144 25.672 57.144 57.384l0.088 118.464zM335.352 451.392c-31.56 0-57.144 25.672-57.144 57.384v61.048c0 31.712 25.584 57.416 57.144 57.416s57.176-25.704 57.176-57.416h-32.656c0 0.014 0 0.031 0 0.048 0 13.55-10.973 24.537-24.518 24.56l-0.002 0c-13.533-0.041-24.488-11.021-24.488-24.56 0-0.017 0-0.034 0-0.051l-0 0.003v-14.144h49v-32.776h-49v-14.12c-0-0.014-0-0.031-0-0.048 0-13.539 10.955-24.519 24.484-24.56l0.004-0c13.547 0.023 24.52 11.010 24.52 24.56 0 0.017-0 0.034-0 0.051l0-0.003h32.656c0-31.712-25.616-57.384-57.176-57.384zM640.128 242.336c-31.56 0-57.144 25.704-57.144 57.384v151.672h-12.224v12.256h12.224v163.928c0 31.712 25.584 57.384 57.144 57.384s57.144-25.672 57.144-57.384v-163.92h12.288v-12.256h-12.288v-151.672c0-31.68-25.584-57.384-57.144-57.384zM640.128 268.984v182.408h-34.704v-147.584c-0-0.017-0-0.036-0-0.056 0-19.179 15.53-34.732 34.701-34.768l0.003-0zM554.416 291.488l-72.816 1.528 59.824 39.248 1.312-0.424v0.64zM542.736 332.472l-0.152 0.552-1.16-0.76-68.272 21.16 68.272 21.224 1.16-0.76 0.152 0.52zM542.736 374.4v0.672l-1.312-0.424-59.824 39.248 72.816 1.496zM725.848 291.488l11.736 41.016v-0.672l1.312 0.424 59.768-39.248zM738.896 332.256l-1.16 0.76-0.152-0.52v41.904l0.152-0.52 1.16 0.76 68.216-21.224zM738.896 374.64l-1.312 0.424v-0.664l-11.736 40.984 72.816-1.496zM622.808 332.496c-6.768 0-12.288 5.488-12.288 12.288-0 0-0 0-0 0 0 6.793 5.498 12.302 12.286 12.32l0.002 0c6.768 0 12.224-5.52 12.224-12.32 0-0.014 0-0.031 0-0.048 0-6.754-5.471-12.231-12.223-12.24l-0.001-0zM657.512 332.496c6.736 0 12.224 5.488 12.224 12.288s-5.488 12.32-12.224 12.32c-6.79-0.018-12.288-5.527-12.288-12.32 0-0 0-0 0-0l-0 0c0-6.8 5.52-12.288 12.288-12.288zM622.808 365.272c-6.768 0-12.288 5.488-12.288 12.288-0 0-0 0-0 0 0 6.793 5.498 12.302 12.286 12.32l0.002 0c6.768 0 12.224-5.52 12.224-12.32 0-0.014 0-0.031 0-0.048 0-6.754-5.471-12.231-12.223-12.24l-0.001-0zM657.512 365.272c6.736 0 12.224 5.488 12.224 12.288s-5.488 12.32-12.224 12.32c-6.79-0.018-12.288-5.527-12.288-12.32 0-0 0-0 0-0l-0 0c0-6.8 5.52-12.288 12.288-12.288zM622.808 398.080c-6.768 0-12.288 5.488-12.288 12.256 0.007 0.408 0.030 0.8 0.069 1.187l-0.005-0.059c0.601 6.289 5.835 11.175 12.219 11.224l0.005 0c6.37-0.013 11.596-4.889 12.164-11.112l0.004-0.048v-0.064c0.035-0.33 0.058-0.722 0.064-1.118l0-0.010c0-0.005 0-0.010 0-0.016 0-6.754-5.471-12.231-12.223-12.24l-0.001-0zM657.512 398.080c6.753 0.009 12.224 5.486 12.224 12.24 0 0.006-0 0.011-0 0.017l0-0.001c-0.007 0.408-0.030 0.8-0.069 1.187l0.005-0.059c-0.608 6.28-5.824 11.224-12.168 11.224-6.4 0-11.68-4.912-12.224-11.16v-0.064c-0.035-0.33-0.058-0.722-0.064-1.118l-0-0.010c0-6.768 5.52-12.256 12.288-12.256zM544.2 451.384v178.232c0 53.208 42.968 96.384 95.928 96.384s95.928-43.176 95.928-96.384v-178.224h-12.224v178.232c0 46.408-37.472 84.040-83.704 84.040s-83.64-37.624-83.64-84.040v-178.232zM640.128 463.64h34.704v122.672h-0.216l0.216 0.304v34.824l-0.456 5.584-34.24-40.704h34.488l-34.488-40.888h34.552l-34.552-40.92h34.64zM674.368 627.048c-1.399 8.615-5.803 16.013-12.080 21.234l-0.056 0.046-22.104-21.128zM589.144 748.848v32.808h102.032v-32.808zM589.144 748.848z"
              ],
              "attrs": [],
              "isMulticolor": false,
              "isMulticolor2": false,
              "colorPermutations": {},
              "tags": ["openal-plain"],
              "grid": 0
          },
          "attrs": [],
          "properties": {
              "order": 1002,
              "id": 0,
              "name": "openal-plain",
              "prevSize": 32,
              "code": 59659
          },
          "setIdx": 0,
          "setId": 4,
          "iconIdx": 0
      }
  ],
  "height": 1024,
  "metadata": { "name": "devicon" },
  "preferences": {
      "showGlyphs": true,
      "showQuickUse": true,
      "showQuickUse2": true,
      "showSVGs": false,
      "fontPref": {
          "prefix": "devicon-",
          "metadata": {
              "fontFamily": "devicon",
              "majorVersion": 1,
              "minorVersion": 0
          },
          "metrics": { "emSize": 1024, "baseline": 6.25, "whitespace": 50 },
          "showSelector": false,
          "showVersion": false,
          "resetPoint": 58880,
          "ie7": false,
          "embed": false,
          "autoHost": false
      },
      "imagePref": {
          "prefix": "icon-",
          "png": true,
          "useClassSelector": true,
          "color": 4473924,
          "bgColor": 16777215,
          "classSelector": ".icon",
          "height": 32,
          "columns": 16,
          "margin": 16,
          "name": "icomoon"
      },
      "historySize": 100,
      "showCodes": true,
      "gridSize": 16,
      "quickUsageToken": {
          "UntitledProject": "YzMyNDZjOWRjOGE4NTFiOTdiNTg3Mjk1ZjA5YTY3MDYjMSMxNjY0OTE3MzI0IyMjYzVmNzRhMWRlNTRk"
      }
  }
}

@Finii
Copy link
Collaborator

Finii commented Oct 5, 2022

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


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
Copy link

Snailedlt commented Nov 19, 2022

@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
Copy link
Collaborator

Finii commented May 5, 2023

Closed because moved to #1095

Copy link
Contributor

github-actions bot commented Nov 6, 2023

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.

@github-actions github-actions bot locked as resolved and limited conversation to collaborators Nov 6, 2023
@Finii Finii added the keep_unlocked Allow discuissions for extended time even after closing label Apr 18, 2024
Repository owner unlocked this conversation Apr 18, 2024
@Finii Finii mentioned this issue Aug 25, 2024
4 tasks
@Finii
Copy link
Collaborator

Finii commented Aug 25, 2024

Started actively working on this one. See draft PR mentioned above.

@Finii
Copy link
Collaborator

Finii commented Aug 25, 2024

Dear @Snailedlt

I am about to add / switch over to your devicons 🎉

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:

  • The existing vorillaz/devicons codepoints can be preserved for updated in devicons/devicon icons
  • Some icons since dropped in devicons/devicon can be preserved here (example: git branch / git commit)
  • We do not need to include all the wordmark icons as they are quite useless for terminal users

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).


Edit

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:

image

@Snailedlt
Copy link

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
keep_unlocked Allow discuissions for extended time even after closing { ; } update glyph set
Projects
None yet
Development

Successfully merging a pull request may close this issue.

7 participants