 Thanks. If you can't hear me, shout something. So I tend to be pretty wordy in general. And also, this is an abbreviated version of a much longer, like 40-minute talk. So I'm hoping that I correctly took out the right things. But I'll talk really, really fast, just in case. So the topic is we have free web fonts. What do we do next? And by that, I mean we have Google Fonts and we have open font libraries, a couple other services like this that sort of have the same idea behind them, which is serving HTTP web fonts, usually open font licensed. There are commercial services that do web fonts too. We're not talking about those. But yeah, who am I? So you can tell by all the gray in my beard that I've been around for a long time. For a long time, I was a journalist working exclusively in open source. And I sort of did font things on the side. And then I disappeared for a year. And I came back just working on typeface design and things. Now on to the topic at hand, when we talk about those web font services, they're huge, right? Trillions of hits. And that's literal. I think I checked this morning and the Google Stats were just under 20 trillion fonts served. Those are all open fonts to one degree or another, maybe open source, maybe just an open license. That's way more than something like YouTube will give you. And those projects have sponsored development of a ton of fonts. But the thing I want to point out is that that's just true on the web, which means if you look at other areas where people use fonts, open fonts haven't made nearly as big of an impact. I think I can prove that if you don't believe it. And just a couple of examples. Look at like ebooks. E-Pub is virtually the same thing as HTML, so you think it'd be easy to make a dent there. But if you look at what actually ships and readers, Amazon commissioned typefaces custom for their devices. That's perfectly fine. Barnes & Noble, with the note apparently didn't. They offer a lot more. This is compiled from a couple of different devices. Those are mostly monotype fonts and Microsoft fonts. What's really surprising though is the Kobo. The Kobo is a really open device. It's not boot locked. You can side load things on it. But they still don't have any interest in serving open fonts on that. The same is true if you go to print on demand. You'd think people uploading things. You want to give them a choice of typefaces. You don't really have much. If you have a license for something yourself, you can upload your PDF to Lulu or one of those other companies and use it. But if you don't, you fall back to a pretty small set of things, none of which are open fonts. And if you look at marketing things, like wristbands and t-shirts and stuff like that, you get virtually nothing but cheapo freeware fonts that probably don't even have accented characters in them. So who cares? A lot of the success of Google Fonts is due to marketing. And maybe if the same people spent a lot of effort reaching out to publishers for ebooks, they could make a dent there. That's fine. That's true. But the point I'm just making is that these things are services. They're not catchalls. And when it's a service, it's a specific service, in other words. So it has predefined fixed boundaries. And it doesn't solve problems outside of that. Therefore, if we care about open source and typography, we have to find those challenges and solve them ourselves. And I'm going to talk about a couple of those that I think would be of interest to people here. A couple I'm not going to talk about adding more fonts that are open. There's a lot of those already. These numbers, they kind of count packages in different ways, so they're rough. But that's a lot. And I'm also not going to talk about technical things like variable fonts. You have a question? OK. So there's really important technical work like variable font support. Currently, the man on the front row here, Matthias, is working on this. I think if you look at the top three things there, free type, Parfums and Font Config. It's already pretty much deployed. My understanding is that, hang on GTK, you've got a release cycle or two before it lands. I'm going to point to a blog entry by him later on. But we're not going to talk about that, because that's being worked on actively. I am going to talk about things like this. Be honest, how many of you have seen a slide this weekend that looks something like that? It's not great, right? I mean, this is the default that you get in Libre Office. And if you open the templates, mainly you get a choice of what color the rectangle is added to that. The version I'm using is, I think, 5.3. There's about a dozen templates available, and half of them, at least, use Liberation Sans. A lot of others use Deja Vu. These are fonts that look like generic Sans serifs, like Helvetica, basically. And I'm not saying they're poorly executed fonts, but they're a safe choice that you make because you want to make sure you cover a lot of languages or something like that. The design, though, is intentionally unobtrusive. That's the nicest thing you could say about it. You may hate the font that I'm using here, but I mean, at least a presentation is something where you might want to make an impact, and it'd be nice to have some options there. And when we talk about templates needing improvement, we're really talking about providing the user with nice, typographic defaults. Libre Office actually does a better job at this than a lot of other projects in that they have a set of fonts that ships with the bundle, if you just downloaded the bundle. Was anyone at the Libre Office talks yesterday? Unfortunately, the one about fonts, the speaker, was advocating that they stop shipping fonts with it. So I asked him a question about that. Don't need to get into that. It's more interesting to look at just what the choices are for open source projects in general. Scribes is debating this. Right now, there's a bug on that. You can look it up if you want there. They haven't actually released this, but it's in the development version. Inkscape and GIMP, though, they don't ship any fonts at all, so your left user has whatever is already installed on their system. With Linux distributions, it's a little hard to tell because these days package selection varies based on some options that you choose, particularly your locale. Generally speaking, distributions, again, try to take safe choices to make sure that language support works. The desktop environment has a default font. You kind of get a random selection of other things there. And that makes sense as a choice, but it leads directly into the next unsolved problem that I want to talk about in a little more depth. And that's what goes into a package, a font package. I'm talking about free operating systems, basically Linux distributions. I assume the same thing would apply to BSDs and other things. Unnamed source, photo credit to Richard Hughes for this, was I really hate the fact that we package them like command line apps, because they're not command line apps. They're visual things, and people use them to make visual choices. What's unsatisfactory about the way they're packaged currently? You don't get any documentation most of the time. And sometimes you need that, especially if it's a complicated script where you have some choices about how things are displayed. You don't really get much visually that shows you what's in the font. And it doesn't integrate with the system at all. And that last point is true in other OSes, too. But I think we at least have the ability, with package management, to integrate the documentation that comes with how to use the font into the system help, or how to get in touch with the designer. And we don't really do that. There's some sort of lower level issues that I think we could get in order before we start tackling the design stuff, for instance, inconsistent paths and names, and what metadata is included in the packages. By the path, I mean your fonts generally end up in a subdirectory of user share fonts. The file format's pretty well-defined, type one, true type, WAF. After that, it's the Wild West. This is an example. Noto is the giant mega family from Google, where each language has a separate font. Polish question, is that Leto or Latto? Latto. Latto is a family of related designs. Lowheats is a family of Indic fonts that are related, and each one of them gets a separate directory, even though they're all, they come together. And in fact, if you know these languages, Asimis and Bengali use the same script, so there can't be much difference between those two. Below that, Beng extra, that's a language-related package. So whatever the fonts that exist in there are, are just connected by the language. And then Samyac is a project that produces several fonts, but somehow the fonts have ended up in two different directories there, which is just a packaging bug. This is also true of what the packages are called themselves. CrossCore is a functional set of fonts designed to be metric compatible with your generic Microsoft fonts. Dejavu is a family with multiple styles. George Williams is a designer. Gujar is a language tag. Indic is a really broad category. SIL there is a foundry, so they have SIL and then the name of the font. GS Fonts is all about one application, GoScript, and then you have some that don't even fit into the same pattern as the rest of them, like UniFonts. Fortunately, this stuff is fixable, I would say. It might cause a little pain, but we should do that. A little more complicated is some of the content of those packages, and this goes back to what unnamed source Richard Hughes was saying. They're not command line apps. The AppStream metadata system used for packages in software centers these days has some options for fonts. You can do a provides, sort of list the font family names. You can tell the license. You can put a screenshot in. You can add a URL. A lot of that's not really font specific, though. The good news, though, progress on this is that AppStream is being adopted for more font packages and it's extensible. I actually opened this issue asking for some more specific things like designer and foundry, because sometimes it doesn't matter. And we'll talk about that in a second. No action on that, but I think I am going to get to talk to the AppStream people next week. So I'm hopeful. So what else could go into the packages? I think if we look at commercial fonts, we'll see some things. It's not perfect. But you definitely get the license that you agree to. You also get trademark information, which is really important to font designers. And you also get a specimen and some documentation, usually, and you get some way to contact the person that you bought it from. For us, we do generally include the license in an open font package. We don't do so well with trademarks, though. Specimens and docs, we drop the ball. If you're not familiar with it, what's a specimen? This is usually a booklet or something that the type designers created. It's a marketing thing when you are searching for a font and have a bought one. This is for Gentium, which is an SIL font. It's rather academic looking, but it shows the font in use. And academic looking is appropriate for Gentium. They can get a little more lively. This is Yersa from Rosetta Type. It's a Google font. That's actually on the web. They can also show you some really technical things. This is Bungie, which is a color font. It's multi-layer, so you need to know how the layers work to select the colors. And you need to know how to fake that if your application doesn't support multi-layered fonts. And in some cases, you need to see the font in use to know if it works at all. This is Bengali. And without any Bengali speakers here, it's a little hard to tell. But the way Bengali works is a lot of things combine together. These are character codes that are separate in unicode and they form conjuncts together. And the vowel markers have to move around and stuff like that. So the specimen shows that it works, whereas a blank character table or list really won't do that. And some of the documentation deals with this. This is from another SIL font called Awami. And it shows you how to activate the different stylistic variants. And you need to know that if you're setting this text. So yeah, we might have to actually create some specimens in documentation. I say, let's do that. If you're a designer and you want a graphic designer to do this, let's make some specimens. If you're into typography, we could probably make some documentation for some of the fonts that we have in that we're packaging already. There's been a little bit of work on this in the past. This was a book that some people made, I forget where. But it's on the whole, it's a pretty green field creating specimens. These things are important because of the next problem that I want to bring up, though, which is how we manage fonts. And I don't love that term. It's a little bit unclear. That's sort of how you talk about living with a chronic illness. It also kind of sounds like you're administering a database. And that's not really what you want your users to be doing. Ultimately, font management is about how you get fonts in and how you get them out when you want to use them. And OK, like I was saying, the distro package is where we start with this. This is from Ubuntu Software Center. There's a few things there with some information. Each font, there's a sample image. And as you can see, there's a little bit of metadata at the bottom. It's not very font specific. It says developer, which is KDE. That doesn't tell you who designed it. And sometimes you care about that. This font was designed by a friend of mine who passed away recently. And sometimes I like to use his fonts in presentations because he's a friend of mine and I care about that. And it'd be nice to have access to that. And sometimes these software centers don't really work at all. So just relying on automation is not perfect. But the bigger issue is that once you leave the safe confines of the distro package, all you have is a zip file downloaded from the web. This is essentially what everyone has to do. That's what you get when you're getting something from Google Fonts. They don't have an API for serving fonts directly to an application. It's possible to add that, but that's a choice for them to make. We can't count on that happening. And when you download a zip file, well, you're on your own. You open that up and happy hunting. We rely on the user to get them out and put them in the right place. And ultimately, that makes it accessible to the stack. But we really want it to be accessible to the user. There's not part of the official GNOME stack application called GNOME Font Manager that I think it pulls data right out of the file. So you can see things like weight and slant. It'll give you a waterfall. It's what it looks like. You can tell the wording is pulled directly out of a field in the font, because it doesn't always make sense. This doesn't even show you what you want to see, because again, any scripts have to combine together. So automated data doesn't always work for you. Sometimes it lets you down. How do you make a choice there? The real problem here isn't mistakes, though. It's that GNOME Font Manager isn't aware of anything outside the font file. Last year, I spent a lot of time around book designers and information designers and seeing how they select their fonts, which is what leads to my next suggestion, is that we think document first when it comes to font selection. And by document first, I mean any circumstance where someone is choosing a font, they have a document they're already working on first. And that's the context they make that decision in. And that's more important to them than the font is. OK, so yeah, they're already working. And there's choices about meeting requirements. They don't have a choice on and fulfilling some options. Those requirements can be important. Like, is this an academic use project? Can I use any font I want? Do I have to subset it? Do I have to display English and Arabic together? I probably want a font where they were designed together, so I don't have to manually tweak the alignments. Is it a business card or a poster? What look do I want? The options are everything else. This is where you make your decisions about, I like this designer, I'm always happy with this foundry. I have some specific features I care about. Maybe some specific glyphs. In other words, that's metadata. People don't really ask about the weight with slope numbers. They want something like a basketball font is what I want. Or I want something lively, but it's semi-condensed. And honestly, which of these is what you would want to choose from? That's not a fair fight. The one on the left is automatically generated, but that's the point. But the specimen is a designed object created with intent to show the font and use, which a character table doesn't do. And when I was thinking about why I don't think no font manager works, I decided we should consider the way we do music, because music players are widely used and tested, and they're 100% about a collection full of metadata. That's rhythm box. Most of that screen real estate is metadata, and you can search and sort on it. There's obviously other views you can take. This is no music. And you can always edit your tags and things. I think this is a better way to consider it. There's some lessons we can learn. Search and sort your metadata. Make it easy to add music. Allow people to edit their tags. Historically, that's been a little taboo in fonts. But what choice do we have? I think if we're going to integrate services, it would have to be at the font manager level. Yeah, fortunately, there's been a little progress. This is Matias' work on the font chooser and gnome. But I think there's probably more pieces that we need to think about how they fit together when you're loading a font in and when you're choosing it. My time is up. It's just about accurate. There are other problems, which I don't have time to talk about. Ask me about any of them. I am going to do a 40-minute version of this next month in Los Angeles at scale. There will be video on that if you don't want to come to Los Angeles for it. But yeah. Plenty of questions. Yes? Correct. Right. Do you know anywhere to find numbers on that week? No. OK, so the question is the numbers that I cited at the beginning of how many font packages are in these different locations doesn't take into account what scripts are supported. Is there a way to get that info? It's always a little tricky because someone can mark the font as supporting a language and be wrong. The numbers that I pull were just the base-level packages. So Google Fonts sometimes separates things. There's a small cap version that's listed separately from the main fonts. I didn't try to account for all that because there's too many of them. You could probably do some data mining and get script support. I think that Google Fonts allows you to search on that. But again, it's a human error that you have to worry about more than there not being info in the font files there. So I don't know. It's worth trying. Anyone else? Well, I don't know. I think in general, reality in type design is that people who are designing for Japanese feel like they have to include Latin in order to sell the font. It's not necessarily true in every script, but it's generally true in Arabic. And a few other places, it's just a globalization thing. When you get beyond that, it's hard to say. If you need Japanese and Cyrillic together, it's going to be tougher to find. But yes, use your context there. The question is, how do you judge the quality of a multilingual font if you don't read one of the languages? And essentially, you can't unless you get really outside of what looks good and you see things colliding or being spaced completely incorrectly. But that's sort of a design level problem. I mean, the correct thing to do there is to fix the font, not to change the way you search for the font, I guess. Well, actually, Maryweather is a great example because you go to the Maryweather homepage, which I don't think is probably linked to from the package. But you can find on Google Fonts how to fix your Maryweather bugs form is the top thing. And that designer, Evan Sorkin, has really made a concerted effort to reach out to people and do that. So it's not as nice with some other fonts. But in that case, they're aware of the need to get feedback from people. There's not an automatic way. And when I mentioned the system integration, that's sort of what I was thinking about is we could include that somewhere in the Linux desktop environment or in the package. I don't want to act like I have the answer for how that should be done. But I can tell you, as someone who's published open fonts, extraordinarily rare to get feedback from people. You'll get feedback from font engineers saying something doesn't build, maybe, but design things really, really hard. So anyway, we can improve that. We have a non-zero positive impact, I guess. Anybody else? Oh, yeah. Well, thanks.