Adobe's Source Code Pro Font
opensourcehacker.com
opensourcehacker.com
Been using it in the recent years.
here's a preview of Inconsolata-g at high res (~100kB)
[1]: http://www.google.com/webfonts/specimen/Droid+Sans+Mono
I program in Python, C, C++ and Java. In all these languages I prefer a proportional font. However I had to stop, mainly because the editors I want to use (Sublime text 2 at the moment) don't support proportional fonts.
"font_face": "Verdana"
Though I may be missing something.The only mitigating factor would be that the spaces at the left margin all (presumably) have the same width.
One is names_with_underscores. In a monospaced font, the underscore is the same width as every other character. In a proportional font, the underscore is one of the widest of characters, and much wider than a space.
For example, in the font I'm coding in right now, an underscore is 13 pixels wide, a parenthesis is 8 pixels, and a space is only 5 pixels!
So what happens is that the underscore in a way gives more visual separation in an expression than spaces or other punctuation.
var foo_bar = some_function(one_param, another_param);
To some degree, my eyes group that code this way:var foo bar = some function(one param, another param);
My solution for this is simple: don't use names_with_underscores (except when language conventions require it, such as in Ruby), and do add spaces inside the parentheses:
var fooBar = someFunction( oneParam, anotherParam );
Why do the spaces go inside the parentheses and not outside? Well, you need a space in there somewhere, and this just doesn't work for me: var fooBar = someFunction (oneParam, anotherParam);
Nor this (with no space at all): var fooBar = someFunction(oneParam, anotherParam);
To me, the space belongs at the same place where I might put a line break if I had a too-long line. I would never break lines like this: var fooBar = someFunction
(oneParam,
anotherParam);
or like this: var fooBar = someFunction(oneParam,
anotherParam);
But I do break lines like this: var fooBar = someFunction(
oneParam,
anotherParam
);
This way the spacing goes in the same place regardless of whether it's a space or a linebreak.Recent example: http://www.michielovertoom.com/pictures/kwrite-textanalyse.p...
I really enjoy reading text in proportional fonts much more than monospaced. That's true for program code as much as any other text.
Like you, it doesn't bother me to lose vertical alignment. The only vertical alignment that matters to me in code is the indentation, and that works fine in proportional fonts. (The one exception being that the popular two-space indents are really lousy in a proportional font. So I prefer tabs, or if spaces are a requirement, four-space indents.)
In fact, some time before I started using proportional fonts, I'd already changed my coding style to avoid vertical alignment other than the left margin. I used to write code something like this:
function someFunction(aParam, // This is the the main thing
anotherParam, // This is another thing
aParamWithALongerName) { // Remind me what this is for
firstStep(); // Here is a description
secondStep(); // of these three statements
thirdStepSortOf(); // that go together
}
That kind of code is the very reason for coding in monospaced fonts, but why? It is a pain to maintain and keep the spacing right, and in this (fairly realistic) example I find it extremely unhelpful to have all that whitespace separating "aParam" with its comment.Instead, about ten years ago, I switched to a style more like this:
function someFunction(
aParam, // This is the the main thing
anotherParam, // This is another thing
aParamWithALongerName // Remind me what this is for
) {
// Here is a description of these three
// statements that go together
firstStep();
secondStep();
thirdStepSortOf();
}
Now it may not be as "pretty" to have those comments on the parameters not all lined up as they were before, but it's a heck of a lot easier to maintain, and to my eyes it's easier to read too. The comments about the parameters are not related to each other, they are related to the parameter that each one applies to. With this style I can read: aParam, // This is the the main thing
as pretty much a single unit, where the excessive whitespace in my previous style made it hard to match up each parameter with its comment.Having made this change, some time later I discovered that the version of Visual Studio I was using at the time supported proportional fonts, gave it a whirl, and like you, found I really liked it.
It is true that when I read other people's code who've used columnar alignment, the alignment doesn't work any more. But for the most part that just doesn't bother me. In the few cases where the alignment really makes a difference, I just switch to a monospaced font to read that file.
My favorite editor, Komodo IDE (or the free Komodo Edit), does a marvelous job of handling this. Like many editors, you can set up a customized theme of fonts and colors, but unlike any other editor I know of, each theme includes separate selections for a proportional font and a monospaced font. For some reason they don't provide a keyboard shortcut by default to switch between them, but I mapped Alt+O (on Windows) which is unused otherwise. I remember it by thinking "prOpOrtiOnal" and "mOnOspaced". :-) So I can switch between my favorite proportional and monospaced fonts easily, and it also remembers that setting for each file I've edited.
UltraEdit and UEStudio (Windows only) are not bad here either. They don't have an explicit way to select proportional vs. monospaced, but if you press Alt+C to go into column selection mode it switches to a monospaced font while in that mode. So that's a way to view a monospaced file. I wish more editors had this kind of flexibility.
Aligning crap like that is one of the indicators I use to tell if someone is an inexperienced coder. After you write enough LOC, you eventually realize that lining things up is a waste of time. You're inevitably going to insert a line long enough to screw up your alignment, and now you'll have to bungle your diff.
It's interesting how much of your productivity comes from the subtle/indirect recognition of things. Changing something as trivial your color scheme or font can take a good chunk of time for adjustment.
I'm a huge fan of Ubuntu's monospaced font and use it on my Mac with Sublime.
http://wsld.me/JzYm (Ubuntu Mono, 16pt)
I've spent many hours trying to figure out how to convince Vim and/or OS X to lighten up on their font rendering. For some reason the only place I've been able to pull this off is Drracket which I just use for a class, and which has an option to do it. I've never been able to pull it off in my standard coding environment. I can't understand why that option isn't available anywhere else, or on an operating system level.
This is Monaco 12pt in Drracket and Vim, with that Drracket font smoothing option at the bottom: http://i.imgur.com/Va0ZN.png
Is there a good reason there's such little control over font rendering, at least on Mac?
Also when switching to the retina display the fuzziness goes 100% away.
Yeah, I'm looking forward to my first retina laptop.
Because we (I) find them extremely easy to read. I can't stand white or off-white backgrounds.
I do it mostly because staring at white background all day burns into my retinas.
> I've spent many hours trying to figure out how to convince Vim and/or OS X to lighten up on their font rendering
There was a system-wide anti-aliasing strength setting for OS X.
defaults -currentHost write -globalDomain AppleFontSmoothing -int 2
I believe it's 0 to 3 but I can't check right now.On the other hand, ClearType is optimized for low-ppi displays. If you try to view text rendered with ClearType on a high ppi display (128+ ppi) it will look incredibly thin because ClearType attempts to force straight font lines into a single row or column of pixels which is incredibly thin at such a high ppi. That's the very thing that makes ClearType fonts look much crisper on very low ppi displays.
tl;dr OSX font rendering is much more readable on 128+ (or even 220) ppi displays.
I still prefer Ubuntu Mono though
https://github.com/rbanffy/3270font
Yesterday, I moved all my terminals to the narrow version.
https://raw.github.com/wiki/rbanffy/3270font/emacs.png
edit: corrected URL and added it to the README file.
I find it much more pleasing with the benefit of great differentiation between 0 O etc...
http://damieng.com/blog/2008/05/26/envy-code-r-preview-7-cod...
Let the fixed width font war begin. Apple Vs. Microsoft vs. Adobe.
http://www.fsd.it/fonts/pragmatapro.htm
Some sample screenshots from OS X:
http://i.imgur.com/oxhSg.png (white background)
http://i.imgur.com/M0ZJz.png (black background)
My only remaining concern is that the hypen isn't vertically centered with many of the other symbols, making -= and -> look awkward.
CHANGES FROM 0.8 TO 0.81
edited by Fabrizio Schiavi 2012-06
* dashrockets
->
<-
<=
=========> 0%
>=
+=
-=
*=
+--------+--------+--------+
are horizontally aligned
* | ¦ "bar" and "brokenbar" are now designed to be overlapped between two lines of text
| ¦ (useful for iTerm2, tmux 1.6., Terminal.app and others)
* horizontal strokes of the letter Nun (U+05E0) is a bit shorter,
to help make it more distinct from Kaph (U+05DB)
* Italic weight is TrueType handhinted
* Bold Italic weight is TrueType handhinted
* added an entire Unicode block:
2100-214F Letterlike Symbols to the Regular weight
* added these letters from the block
1D400-1D7FF Mathematical Alphanumeric Symbols
to the Regular weight:
Amathdoublestruck, Bmathdoublestruck, Dmathdoublestruck,
Emathdoublestruck, Fmathdoublestruck, Gmathdoublestruck,
Imathdoublestruck, Jmathdoublestruck, Kmathdoublestruck,
Lmathdoublestruck, Mmathdoublestruck, Omathdoublestruck,
bmathdoublestruck, dmathdoublestruck, emathdoublestruck,
imathdoublestruck, jmathdoublestruck, Bmathboldfraktur,
Cmathboldfraktur, Dmathboldfraktur, Emathboldfraktur, Fmathboldfraktur,
Gmathboldfraktur, Hmathboldfraktur, ImathboldfrakturCoding with dark text on a white background is much easier on the eyes, too, unless you have a screen that won't let you turn down the brightness.
Pro tip: hold up a white sheet of paper in your well-lit work environment. Adjust your screen brightness to match the brightness of the piece of paper. Your screen should not be brighter than your work environment.
Super pro tip: work outside. Get a professional laptop with a matte screen, one of those lightweight "antigravity" chairs, and find a nice place to work outdoors. A 12x24" piece of wood makes a good lap desk if you need to use a mouse and fits well over the armrests of all of the outdoor chairs I have worked in.
DejaVu Sans Mono can be better in some environments http://dejavu-fonts.org/wiki/
I also discovered I like the new Ubuntu Mono http://font.ubuntu.com/
except it has too much vertical spacing, but I hope to find a way to easily edit that someday
I think so, too. At least compared to Consolas which I use and prefer.
There's too much attention for 0 vs O's and too little for unicode coverage. Personally, I never understood the whole character differentiation thing when most modern editors/IDEs feature syntax highlighting and checking.
http://www.inp.nsk.su/~bolkhov/files/fonts/univga/index.html
When I got a retina macbook the resolution meant each pixel of the font was 4 on the display instead of 1 so I tried and failed to find a substitute again. I ended up using fontforge to double the resolution of the font and smoothed it out by hand with some extra pixels. I like it even more now.
Update: I bit the bullet and installed the Infinality patchset. The result is astonishing...
serifs unite!
I'd got used to Monaco, but this makes everything so much clearer. I've been using it since this article came up, not yet been tempted to switch back.
Actually, between elementary OS's font rendering settings, great terminal support and unix/linux tools, I'm spending basically every second on my MBA inside my eOS VM.
Re-read and realized you mention the theme, link for others who are curious: https://gist.github.com/3712874
The dots are unsaved files (usually they're files that are open that I've renamed/deleted and thus it marks them as unsaved).
The ST2 theme is "Aqua/Monokai Aqua"
(EDIT: Note, that prompt looks AWFUL in Terminal.app/iTerm2.app. It can be made to look nice if you adjust the palette color settings for your emulator, fortunately, this screenshot is with Gnome-terminal's Tango palette.).
I have a customized vim config and I give it a serious shot once a year. So far Sublime Text 2 still has me very, very happy.
The font is not that good though. In Windows it is rendered too wide. Does not seem to be able to replace my current fav Segoe UI Mono that I find more readable.
But now it is a completely different story: we have the source codes! Let's go edit some fonts the way we like!
http://terminus-font.sourceforge.net/
> Version 4.38 contains 879 characters, covers about 120 language sets and supports ISO8859-1/2/5/7/9/13/15/16, Paratype-PT154/PT254, KOI8-R/U/E/F, Esperanto, many IBM, Windows and Macintosh code pages, as well as the IBM VGA, vt100 and xterm pseudographic characters.