Fira Sans: a Free, Open Source Typeface Commissioned by Mozilla

Nice, but I didn't mean putting the binary files on git. It's not easy to see changes since the file format is not text based.

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.)

So it's actually quite easy to pick up and be able to read it fluently (you can have your first successes within 15 minutes, and have it pretty much down within days). Here, have a comic: http://www.ryanestrada.com/learntoreadkoreanin15minutes/inde...

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:

http://ilovetypography.com/2010/11/02/reviving-caslon-part-2...

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.

But wouldn't being illiterate in Hangul be the most effective "Lorem Ipsum"?

OMG, Chrome completely fails to render the characters on that Google result page. http://i.imgur.com/fY8ZhZH.png

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.

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)

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.

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.

[1] http://nickgravgaard.com/elastictabstops/

Would you use that in the example I gave, in the middle of the line of code? I don't quite see how that would work.

Lots of use use something that can export to latex :)

I have the same issue. A sad thing, the font looks good but the line spacing is way too much for my taste.

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.

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.

Heck, even Apple disagrees with you!

No, they really, really don't.

[1] https://developer.apple.com/library/mac/documentation/UserEx...

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.

I did this when quoting English and German language works in an essay recently. It felt wrong, though.

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.