by Paul D. Hunt
Following up on Source Sans
The public reception of the release of Source Sans Pro last month was very encouraging. My colleague, Ken Lunde, pointed out that this was not Adobe’s first open source font as Kenten Generic has been available for some time now. But I stand by my claim that it is Adobe’s first open source type family. Sorry, Ken. The blog post announcing the family’s release has been our most popular in the history of Typblography and the news was picked up by major tech media outlets such as Wired, Ars Technica, The Verge, &c. As of today, the fonts have been downloaded over 68,250 times from SourceForge.
One particularly surprising aspect of Source Sans’s release was the amount of interest generated by the teaser graphic of the monospaced version. It seemed that this generated about as much buzz as the fonts that we released. Brackets, the open source code editor created by Adobe, has just recently implemented the regular weight of Source Code into their project. Likewise, the font will be integrated into Adobe Edge Code, which was announced this morning at our Create the Web event in San Francisco. The complete family of six weights will also be available as part of our new Adobe Edge Web Fonts service, which was just announced this morning.
As a font developer, I spend a good chunk of each day coding in a text editor and reading output messages from a terminal window, so I can appreciate the importance of a good monospaced font. Of course there is no technical limitation to using monospaced fonts when coding, but it is a very useful convention. When the Brackets team reached out to us on the Adobe type team, asking if we could develop a coding font for their open source application, we thought it made sense to adapt Source Sans, which I was working on at the time. Personally, I felt that I could use this opportunity to create a coding font that I would want to use myself. Given the existing family name, I couldn’t resist the opportunity to name the monospaced variant designed for coding applications Source Code.
Adapting the design
To my eye, many existing monospaced font suffer from one of three problems. The first problem that I often notice is that, many monospaced fonts force lowercase letters with a very large x-height into a single width, resulting in overly condensed letter forms which result in words and text with a monotonous rhythm, which quickly becomes tedious for human eyes to process. The second problem is somewhat the opposite of the first: many monospaced fonts have lowercase letters that leave too much space in between letters, causing words and strings to not hold together. Lastly, there is a category of monospaced fonts whose details I find to be too fussy to really work well in coding applications where a programmer doesn’t want to be distracted by such things.
In designing Source Code, I tried my best to avoid these common design flaws. I had already put significant thought in how to differentiate similarly-structured characters in Source Sans, so many of its design features translated well in adapting the design to a monospaced version. Modifying the uppercase letters was mostly a simple task of condensing the glyph shapes to fit within the standard monowidth of 60% of the em square. Only the M and the W needed to be more heavily modified. I also swapped out the simple, single-stroke uppercase I with a serifed version to better fill out the advance width.
In adapting the lowercase letter shapes, I wanted to keep the more elegant vertical proportions of Source Sans. Keeping the moderate x-height of the parent family allowed me to retain the salient features of each letter so that each character shape can be readily deciphered. In particular the greater difference in letter heights between upper and lowercase makes it much simpler to differentiate lowercase o from uppercase O. The challenge in adapting the lowercase letters to monospaced versions is to extend them enough so that words and strings hold together, while preventing them from becoming so wide that they appear too much of a caricature.
As with Source Sans, I sought to distill each letterform to its simplest form, only adding serifs to the tops of i, j, and l in areas that would seem like empty gaps otherwise. The figures of Source Sans were made somewhat smaller than the capital height to provide for greater ease of reading in text settings. I kept this feature in Source Code, where this difference also serves to further distinguish 0 from O, and 1 from l. In coding, many of the characters we take for granted are more meaningful symbols in computer languages. To make these more legible, I increased the size of punctuation marks, and optimized the shapes of important characters like the greater- and less-than signs, and adjusted heights of dashes and mathematical symbols so that these align better with each other. Many of these important adjustments came from input we received from working closely with the Brackets team, and I thank them for their valuable contributions to this project.
Where are the bitmaps?
I understand that many coders prefer working with bitmapped monospaced fonts. If you fit this description, I regret to inform you that you will be disappointed at the Source Code fonts in this regard. In today’s rendering environments of Retina displays, DirectWrite, Clear Type, and font smoothing we decided to target antialiased rendering environments only. According to my fellow font developer, Frank Grießhammer, “Probably, monospaced pixel fonts optimized for 10, 11 and 12 pt. are the only genre in which one can say ‘Yes – there are enough of them already.’”
Today I’m glad to announce that the complete Source Code family of six weights is ready for primetime and is available through the same channels as Source Sans. You can download the fonts and source files from the Open@Adobe portal on SourceForge. You can clone and fork the project on GitHub. You can also use the fonts on the web through Adobe Edge Web Fonts, Typekit, WebINK, and Google Web Fonts. Again I have to thank my colleagues on Adobe’s type team for all their invaluable help and support with this project: thank you Miguel Sousa, Frank Grießhammer, and Ernie March.