

Input: Fonts for Code - wasabian
http://input.fontbureau.com

======
Stratoscope
Wow, I never thought I would see proportional fonts specifically designed for
coding. I've coded almost exclusively in proportional fonts for over ten
years. The font I use the most is Georgia. It makes code easier to read and
more pleasing to the eye, just like any other text.

Besides personal preference, I think there are two main reasons people avoid
proportional fonts: column alignment and two-space indents.

Two-space indents are an unfortunate trend in coding styles, because they
practically mandate the use of a monospaced font to see the indentation. I use
tabs for indentation, which let each developer adjust the visual indentation
to suit their own eyes. Four-space indents are OK too.

I would love to see programmer's editors provide a way to control the amount
of visual indentation that each leading space represents.

Column alignment of course is not possible with proportional fonts, but that's
an easy problem to solve: don't do it. Instead of this:

    
    
      void DoSomethingWithStuff(SomeReallyFancyTypeName thing,
                                string                  name
                                int                     count,
                                bool                    condition);
    

Write this:

    
    
      void DoSomethingWithStuff(
          SomeReallyFancyTypeName thing,
          string name
          int count,
          bool condition
      );
    

While you lose the advantage of seeing all the parameter names lined up, it
becomes much easier to visually associate each name with its type. My eyes
tend to wander when I have to scan across a wide horizontal gap to match
things up.

This style also leads to much shorter line lengths as can be seen here, and
it's easier to maintain: You don't have to realign things when you change the
length of the function name or one of the type names, or when you add a
parameter with a longer name than the ones you have already.

A case where column alignment is more useful is ASCII art in comments. I've
experimented with using a monospaced font for comments and proportional for
code, which solves that problem nicely. But I don't use ASCII art much myself,
so I went back to proportional for everything.

I'm looking forward to trying out these fonts!

~~~
drivingmenuts
I would say that the problem is "SomeReallyFancyTypeName" where you've created
a ridiculously long type name (one of the reasons I avoid Windows programming
at all costs).

That aside, editors don't handle tabbing very well. It's far more space-
efficient to insert two tabs instead of 8 spaces, but space and bandwidth are
so cheap these days, no one can be arsed to fix what is viewed as a minor
problem (use enough spaces and sooner or later, we're talking real bandwidth).

Then, there's the moment where we have to decide what those all those tabs
(and sometimes spaces) mean, depending on the language, the layout rules,
personal preferences, etc. For example, some people write Python with 2 spaces
at the beginning of a line (which is plainly heresy). Others write it with 4
spaces (which is damnable blasphemy). Which is right?

And how many other languages are like this?(hint: any language in which layout
is indented for any reason)

And concerning line length - what's the maximum allowable length before
wrapping? You say 80, I say 132 (sometimes more), but I run terminal in a
full-screen mode with 13-pt type, single-screened, never side-by-side.

Personally, I've learned my lesson. I'm waiting for editors to smarten up
before I muck around with proportional fonts for code. Again.

~~~
Stratoscope
Thanks for the comments. You're right, "SomeReallyFancyTypeName" was a bit of
a strawman on my part. But even with shorter type names you still have the
same problems if you use column alignment. I actually gave up column alignment
long before I started using a proportional font. I just found it to cause more
headaches than it was worth.

You mentioned that "editors don't handle tabbing very well". All the editors I
use most frequently - IntelliJ IDE, Visual Studio, MonoDevelop, Komodo,
Sublime Text, UltraEdit - handle both tabs and proportional fonts without any
problem, so that hasn't been an issue for me. I'm curious to know what editors
have trouble with tabs.

Anyway, I try not to worry too much about tabs vs. spaces. My only real
objection is two-space indents. That's just not enough for many people
including myself.

Of course many editors don't support proportional fonts, but that doesn't
cause a problem for those of us who like to use proportional fonts in the
editors that support them. It's really easy to write code that is equally
readable in a monospaced or proportional font.

Regarding the line lengths, my coding style lends itself to very short line
lengths, as shown in the example above. I think that helps give some freedom
to use wider indentation.

~~~
drivingmenuts
This
([http://nickgravgaard.com/elastictabstops/](http://nickgravgaard.com/elastictabstops/))
is smart tab handling. All other editor aren't that great, compared to this.

------
eklavya
Totally subjective opinion, but yet to see something beat Consolas.

~~~
ayrx
I actually prefer Ubuntu Mono over Consolas or Inconsolata but fonts are a
very subjective thing. :)

~~~
webjunkie
On my Macbook I've tried many many coding fonts, yet Ubuntu Mono is actually
the best. All others either seem to render weird to me or I don't like their
look in the first place.

------
tekacs
Scanning over the page and the 'explanation' page, I found a headache
developing as I tried to read everything there.

My experience so far is that I find this far harder to read. For reference's
sake, I don't do parameter alignment in my own code (see Stratoscope's
comment), but still find it easy to scan code in most-any monospace, probably
because my eyes just know where to jump to all the time...

For all the words in favour of proportional fonts, I would venture that when
the words on a page are in fact ultimately forming macroscopic symbols
(identifiers), often with PascalCase or camelCase or underscore_words,
uniformity no matter the characters used is perhaps a more useful feature than
making the words easily comparable to those read in prose?

~~~
krick
Agreed. If somebody likes that — well, that's nice. I even see on screencasts
sometimes TextMate with proportional fonts, so obviously somebody will find it
desirable. But it won't be me for sure. First off, what I've seen there
doesn't seems readable by itself. Second, I don't really see any real benefits
of using proportional fonts for coding, while drawbacks are quite big: when
I'm tired or just reading quickly through the code I often find myself
depending on being able to see that lines with the same number of characters
have the same width.

Even more than that (maybe it's something like "professional deformation"
already, but I'm fine with it): I've considered using non-monospaced fonts
automatically for stuff like LaTeX or markdown, or my own txt notes, but
didn't find it pleasant enough. For all the european languages, anyway —
typing japanese in vim is a bit painful for me and I don't know languages with
more exotic writing system, be it arabic or hindi. I even hard-wrap natural
language texts, which would be crazy using proportional font — and am glad I
did so, when I want to see it through `less` on fullscreen.

------
PeterisP
Maybe this is the place to ask about my pet peeve - why do fonts, including
specialized coding fonts, position parenthesis with both sides equally?

I mean, it seems that for readability it would be better to emphasize the fact
that they're asymmetrical - when looking at "foo(bar)baz" , it would be better
if the parens would be a pixel or so closer to their inner contents; but
currently "foo(bar" on most fonts looks as if the paren is merging with the
initial text.

The same would apply for foo[bar]baz and foo{bar}baz.

~~~
arrrg
Fonts do it because outside of code there is just always a space character
inserted before every parenthesis. Adding additional space inside the
parenthesis character would just increase that space, something that is not
desirable.

~~~
PeterisP
The topic is developer-oriented specialized fonts - so there is no such thing
as 'outside of code', and in a monospaced font no space can be added since the
width is fixed - so my question was about shifting the parenthesis towards the
'inside' within that width.

~~~
arrrg
I was just giving a historic explanation as to why no one might have thought
of that. (By the way, good modern fonts actually do a lot in terms of
automatically adjusting the spacing of individual letters, and popular layout
tools like InDesign offer algorithmic alternatives to whatever the font comes
with by default. In proportional fonts “Te” will typically be closer together
than “Th” – if you output those fonts with the right program. So fudging with
spacing in some automated fashion is not out of the question.)

However, even in code it is desirable to not add extra space to parenthesis,
since “foo (bar” is certainly no less common than “foo(bar”. Basically, the
font would have to automatically adjust depending on whether or not a space is
in front of it to treat both of those cases appropriately. (I think that’s
possible with current font formats, so there is likely no technological hurdle
to this.) However, that might not be desirable since it might make “foo (bar”
and “foo(bar” easier to confuse.

------
alexanderteinum
This is some truly amazing work. Love the option to change the built-in line
spacing.

(I’m a monospace addict, and I always switch between Source Code Pro, M+ 1m,
and others. What I don’t like about M+ 1m is that it’s narrow, and the line-
spacing in the web font is too small.)

~~~
swah
Do you use M+1m in a retina display exclusively?

~~~
alexanderteinum
Yep, I’ve actually never seen it without retina display.

~~~
swah
I think this must be made clearer when comparing fonts. I expect a lot of
things to look good on retina!

------
NAFV_P
On the info page:

""" <div><span class="highlight">M</span></div>

<div><span class="highlight">M</span></div>

<div><spam class="highlight">M</spam></div>

<div><span class="highlight">M</span></div>

proportional fonts can make it easier to spot typos """

The example given demonstrates that a _certain subset_ of typos can be caught
using proportional fonts, but not all.

If a word has too many or too few characters in it, I think you are more
likely to spot it utilising a monospaced font.

EDIT: the quote has been made more legible.

------
sanityinc
Just the Mono family alone is excellent. There are a number of different
weights available, each with italic and bold variants, and the repertoire of
glyphs is extensive.

I enjoy condensed fonts like Pragmata Pro (which I highly recommend), and this
appears to be one of the few viable alternatives I've seen. Merits a week-long
test-drive, I think.

~~~
swah
Actually, it looks a lot like PragmataPro:
[https://www.dropbox.com/s/7c5yifw5saip3ae/pragmata_vs_input....](https://www.dropbox.com/s/7c5yifw5saip3ae/pragmata_vs_input.png)

~~~
sanityinc
Yes indeed, but with light and ultralight variants. A day later, and I'm still
enjoying Input a lot.

------
err4nt
I have been having a love affair with Source Code Pro, thin weight, at about
14pt, using Solarized Dark color palette.

There's something refreshing about it, it's nice, big, clean, and LEGIBLE. I
use it for my IDE and terminals and there's no turning back.

Highly recommend everybody check out Source Code Pro!

~~~
alaoiigha
I just recently switched. Turns out, this is the same font that Codegansta
uses, as seen here: [https://gophercasts.io/](https://gophercasts.io/)

So you can get a nice preview of it if you like :)

(though, i think he uses 12pt, i use 13pt personally.)

------
noir_lord
Looks nice, I've switched my terminal to Condensed and works great.

I unfortunately can't use it in my main IDE's as both PyCharm and PHPStorm
have bad aliasing on Linux fortunately solved by Terminus which doesn't
require it.

------
artursapek
I will likely never stop using M+ 1m, which is a somewhat unknown font. Nice
and narrow. Efficient.
[http://www.fontsquirrel.com/fonts/M-1m](http://www.fontsquirrel.com/fonts/M-1m)

------
zitterbewegung
The example with breakcycles seems to be broken on chrome 36.0.1985.125
(Official Build 283153) for windows.
[http://imgur.com/hd4REcG](http://imgur.com/hd4REcG)

------
willtheperson
This caused me to lookup Sublime Text (3)'s font configuration options and see
there were some options I didn't know about. For example, you can add line-
height by adding

    
    
        {
            "line_padding_bottom": 2,
            "line_padding_top": 2
        }
    

to your Preferences file. Found this info here in what is also the best
version of a ST manual I've seen [http://sublime-text-unofficial-
documentation.readthedocs.org...](http://sublime-text-unofficial-
documentation.readthedocs.org/en/latest/reference/settings.html)

------
jamesaguilar
I like the look of it. Will definitely try for a couple of days next week. No
reason not to. ☺

------
NikKlaus
It's nice but Pragmata Pro is teh_one

------
mikerg87
I would have liked to have seen the example page have a section how it behaves
with ASCII art that you sometimes see in comments.

~~~
kupfers
Check out the code of the Input.com site. There is some ASCII (logo)art in it.

~~~
kupfers
Woops, I mean inputfont.com

------
jimhefferon
HN would benefit from a programming font respite.

