Font Reaper dismantles an icon font, such as Font Awesome, and builds a syntactically similar alternative. It uses svgpath to flip, center, and align glyphs. I wrote it under Node 4, but it should hopefully be a bit version agnostic.
To use, after downloading/cloning and npm install, run:
node reaper.js css/someiconfont.css
The result will get stored in the /out directory. The files currently there are the result of running this on Font Awesome.
This is a quick and dirty program, made out of a need to break up Font Awesome and fall back to something other than raster images or sprites. It does not have any business being a part of any build or deployment script. The expectation is that you will want to modify the files this script generates to suit your needs, and likely the script itself as well.
A proper solution would be to fix the problems with grunticon or something similar, and build from raw svg files accordingly.
All class names and aliases from the icon font are preserved. You can use this as
<i class="icon icon-whatever"><s class="screenreader-only">descriptive text goes here</s></i>, much like you do with icon fonts.
I have included Font Awesome and the resulting output as an example.
Seren Davies did a talk, Death to Icon Fonts, where she discusses her trouble with them as a person with dyslexia, and other issues with said fonts. My forums have a lot of members with dyslexia, and other members with a great variety of accessibility challenges besides.
Of course, the ideal solution is that user fonts should not clobber glyphs they don't have. There are certainly better font replacers available.
It would also be ideal that some of my forums' membership was not still chained to IE7. Yes, I have to write that sentence with all seriousness in 2016. Fortunately my visually impaired members are not so chained, or I would be a bit stumped.
Old browsers aside, SVGs as background or content properties just work, in the exact same manner, across a wide variety of environments and usages. There are a lot of little issues that make font-based solutions a less than optimal choice.
background.css vs content.css
Font Reaper takes an icon font's css file, tries to read the svg file it specifies (place your fonts in the appropriate relative directory specified in said css), then builds a pair of .css files with the svg glyphs embedded as data uris.
out-background.css implements this in a background-image property. This is the most robust solution, however, Opera Mini has a bug in its implementation of the cover an contain options for background-size. Hopefully this bug will get fixed soon.
out-content.css implements this in a content property in ::before. This functions properly in Opera Mini, however, it is a bit less forgiving about what you do with it. Font Reaper auto-squares glyphs specifically so this trick behaves relatively cleanly. Be careful with this trick if you are not using square glyphs.
Unfortunately, you cannot style the result normally. You have to either use css filters (not supported by IE or Opera Mini) and/or alter the script to embed your desired fill/stroke colors into the path elements.
The IE7 and IE8 Fallbacks
Will hopefully not be needed for long. My IE7 and IE8 users are fully aware of their predicament and do not expect things to be flawless. They pray for an end to their nightmare; meanwhile, a shoddy fallback is better than nothing.
IE7 is IE7. If you need this I assume you are familiar with triggering hasLayout, expressions, yadda yadda. It implements this hack by steveush. It works even more reliably than the IE8 hack does.
You will notice a script in the generated test.html for IE8. It is based on ausi's answer to this Stackoverflow question, with some cleaning and an added delay. A delay of 0 has about a 50/50 chance of working in my experience, and does not seem to be much faster visually. It can additionally help to ensure that you are setting expiration headers for .eot files on your webserver.
IE8 has some serious issues trying to render a lot of different icons in pseudo-elements.
Making fallbacks for other old browsers
I count my blessings that none of my membership requires this.
Some notes about svg fragments
Since this script squares and normalizes each glyph to the same viewbox, making a composite svg with fragments would be easy.
Support appears to be spotty, however. If I find out Safari actually handles these properly, I will update the script accordingly.
If you are going to use fragment identifiers anyway, please remember that screen readers do not read inside svg files.
I saw a tutorial that did just this, and I have seen large, production sites following their advice.
It does not work.
While JAWS may be out of your price range, NVDA is certainly affordable for you, and I highly recommend it.
Final usage notes
This script can easily generate massive .css files, about 50-60% bigger than the svg file they originate from, which are already several times bigger than other font formats.
You should pick out the most important glyphs, along with the core icon classes, and put these into your main .css file in your <head>, for your above-the-fold / first 100ms content.
The rest of the icons you need should be in a separate stylesheet, loaded at the end of <body>.
The icons you do not need should not be loaded at all.
Automated, lossless, SVG optimization.
This should reduce your outputted CSS file dramatically.
You should also probably mention the gzip sizes as well.
out-content.cssis 483KB, but with maximum gzip compression it's 110KB, and even with minimal gzip compression it's 123KB. That's 75-78% reduction because there's so much repetition in an SVG spritesheet file. That reduction will likely go down once those SVG's are better optimized, but the end filesizes will go down as well, which is the more important part.
Vertical centering of output svg
Hi, some of the svgs that are being generated need a bit of manual tweaking. Can you recommend the best way of doing this? I've tried to use illustrator but the paths that are output from illustrator after saving are much more verbose and are displayed very small when I update my LESS variables with them.
For reference, I have created a LESS mixin which accepts a path argument, and I am using that to output my svgs in my css. This isn't really related to the problem though, It's just to provide some context.
My problem is that some of the font awesome svgs that are output are not rendering vertically centered for me. Here's an example with red background to illustrate the problem. I'm using the same CSS that you've got in your example folders to render these.