CSS3’s fonts module contains @font-face, an easy-to-use mechanism for using custom fonts on web pages. It’s ready to use in all major browsers, except for their differences in font file format support. Linking directly to OpenType or TrueType fonts in your @font-face rules only works in non-IE browsers. You have to serve Microsoft’s proprietary EOT format to IE.

Microsoft provides a tool called WEFT for creating such files. While WEFT might be sufficient for many users, Windows plays no role in my web development toolchain (with the exception of VMs for IE testing, of course). And, frankly, I’ve found WEFT’s GUI to be confusing and unusable. I need to be able to create EOT files under sensible operating systems like, say, FreeBSD.

If you have TrueType (.ttf) files for your desired font, you can use ttf2eot—a simple command-line tool, whose code was extracted from Google Chrome—to generate EOT files. Kudos to Truex for alerting me to this tool. A simple make in the ttf2eot directory will generate the ttf2eot executable, which can be used like so:

$ ttf2eot < Foo.ttf > Foo.eot

Things are a bit more complicated if you have OpenType (.otf), not TrueType files. You’ll first have to convert them to TrueType. Fortunately, FontForge can do this. On FreeBSD, this is a simple install from ports:

$ cd /usr/ports/print/fontforge ; sudo make install clean

On Mac OS X, you can install it from MacPorts like so (or at least you will be able to, when bug #20085 is fixed):

$ sudo port install fontforge

Once you’ve got FontForge installed, create the following script (happily borrowed from the FontForge Scripting Tutorial). Call it convert.pe, make it executable, and drop it in your PATH somewhere.

#!/usr/bin/env fontforge
Open($1)
Generate($1:r + ".ttf")

Now, to create Foo.ttf, you should be able to run the following command:

$ convert.pe Foo.otf

You can automate all of the above steps with GNU Make like so:

%.eot: %.ttf
	ttf2eot < $< > $@

%.ttf: %.otf
	convert.pe $<

You’re now equipped to use any font (whose license permits embedding with @font-face) on your website, in an automated fashion, in all major browsers.

Well, that’s slightly overstating it. There’s a catch. Actually, there are two catches. As describd in beautiful fonts with @font-face, Internet Explorer only recognizes the font-family and src descriptors within @font-face rules, so each family can only contain a single face. So you won’t be able to simultaneously use the regular, bold, and italic variants of the same face on the same page, like you can with WEFT. Also, you can’t just put a url(foo.eot) rule in your existing src setting. It doesn’t understand format() hints and will ignore any @font-face rule containing these hints. (Emphasis mine.) You have to use a separate @font-face rule for IE. At the end of the day, your CSS will look something like this:

/* For IE */

@font-face {
  font-family: "Foo";
  src: url(Foo.eot);
}

/* Other browsers */

@font-face {
  font-family: "Foo";
  src: local('Foo'),
       url(Foo.otf) format("opentype");
}

@font-face {
  font-family: "Foo";
  src: local('Foo Bold'),
       url(FooBold.otf) format("opentype");
  font-weight: bold;
}

@font-face {
  font-family: "Foo";
  src: local('Foo Italic'),
       url(FooItalic.otf) format("opentype");
  font-style: italic;
}

@font-face {
  font-family: "Foo";
  src: local('Foo Bold Italic'),
       url(FooBoldItalic.otf) format("opentype");
  font-weight: bold;
  font-style: italic;
}

View Answers

$10
1 (6.2%)

$25
3 (18.8%)

$50
2 (12.5%)

$100
7 (43.8%)

$200 or more
3 (18.8%)

View Answers

Nothing - just max props for winning and a trophy
2 (11.8%)

10% - one decent prize for the winner
3 (17.6%)

25% - decent prizes for top few places
9 (52.9%)

50% - closer to a normal payout structure, although of course less places and smaller prizes
3 (17.6%)

Somebody emailed me the other day, asking about how to go about learning Emacs. This is my (edited and rearranged) reply.

I know you’re something of an emacs wizard, so I thought I might as well ask you: how should I learn emacs? … I’ve used emacs for several years now but have not added very much emacs skill to my repertoire.

Well, the short answer is, you should learn Emacs by using it for about a decade. That’s a pretty lame non-answer, so let me try to elaborate.

I started using Emacs in the fall of 1997, as a freshman in college. For at least the first year or so of using Emacs, my Emacs repertoire probably consisted of tens of key bindings (not counting the myriad bindings of self-insert-command, of course), and only a handfull of major modes (c-mode, java-mode, makefile-mode, that might be about it). So basically, for at least a year, my use of Emacs didn’t differ substantially from the average user of, say, Notepad.

I distinctly remember a moment during my sophomore year, while in a professor’s office talking about some assignment or some such, being amazed by some crazy magic he worked in an Emacs buffer, making seemingly very complex edits in a dizzyingly short amount of time. I remember asking what the hell he had just done. He had a good laugh—at this point, I was known among other students as “the Emacs guy,” and yet I didn’t even know how to record or use keyboard macros. This was pretty embarrassing.

I’ve continued to use Emacs this whole time, and it turns out that I’ve learned a lot about it since then. I continue to learn about it every day. The thing is, this isn’t even about Emacs specifically. It takes about ten years of such practice to learn anything well. From Norvig (emphasis his):

Researchers (Bloom (1985), Bryan & Harter (1899), Hayes (1989), Simmon & Chase (1973)) have shown it takes about ten years to develop expertise in any of a wide variety of areas, including chess playing, music composition, telegraph operation, painting, piano playing, swimming, tennis, and research in neuropsychology and topology. The key is deliberative practice: not just doing it again and again, but challenging yourself with a task that is just beyond your current ability, trying it, analyzing your performance while and after doing it, and correcting any mistakes. Then repeat. And repeat again. There appear to be no real shortcuts: even Mozart, who was a musical prodigy at age 4, took 13 more years before he began to produce world-class music. In another genre, the Beatles seemed to burst onto the scene with a string of #1 hits and an appearance on the Ed Sullivan show in 1964. But they had been playing small clubs in Liverpool and Hamburg since 1957, and while they had mass appeal early on, their first great critical success, Sgt. Peppers, was released in 1967.

So how do you get from where you are to using Emacs so much you spend your spare time hacking on various Emacs libraries for fun? Mostly by making a point of using Emacs for all of your editing needs, and allowing Emacs to slowly take over your other computings tasks as well.

For instance, the big application that people typically expand their Emacs-fu with is using Emacs to read mail (see also Zawinski’s Law of Software Envelopment). I recommend trying Gnus. The several weeks you waste trying to figure out how to point Gnus at your mail server more than pays for itself by the amount you learn while driving yourself mad.

Emacs is called “the extensible, customizable, self-documenting real-time display editor.” I want to draw your attention to the self-documenting part. Perhaps the most critical Emacs skills to develop early on is how to navigate and interrogate Emacs’ help features, which are extensive. Type C-h C-h to get started down that path.

(related: what is the best tutorial/book on emacs lisp?)

IIRC I learned elisp via a combination of bumbling, Usenet, and Glickstein but, honestly, I think the elisp manual & tutorial (combined with the Emacs manual itself) are much better than muddling through like I did. (Though, if you’d like, you can borrow my ancient and increasingly-inaccurate copy of Glickstein.)

• You can get to the elisp tutorial within emacs by typing the following: C-h i d m emacs lisp intro RET
• You can get to the elisp manual within Emacs by typing the following: C-h i d m elisp RET
• You can get to the Emacs manual within Emacs by typing the following: C-h i d m emacs RET

Here’s a breakdown of the above commands so you know what each part is about:

C-h i

brings up the Emacs interface to Info, the GNU documentation system

d

goes to the Info root menu (in case you were already somewhere else in Info)

m emacs RET

opens the Info menu item named emacs

For real-time help from friendly experts, try the #emacs IRC channel on Freenode. Eventually, you might try IRCing from within Emacs; there are several IRC clients, including two which ship with Emacs itself.

In his latest blog post, Shane McCarron managed to illustrate the disconnect about what the Web is and isn't better than I've ever been able to (emphasis his, importance mine):

What's the problem? The organization with the primary responsibility for taking the web forward has two competing sets of activities. There's the browser-centric work - this includes HTML5, CSS, and the Rich Web Client Activity (HTML DOM stuff, Widgets, XMLHTTPRequest etc.). Then there's the web-centric work - this includes XML, XPath, Xinclude, XML Schema, RDF, OWL, etc. And while these sets of activities could be designed to dovetail together, the browser-centric work seems to be ignoring the rest of the work.

The worldview that allows Shane to paint XML, XPath, Xinclude, XML Schema, RDF, OWL, etc. as web-centric work whilst claiming HTML5, CSS, … HTML DOM stuff, Widgets, XMLHTTPRequest etc. to be merely browser-centric—that, right there, in plain language, is the gap between the imaginary Web of some people's fancy and the actual Web that is used every day by millions of people.