Today’s announcement of variable fonts in OpenType 1.8 represents a renaissance of the functionality of multiple master and GX Variations capabilities in mainstream fonts. With the announcement made jointly by Microsoft, Google, Adobe and Apple, it also marks a surprising and new level of multi-company cooperation in font standards, at a level I for one have never seen in my nearly two decades in fonts.
The need for increased cooperation has been brought home in the past couple of years with the lurching and dispersed movement towards color fonts. The idea with color fonts is that there are uses for being able to spec multiple specific colors in the glyphs of a font, whether for colorful emoji or multi-color letters. For color fonts, there were four different approaches that all deployed and are now in OpenType. Microsoft invented one, Apple another, Google a third, and Adobe plus Mozilla a fourth. One can debate the merits of each approach, but clearly developing them in isolation and putting four competing approaches into the OpenType spec has not helped the adoption of any or all of them. (Apple originally said their approach was only intended for internal use and did not submit it for OpenType standardization, but changed their mind and submitted it at the last minute for OpenType 1.8, so the spec just went from three to four color fonts approaches.)
In the end, although developing separately allowed for the secrecy and control, it did not yield an ideal long-term outcome. Sure, each vendor can make fonts that work in isolation in their environment, but it should come as no surprise that users and font creators have been slow to embrace these color font solutions that worked with only platform and limited browsers.It seems clear that the decision-makers and reps of the companies involved were at least somewhat chastened by this outcome. I believe this lesson helped inspire increased cooperation on variable fonts.
- FontLab announces support for variable fonts
- Official variable fonts announcement article
- OpenType 1.8 specification
- Adobe’s announcement
- Google’s announcement
I need feedback!
Prior to this year’s TypeCon Denver conference, which I’m at right now, there was a fairly hot twitter discussion about the relative lack of female speakers in the lineup, at about 17%. The discussion was nicely captured by Indra Kupferschmid. It got an eloquent response on Medium from Elizabeth CareySmith, and spurred major interviews and research from Dyana Weissman, which you can read in her epic article/series on Typographica.
When I saw the Twitter discussion (a few days late, due to travel), I started a discussion with my fellow ATypI board members, and started crunching numbers about our own conference. I found that we have about 30% female attendees the past two years, and also about 30% female speakers last year and in the coming conference this year. (Although this year is differently skewed, with 50/50 women in the opening two-track day with workshops, and fewer in the single-track portion of the conference—unlike last year.) This also tracks well with the percentages of submissions, at least for this year.
Women have a much higher participation level in type and type design in the younger generation, the last 5-10 years has really seen a big shift. Given that, it might be tempting to think that if our speakers reflect the same diversity as our (younger-skewing than speakers) attendees, we are doing okay. Is that a fair assessment? Or do we need to do more?
(Oh, and yes, I and others are also aware that there are other diversity issues not only among conference speakers but in our entire industry: quick, how many black TypeCon or ATypI speakers, or type designers, can you name?)
This is an active plea for feedback about gender diversity in the ATypI conference in particular—most especially from women in type and type design. You can message me privately if you’d rather not say something public.
(I’ve already had one board member say that,
which made me sad. Damn. but it turned out she just meant she thought it was boring and didn’t think we had a problem with gender at ATypI conferences. Anyway, I welcome feedback, really.)
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.
(Note: Tamye’s series of articles on Adobe Type has been released as a full book. Very nice. Copies were in the conference-goers’ goody bags at TypeCon 2015 in Denver.)
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.
NOTE: These were later updated to reflect minor tweaks Adobe has made since I described the character sets and posted the data, almost six years ago. I added currency symbols such as the Indian rupee, Turkish lira, Russian ruble and Ukrainian hryvni, and changed a few glyph names to match current Adobe practice. 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.
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.