Input: Fonts for Code and Data(input.fontbureau.com)

70 pointsby fallat11 yıl önce19 comments

input.fontbureau.com

http://input.fontbureau.com/

20 comments

tellor11 yıl önce

Its nice!

For some sites that render code I use stylish add-on in browser:

Here snippet for nice "code fonts courier-hinting" in stylish add-on:

@namespace url(http://www.w3.org/1999/xhtml);

@-moz-document domain("forums.gentoo.org") { .code { font-family: 'DejaVu Sans Mono' }

}

yoklov11 yıl önce

I'm not against it in principal, but leaving alignment to the editor sounds like the kind of thing that could be coding standard unfriendly (unless it were done quite well, or was solely visual).

Adaptive11 yıl önce

Yep. I just use the monospaced variant. Unless we radically rework editors and terminals, proportionally spaced type seems unworkable.

Stratoscope11 yıl önce

That's just a matter of coding style. It's very easy to write code that reads equally well in a proportional or monospaced font. All you have to do is give up column alignment.

I haven't used column alignment in my code in over ten years, and it's been a real blessing. Column alignment leads to some absurd practices, like the examples below from this Servo source file:

https://github.com/servo/servo/blob/master/components/layout...

You may need to scroll horizontally to read these long lines:

  let construction_item = ConstructionItem::TableColumnFragment(Fragment::new(node,
                                                                              specific));

  self.set_flow_construction_result(&kid,
                                    ConstructionResult::Flow(kid_flow,
                                                             Descendants::new()))

Those statements would be more readable and much more maintainable with a simple change: Stop making a distinction between parentheses and curly braces. Instead of lining up columns where parens are used, indent expressions the same way we typically indent statements:

  let construction_item = ConstructionItem::TableColumnFragment(
      Fragment::new( node, specific )
  );

  self.set_flow_construction_result(
      &kid,
      ConstructionResult::Flow( kid_flow, Descendants::new() )
  )

Here's some of the trouble column alignment gets you into, again from the same source file:

  ConstructionResult::ConstructionItem(ConstructionItem::Whitespace(whitespace_node,
                                                                whitespace_style,
                                                                whitespace_damage)) => {
      ...
  }

It's easy to guess what may have happened here: at one time the code was aligned perfectly, but then four characters were added somewhere in one of those names, pushing whitespace_node farther to the right so it no longer aligned with the code below it.

With a non-column-aligned style, this would never happen:

  ConstructionResult::ConstructionItem(
      ConstructionItem::Whitespace(
          whitespace_node,
          whitespace_style,
          whitespace_damage
      )
  ) => {
      ...
  }

Now you can change any of those names and it won't affect the code formatting one bit. And look how much shorter your lines are when you use indentation instead of alignment!

Another benefit of giving up column alignment is that it eliminates any need for arguing about "tabs for indentation, spaces for alignment" and all that. And with no alignment, your code becomes resilient to re-indentation. Company founders get older and find it's become harder to read two-space-aligned code? You can re-indent the source mechanically to four spaces, or tabs, or whatever you like, and it won't break the formatting at all.

Of course if you have to work with column-aligned code like the Servo source, you'll probably need to use a monospaced font. But if you have any influence over the formatting of the code you work, try giving up column alignment. Even if you don't find it makes any difference in readability, the people who have to maintain your code later will appreciate not having to fiddle with the alignment any more.

Retra11 yıl önce

It is just far easier to use a monospaced font than to implement a whole tabbing system in every editor you'd want to use. And the alignment needs can vary by language and application.

That's why it is so nice to work in a grid: you can align things however you like for any purpose. You don't have to rewrite someone else's parser or build a plugin to properly format an ad-hoc table in a comment.

"If source code editors can highlight syntax, they could also interpret tabs and syntax to create true, adjustable columns of text."

Yeah, but they don't.

seanmcdirmid11 yıl önce

Oh but they could. Are programmers condemned to an eternity monospace typewriter hell because we are too lazy to build better editors? Will we be able to upgrade to proportional fonts before the singularity occurs and programming becomes obsolete anyways?

I've been proportional for about 3 years now; once you go with better typography you can't really go back.

Retra11 yıl önce

Yes, we probably are condemned. For the same reason that mathematicians are condemned to know how to add and subtract, even though one could achieve the same results using a more general method.

Monospace is just simpler. We use it in consoles, and they aren't going away or being revolutionized. And if you want to write a new text editor, you will probably end up supporting monospace behavior before proportional simply because it is such a simple and flexible algorithm.

And in the end, the only reason to use proportional font is for style and a marginal increase in readability.

So it's not a matter of laziness, but of efficiency and design fundamentals.

seanmcdirmid11 yıl önce

> And in the end, the only reason to use proportional font is for style and a marginal increase in readability.

Everyone always claims that "we read code" more than "we write code", yet we still optimize for writing rather than reading. Reading code that has been typeset well is a joy and much improved experience vs. reading code that has not.

[deleted]11 yıl önce

Adaptive11 yıl önce

I've been using input in terminal/vim for a couple months and quite like it. Not sure if it's the end-all be-all font but it's pretty easy on the eyes, and very tweakable.

cxa11 yıl önce

I've been using Input as my default monospace font in both Mac and Linux for the past 5 months, and I have a very high opinion of it.

To anyone curious, I recommend trying the preview tool: http://input.fontbureau.com/preview/

One of its best feature is that after you select your preferences for style, width, weight, and alternates, you can bookmark the URL for later reference or sharing.

31411 yıl önce

Just tried it. It is nice, but I think that I've been spoiled by Menlo, which I am now going back to. Not a very high DPI screen but around 14pt Menlo just seems easier on the eyes.

iamcurious11 yıl önce

Care to share how you did it?

amelius11 yıl önce

I just use the Sony font that comes with Linux. Also works in an xterm.

rbanffy11 yıl önce

Has a very vintage feeling. Makes me want to get a NEWS workstation...

My terminals go for the 3278 looks: https://github.com/rbanffy/3270font (but that'll probably not work with xterm)

posnet11 yıl önce

I ended up buying the Butterick fonts a while back for a personal project, now I use Triplicate for basically all my coding/terminal needs. I like because it has good readability on both low res and high res screens.

seanmcdirmid11 yıl önce

I've played around with typography in the programming environment I'm building, here are some of the experiments I ran:

http://research.microsoft.com/en-us/projects/liveprogramming...

That was about a year ago, what I have now is a bit more tame.

melloclello11 yıl önce

This is amazing, I wish programming was more like this.

seanmcdirmid11 yıl önce

Thanks. I hope to release an OSS version by the end of this summer.

westoque11 yıl önce

I've never seen so much detailed explanation for designing a font. +1