Phinney on Fonts About Thomas & the blog Phinney on Fonts main page

Picture of ThomasThomas “my other car is a sans serif” Phinney on fonts, typography & text. Geeky troubleshooting and info for font developers and users. Consulting & expert witness for fonts & typography.Read more...


Font Production Person Needed, first half 2021 »

NOTE: The position has been filled! 

Qualifications:

Features

Details

WHAT? I have been commissioned to continue a variable font project I started this year with Google. In 2020, I did a first version with a weight axis, but now I need to do a big expansion in 2021—with two more axes. The work is primarily adding further masters to an existing typeface, not original design work. Given the desired timeline, there is too much work and not enough time for me to do it solo. 

WHEN? This would start at or near the beginning of January and run through May.

WHO? So I am looking for one more person to help work on it in FontLab 7; currently it is me plus some help from Vassil Kateliev. This will be work for hire, and the resulting typeface will be owned by Google (not open source). Vassil is our scripting guru, and can do some amazing things with automation—his contributions in that regard were invaluable in the version 1 project. This time he will likely also have some hands-​on production role. I will do considerable production work myself.

PUBLIC? Unlike some of my/​our recent projects, this isn’t open source, and I can’t yet talk about it publicly. For candidates who seem plausible, I will get you to sign an NDA with Google, and then I can tell you the details, and we can talk more!

MONEY. This involves a fixed amount of money, with the hours dependent on your experience/​productivity. Although I am doing the primary screening and will be supervising the work, you will negotiate pay with Google, and be paid by Google (monthly after the end of each month).

COMMENTARY. This is not artistically interesting work, but it is somewhat technically interesting, and you are working with some arguably nice people. Pay is OK, and it may lead directly or indirectly to future work. It will be a high-​profile project, but I am sorry to say it is not yet known if we will be able to talk about our contributions afterward.

DIVERSITY. Diverse applicants are especially welcome. 

Process:

Contact me with the form below. If you seem like a plausible candidate, I will have Google share a non-​disclosure agreement (NDA) with you; you signing the NDA will allow me to explain the job in more detail.

Note that getting the NDA requires your postal address, and company name if any.

Science Gothic—Design/Production Person Needed »

(UPDATE: Applications are closed. I definitely have enough qualified people to consider! Anyone who expressed interest should have heard from me before 5 pm PST, August 6th, 2019.)

Today I got back a signed contract, commissioning Font Detective LLC to do a new version of the classic American Type Founders’ typeface Bank Gothic (Morris Fuller Benton, 1930–34), for Google Fonts.
UPDATE: We are calling it Science Gothic.

This will be a multi-​axis Variable Font. I have done a fair bit of prototyping, but there is lots of work ahead! And, given the timeline, too much work and not enough time for me to do it solo.

Freelance Type Design — Open Source Bank Gothic, FontLab VI

The new Bank Science Gothic will have an extended Latin and Cyrillic character set (about 1200 glyphs). It has weight, width and contrast axes, plus an oblique axis as well. I am looking for at least one more person (maybe two) to help work on it in FontLab VI; currently it is me and one p/​t person. 

The typeface has 3 x 3 masters for weight/​width, and then double that again for contrast (and again for italics, although that will be basically oblique and largely automated). Luckily the square-​geometric design is well-​suited to this treatment and makes for mostly easier editing.

An initial demo-​ready deadline will be the end of August. Full-​time availability preferred, although the first week or so may be a bit slower. Aiming to have the font final in late November. This will be work for hire, and the resulting typeface will be open source, and licensed under the Open Font License.

More Bank Gothic in use—it’s everywhere! (Avengers Endgame movie title in the film, for instance.) But this is our chance to make it massively more versatile and flexible, and available to everyone.

How to apply: email me directly, or just leave a comment here (I won’t publish it) with your email address. I will send a link to a more detailed job description and more info!

Reliably Changing Versions of Fonts »

For people who design fonts, swapping versions of your font can be a problem, as your operating system or apps have font caches which may become confused when you replace your fonts on the fly. The app you are using a font in may sometimes still display/​use the old version, even though you replaced it! So for people who need to be absolutely sure they are getting the new version, here are some options. Note that latest versions of Adobe CC apps may recognize fonts swapped on the fly. Office 360 as well, at least on Windows. So if you are not having trouble, and you are swapping fonts some other way, good for you! But if you are having trouble, here are some more options.

Here are some approaches for reliably swapping versions of fonts that have the same internal names, to new versions. This applies to both Mac and Windows, and across all apps as well. When working this way, as best as I recall, in the past 10–15 years, I have only hit font caching problems once! I suspect that was just a failure to apply my method religiously enough. There are two options for fonts with the same internal names on the desktop, plus to avoid the problem entirely, there is an approach to making font names unique, and some links to web-​based test sites.

Option 1: Brute force (cross-​platform)

  1. Close apps that you are using the fonts in, particularly those which cache your fonts, including Adobe CC apps and Microsoft Office.
  2. Then, uninstall the “old” font version from your OS. Don’t just overwrite it in place with the new version! (If you are using a font management app, you can just deactivate, but I usually nuke them anyway, I don’t need 170 versions of the same font kicking around.)
  3. Relaunch those darn font-​caching apps, including Adobe CC apps and Microsoft Office. That’s after you uninstall the font. Even open a doc that uses the now-​missing font! This gives the app and its cache a chance to recognize the font is no longer there and update appropriately.
  4. Quit Office apps (without saving your docs, no need). Note: no need to quit Adobe CC apps, they can recognize newly-​installed fonts on the fly.
  5. Install your new font versions; or activate them in your font manager.
  6. If you are using Office apps with your fonts, you can launch them apps again and work normally.

Option 2: FontNuke (Mac only)

I forgot about this option for a while, but was reminded of it by James Montalbano in a thread on TypeDrawers. FontNuke is a Mac utility that clears font caches, and then reboots your system. It’s available through major utility aggregators like MacUpdate and CNet. I’ve used it occasionally, and it works fabulously. Downside: it requires a system restart. That’s why I ended up tending to go with Option 1. (Also, Mac restarts used to take longer than they do nowadays. Yay for SSDs!) Upside: if your system font caches have gotten messed up, or you don’t want to go through all the steps above, it becomes the simplest solution.

Option 3: Font Naming Tricks (cross-​platform)

Option 1 seem like too much freakin’ work? Or you need something that works on Windows, or reboots suck? I hear you. That’s why as a font designer, I sometimes work with a system where instead of keeping the internal names the same, I actually put the build version number right at the end of the gosh-​darned family name, so it shows in the menu with the version number. I also put it on the end of the file name. I leave it this way as long as possible during development. Sure, this has its limitations, as the new font won’t just automatically substitute for the old one in existing documents. And it has to be changed before releasing the font. But if I am in the midst of frequent font revisions, it also means I can swap out font versions constantly, as often as I like, and not worry in the least about my apps or OS getting confused. That is pretty sweet.

  1. Before generating the actual TTF or OTF font, increment a build number at the end of the font family name
  2. Remember that your existing docs won’t recognize this as being the same font family.  🙁  But you don’t have to worry about caching and conflicts! 🙂

Option 4: Test in the browser instead

If you don’t have to test in a desktop app, you can avoid a lot of grief! There are sites for testing fonts in a web browser. You can drag the font into a browser window and test it there. Impallari’s is great

If you are doing browser-​based font testing—or font testing anywhere, really—with an incomplete character set, consider Miguel Sousa’s Adhesion Text to get useful words for test purposes. (Don’t miss the options for other languages, and more!) 

Font Detective Site Launch »

It’s still a sideline from my day job running FontLab, but I have been doing enough font detective work (identifying fonts in backdated documents, analyzing point size, and other font consulting) that I realized I really ought to formalize this whole line of work a bit more. So: a dedicated web site! Plus, I am attending my first conference of forensic document examiners in a week and a half. I did my first case way back in 1999, but this work has been ramping up a lot in recent years and months

Regarding the new site, the formatting and graphics of the secondary pages is still a work in progress, it is in pretty good shape now. I did much of it myself, and hired a talented web designer to get it over the finish line. My initial logo was a bit off for the colors, and my web designer Josh Korwin cleverly suggested simplifying it to be just black-​and-​white, and now it pops! So I am happy with it.

Font Detective logo

Why Variable Fonts Will Succeed »

Third time’s the charm? Why OpenType Font Variations (variable fonts) will likely succeed where predecessors failed.

OK, this is kind of funny: a post I wrote in November 2016 that languished in my “drafts” afterwards when I was busy with work, waiting on illustrations/​graphics that I never did add. Just for fun, I’m going ahead and publishing it exactly as is, showing what I was thinking at the time, just after Variable Fonts were announced. The only other note I want to add is that if you want to play with variable fonts, check out Axis-​Praxis.

OpenType 1.8 was announced in September, featuring variable fonts. In short, variable fonts allow for packaging an entire family of fonts in a single font file, using master designs and interpolating between them, on what are called “design axes.” The type designer who makes the font can use this for whatever they like, but varying weight or width are among the more common standard uses.

What makes this exciting is that in a savvy environment, someone using the fonts can specify any in-​between variation they like, within the “design space” (dynamic range) covered by the font. So for example, in a font with weight and width axes, a user could dial in the precise degree of boldness and level of condensing or expansion they desire.

Font families built as variable fonts are vastly more flexible than before, yet can use less file storage than traditional font families—vastly less if you have large, complex families with a ton of styles.

More details:

Which is all very well, but this kind of tech has been tried twice before: GX Variations (the basis of the new tech) from Apple, and Multiple Master from Adobe. Neither ever got very far. Why should this time be different?

First, I will note that when it comes to traditional design, it is only when there is support for the designer/​user picking their own arbitrary instances from the design space of the font, rather than just relying on pre-​specified instances, is there a benefit to designers. This means that traditional desktop design/​authoring apps need to implement sliders or some user interface to reap the benefits of the technology (although this is not so much of an issue for the web).

Second, the other benefit of variable fonts, more compact representation of large families, was barely noticed the first time out. But with web fonts being a big deal and file size a huge concern, this is a newly important benefit.

So, right off the bat, it is clear that it is more work to make this work with desktop apps, and that the circumstances make the web benefit more and get easier adoption.

Speaking of adoption, it is worth noting that neither all existing nor all future font families need to be delivered as variable fonts for the format to be useful and successful. It may always be a minority of fonts available, yet still be a success with strong niche use in some areas (such as web design).

Why GX Variations Failed

Apple introduced what is essentially the same tech back in 1991, as GX Variations, part of TrueType GX. While many other aspects of TrueType GX survived in varying degrees, I can’t even find a good list of GX Variations fonts. I know only three offhand: the OS-​supplied Skia GX (by Matthew Carter), the Monotype demo masterpiece Buffalo Gals (by Tom Rickner), and Adobe’s Tekton GX (by David Siegel).

GX Variations, in its original instantiation, would have required apps to give up control of their line layout to Apple’s line layout engine. Of course, this would also mean that any such app would have been Mac-​only. Although there are certainly some Mac-​only design apps, the Mac-​only aspect meant that the relevant heavyweights of the era, Quark and Adobe, never supported it.

Apple supported GX with font dev tools, but they were largely command-​line based and hardly designer-​friendly. None of the font editing tools of the era supported GX Variations, either.

With only a tiny handful of demo fonts, no major app support, and no major font tool support, GX Variations has never seen much pickup.

Why Multiple Master Failed

Adobe developed their multiple master (MM) tech at the same time as Apple did GX Variations, but completely independently. MM is a slightly less sophisticated/​complicated version of the same concept as GX variations, handled as an extension to Adobe’s PostScript Type 1 format. The MM technology was even briefly (1996–98) incorporated in the original OpenType spec, although only for OpenType fonts with PostScript outlines.

MM did a tad better than GX Variations in terms of real-​world use. There were 27 families offered by Adobe in the MM format, one by Monotype, and about eight free families from four different independent designers. Adobe also used MM internally in Acrobat’s font-​substitution technology. Illustrator added “sliders” for MM fonts, but only just before Adobe pulled the plug.

And pull the plug, Adobe did, back in late 1998. Adobe was already moving away from Type 1 fonts, and they withdrew the MM functionality from OpenType. The then-​manager of the Adobe type group, Dan Mills, believed that OpenType adoption might be significantly hampered if we were telling people they had to support this major added complication in order to properly support OpenType. Plus, OpenType ally Microsoft had never been very enamored of MM and had no interest in the tech at the time. So, Adobe pulled the plug.

Why didn’t MM get better traction before that? Well, it was an Adobe invention competing with a similar Apple technology. The folks on the Adobe font team failed to realize early enough how important it would be to actively evangelize this technology to Adobe’s own apps as well as outside apps, and devote real resources to that effort. Because Adobe apps competed with third party apps, this hindered Adobe outreach to third party app developers. And few others were involved and supporting MM, outside the Adobe type team: it was an Adobe thing.

Axis-​based Fonts Behind the Scenes

Although development of new MM fonts ceased around 1998, many type designers saw that axis-​based font technologies were very helpful in developing large families. Crude support in Fontographer followed by more sophisticated support in FontLab allowed type designers to use MM capabilities to design fonts. It is simply easier to design two weights and interpolate the rest, than to design three, six or ten weights separately. If one adds in width variations or other axes as well, that can further multiply the savings in design work. One doubts that Robert Slimbach would have designed 156 styles of Kepler individually!

Even more sophisticated tools emerged in later years, such as Erik van Blokland’s Superpolator.

As a result, even while MM and GX Variations died off, and only about three dozen families used those technologies, scores more families have since been developed using the exact same concepts—just upstream in the design process.

Other Lessons

Two other font technologies have launched later, and were informative in their own ways.

The Microsoft/​Adobe collaboration on OpenType, which later widened further into an open standard, has done well and become the primary font standard for the future. Many choices made in that process reflected learning from the MM and GX history, and it shows.

More recently, the addition of color font support to OpenType has been more disjointed; I blogged about that at some length, explaining how this served as a bit of a wake-​up call to the big players as far as the need to cooperate and collaborate on variable fonts.

What’s Different with Variable Fonts

Variable fonts are being backed from Day One by a much broader coalition than ever got behind MM or GX. The same four players who came up with four different solutions for color fonts are backing a unified approach to variable fonts. Apple, Microsoft, Adobe and Google made the initial announcement jointly (at ATypI 2016 in Warsaw), with representatives of all four companies on stage and presenting. Every one of the major players in type design tools and related utilities (including my company, FontLab) have already started implementing support, many of us having started that work before the announcement.

Assuming Mozilla joins in, this stuff is just going to work in all the latest web browser versions in pretty short order.

Because of the ongoing behind-​the-​scenes role of axis-​based fonts in development of regular fonts over the past 15-​20 years, many type designers already know how to design type families in this way, understand the flexibility and power inherent in variable fonts, and even already have existing type families that could be “relatively easily” re-​issued as variable fonts (with varying degrees of added work).

There are no guarantees. The variable fonts story still has some weaknesses, notably around formatted text interchange, and of course with desktop app support for an interface to interact with the variability. But the odds are good of at least moderate success. The alliance supporting it is strong. There are significant benefits, albeit not as compelling as OpenType as a whole.

Some Predictions

The Lesson of Color Fonts for Variable Fonts »

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.

 

More reading:

Women’s voices in type & ATypI »

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

Awesome: Fiona Ross receives 2014 SOTA Typography Award »

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.

Fiona Ross receiving SoTA Typography award

Fiona Ross receiving SoTA Typography award. Photo © 2014 Laurence Penney, all rights reserved, used with his kind permission.

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.

 

Fabulous Adobe font/​format history article »

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 mag off-​base on Roboto typeface »

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.

Roboto compared to other UI fonts

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 in a user inferface, that is 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. (Update: Apple later changed to San Francisco, which has the same “modern” look as Helvetica, but with just slightly more open counters… rather like Roboto in that regard.)

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.

« Previous posts