I was standing at the side of the room at TypeCon 2014 in DC for the SoTA Typography award, given to one person each year for contributions to the field of type design. Honestly, I was trying to decide whether to bag out early and get some dinner, or wait and hear the speeches. I was sure the award recipient would be somebody deserving, but that leaves a lot of room. Victor Gaultney of SIL, who specialize in fonts for global language support, was standing next to me. We chatted and agreed that we had no idea who was going to get the award this year.When the award presentation began, in the first few moments it became apparent to us from the preamble who was getting the award. I couldn’t help myself. “They’re giving it to Fiona!” I burst out, turning to Victor. We looked at each other, did a spontaneous fist bump, and shouted “YES!” in unison, doubtless disturbing the nearby attendees (sorry about that, folks).
I simply couldn’t imagine a more appropriate recipient for the award, and certainly nobody as deserving whose early career was so long unsung in public. Needless to say, I stayed through to the very end of the speeches and ceremony.
While it is not precisely true to say my younger daughter is named after Ms. Ross, neither is her first name being Fiona completely coincidental. Fiona Ross is an amazing person in both her professional achievements and as a human being, so sharing a name with her hardly seemed like a bad thing. Ms Ross has made immense contributions to global type design: in her work heading up Linotype’s non-Latin type design team; as an educator at the University of Reading for their MA Typeface Design program; and creating and overseeing commissioned type designs at Tiro Typeworks (with John Hudson, Ross Mills and Tim Holloway, among others) for clients such as Adobe, Microsoft, and Harvard University.
Typefaces designed personally by Fiona (such as the Linotype Bengali) or by her team remain among the most widely used typefaces in the relevant parts of the world, their equivalents of Times and Helvetica.
I had the occasion to hire Tiro, and hence Fiona, when Adobe needed Arabic, Hebrew and Thai typefaces. The team did splendid work on all three, as well as developing a quote on a set of Indic typefaces, some of which would eventually be commissioned by Adobe, years later. Fiona was polite and gentle early on when I made a criticism showing my complete and utter ignorance of the norms of Thai type design, about which I can only say… I was young and foolish.
That is another theme in her career: Fiona Ross has also been unfailingly helpful and absurdly humble. She does not like to be called an “expert” on non-Latin type design, preferring the term “specialist.” But as must undoubtedly be clear by now, if she is not an expert, then there must be no experts, as she is in the top tier of the most knowledgeable people in the world in this area. This willingness to share her knowledge and erudition has magnified her impact on the world and on the field of type design. No better award candidate could be imagined.
- The complete text of John Hudson’s speech praising Fiona Ross and her career, on the occasion of her receipt of the SOTA Typography Award.
- Harvard University Press on Fiona’s work with them.
- University of Reading Typography blog on the award.
The good folks at Adobe just posted a huge article by Tamye Riggs covering Adobe’s type history from about 1991–2006 or so, focused especially on the invention and later abandoning of multiple masters and the rise of OpenType. It features the first and only public comment from Carol Twombly on her departure from Adobe and type design. It also has several quotes from me.
In general this is a really comprehensive article. Still, I am thinking I will write some more about the reasons OpenType succeeded where GX and MM did not.
Wired magazine’s puff-piece on Google’s Roboto typeface revisions is really bothering me. I thought if I held off, I could just do a few sarcastic tweets and be done with it, but no.
I am not a huge Roboto-hater like some folks in the type community. I just object to uncritically publishing quotes that make blatantly false statements.
“UIs [user interfaces] are crafted from images and type,” Matias Duarte, Android’s head of design tells WIRED. “But the idea of having a typeface that’s thought out as a UI typeface—that’s not been done before.”
Well, that’s pretty much simply false. (UPDATE: Duarte says he thinks he was misquoted, basically he was trying to just say UI typefaces are hard, and Roboto had a particular challenge in needing to work in a wide range of contexts and types of devices.)
[Perhaps not Duarte, but apparently the Wired author was] unfamiliar both with an obscure operating system called “Windows” and its typefaces Segoe UI (introduced in Windows 7) and Tahoma (introduced in Windows 95), both of which were specifically designed/intended for UI usage. Not to mention Chicago, developed for the original Mac OS back in 1984. (UPDATE: Plus, there is Prelude, designed by David Berlow and Font Bureau as a UI typeface for the Palm Pre operating system—when Duarte himself was in charge of UI for the Pre. Not to mention Android’s own Droid Sans, also designed as a UI typeface.)
A slightly weaker argument could be made for Lucida Grande (the Mac OS X UI font), which is only slightly tweaked from Lucida Sans. Of course, Lucida Sans itself was specifically designed for low-res screens and the like. Designer Chuck Bigelow got a MacArthur “Genius” award for his work on the family.
There are seven substantial paragraphs to the article, but both the people quoted are on the Android team. Thus it avoids mentioning the most famous thing anybody has said about Roboto, ever: Stephen “Stewf” Coles calling it a “four-headed Frankenfont” in a strong attack on the design philosophy behind it.
This is also why there is so much puffery throughout the article emphasizing how the typeface is designed for performance rather than aesthetics. Such choices do certainly explain most of the changes from v1 to v2 of Roboto, but “performance over aesthetics” is clearly false as a general proposition about the typeface. My big problem with Roboto is that the choice of closed counterforms for many letters and numbers (35CGSacs) is an inherently anti-legibility choice. Yes, they had more of these before the revision, and some (5) have been slightly improved, but they need to finish the process of transforming it into a different typeface if they want it to be an outstanding UI typeface.
Indeed, I would argue that such closed shapes are stupid bordering on criminal in a user interface typeface. There is a reason that most other typefaces specifically designed for user interfaces have used open counters, and that is because there is massive evidence that tells us these shapes are more legible (see for example the research cited in Sofie Beier’s book on the subject). Legibility should be
a the paramount concern for a user interface typeface.
Roboto designer Christian Robertson explains the mix of open and closed shapes as saying that they create an appealing texture in body text. Which is lovely and all, but not as important as legibility.
That said, to be fair, Apple is doing a much worse thing in choosing Helvetica Neue as their UI typeface, first for iOS and soon for the next version of OS X. They too have gone to lengths to declare publicly how they are optimizing it for legibility, which is rather like trying to polish a turd. Helvetica is inherently anti-legibility. The only way to make it otherwise would be to change it so much that it doesn’t look like Helvetica any more. Sadly, that is not what Apple is doing.
Aside from the business of being first with a dedicated custom UI font, if Google and Apple were to explain that they are making their UI font choices for design reasons, that’s fine. But when they (or Wired) start touting the awesome legibility and functionality of their choices, I have to call them out on it. Nonsense.
I just finished creating an organized page of type design info and links. Enjoy!
Are you a user of fonts who needs to tell if a font is well made, or an aspiring novice type designer? The March–April 2014 issue of Communication Arts features my article on evaluating font quality, “How to Tell If a Font Sucks,” on p. 24—now online as well!
It looks like it is hard to see the subtleties in some of the graphics in the down-res web-ified version of the article, though the print mag looks great. I will see about posting a version with high-res images in PDF.
I’m really pleased with this article. My new editor Robin Doyle at CA did a great job helping me clarify some points and figure out where more graphics were needed.
That said, there are some corner cases and subtleties around this discussion that I didn’t have time or space to get into in the article, which was already long and involved. But that is what blogs are for.
Although I stand by everything in that article, typefaces that are deliberately naïve/unsophisticated are one place for legitimate exceptions to some of the guidance I give in the article. For example, I had a lovely discussion with some folks who made a typeface based on some classic road signs. The original signs did not use optical compensation at stroke joins (point 5 in the article), so they didn’t do it in the typeface either. Although I might rarely be interested in going that way myself, I have to agree that it was a perfectly legitimate design choice, given the origins of the typeface as a signage revival—even though in many another context I would be calling it crap!
Optical compensation at stroke joins is also specific to certain typographic traditions. Certainly for Latin-based fonts (English, French, German, Hungarian, etc.) it is nearly universal, as it is for Cyrillic (Russian, etc.) and Greek. But some writing systems do things differently, such as Devanagari (used for Hindi, Marathi, Sanskit).
Non-western writing systems can also change other assumptions. For example, the idea that straight-to-round transitions (point 6 in my article) should be very smooth is very much not the case for Thai.
Anyhow, check it out and let me know if I can clarify anything else!
Last week I wrote about posting five FontLab encoding files for Adobe Latin character sets.
Today I posted in the same Github repository three FontLab encoding files for Adobe Cyrillic character sets, and updated the five Latin files with a few added currency symbols and glyph name changes (as I expected I might).
The character set definitions underlying these files were built on a bunch of research I did at Adobe back in 2006–08, with additional work by Miguel Sousa. The headers include much detail on the differences between each set, and the languages covered. Both of these character sets reflect the latest data from Adobe on how they name glyphs and what they are including in current fonts (not including OpenType alternates and features, mind you). The headers of the files have some interesting details and history, especially on the Cyrillic side.
Thanks as always to my old friends at Adobe, including Miguel and David Lemon, for their willingness to share production information with the type design community.
I dedicate this post and my work on the Cyrillic encoding files to the memory of Emil Yakupov, CEO of the ParaType type foundry in Moscow, who passed away just a month ago at the age of 56. His advice and feedback on Cyrillic character sets—among many things—was invaluable to me. I remember one of our first meetings, when Emil gave me a pair of ParaType catalogs as I was first becoming involved with Cyrillic type design. I still consult them to this day when trying to internalize what forms different Cyrillic characters can take in different font styles.
Also, Emil remembered by Adam Twardoch.
I just posted some free FontLab “.enc” encoding/character set files for the five Adobe Latin character sets, in my Github repository.
To install, quit FontLab, find the “Encoding” folder in the shared “FontLab” folder, and drop the files in there. Restart FontLab and these will be available as encodings.
Caveat: these may soon be updated to reflect minor tweaks Adobe has made since I described the character sets and posted the data, almost six years ago. Probably mostly adding currency symbols such as the Indian rupee, Turkish lira, and perhaps the Russian ruble and Ukrainian hryvni, and perhaps changing glyph names for the S and T with comma accent and cedilla.
This follows a couple of possibly-useful FontLab scripts I posted a couple of weeks ago, in the same place.
I have started posting a few scripts in my own repository on GitHub. They are libre (free, open source) under an Apache 2.0 license.
- Generate-substitutions.py: Select some glyphs in the font window. Run the script. It will automatically generate useful OpenType feature code (in .fea/AFDKO syntax) in the Output window, which you can copy/paste right into the appropriate feature. The script works with both simple substitutions and ligatures as long as you follow standard Adobe glyph naming standards (appropriate use of period and underscore). It does not work with complex cases involving multiple-feature interaction, sorry.
- Make-numbers-from-dnom.py: First you need to create some numbers sized and positioned for use as denominators. The script will take all the glyphs in your font ending in “.dnom” and create numerator, superscript and subscript versions using the dnom glyphs as components. If the font is an italic font, it will use the italic angle of the font to calculate how much to shift the components horizontally while moving them vertically. NOTE: the vertical shifts are hardcoded in the script now, but easily edited. Future improvement ideas: pop up a dialog to enter the vertical shift numbers, and/or try to auto-calculate them.
Unfortunately, my “best” (or at least most complicated) script is very specific to my workflow on developing my Cristoforo family (it does the steps detailed at the bottom of this blog post). It is a heavily modified version of Ben Kiel’s “Better Generate Font” script. I chose not to post it as the workflow is just so very peculiar to my needs and does things like put my license URLs in the font, but if you want it for some reason, perhaps as a starting point, ping me.
I am very excited to be getting my visa for India today! I’m one of the instructors for a 3-day advanced type design workshop with FontLab. Registration is now open on the FontLab blog, and there is a detailed schedule of planned talks.
One problem with releasing lots of pre-release builds to my Kickstarter backers is that I don’t test every single one as much as I otherwise would. Generally any errors are minor, but earlier today I managed a moderately important one: I didn’t remove overlapping paths in my outlines during the build process. Well, actually, I did remove overlap, but as I did not first decompose my composite glyphs, it didn’t fix most of the problem cases.
Why would you want to have overlapping paths in your glyph outlines, and why/when would it be a problem?
Here are several glyphs (as shown by H. James Lucas) that had overlapping paths in this last build:
So, clearly it’s a problem if they render badly in some apps. Interestingly, this is dependent on not only what is doing the font rendering, but also what size the glyphs are rendered at. Adobe’s core rendering engine has three or four different rendering modes, and what it picks is size-dependent.
Overlapping paths are sort of okay in TrueType fonts—the rendering engines will deal with them better. But they will still produce bad results if a user does something like apply an outline or stroke to the text.
So why do I leave these things in while developing the font? Well, during development, it is useful to keep the basic elements separate, and only remove overlap later on. So for example, if I change the underlying swash H glyph, I want the Swash-H-with-bar to automatically pick that up. Similarly, the C shape seen in the colon currency symbol (used in Costa Rica and El Salvador) is shared between the Ghanaian cedi, the euro symbol, and a stylistic variant of the cap C. I used the same primitive elements in the ffj ligature in numerous other ligatures (including ffi). And so on.
Of course, as leaving overlaps in the final font causes problems, normally I take care of this as part of each build. My usual build sequence for creating OpenType OTF fonts from my FontLab file:
- Create a “next version” and make sure version string has been correctly incremented (in several places), including in the file name itself.
- With the current version of the file
- Remove all hinting (shift-F7 in FontLab Studio 5 for Mac)
- Select all glyphs in font (Cmd-A in FLS)
- Autohint all glyphs (F7 in FLS)
- Save file
- Then the following actions, done without saving the file again, to preserve original data in the FontLab file:
- Decompose all composite glyphs
- Remove overlap (Cmd-F10 in FLS)
- Export OTF font (Cmd-Opt-G in FLS) with correct version number in the file name
- Change license URL string to point at the personal license
- Export OTF font again with “-NC” (non-commercial) in the file name, in addition to the version number
- Close font without saving file
Anyhow, in this particular build I missed the “decompose” step, so all overlaps involving composite glyphs (most of them) still overlapping. Of course I have fixed this, and am sending revised fonts to my backers.