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

Distributing work of adding icons via PR? #109

Open
jonathan-g opened this issue Jul 24, 2019 · 2 comments · May be fixed by #158
Open

Distributing work of adding icons via PR? #109

jonathan-g opened this issue Jul 24, 2019 · 2 comments · May be fixed by #158

Comments

@jonathan-g
Copy link

Right now, the process for adding new icons is to create an issue and submit an SVG of the requested glyph and wait to see whether @jpswalsh wants to add it when he has time in his busy life.

Is there a way this project could be adapted to allow users to do more of the work ourselves: convert the SVG into the appropriate format to add to the .eot, .ttf, .svg, and .woff font files, and then submit a PR, as opposed to needing one person to do all the work alone?

For instance, I'd be willing to do work to speed up adding the SSRN logo (#42) and The Conversation (#56) to academicicons if there were a clear process for doing so.

Part of the challenge is that git is not good at merging different versions of binary files like academicicons.ttf, so a process like this would only work well if there were a toolchain to automate building the main font files (academicicons.ttf, .eot, .svg, and .woff) from .svg files for the individual glyphs (or from a master .svg for the whole font, since that's a textual XML-based format), and adapting this project to that way of working might be a lot more trouble than it's worth.

@jpswalsh
Copy link
Owner

I agree 100% with this suggestion, and have reached the same conclusion myself. However, I don't know how to go down that path. If there were some automated way to do the multiple steps I go through in the IcoMoon online tool, with only a folder of SVGs as input, then there wouldn't be the bottleneck that there is now.

Having said that, I think there's an argument to be made that we can move away from the font file approach entirely, which is actually a bit of a hack. I'd much rather Academicons became first and foremost a curated library of text-based vector icons, where the output is free to change with the trends of the web design world. There has been talk for a couple of years on the merits of using the .svg format for icons rather than font files. I'd be happy to support any work in this direction.

@Bertbk
Copy link

Bertbk commented Sep 12, 2019

I also totally agree. I would also love to help but I'm clearly not expert in "icon process". Have a few questions, though:

  1. Wouldn't fontello and it's API be a usefull friend for us? They provide ready to use Makefile. Users would thus "only" have to add their SVG to the JSON config file, which is git-friendly and we could build a CI / Test. I tried it locally with a single homemade svg-icon (HAL, issue Icon Request: HAL #99 ) and it worked like a charm...

  2. @jpswalsh Could you please elaborate about keeping only .svg file and leaving the font files away? In particular, would that breaks the CTAN LaTeX package you provide?

Thanks

Edit : Maybe, a good idea would be to merge academics icon into ForkAwesome?
Moreover, it seems to be simple to do a PR in their project, see for example this one

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants