Please screenshot renderings via multiple important renderer, important ex: Apple Safari on a Retina box (highlights weird over-bolding due to their hinting prefs), Chrome and Firefox on Windows (both use Freetype, but custom builds and don't quite match stock), and anything normal on a Linux that doesn't use a hacked up Freetype (ergo Ubuntu is out, so is RHEL/Centos and Fedora).
Also, in both white on black and black on white, because font rendering is non-linear in respect to the 2.2 gamma curve (fun fact: everybody still uses 1.8 gamma for font rendering).
> anything normal on a Linux that doesn't use a hacked up Freetype (ergo Ubuntu is out, so is RHEL/Centos and Fedora).
Your definition of "normal", "important" Linux _excludes_ Ubuntu, RHEL/CentOS, and Fedora?
I get your point about hacked up FreeType, but given that the three largest distributions on the planet are excluded from your list doesn't really gel.
Ubuntu is still much better out the box than Fedora (though it's a simple fix with freetype-freeworld) on none-HiDPI screens - though it's subjective obviously.
This is based on Roboto (reusing some outlines directly; not initially acknowledged by the designer on the marketing site), and arguably doesn't tread much new ground either in character or use-case or license. Not convinced there is anything this adds to an already crowded space.
Hello Jack. I'm the creator of Interface. Indeed many glyphs's outlines comes from Roboto (though fitted into different glyph boxes.)
The "playground" feature of the website even has a feature for comparing Interface with Roboto. When you do, and you look at the details, you'll find that Interface is actually quite different from Roboto, at least as far as "different" goes with utilitarian UI fonts. https://rsms.me/interface/lab/?size=22&compare=roboto
Hi Rasmus, I think that at the point size at which this is meant to be used—e.g. around 11px (https://rsms.me/interface/lab/?size=11&compare=roboto) —the differences between the two become harder to distinguish. The issue is really that the character of the type is going to be dictated by the systematic decisions: stroke weight, x-height, proportion, spacing. Starting from Roboto and not changing these parameters in your solution means drastically limiting how far away from the original source that you can realistically get. In the end, changing the stroke endings and changing the bounding box of some characters in invisible in the intended use case.
Here is a screenshot comparing Roboto (11.5px) to InterfaceRSMS (11px), which illustrates: http://imgur.com/a/nl5mp
There are plenty of UI typefaces out there that take a noticeably different approach, an easy comparison to Lucida Grande is probably enough to justify the point. (EDIT: for completeness, http://imgur.com/a/CjD06)
Thanks for the thoughtful comment. Indeed really small sizes like 11px, distinguishing factors are few and even San Francisco and Roboto start looking like the same font, at least as far as most people are concerned. The goal with Interface is not to create a unique-looking typeface, or even to try to make something different in terms of style, but to create the best possible small-size, computer-screen, user-interface oriented font, even if that means that some characteristics become very similar to other typefaces. For instance.
My argument is only that starting with the proportion and metrics of Roboto and not changing them means that what you will end up with at best is a marginal improvment over Roboto. If "marinal improvement over Roboto" is what you are aiming for, great, but don't oversell it or your work will be dismissed in the same way that I did in the original post. There are myriad solutions to how letterforms are created, and it isn't a foregone conclusion that these forms are or will continue to be "the best".
The comparison is not great for objective comparison—the metrics of Interface have been changed so that 11px =/= 11px from one to the other… this was the best approximation that I could get in-browser. Usually you'd want to set the two typefaces up so that the x-height is the same, and in this case Roboto is probably slightly larger still, and hence a bit darker in overall color.
Except that isn't how font metrics work—the size of the type on the body is not necessarily equivalent between two different fonts. There is no stanard that says that 12pt Times shares any vertical metrics with 12pt Helvetica, or 12pt anything else.
The most informed comparision can be made when the x-height is optically equivalent. The other option, cap height, isn't as useful because it is then harder to judge the lowercase (a majority of the letterforms).
I think what jack's saying is that "font-size" to some extent is arbitrary. It's not scientific or worthwhile to compare fonts across a specific size if they have different x-heights. The only meaningful comparison is to evaluate legibility for fonts that are "relatively" the same size. For example, if Interface 12pt is equivalent in x-height to Roboto at 12.5pt, and Roboto is more legible, and legibility is the goal, then obviously the user should pick Roboto at 12.5pt (all things considered).
Also subjective, but at that size on my machine (13" MBA, non-Retina, El Capitan, Chrome), I find Roboto is a lot easier to read. Interface looks 'greyer' and the contrast isn't so good.
While not the intended use case, I find Interface to be surprisingly readable at extremely tiny font sizes (7, 6, and even 5!).
Sure, you shouldn't be designing an interface with those sizes, but it may be something to consider for some zooming interfaces (primarily maps with lots of tags: street names, POIs, etc.)
You should probably be loading the Roboto font via Google Fonts or similar, because my system does not have Roboto installed by default, so it is defaulting to serif in your comparison.
Roboto is already being loaded from google fonts (https://github.com/rsms/interface/blob/b91dd3af/docs/lab/ind...) However, I think Chrome might do something weird where it fails to actually load the font files when later the font family "Roboto" is requested (https://github.com/rsms/interface/blob/b91dd3af/docs/lab/ind...) — a common hack for this issue is to have an invisible element in the document that explicitly uses the font and forces the browser to load it at document-load time. Could try that hack here.
Anyhow, the version of Roboto served from google fonts is an older version and a subset of the "real" roboto, as can be fetched from roboto's source code repository. If you have Roboto installed locally, you probably have the more recent and more complete version installed and will likely want to compare with that (rather than what's on google fonts.)
Good to have a version of Roboto that is not distinctly associated with the Android OS. I remember having to dismiss Roboto in favor of Arimo just for that reason (despite Roboto being a better fit overall).
A disproportionate sans serif without any letter spacing. It's free though, so better than nothing.
Edit: Dear downvoters, what I am saying is that you can take any ramdom sans serif, reduce the letter-spacing and you end up with a similar looking font face which might be even more balanced. Despite my criticism, I expressed my high appreciation that the creator offers his work for free. If you disagree let me know why instead of downvoting, maybe I am wrong and missed something.
By disproportionate I meant that it feels like a slightly condensed font without really being a condensed font. This paired with this too small letter spacing creates this disproportionate look.
Another poster just commented that it looks like Roboto (or is even based on Roboto) and Roboto faces the same issues but not that worse. Roboto itself is a mutated Helvetica Neue which is admittedly a reference sans serif where every other sans looks inferior amd kind of turned out badly in comparison.
I'm looking at the rendered image and the letter spacing seems vastly better than it is when rendered on the page (Freetype, Linux, with a few simple fontconfig improvements).
IMO, it's balanced out by the fuller explanation of what they intended to say and the request for clarification of what was wrong. It's not like they just added a "Why am I being downvoted?" without adding any further value.
Sadly, digits have a different width, so if you have e.g. a right-aligned, increasing numerical value in your UI, the left digit of it will "wiggle around" if the last digit iterates through 0-9, and if you have numerical values, they won't align.
This may be OK for text, but specifically for user interfaces, this is the very first thing I check when considering whether a font is usable.
With a good font, it will be immediately obvious which of these amounts is more, while this font would likely mislead you:
Normally this is done with "tabular numbers", an alternate set of glyphs in the font where all digit glyphs is equally wide. However, another feature a font can provide is "proportional numbers"—the inverse of tabular numbers. Most fonts usually provide one or the other. Roboto for instance provides "proportional numbers" as an option, and uses tabular numbers by default. Interface by contrast uses proportional numbers by default, and the plan is to add tabular numbers as a feature that you opt in to for the scenarios you point out (e.g. tables.) In CSS you'd opt-in to tabular numbers with: `font-variant-numeric: tabular-nums`
What is the rationale for defaulting to proportional numbers? I always assumed that "tabular numbers" are just "numbers", and deviating from that standard sounds like a recipe for needless confusion. Sure, you can flip a CSS switch, but how many webdesigners know that these switches even exist? And what about native UI frameworks where these switches don't even exist?
Looking at Interface's glyph map, I see that letter-O (O) is slightly wider than number-zero (0). Capital-eye (I) is indistinguishable from small-ell (l), though number-one (1) is distinguishable from both.
What other glyph ambiguities do you look out for on new fonts?
This is by design. A wider "O" would indeed make separating zero from "O" easier (and an earlier iteration of Interface had a wider "O") but it adds some uneven pace to how longer words and sentences read.
The hope is to add a stylistic set for character disambiguation to the font, which when enabled would enable graphic features on glyphs like upper-case "i" and lower-case "l", zero and "O", and so on. Tracked here: https://github.com/rsms/interface/issues/1
Though not abiguous in sharing the exact same shapes, many characters can share similar structures that (arguably; citation needed) can cause visual confusion. For example;
3 and 8 in a typeface like Helvetica are very similar. Opening the aperture of the 3 or using a form with a corner in the upper right can be observed in some UI typefaces.
The "single story a" can be an issue in typefaces that ise it, adding to the plethora of round forms (eopdqbc etc.). Breaking up the monotony of those shapes is also frequently advised.
"Tail-less" t and r in sans type can be problematic at small sizes.
> Since this font is very similar to Roboto, glyph outlines from Roboto are indeed being used, mainly as "placeholders" while the glyph set is expanded. The Roboto license can be found in the source directory.
Mainly?
If this is a deliberate near-clone of Roboto, then at the very least there should be some explanation of how it differs and why.
It's nearly identical to the new Mac OS system font San Francisco (SF) but with tighter spacing and (subjectively to me) nicer finials and terminals. Looks great.
I actually came across this yesterday and set it as a system font on my Linux machine, which runs Elementary.
Although I don't have a HIDPI display, it is nicer and (subjectively) more readable than what I've tried before (I still use Fira Code for coding and Fira Mono inside the terminal, but for the UI tried various variations of Fira, Roboto and other sans serif fonts, yet none of them stuck).
I was interested to discover fonts with programming-specific ligatures when they were discussed last month. I haven't experimented enough yet to know how well they work out in the long term.
This is a good idea. Why hasn't someone thought of it before? Why didn't I think of it?
I've been using Frama-C recently, with the option of \forall or ∀, for example. The latter is more readable, but a pain to type. I'll have to try some of these.
Thanks for this font, I really appreciate the mix between Roboto and Helvetica or San Francisco. The cuts of Interface are more horizontals than Roboto (look the S for example) and I find it more readable, rational and beautiful. Good job !
yes, I'm not adverse to a spot of nice typography, aesthetics and presentation are key to getting a message across, for productivity UI in particular I like at least the choice to have a system font, it's usually the nicest rendering font and things like multi language support mostly just work.
Nice font. Would there be a way for you guys to incorporate the font on a platform like Google's webfonts? For our business (http://fairpixels.pro) we are constantly looking for great fonts to use in the UI work we do for software teams. Having a scattered landscape doesn't help.
Glad you like it. Once Interface reaches a more stable state (i.e. more glyphs and kerning have been added), the intention is to submit it for inclusion on Google fonts. In the meantime, you can use https://rsms.me/interface/interface.css which always points to the latest release of the font, and is hosted on a CDN (by Cloudflare, backed by GitHub.)
I'm sure this is like tabs vs spaces for typographists, but why the hell do people make and use sans-serif fonts? Even ignoring aesthetics, the fact that there are horrendous ambiguities (like between I and l) renders these fonts completely inappropriate for computational tasks like copying passwords or secret keys. I have run into this problem multiple times on OS X and iOS, where the password managers use sans serif fonts.
I don't want to obsess over the analogy but just want to point out that it's not a typical holy war in the tabs/spaces or vi/emacs sense because no one is claiming that only one of serifs or sans-serif is best. Most acknowledge the benefits of both.
Serif fonts are harder to render on low DPI displays, such as nearly every Windows machine in existence. I really wish that high DPI displays would take over the world, but I know how difficult that will be. I'm even having trouble myself, I'm in the market for a new Chromebook and I found one with a very nice 235dpi display. I can get it for $400, but my wife is giving me grief because similar ones with a crappy display are available for $250.
This is valid commentary and subject to much discussion throughout the recent history of typography. There's always a blance condition between personality, legibility, character ambiguity, pace, and so on. Every typeface needs to go in some direction on these dimensions, which is why we have different font families for different uses! For instance, mono-spaced fonts with "slab" serifs are popular with computer code since column alignment (mono-spaced) and ambiguity (slab serifs and other visual traits like slashed zero) are used. However, for most people it's easier to read a variable-width font with regular serifs for longer text, like what you'd find in a book. Similarly, for user-interface labels, dialogs, buttons, etc it's often better to use a font without serifs and with a little more tracking/letter-spacing than what you'd use for large bodies of text (e.g. in a book.) Interface is designed for the latter use-case; user interfaces on computer screens.
Please screenshot renderings via multiple important renderer, important ex: Apple Safari on a Retina box (highlights weird over-bolding due to their hinting prefs), Chrome and Firefox on Windows (both use Freetype, but custom builds and don't quite match stock), and anything normal on a Linux that doesn't use a hacked up Freetype (ergo Ubuntu is out, so is RHEL/Centos and Fedora).
Also, in both white on black and black on white, because font rendering is non-linear in respect to the 2.2 gamma curve (fun fact: everybody still uses 1.8 gamma for font rendering).