I just went through a process of @font-facing a website for one of my projects and I have several things to add:
1. Don't bother with direct font editing. Instead use a vector editor like Inkscape  to save your icons as SVG and then convert them to a complete font-face kit with IcoMoon .
2. IcoMoon will also let you cherry pick icons from a large number of both free and commercial icon packs. This is a great starting point, especially at the sketching phase.
3. A better way to browse icon packs though is with Fontello . Same packs, snappier interface.
4. FontSquirrel font-kit generator is really good, because it does a great job (re-)hinting TTFs so that they come out looking better in smaller sizes (10-14px)
-- but --
There are fonts that FontSquirrel generator doesn't process correctly. It would happily spit out an @font-face kit, which will look normal most of the time. However on selected Windows boxes the font will render without anti-aliasing, naturally making it look like butt. It doesn't appear to depend on the Windows version (saw it happen on XP and W7) nor the browser (saw it on IE and Firefox). Also, same machines will render all other font-face kits just fine. I spent a couple of days chasing the cause, but then gave up because I found a simple workaround.
The workaround is to serve OTFs. Instead of specifying .eot, .woff, .ttd, .svg in your CSS, list .eot, .otf, .woff, .ttf, .svg. OpenType files are generally heavier, but they also compress better, so it's a wash in terms of a I/O hit if served over gzip'd HTTP.
In other words -
| Make sure to test the hell |
| out of your font-face kits |
To that effect, Adobe Browser Lab  includes a version of Firefox that exhibits above behavior. However, the Lab also includes a version of Chrome that pixelates all fonts, because it appears to run on a machine with anti-aliasing disabled at the OS level (yes, it doesn't make any sense, must be some sort of an inside Adobe joke).
So, the testing strategy is to get a proven font-face kit, like Open Sans, and check that both your font and this litmus font render well. If both look aliased, then it's the OS issue. If only yours does, then it's a problem with the font-face kit.
Awesome. This approach can definitely work for lots of people. We default to WOFF because it's essentially just a slightly more compressed OTF file, it's something all browser venders seem to agree on, and it just seems like The Right Thing To Do for the web. We serve raw TTF files for the stock Android Browser. I had so much trouble hinting the raw OTF font for Chrome on Windows that I gave up and used SVG. As I mentioned in the article, SVG fonts don't get mangled by the browser's font rendering engine or ClearType.
WOFF is a result of font foundries and online font services pressuring W3C to produce a browser-only font format. Something that cannot be save-as'd and dragged into the C:\Windows\Fonts. It is indeed somewhat optimized for the web use, but that wasn't the primary design goal behind it.
Ah, well copy protection is definitely not a concern for us, since we serve the raw TTF alongside the other formats. The fact that the WOFF file was about 30% smaller than the TTF was more of a deciding factor.
If you have the icons as svg you could also try raphaeljs . It'll render the svg path as svg on most modern browsers and as vml on older IE browsers (ie6+). The added benefit is that raphael also does animations which enables you to animate your icons on browsers that don't support css3 animation.