Fira Sans is also one of the 3 free fonts (along with Charter and Source Code Pro) recommended by
Butterick's Practical Typography: http://practicaltypography.com/
% Font settings
\usepackage[T1]{fontenc}
% Serif body font
\usepackage{charter}
% Math font
\usepackage[charter]{mathdesign}
% Monospaced font
\usepackage{sourcecodepro}
% Sans-serif font
\usepackage[lf]{FiraSans}
The comments on that review at typographica point out that Fira's quality for non-Latin scripts is less than perfect. Butterick generally ignores this part of the Unicode spectrum, to the point where his own fonts completely miss non-Latin scripts.
As a recent student of Korean, the state of Hangul typography makes me sad. There are a few quite food typefaces for Hangul, but nowhere near as many as for the Latin script.
Now, Latin's had much longer to develop today's movable type design tradition with gusto (with many typefaces popular today tracing back directly to designs developed before Hangul saw mass real adoption - Hangul was originally developed on metal letterpress, but still heavily informed by Chinese calligraphy), so this isn't necessarily surprising - but I wish it'd tempt more designers to bring their knowledge and experience to bear on the script, given the opportunity to make critical contributions.
> I wish it'd tempt more designers to bring their knowledge and experience to bear on the script, given the opportunity to make critical contributions.
I wonder if non-Korean type designers are hesitant to work on Hangul fonts because they're illiterate in Korean. I could imagine that it would be hard to have good intuitions about readability and appearance for a writing scheme one doesn't understand.
You need to separate writing systems and language there, though. Unlike the Chinese writing system that it bears superficial resemblance to, Hangul is an alphabet, and it's more purely and consistently phonographic than most writing systems in widespread use. Many of the letter shapes are actually based on things like tongue position and mouth shape when making a particular sound - and there's only roughly as many of them as there are Latin letters. It was specifically designed to be fast and easy to learn, to promote mass literacy. (Both the scientific rigor and the noble motivation that went into it, and the resulting elegance, give it a lot of geeky appeal really.)
Actually learning Korean OTOH is another matter entirely, though :) (don't I know it ...).
Anyway, I think even without the ability to understand the words, type designers have experience and knowledge they could usefully apply to the Hangul script. I recently read this nice series by William Berkson on a new revival of Caslon's designs he's been making:
All that stuff he touches on there - rhythm, visualizations of regularity, avoiding the picket fence effect, etc. - should apply equally to making a good Hangul typeface. Or if not that, then the same sort of thinking and methodology could lead to new truths about what makes a good Hangul typeface.
I think what might actually be keeping designers from it though is the awareness that Hangul design is embedded into a very different typographic lineage, i.e. Chinese calligraphy and such. Their own Latin designs frequently pay homage to the past - reviving Caslon is a good example - and it must be a stark naked feeling to lack the same sort of historical and cultural awareness when trying to navigate Hangul typography. It definitely takes a lot of ego for someone from the West to show up and say they can just make a better Hangul font, I suppose - but I still wish more would be that ballsy.
After all, eyeballs and computer screens work the same everywhere.
I mean, yes this is true, but I think the point was that if someone isn't fluent in Korean, and isn't familiar enough with the alphabet, they'll not feel qualified to say if to a native Korean it would look good.
I studied Japanese for many years, and know the two phonographic alphabets quite well, yet I'd still defer to my native Japanese speaking friends when it came to determining if something was legible. I've found that things that are legible to me are sometimes not to them, and vice versa enough that I suspect a font designer with any humility would be quite uncomfortable designing a font with characters they weren't very familiar with.
Have you ever seen type in print that you find difficult to read because some of the characters are so stylized that they're difficult to make out? That'd be my concern as a non-Korean speaking/reading person developing a typeface. I believe that Hangul is an alphabetic system, but that the parts of a character block are somehow grouped according to syllabic units. I'd be very wary of developing a typeface for such a system because I'd be more likely to design a typeface that doesn't present the necessary information in a readable way.
There's probably more than you think, but the local market tends to use their own software. There also aren't necessarily lots of "look a-like" analogs to Western fonts.
Yeah it'd be nice if they used something like UFO (
http://unifiedfontobject.org/), or even Fontforge's SFD.
It should be possible to take each binary OTF, export it with fontforge, and create a "mirror" repository where you can see the changes in a more human-readable format.
Thanks, I'll use the \DisableLigatures.
I actually don't like old-style numbers (see the [lf] option for Fira), but its a matter of personal preference.
I wandered the internet for years looking for the perfect monospace font for me. There was never anything that fit; Ubuntu Mono was nice but a bit too "unprofessional", Liberation/Droid too boring, Microsoft/Apple fonts didn't fit either. I looked through so many font comparison sites, tried a whole bunch, just ended up sticking with the defaults.
Then I found Fira Mono. I use it everywhere. It looks great; it's very clear and easy to read, it has a nice style. Fonts are a very personal thing so thanks to Mozilla for finally letting me have one that was "mine".
Another font which is very nice for code IMO is Fantasque[0,1]. It's a lot less "rigid" than most other monospace fonts, but after some use I actually found that it helps readability overall.
Strange your list seems to be lacking DejaVu Mono. Just never came about it? Not that I dislike your final choice of Fira Mono. But I always thought DejaVu Mono was the best monospaced typeface out there for years.
After reading a few shell scripts in Fira Mono, I find the serif on the lowercase "r" very distracting compared to Inconsolata. The lowercase "i" too, even though it looks very similar to Inconsolata's lowercase "i".
Also, for some reason I find the dot in the number "0" to be more distracting than using a slash to distinguish it from an uppercase "O".
I kinda like it. It forces a comfortable min line height that makes it very readable. However, upon further investigation it breaks readability of text in menus/lists that have max height shorter than the expected standard fonts line height. Hence cutting off the text... huge bummer. Oh well, back to uncomfortably dense fonts :(
I'm not against that at all, but it doesn't really work when you're on a shared codebase with people who use spaces to align things based on the assumption of fixed-width fonts. Things like:
hash[:foo] = 5
hash[:sdfkd] = "x"
hash[:x] = "y"
Of course, I'm against doing this anyway, because it causes issues when you want to add an even longer key to the hash.
If you are using a decent text editor it's easy to keep things aligned. Emacs for example m-x align-regexp = will do the trick. I would assume vim, etc have similar options.
Realigning the values causes all of the lines to change in a line-by-line diff (e.g. as displayed by git diff). It also makes "git blame" less helpful, since every realigned line appears to originate from the alignment commit.
I agree -- but I'd think the work-around would be to do whitespace-insensitvie diffs? Which would probably be a good idea if the codebase uses indentation like this?
Elastic tabstops[1] are one of those things I wish was standard in the programming world, because it seems to have essentially no downside as long as tools support it.
Failing that, many text editors will provide some sort of realign command that will adjust spaces on adjacent lines so the columns line up as intended in these situations, and many diff tools and related functions like 'blame' commands in VCSes will allow you to ignore whitespace-only changes these days.
Personally, I prefer to have non-trivial code neatly lined up, despite the potential irritations when reviewing changes later. I find the advantages of highlighting patterns (and highlighting where a line didn't follow the same pattern as all the others) outweigh any practical issues where a few tools show diffs I would prefer to ignore.
I make an exception for Python, because PEP8 explicitly advises not to do this, and sometimes having a coding style that is consistent with everyone else is worth more than any of the above.
This algorithm sounds like it has a dreadful worst-case complexity. It can have to parse the whole file to give the intended result (eg. in the case of a dense table, when deleting a character at the end of the longest cell of a column).
It also has terrible partial results. For instance, removing the tab after `cell-missing` in the example triggers a weird alignment.
That is too bad, since the idea is bright.
PS. This is off-topic, but I cannot create a new thread on it, since it was submitted to HN six years ago and that old thread is locked: https://news.ycombinator.com/item?id=333626
FWIW, it's not that particular implementation that I'm in favour of. As you say, it has some issues.
Also, while the page I linked to was the first time I saw anyone offer a convenient name and write-up to cite, I should acknowledge that there had been discussions about using tab widths that varied by context long before that page was written. Many editors have provided related functionality where hitting tab once would automatically align your code blocks, function parameters, etc.
I suspect that for anything closer to the specific elastic tabstops idea I cited to become established, we'd need a distinct character rather than reusing ASCII spaces and tabs. This could work rather like the way various typesetting systems and DTP packages have "align to here" markers that don't necessarily introduce any extra horizontal space themselves but do indicate that consistency should be enforced across related lines.
I personally think that a standardised character like that and support for it in tools like editors and diff displays could bring several modest benefits: aside from the immediate convenience of aligning code more neatly if that's helpful, it could actually clean up a lot of whitespace-based diffs that tend to confuse tools today without necessarily having to ignore all whitespace, and of course it would improve the usefulness of proportional fonts when reading code, which I think is where we came in.
Do you create a new spreadsheet using a spreadsheet app every time your notes include tabular data? I ask because a proportional font would be incompatible with the table/spreadsheet syntax of every lightweight markup language I've used. I would hate to have to create a new spreadsheet using Excel every time I have new tabular data for my Org-mode-powered personal wiki rather than simply use Org mode's spreadsheet syntax.
I use proportional fonts for my latex editor, and have always been able to align my tables well enough in .tex files. Of course, latex output has no problem aligning table columns without using a fixed width font.
I tend to agree, I use monospaced fonts -- however -- what's wrong with tabs? Surely if you're using variable width fonts, you could pair them with tabs?
Let me know how that works for you if you ever write Lisp, Haskell, or have to deal with someone who thought they could make their $ALGOL_INSPIRED_LANGUAGE look cute by aligning everything into tables.
Mono space is a type writer anachronism. Lisp was designed in hype 60s and not many people write code in it; Haskell could benefit from better mathematical typesetting.
I've heard that going proportional would be bad, but I made the switch and have noticed yet any badly formatted third party code (I mostly use C#).
Haskell, despite how people talk about it, isn't necessarily that heavy symbol-wise. Table-based aligning makes haskell code look very good (esp. when dealing with a lot of pattern matching)
Haskell just looks horrible when set in ASCII at all; where did they come up with \ for lambda? It would definitely benefit aesthetically from at least more Greek use.
I know, but it's too subtle and makes the code look bizarre. Well, if there were lambdas everywhere, I'm not sure it would look much better...code would begin to feel more like a boring POPL paper.
Are you using a serif font? Because sans-serif is very bad when it comes to representing source code:
the characters 1lI and 0O all look alike.
For example Pidgin's choice of a sans-serif font always caused me troubles, had to either switch the font, or the system-wide sans-serif font to something where I can tell the difference.
Segoe UI. Honestly, I knew this would be a problem but I haven't had this problem yet. The most annoying thing is that subtraction (-) is too short in relation to addition (+).
In my ideal world, code would be typeset in proportional fonts, with mathematically appropriate glyphs chosen from a font with a comprehensive Unicode character set, including a proper minus instead of hyphen-minus.
The usual problems with this are arranging indentations/alignments neatly where you really do want them and avoiding an explosion of funny characters once you've got a large part of the Unicode character set to play with. Tools are pretty good at the first these days, but pity the poor Haskell developers if we don't fix the second. People will be writing logging libraries that use different levels of emoticon to save writing 'debug' and 'error'...
I'm a big big fan of Bistream Vera Sans Mono. It walks the line between being humane and being rigorous quite well, in my opinion. http://en.wikipedia.org/wiki/Bitstream_Vera
True, but using a built-in font does mean Firefox is consistent across operating systems. Unfortunately, it's tough to be consistent across both OSes and applications within an OS!
That's not what I want. I don't use the other operating systems, and I don't care if Firefox is consistent across them.
You care if Firefox is consistent, and that's just arrogance, because you are not the platform. If everyone did what you're doing, then the platform would have no common consistency at all.
Put away your designer arrogance; my Mac isn't your canvas on which to ruin platform consistency.
> my Mac isn't your canvas on which to ruin platform consistency.
So, you already have the solution: Safari. That is the the platform recommended, platform consistent solution you seek. It exists. With that being the case, what harm is there in other software accepting that just because Apple does it doesn't mean it's always the right solution? Even Apple can't settle on a standard font to use across all it's solutions. And using Apple as the gold standard assumes they never make or don't still have glaring UI/UX problems to overcome.
Put away your arrogance. Not all software needs to meet your exacting standards. Heck, even Apple disagrees with you!
It has nothing to do with a "gold standard", or "just because Apple does it". It also has nothing to do with Safari, or using an application solely written by Apple.
On the platform, we contribute to the ecosystem by respecting the value of the whole.
It's about humility: Understanding that you're operating as part of a larger whole, and that larger whole is more valuable to your customer if it is consistent and interoperable.
The only reason to diverge from the common platform standards is if your divergence provides more value to the user in a way that doesn't detract from platform consistency. Sometimes, people come up with novel new ways to do things that genuinely fit right in to the established platform norms.
Using a non-standard[1] user interface font to achieve cross-platform consistency isn't one of those cases.
Diverging for the sake of your UX designer's ego or your "brand identity" does not provide value to the user. In fact, it's robs the user of value to the sole benefit of your product/brand concerns.
Yes, yes they do. They've made many changes that violate your next statement:
> The only reason to diverge from the common platform standards is if your divergence provides more value to the user...
I'm sorry if you feel that there should be only standard font used for UI elements (there isn't in Apple products), or that other users values aren't equally valuable.
> It's about humility: Understanding that you're operating as part of a larger whole, and that larger whole is more valuable to your customer if it is consistent and interoperable.
Apple is the biggest violator of this across all their platforms. If they don't do it, why should anyone else?
You seem to not understand that Apple defines the platform; consistency has to start somewhere, and it's not going to emerge by committee.
Apple and 3rd-party developers extends conventions by exploring coherent and consistent extensions to the platform.
Mozilla choosing to use a font that nobody else uses, for the purposes of consistency across their browser, not the platform, has nothing to do with what benefits the rest of the ecosystem, or by extension, the users, and everything to do with what Mozilla wants.
In this case, the decision is arrogantly wrong because it's predicated on an over-inflated sense of Firefox's position relative to the entire platform and ecosystem of consistent applications, and this position is based on self-interest, putting branding interests and their designer's ego ahead of the interests of their customers.
Design that doesn't put the user first is egotistical by nature.
There's nothing to get used to; design isn't new on Apple's platforms. If anything, Apple has driven software design more than any other platform or company.
Apple's customers value -- and paid for -- a consistent ecosystem, on which Apple defines design guidelines and HIG requirements. Apple developers and designers work together to maintain a consistent ecosystem and the resulting mutual benefit.
The problem is perception. If people associate the name with Hitler (and I think they do), then no matter what the "correct" definition is, the name will be what people think it is.
This is how languages evolve. If enough people think something about a word, then over time there is a good chance that word will morph into the the new meaning. The same thing happens with pronunciation. For example, originally the "correct" pronunciation of the word "forte" was "fort", however most people think and use "fortay". Now most dictionaries will give both pronunciations or even the "incorrect" one and over time it will almost certainly change into "fortay" completely.
If we are going to be pedantic, then „Führer” means someone who leads, whereas „Leiter” is more close to the English term ‘leader’. ‘Leader’ and „Leiter” share the same etymology, „Führer” does not. The same difference is present in Danish as well: »leder« vs »fører«.
Essentially, „ein Führer” is more than just a leader.
Never mind old Adolf -- the bit of pedancy I really admire in your post is that you consistently and correctly use different typographical quoting conventions for German, English and Danish.
This is a trait I adopted a year ago for own filthy pleasure. I felt it was wrong to quote sentences and/or words in other languages with quotation marks meant for another language.
I am confident other people have different views on this. Fortunately for most people, I don't get to write much on languages. Strangely, while my dyslexia is somewhat preventing this, it is also the same disorder that is causing me to become more obsessive about my writing, including the quotation marks.
Edit: To ensure it, I have reconfigured my keymap to have all the symbols ready as keys.
>‘Leader’ and „Leiter” share the same etymology, „Führer” does not.
You're not being pedantic, you're introducing an unnecessary element. The etymology of a word isn't relevant in determining its current meaning. Führer is usually translated as leader and there is nothing wrong with that translation.
Perhaps, but „Führer” is far more affectionate in a way than „Leiter” is. I do not disagree with the translation, but its association with Hitler in English is not entirely inaccurate.
And Hitler is just a last name that tons of people have had, so what would be the problem with calling it Hitler? Obviously, the problem is with the inevitable connotations the name will have.
'Tonnes of people' might be an overstatement. Other than the immediate relatives of Adolf Hitler (father, mother, siblings, half-siblings and their children), no other people with the surname Hitler are known.
And there is a good reason for that. The surname „Hitler” is an alternative spelling of „Hiedler”. Hitler's father, Alois Schicklgruber, decided to change his name to his stepfather's family name, „Hielder”. Likely because Alois was born out of wedlock and wanted to rid himself of his old surname once he became established. It is unknown why he changed the spelling to „Hitler”.
Adolf Hitler did comment once that he thanked his father for changing the surname, as „heil Schicklgruber” would have sounded awkward.
I'm very impressed by this font, since it is the only font coming out of the open source community that i can remember which has hinting info, meaning it will still look good at font size 8 without smoothing.
Do I understand the post correctly that the font is bundled in Firefox and thus usable with no download lag? (If so, does that go equally for all variants?)
I've instantly fallen in love with (the mono version of) this font. One thing that is a bit unfortunate though is it seems to have some odd line-height/descender thing going on.
In Sublime Text 2/3 I can fix this easily with:
"line_padding_top": 0,
"line_padding_bottom": -2
But in iTerm2 all you get is a basic 'vertical character spacing' setting, and the best I could do looks like this:
Which looks more like your screenshot, and is no longer lopsided, but IMO still looks pretty bad. I guess I just like tight lines. The huge cursor block is... I don't know distracting somehow. My current terminal uses plain old Menlo and it looks like this:
So glad that I found this font I have a project this weekend this will be perfect for. Have been looking for a new heading font for a while. Have been having a lot of fun with Campton and Open Sans (my standard) but this one has such a great style.
As we discuss this, can HN get away from using Verdana? The site looks less than pleasing when viewing from a FOSS Linux install; to get the HN official look, I must install ttf third party stuff.
It is a courtesy to explain downvoting when there is no controversy evident in the post.
Let me explain my post: There are myriad open fonts available on the web, and webfonts is a known, stable feature of web browsers. There is no reason to use proprietary fonts on a tech website of such a caliber.
I find I prefer fonts that I don't have to anti-alias. It seems all of these look quite horrific in iTerm2 unless you turn on anti-alias which then makes them feel to soft and fuzzy to me.
Looks like it's down, and the official links for download don't seem to work anymore. It's available here on github tho: https://github.com/mozilla/Fira
It's not great. The "Me" in "Medium" in that PNG is most egregious. I'm not sure whether it's a problem with the font or if their designer was messing around with letter spacing in Photoshop.
It is also used in Racket's documentation: http://typographica.org/typeface-reviews/fira-sans/
And here is how I use it in LaTeX: