Berkeley Mono was launched earlier this year on Hacker News. We just want to say thank you to all who provided feedback. Since then, we've made several optical refinements, and bug fixes as well as added a handful of new glyphs.

Berkeley Mono v1.008 is now available. If you're an existing customer, please login to download the latest release and font packages. We also want to share some progress on Ligatures, the top most requested feature. Ligatures are a hotly debated topic and we'll be taking a balanced and objective view of it.

In other news, we're launching Indie Commercial License for small businesses.

And lastly, we've made a few changes to our website and account management system. Let us know if you come across any issues.

v1.008 marks the first update since the launch of Berkeley Mono. Lots of changes and refinements to the optical aspects of Berkeley Mono. Notable optical refinements:

• [U+0072] Lowercase 'r'
• [U+0037] Number '7' with a stem
• [U+0065] Lowercase 'e', improve small size legibility
• Punctuation is centered and has equal side-bearings

If you're an existing customer, get the latest release:

Download

If you'd like to get a copy:

Purchase Berkeley Mono

Berkeley Mono v1.008 also includes Powerline glyphs. These are allocated to special private Unicode range as per the powerline specification. If you'd like to install it, please follow this guide. For details, see Unicode proposal L2/19-068R2 (PDF) specification. Currently, the powerline glyphs are mapped to the following range. Should the Unicode standard be adopted, we will update Berkeley Mono accordingly.

Coming soon!

Listen. We have some thoughts about this ligatures thing.

Berkeley Mono's aspires to be the finest typeface for programming. Writing code should be a precise and unambiguous process. Ligatures violate this implicit assumption by changing stuff on the fly, often merging glyphs or entirely replacing them. Totally wild for an activity that demands precision and explicitness. That said, we're sympathetic to why ligatures are used and many programmers prefer to use them. We've analyzed several takes on ligatures across the programming community and the following is our quirky map of the battlefield.

Proponents of Ligatures

• Ligatures are never stored in the code files, it is purely a private presentation layer.
• Ligatures can be instantly turned off in the IDE or by using a different typeface without affecting the code.
• The compiler has no idea it was fed ligatures.
• Ligatures are like syntax highlighting, they make code easier to read and parse for humans.
• Ligatures do not change the underlying unicode representation.
• Ligatures reflect my training in academics. I am used to looking at formal mathematical notations.
• I am a Theoretical Physicist.
• Ligatures are pretty and aesthetically cute.
• Ligatures are no different than people insisting SQL keywords should be in ALL CAPS.
• We are humans, we don't give a damn about what the machines think or want. Obey us.
• Programmers are the customers, Typographers are the vendors. Requirements are set by the customer and the vendor delivers according to those requirements.
• I seldom print code for others to read or share on my screen. If I do, I turn off ligatures.
• Ligatures do not infringe on other people's rights, they can view the code as they please in their own typefaces with or without ligatures.
• No one is forcing anyone to use ligatures. It's a personal choice and doesn't affect others.

Opponents of Ligatures

• One key press = One character printed on the screen. This should never be violated. We've made physical standards too (keyboards).
• Ligatures are a needless decoration, a distraction.
• Ligatures confuse others who are looking over my shoulder. If I temporarily turn them off, then I am confused after years of training in looking at ligatures.
• Most code available to read out there has no ligatures unless I change the typeface in every single context.
• I am a Compiler Engineer.
• I read programming books. I publish programming books. In both cases, we have a common expected standard of language syntax and the glyphs that encode it.
• Programming syntax is designed by programmers too, with common input methods in mind (Standard ANSI/ISO keyboards)
• Fails WYSIWYG.
• Programming languages such as Haskell and Julia natively support Unicode chars, so we should just write code with proper unicode chars, not some faux presentation layer.
• ASCII-128 or gtfo.
• Although ligatures are purely optional, they create mass societal unrest and chaos.
• Ligatures promote impreciseness, ambiguity, and implicitness.
• Unicode > Ligatures.

As you can see, we have a lot of firepower wielded by a diverse group of warriors (compiler engineer, vs. full stack engineer, vs. scientist) as well as an armada of next generation combat vehicles (C vs. Haskell); a massive fog of war. To further equip yourself with strategic aspects of the battle, there are a couple of well written articles about programming ligatures that we recommend:

• Ligatures in programming fonts: hell no, Matthew Butterick [2019]
• Monospaced Programming Fonts with Ligatures, Scott Hanselman [2017]

We have also interviewed several engineers who have varying affinity towards the idea of ligatures. Customers who reached out to Berkeley Graphics regarding ligatures—thank you for the discussion.