I have fielded many versions of this question: “What does the emoji with an X in a large rectangle mean?” or “When texting, what is the meaning of the symbol with an “X” inside a tall rectangle?”
That it is an X-in-a-tall-rectangle is just the most common rendition, although not the only possible one, for the “.notdef”. A variety of font-specific notdefs are shown above.
It is not an emoji, but you can get it instead of an emoji or other unusual character. A notdef (undefined glyph) is what gets displayed when a character is specified in text, but your current font does not support that character. Most commonly it happens with a newer emoji, but it could be in an unusual language or a new currency symbol, or… well, something unusual.
This problem is not unique to texting, but applies to all kinds of displays of text on all devices, whenever the needed character is not available in the available font(s).It is an indicator for a “missing character,” which stands in for an emoji or any other character that your device or current font doesn’t have a glyph to display it with. This makes it a very special symbol.
(A particularly hefty notdef, that I designed for one of my typefaces. The font is quite bold, so I made the outer box of the notdef quite bold to match. How font-specific should a notdef be? As I get older and hopefully wiser, I gravitate towards what seems to be a near-concensus view that it should contrast with the font, so users realize something is wrong. That means matching weight is actually a bad idea. Oops.)
This is more common when you are receiving rather than sending a text, since you are unlikely to enter a character that you don’t see correctly. But it can happen when you try to view a web page, or copy text from a source and paste it somewhere that it comes out in a different font.
Often there is some kind of font fallback available; your phone (or computer) tries to display unusual characters and emoji in some other font, that supports those characters. That is why in some situations you can see a name and some unusual character in the name is displayed in a different font than the rest of the name. But phones have limited storage space, and whether it is a phone or computer, there are over 150,000 characters defined in Unicode, with more added every year.
So when your phone (or web browser or computer) runs out of ideas on how to display a character? You get a notdef.
If you copy and paste a notdef on your computer or into a text or email you are sending, you will probably be copying some specific emoji or obscure character. That means that some other person who receives that (or later views the same file on their computer) may well see something else entirely!
Even if they do see a notdef, it may look different, depending on the font they see it in. Here are the most common/standard approaches to the notdef, as defined in the OpenType specification.
The thinner box creates a very different appearance compared to the X-in-a-box approach, doesn’t it? Note that these are general approaches, not precise glyph outlines that a font maker would use directly.
The plain rectangular box is the style of notdef that was common in PostScript Type 1 fonts, back in the 1980s–90s. But it has fallen out of favor. I believe the main reason for this is that as a shape it is not as distinctive, and hence more easily missed by someone looking over some text.
That plain box is the origin of the slang term “tofu” for the notdef, over some notional idea that it resembled a piece of tofu. I originally thought Google staff invented this slang, as the first time I remembered seeing it was in publicity for Google’s “Noto” universal font set (“Noto” being short for “no tofu”!). But my font colleague Denis Moyogo Jacquerye pointed to this thread on the Unicode mailing list in spring 2009, and says it was one of a number of references around that time. John Hudson seconds encountering the “tofu” term in Unicode circles, so I may have been hasty in assuming it was a Google invention.
The question-mark-in-a-box is used in many of Microsoft’s fonts, such as Calibri. Note how the question mark inside the notdef is in the style of the font—it isn’t just a generic one. This style was invented by John Hudson during the development of Calibri and the other so-called “ClearType fonts,” that shipped in January 2007.
“The ART[Advanced Reading Technologies] group had used a spiral .notdef in Palatino Linotype, but it had caused confusion because it wasn’t recognised by users as a missing glyph indicator. For the C* fonts, I suggested that a) a box of some kind was necessary, and b) a question mark would indicate uncertainty: there’s a character here, but we don’t know how to display it.”
A plain rectangular box was the style of notdef that was common in PostScript Type 1 fonts, back in the 1980s–90s. But it has fallen out of favor. I believe the main reason for this is that as a shape it is not as distinctive, and hence more easily missed by someone looking over some text and trying to spot errors and glitches. When I was at Adobe, we went from the empty box to the X-in-a-box style as part of our transition from PostScript Type 1 to OpenType, from 1999–2003.
HOWDO I GETTHERIGHTCHARACTERINSTEAD?
Updating to the latest OS for your phone (or computer) usually also updates your Unicode and emoji support and system fonts. If the problem is in an app that has its own Unicode/emoji/fonts, then updating that app may help.
Many apps and OSes will use “fallback fonts” when the current font does not support a needed character. In that case, the above advice is good: you need better support from some core system font.
(This was originally written for Quora, but as Quora continues to turn to garbage, one of my answers on this, despite having the most upvotes, was made invisible by the system for unclear reasons. So I have merged my answers to two similar questions into one, and posted it here.)
(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!
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.
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
Variable fonts will see rapid adoption in a few very high-impact and high-visibility places, including as system fonts.
Variable fonts will take a little time to become popular or widespread on the web, but some sophisticated and design-intensive web sites will love them.
Within three years, variable fonts will become a common format for many new fonts, particularly for large or sophisticated families from major foundries and high-end boutique foundries. But for (at least) the next few years, the same families will usually be issued as static (non-variable) fonts as well.
Success of variable fonts is partly dependent on app support. Thanks to subscription models for Creative Cloud and Microsoft Office (and live app updates for Google Docs), any support from apps will be rapidly seen by end users, but… these big companies tend to operate in fairly siloed ways. Cool though this tech is, it is unlikely to attract the attention that results in a top-down dictate from on high that everyone in the company must support it. This means that the Adobe, Microsoft and Google fonts teams’ support for the fonts is no guarantee at all of front end app support by Creative Cloud, Microsoft Office or Google Docs. Such support, or the lack of it, will influence type foundries in their adoption.
Because Apple’s existing GX Variations represents a large subset of the variable fonts technology, system-level and desktop app-level support for variable fonts is likely easier for Apple than for just about anyone else. Yet I still won’t bet on how quickly Apple will support this in iWork (their Keynote, Pages, and Numbers apps).
Very few foundries, and no large ones, will release what Ben Blom calls “static variable fonts” that in essence prevent interpolation and work like a family of old static fonts while preventing user interpolation. It misses on the big advantage of variable fonts, which is the ability to pick arbitrary points in the design space. The sole advantage of such fonts is smaller file size, but potential (or actual) user confusion will cause most foundries and users to avoid this experiment.
Variable fonts will not be the majority of retail font revenue ten years from now. They will not completely displace static fonts any time soon, if ever.
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.
I am writing this from the ATypI conference 2013 in Amsterdam. I hosted a panel on free fonts on the first opening day (Wednesday) of the pre-conference two-tracked discussion, and Victor Gaultney of SIL International did the same on Friday. The panels and discussions around them brought up a bunch of issues, and I wanted to share my thoughts. Note that this is something of a live post, and subject to clarifications and additions, though I think my main positions are pretty set.
Victor Gaultney of SIL International hosted a panel on free fonts at ATypI Amsterdam 2013. Left to right: Dave Crossland, David Lemon (Adobe fonts), David Kuettel (Google), Greg Veen (Typekit, Edge web fonts), Eben Sorkin.
Threat, or Menace?
I don’t think free fonts are evil. If anybody has that misperception about my thinking, it’s my own darn fault for entitling my panel “Free fonts: threat or menace?” I intended it as a joke, a bit of a deliberate incitement to get people talking/thinking, and perhaps poking gentle fun at the not-unusual anti-free attitudes in the type design community. I got the “threat or menace” part from old comic books, in which crusading newspaper publisher J. Jonah Jameson is writing crazy anti-Spider-Man newspaper headlines, but apparently it goes back even further.
Of course free fonts are at least mostly a good thing for people who use fonts. Who doesn’t like free? For hobbyists and casual font users, they are certainly a good thing. For professional users who are passionate about quality, it is less clear, as if free fonts have a negative impact on average quality or continued availability of new, quality fonts, then it may not be all good for them.
Gratis vs Libre
There are two overlapping but distinct kinds of free fonts; it is worth distinguishing them.
“Libre” fonts are those which post few if any restrictions on what the user or acquirer can do with them. They are generally “open source” and can be bundled with either commercial or open source software. Although it is allowed to charge for them, it is also allowed to redistribute them for free, so it is hard to sell them effectively. Most of the really high-end free fonts made by professional type designers are released under libre licenses.
“Free as in beer” or “gratis” fonts are those for which there is no charge. Many of them still have licensing restrictions on what one can do with them, such as only allowing non-commercial use, or restricting modifications.
Most of the “free fonts” in the world are gratis rather than libre, but the biggest growth lately has been in libre fonts. Sites such as “dafont” feature many gratis fonts that are not libre, but also some libre fonts.
Sometimes a type designer or foundry will make some members of a larger family available gratis. Often they will be less useful styles, but whether it’s the regular and the bold or just the black italic, giving away some styles as a teaser for the rest of the family seems like a special case. This has worked well for some designers (e.g. Jos Buivenga / exljbris with his Museo families). Some have seen less result.
Quality vs Free Fonts
I am pretty harsh about font quality. Most of the fonts I have made have never shipped, because my conceptions of quality early on outstripped my ability to execute at that quality level. So I will be the first to say that there are plenty of commercial fonts that suck. Easily 30–40% of commercial fonts leave me thoroughly unimpressed. If you look at libre fonts, and use the Google Fonts collection as your baseline, maybe 65% of those fonts suck. If you just look at all free fonts on dafont, maybe 95% of those fonts stink.
Why is that?
Well, most of the people who are capable of making high quality fonts have some serious training, and/or a fair bit of experience. The people who are at a stage of their career where they are interested in making stuff and willing and able to give it away are mostly younger people just starting out, or people just beginning to get really into type design. On average they have a lot less experience and skill.
Also, polishing a font until it is really good is a whole lot of extra work and a lot less fun than the earlier stages of the design process. Frankly, it’s the 80/20 rule, only with type it is more like 90/10 or 95/5. Most of the quality improvement won’t be immediately/consciously noticed by most potential users, especially in the new growth area of the web where would-be end users are generally less typographically savvy.
I should be clear that when I say “quality” I am not talking about matters of mere taste. There are objective aspects of font quality. For example, in spacing a typical sans serif, if the cap H and N have straight sides, and the white space (sidebearings) allocated to the left and right sides of the cap H are significantly different values, and those in turn differ from the sidebearings of the cap N, then the font is simply badly made.
One of my perennial arguments with the folks at Google is about the fact that they didn’t have a very high quality bar at all, and let in an awful lot of fonts that I would say are simply crap or at least substandard, at an objective level. Some of the folks on the Google side of the fence say that they are simply giving their users free choice and that if one of the fonts I consider to be junk becomes popular, then that’s evidence that it was actually “good.” I don’t have much patience for this line of argument. I think that Google is abandoning what it ought to see as a responsibility to be a gatekeeper not of taste, but of quality. It is not hard to find the expertise to deal with these things.
Interestingly, Adobe, having an increasing interest in there being decent quality libre fonts out there, is actually dedicating some in-house resources (read: people’s time) to helping fix and improve some of those fonts. Kudos to them.
Money for Free Fonts?
Most of the solid quality libre fonts were actually commissioned works, or done in-house by a big company. In either case, somebody with deep pockets had a need or desire for a new open source font, They expected to make money in some other way, and were willing to pay usual professional wages for the development of fonts that met their needs. But these well-paid professional fonts are a minority of all libre fonts.
Google has offered a bounty on libre fonts, but according to Bruno Maag in the discussion here at ATypI, it amounts to some $2000 per font. He suggests a basic three-member family takes about 400 hours to create, and that hence Google is paying $15 an hour for type design, and that isn’t a livable wage. Bruno’s angry outburst about this garnered applause from a significant chunk of the audience.
Of course, the audience here at ATypI in Amsterdam is an audience of middle-class and better westerners, to whom $15/hr is not a real living wage. But in much of the world that is a pretty decent wage, especially for a student or somebody in the earlier stages of their career.
But I expect there is no reason to think that Google or any other specific company will continue to pay for new libre font development at the same rate that new commercial fonts have been being made in the past. If the money to be made in creating libre (and other free fonts) is less than what we had before, it’s possible that the total amount of money will go down, and the impact of libre and gratis fonts on the demand for retail fonts matters.
Eben Sorkin has suggested that for popular libre fonts he has designed, people are starting to ask about paying for customizations, additions and modifications. He thinks he can make sufficient money off of this to make it worthwhile, and that this may be a viable model for everyone.
I am not entirely convinced this will be the reality for the “average” type designer from a wealthy country. Maybe. If not, the development of the bulk of libre fonts will tend to be more of an activity for people from less wealthy countries, and/or done by less experienced type designers.
Some libre or gratis fonts can raise development money on Kickstarter or some similar crowdfunding source. This is challenging, and doesn’t work for all projects. It also requires a different skill set in terms of social connections and marketing to be successful. Unfortunately, many type designers don’t want to have to sell themselves, their story and their projects in that way. (Though arguably it is an important skill for traditional retail proprietary fonts as well!)
David Kuettel of Google responded to Bruno Maag’s outburst with a lengthy and partly evasive response, which basically amounted to “we want to see type designers get paid, and we haven’t worked out the model by which this happens. First we need to finish sorting out various technical and practical issues, and once we iron those out, we will be able to come up with a better model to pay for the fonts.”
I am not excited by this response that wants the type designers to do all their work up front and just trust that sooner or later a model will spontaneously break out that allows them to make money. In the future. With different fonts, as I don’t believe that for the existing libre fonts (that were made before that magical future), Google or anybody else is likely to start paying additional revenue that they don’t have to.
Although interest in using type is growing, growing even faster is the supply of people trying to design it. There are more and more serious college and university programs teaching type design. The loose anarcho-syndicalist Crafting Type collective (which I am a member of) teaches three-day type design workshops to beginners, which while not turning out master type designers certainly gets them past the level of the average gratis typeface, perhaps to the level of the average libre typeface. But (in my estimation) having so many people interested in trying to design type means that supply of type designers is outpacing demand, which is creating another source of downward pressure on prices/wages.
Impact of Gratis & Libre on Commercial Fonts?
There are a number of different theories about the impact of more and more free fonts on the income made from retail font licensing.
(1) One theory is that free fonts will have little or no impact. For the most part they are of poor quality. The people who want to distinguish their work have always been willing to pay and always will be, because being different and distinctive and using quality fonts is of value to them. The people who would use the free fonts would never have bought retail font licenses anyway.
(2) Another theory is that free fonts increase the awareness of fonts in general and help stoke demand, and that as this new audience gets more sophisticated some of them will gradually get more and more interested in commercial alternatives to free fonts.
(3) Some folks believe that just like fonts bundled with apps, free fonts will decrease the total demand for retail fonts. Any demand they create will be outstripped by the demand they satisfy. Some users will not become sophisticated enough to prefer better typefaces, while others will simply choose from the higher-quality free fonts they can find, which appear to only be a growing category.
Personally, I actually buy all three of these theories to some degree. I think there is a core demand (1) that will never go away. But I think the portion of that demand that is truly immutable is a small part of the total market for fonts. I do think that making free fonts available will increase awareness of fonts (2), but I am politely skeptical that any resulting increase in paid font licensing will surpass the decrease due to free fonts substituting for paid fonts (3).
Of course, even if I am right about that mix, that doesn’t say what happens to the total money being spent on fonts. Some people will commission libre fonts, or Google may continue to pay a bounty on the ones they want to see made. My guess is that the total amount of money going into the pockets of type designers is more likely to decrease than increase, but I can’t swear that’s what will happen. But even if the total amount of money going to type designers goes up, I am pretty sure that more people will be doing it and the average $/hr compensation will go down. Mind you, even if so, these economic shifts will not happen overnight.
Result?
I actually hope that some of my projections and guesses are wrong, because of course I would like to see more money ending up in the pockets of type designers. But even if my predictions and guesses are all correct, I don’t see free fonts as bad, exactly. Having more fonts available for free to the average user is still a good thing for the end user. The percentage of new fonts that are of what I think of as high quality may go down (compared to the old proprietary world), but the total numbers of all kinds will only increase. Existing quality fonts won’t go away, even if the average quality of new fonts is lower.
While the changes may be “bad” for many first-world type designers, including people I know personally, I don’t see anything horribly wrong with there being more work for people who have less money, and to whom $15/hr is a good wage. Although I like the idea of everybody in the developing world having the same level of affluence that professionals do in the west, realistically this doesn’t happen overnight. Wages in developing countries increase over time. The changes I foresee in type design economics are part of that shift, even at wages that we would consider potentially exploitive here in the USA. I don’t like the idea of type designers making only $15/hr, and I fear that it won’t get the level of quality and care that I would like to see, but at least that’s not a sweatshop wage. If we were talking $5/hr it would be different.
For those of us (mostly first-world type designers) for whom the coming shift is not a Good Thing, it may be a saddening change. But I think change is inevitable, and all the players involved are going to do what makes sense for them at the time. A company like Adobe making a couple of open source typefaces is not due to some huge change in their corporate ideology or thinking: it just became beneficial to them to create a few open source fonts due to their other business interests. Similarly other type designers are going to do what is right for them (as well as they can judge). If that makes for more free fonts and lower income levels for the average pre-existing type designer, that’s not some evil conspiracy, just change and life.
[Revised twice on 13 October 2013, first to add more on font quality, second to discuss free fonts as a promo for bigger families. Revised 14 October 2013 to clarify wording on free and libre some more, and clarify sweatshop wage position. Later revisions for grammar. Revised again 16 August 2015 to clarify a couple of sentences about economics and wages.]
Through my day job I am doing a 3-part webcast series on web typgraphy best practices. It is free, and registering once covers all three webcasts (with no obligation to attend).
Part 1: Selecting Fonts. Wed Sep 7, 11 am PST
Part 2: Setting Text, Wed Sep 21, 11 am PST
Part 3: The New Frontier—OpenType typography on the Web, Wed Oct 5, 11 am PST
This post by Jeffrey Zeldman on font rendering in web browsers is a good introduction to the subject in a number of respects, but unfortunately repeats a pernicious myth: that web browsers on Windows all render text differently, and that this interacts with the OS rendering. There are a couple of caveats (see below), but for the most part, this a this is a system level setting. On any given Windows computer running XP or Vista or Windows 7, you will generally get >pixel-for-pixel identical glyph rendering in Internet Explorer, Firefox, Chrome, or Safari. (As also shown in Si Daniels’ presentation at ATypI 2009 in Mexico City).
Why is this? All of today’s major web browsers on Windows (IE, Firefox, Chrome, Safari) simply use the OS’s user-adjustable GDI text rendering settings, whatever those may be. Similarly, all today’s major web browsers on Mac OS simply use the system text rendering.
(Yes, there are a couple of caveats. Internet Explorer 7 actually ignores the OS setting in favor of its own prefs setting, which is to use the OSes ClearType rendering regardless. Safari for Windows has an optional setting to use Apple’s “Quartz” text rendering, even on Windows—this was the one-and-only rendering option in Safari 3 for Windows, but Windows users “freaked,” so Apple changed it for Safari 4 for Windows. Also, Firefox can use the kerning built into fonts, which affects spacing, though it doesn’t actually impact rendering of individual glyphs. Every major browser uses the same rendering as some version of OS rendering, however; none does something unrelated to Mac or Windows text rendering.)
So why does rendering vary so much? Windows XP, Vista and Windows 7 can be set to one of three settings for “font smoothing” (a.k.a. anti-aliasing). These settings affect all applications using the old-school GDI APIs for text rendering, which as of late 2009 means all the major web browsers. The font smoothing settings are:
off (uncheck the box that says “use the following method to smooth the edges of screen fonts)
Standard (grayscale)
ClearType (optimization for color LCD screens)
Note that the standard vs ClearType distinction only affects fonts with TrueType outlines. Fonts in PostScript Type 1 or OpenType CFF formats get a less sophisticated type rendering/smoothing which, well, seems less than stellar these days.
“Standard” (grayscale anti-aliasing) is the default on Windows XP, although installing Internet Explorer 8 will change that setting to “ClearType” (even if one then proceeds to use a different web browser). Windows Vista and Windows 7 default to ClearType. So, most folks on Windows are seeing ClearType rendering, one way or another. However,
Besides GDI (all of today’s browsers), there is a completely different rendering mode used by applications which are programmed to use the “DirectWrite” text APIs (similar rendering also available to the largely-ignored WPF APIs). This uses ClearType, but a ClearType which is improved over the GDI version. For TrueType outlines, It offers moderate but noticeable improvements, such as options for improved spacing, and anti-aliasing in the Y direction. OpenType CFF fonts see a truly dramatic improvement, going from really mediocre rendering under GDI to rendering roughly equally well with TrueType under DirectWrite (or under its predecessor, WPF)! Minion Pro and Myriad Pro in OpenType CFF render pretty well down to 9 pixels per em (ppem), and just fabulously at 12 or more.
People keep on sending me links to this article “Boing Boing’s Redesign Uncovers Dark Side of Web Fonts,” about problems Boing Boing had with their new web font implementation. Only thing is, the article has a substantial dose of nonsense mixed in with the perfectly good analysis. I don’t blame the writer, though. This web font stuff is actually really complicated, and information has been hard to come by. Heck, I even briefly forgot a basic point in a first pass at this article. But nonetheless, I am fairly sure that Boing Boing could have fixed their problems easily, if they knew how. Here’s the story:
WHATHAPPENED
The background here is that there are new ways of using fonts with web sites, and Boing Boing tried the simplest approach of just hosting a free font on their own web server and pointing at it, but the on-screen results were not as good as expected.
“…the font it settled on — specifically BPreplay — ended up looking terrible for most users.”
“The result was hordes of angry Boing Boing fans complaining that the new headline font was “ugly,” “an abomination” and “plain nasty.” Of course, the culprit wasn’t really the font, but rather how different it looked depending on which browser and operating system the viewer was using.”
FINDINGTHECULPRIT?
This is where things get tricky. I will update this post as I learn more. But, as best as I can tell, if that link to the font is right, and the font wasn’t modified by Boing Boing, the culprit really was in large part the font. But first let’s follow the trail of the previous article and make some corrections….
“The problem is that while modern browsers, like the latest versions of Safari, Firefox, Opera and Google Chrome, all support @font-face, the Windows XP operating system often doesn’t have anti-aliasing turned on by default.”
Not true. Anti-aliasingis on by default in XP. What isn’t usually on by default in XP is ClearType, Microsoft’s enhanced anti-aliasing for LCD screens. Sometimes a computer vendor will turn ClearType on for the computers they sell (particularly if they are laptops or come with an LCD monitor).
But what makes this even less meaningful is that (again assuming the linked font is the right one), the font in question is in OpenType CFF format. Such fonts are always anti-aliased in XP, even if you turn off anti-aliasing—the setting change only affects TrueType fonts. Even ClearType doesn’t affect how these fonts are rendered (rasterized) in web browsers, either. Same thing in Vista, and as far as I know in Windows 7 as well.
“The rule, which is still part of CSS3’s draft specification, is also not supported by any version of Internet Explorer. So, as cool as your font might look when properly anti-aliased, on Windows XP it looks, as Rob Beschizza, head of Boing Boing’s redesign puts it, ‘like ass.’”
I’m not sure how those two sentences are related. That’s a mystery to me. XP can get good anti-aliasing as well as Vista, and Internet Explorer is bundled with Vista and Windows 7 as much as with XP. But even taking those points separately….
The @font-face rule was actually in CSS 2 way back when, and removed in CSS 2.1. Internet Explorer has supported @font-face in every version from IE 4 to the current IE 8, but the catch is they support it only with Microsoft’s “.eot” font format (a wrapper around a TrueType font), not with regular desktop fonts. But there’s a good reason for not supporting regular desktop fonts directly: font vendors mostly won’t license their fonts to be stuck “naked” on web servers without any additional protections. Sure, there are free fonts, but, well, we’ll talk about those in a few minutes.
If Boing Boing simply put up the naked .otf font file, and didn’t do anything for Internet Explorer users (and people running older versions of other browsers), then what font actually got displayed to those users would depend on what Boing Boing specified as the fallback fonts and whether the people actually had those fonts (and thanks to Ben Kiel for reminding me of this in passing). Now, if the fallback stack relied on fonts that most XP users would not have, but Vista users would, then there might be a difference that was at least partly based on operating system. But of course it would simply be up to the folks constructing the CSS for the web site to pick reasonable fallback fonts, and not really the fault of the operating system. Perhaps as a first-level fallback from their desired font they specified one of the so-called “ClearType fonts” such as Calibri or Corbel, which are bundled with Windows Vista and Office 2007. Not quite right to blame XP for not having the font, but that would explain how somebody could mislabel it as an XP-specific problem.
Other than that, whether you are using Windows XP or not has little to do with whether or not the font looks “like ass.” Turning on ClearType can further improve rendering for fonts with TrueType outlines, but would have no effect on this particular font. Being on Vista instead of XP would make no difference at all for any web browser rendering OpenType CFF fonts such as this one.
Side note: The font wouldn’t even be seen in Internet Explorer, because Boing Boing didn’t use its .eot format as far as I know. Any further problems in IE would then be due to a poorly-specified font fallback stack in the CSS. However, if they had used .eot and TrueType outlines…. Although XP has ClearType off by default, newer versions of Internet Explorer turn it on just for the browser, so there isn’t much difference between IE rendering of TrueType fonts between XP and Vista.
In researching what went wrong, it doesn’t help that Boing Boing backed off from the font change part of their redesign, so we can’t look at it and test it. Looking at this screenshot, however, shows pretty clearly what was going on. This screen capture was definitely taken on Windows, and the font in question is still anti-aliased. However, it has some pretty crappy artifacts in how it’s rendered on screen, at least some of which are related to it being unhinted. When I see things like a single pixel sticking out of the bottom of a round shaped letter, that’s a dead give-away that the problem is likely hinting (or more accurately, lack thereof).
“Hinting” is essentially extra code in the font that improves its rendering at screen resolution. Apple’s rendering approach largely ignores hinting, but Microsoft’s rendering still uses it a fair bit. Passable hinting can be done automatically by font editing tools, so there’s no real excuse for leaving it out of a font (as with this one). In fact, pretty much every commercial font on the planet is hinted, as are most free fonts. But this isn’t even an average free font. Yes, the terrible spacing is pretty typical for free fonts, but being unhinted is uncommon. Maybe it was converted by somebody else.
Bottom line: the font sucks. This should not be a surprise. Most free fonts do. Don’t get me wrong. There are a few great free fonts out there. But 98% of free fonts suck badly, and maybe about 20% of typically-priced retail fonts suck badly, so set your expectations appropriately.
THE “DIRTYLITTLESECRET”
But there’s another problem that might have led to complaints and concerns even if the font was made decently, but still in the same format. The “dirty little secret” of the font world is this: Windows GDI rendering of OpenType CFF and “PostScript” Type 1 fonts on screen just sucks, compared to its rendering of TrueType fonts.
Typophiles have long ignored this fact, because in the environments they’ve cared about, Type 1 and OpenType CFF fonts render perfectly well on screen:
Just about any application on the Mac OS.
Adobe Acrobat, InDesign and Illustrator, on any platform.
Unfortunately, Windows GDI rendering is what 90% of people see in web browsers and office applications today. (Yes, Safari for Windows also has the option to use its own rendering system, but that’s a tiny minority.) Internet Explorer sidesteps the problem simply by not supporting OpenType CFF fonts in .eot format, only TrueType (though one can convert). But it’s not like .eot ever caught on with web designers, anyway.
The future could improve. There is much better OpenType CFF rendering, even applying ClearType, available for applications using Windows Presentation Foundation and DirectWrite, but very few applications use these modes today, so it is sadly not very relevant… yet. My recollection is that the technical preview of Office 2010 for Windows has dramatically better rendering of OpenType CFF, so perhaps it is coming. Maybe Internet Explorer 9 will get there too, supporting both outline formats in .eot or some new web font format. Perhaps in five years decent support for OpenType CFF rasterization on screen will have reached the strong majority of web browsers….
CONCLUSION
So for me it’s a toss-up as to whether I blame Windows GDI rendering, or the fact that Boing Boing used a crappy free font (BPreplay) because they couldn’t legally use the retail font they wanted to (VAG Rounded). My first take is that I think Windows GDI just made worse something that would have been a problem anyway. Somebody who knows what they’re doing could spend ten minutes and either fix the font’s hinting in BPreplay or convert it to the TrueType flavor of OpenType—if the license permits it, I’d be happy to try either for them. But then again, maybe the complaint is more about the fallback font, a factor easily controlled by the web site author.
So yes there are some pitfalls. Obviously things would be better if one format worked across all browsers. But there’s also the question of whether one can use the fonts one wants, which tripped up the Boing Boing folks. What happens with that depends on what font vendors decide to do with the fonts they control the licensing for; many foundries are still trying to figure out how to approach the web fonts conundrum. Will they license fonts for use on web servers directly? Will they do so but specify security requirements that can’t be met by sticking regular desktop fonts on web servers, meaning that we’ll have to wait for new web font formats to be widely adopted, such as WOFF? Will they instead rely on a font serving process that involves something centralized, either run by themselves, or by a third party (such as TypeKit or Kernest)?
How exactly this will play out is still TBD today. What I do know for certain is that within a few years, web fonts will be a reality for the average viewer and the average web site. Many or even most web sites will pick specific fonts that aren’t necessarily already on the viewing computer, and those fonts will get used to display the desired text. Font selection will become part of branding for the web the way it has been in print. We’ll also get an explosion of awful font choices on web sites, particularly small personal ones, much like when the masses first got access to a wide variety of fonts they could print on their home computers. But overall, it will be a Good Thing, and I relish the thought of a more typographically rich web world in a year or three.
[Updated for minor clarifications 2009-10-12, reformatted 2009-10-13, added a bit on font fallback 2009-10-13]
