Snow Leopard’s new monospaced font

Update 10/31/09
I have a more complete comparison of Menlo and Vera Sans Mono here.

You may have heard that Snow Leopard (OS X 10.6) will be shipping with a “new” monospaced font called Menlo. I’ve put “new” in quotes because Menlo is based on Bitstream Vera Sans Mono, a free font released several years ago in coordination with the Gnome Foundation. Since I’ve been using Vera Sans Mono—or DejaVu Mono, basically the same font, but with more glyphs—as my text editing font for years, I found the news of Menlo interesting and wondered how it would differ from Vera Sans Mono.

The answer is found in a comment by Jesse Burgheimer on the Typophile page.

This image is somewhat reduced; go to the Typophile page to see it full-sized.

Before moving on to discuss the particulars of Menlo, I want to say how nice this comparison graphic is. The information is presented so clearly, no additional explanation is needed.

The major differences between Menlo and DejaVu are:

  1. Menlo’s zero has a diagonal slash instead of a dot in the center.
  2. Menlo’s asterisk is lower and larger.
  3. Menlo’s hyphen is longer, about the same width as the plus sign.
  4. Several of Menlo’s punctuation marks—the period and comma in particular—are larger.

I’m not sure I like the third difference; I’ll have to see what the n-dash and m-dash look like. The example seems to be restricted to the ASCII character set. DejaVu’s hyphen, n-dash, and m-dash look like this (at 64-point size)

I’ve always wondered why the n- and m-dashes are the same length—there’s certainly room between the hyphen and the m-dash to fit a distinct n-dash. In any event, Menlo’s hyphen is so wide, there isn’t any room to distinguish it from the dashes. I hope Apple changes that before Snow Leopard’s release.

The Ars Technica article says something I find hard to believe: Snow Leopard will not include the monospaced Monaco font. Longtime Mac developers have been using Monaco since the Mac came out—it was one of the original Mac fonts. The idea of buying a Mac that doesn’t have Monaco on it is probably inconceivable to them. But then, we’ve lost Chicago, New York, and most of the other World Class Cities, too. I’ll bet Monaco lovers are making backups right now.

Update 6/15/09
John Gruber says the Ars Technica article is wrong about Snow Leopard dropping Monaco. Monaco will be in Snow Leopard, it just won’t be the default font in Xcode. That makes more sense.

Further update 6/15/09
Via Gruber, this post by Jon Shea has some nice GIF animations showing the same chunk of text in Vera Sans Mono, Menlo, and Panic Sans, the Vera Sans variant that ships with Coda. To me, the biggest differences are in the asterisk and the underscore. I hadn’t given much thought to the underscore; as a CamelCase devotee, I don’t use underscores very often.

When Shea says

You can see that a lot of characters (“M”, “N”, “l”, “#”, and all the punctuation) look way too light and blurry in Vera Sans Mono, but look great in Menlo. The just look at how blurry that octothorp is in Vera Sans.

I have to disagree. The hash (OK, octothorp) looks almost exactly the same in the two fonts. I prefer the N in Menlo because it’s wider, but it’s not blurry in Vera Sans. Neither is the M or the l.

Some of Shea’s commenters really don’t like Menlo’s lower and larger asterisk. I can see it both ways. If you use monospace fonts mostly for writing code, the asterisk will be your multiplication and pointer character and a lower asterisk is probably preferable. If you use monospace fonts for writing regular text—as I’m doing now—you may want the asterisk in its normal, slightly raised position. Even though I do more text writing than coding, I think the lower asterisk is a good idea; even when writing regular text I almost never use the asterisk as a footnote marker, which is where the raised position comes in handy.

One last thing: I’m getting a sense that Mac users are coalescing around the notion that Menlo is a version of Vera Sans Mono that Apple “fixed.” That idea smells of fanboyism. I’ve been using Vera Sans Mono since it was released. It was—after my own data—the first thing I brought over to the Mac when I switched from Linux. I’ve always had the Terminal use Vera Sans (or DejaVu); same with Mail, BBEdit and, later, TextMate. In short, Vera Sans Mono is a great font and always has been. That’s why Apple chose it as the basis for Menlo. To the extent that Apple has made any improvements, they are marginal at best.

Tags:


2 Responses to “Snow Leopard’s new monospaced font”

  1. Mecki says:

    Actually I think it is correct to say that Apple fixed Vera Sans. You may argue about some letters or the position of the asterisk… but there are some problems Vera Sans has on Mac and yes, I say on Mac, because it does not necessary has those problems on Linux or Windows. Keep in mind that each OS has an own Font Render Engine. Actually there are four major Font Render Engines in the wild: The one from Apple (used in OS X), the one from Microsoft (used in Windows), the one from X11 (used in Linux and various UNIX systems), and the one from Sun (used in Java - yes, Java has an own Font Render Engine, it is not using the one of the system, exactly for that reason: Each system has a different one and the same font will not look alike on different systems otherwise). Of course each system has a different version of that engine, making things even more complicated. There are some letters in Vera Sans that just don’t look right because they get way too soft when anti-aliased. Often when fonts look just right on one platform, they look somewhat ugly on other platforms, because some line is one pixel (or half pixel) too high or too low or too far left/right. This is exactly what Apple has fixed. Look at the equal sign! Compare the one of Menlo (both lines are strong) with the one of Sans Vera (the lower one is strong, the upper one is very soft, anti-aliased way too much). This is exactly what Apple has fixed. Further I agree with Apple that a zero should have a slash (not just a dot) and that a minus should be as big as a plus sign (the minus of Vera Sans looks like there is already a space, Vera Sans 2-3 looks like 2 - 3, because the minus is way too small).

    Apple has not re-created a font here, Apple took an existing one, looked how well it performed on the Mac Font Render Engine and fixed whatever they did not like about it and I think they did a great job, because they fixed almost all glitches of Vera Sans… except one! Two underscores and three underscores can hardly be distinguished, because they have no spaces between them. A programmer/console font should have tiny spaces between them. Why? First of all, some programmers use underscores in variable names (I do for constants in C/Obj-C, that I write all upper case, THIS_IS_A_CONSTANT, thisIsAVaribale) and second of all, if you write C/Obj-C, you sometimes need to use compiler directives in your code, and those start with two underscore, use just one or three and it may take for ever to find out why your code does not work as expected. So you should be able to count underscores without moving you cursor into that line and count by pressing left/right key.

  2. Dr. Drang says:

    Your point about Apple improving the rendering on the Mac is well taken; that’s something I didn’t consider when writing the post. I must say, though, that’s not what other people meant when they said Apple was “fixing” Vera Sans Mono. They meant the significant changes like the asterisk, the zero, and the hyphen.

    Whether the zero is better when dotted or slashed is a matter of taste, and I won’t argue with you—our tastes on the matter differ and no amount of arguing will change that. I do want to defend my preference for the shorter hyphen, though. I spend more time writing text than I do writing code, and distinguishing between the hyphen and the dashes is important; the longer hyphen makes that more difficult. This is a functional problem, just like your (legitimate) complaint about the run-together underscores. Having the hyphen the same width as the plus sign, while in some ways desirable, should be secondary to having unambiguous symbols.