 This is as close as I could come to Pokemon Color as I'd like to, and really I just picked that title because I had no time left. It's going to be weird. Unlike a lot of people, I don't actually have a project that I work on. In fact, for the past year or so I've been doing things like working on specifications and writing documentation and sort of esoteric tracking down bugs. And if you were here last year, I sort of gave this talk about this laundry list of unsolved problems in the free font world that are fixed just because we have a lot more free fonts now. And so I kind of, just over the course of the year, just built down and grabbed a poll on one of those which is the choosing of fonts and why that's so difficult. It's sort of a crack on the floor. And in practice, I've just met a lot of like filing issues on unrelated projects and monitoring other issues and trying to answer questions and begging people to implement features and things like that. For which I must say my TS class is my hero, the GTK maintainer. He actually cares about font-sport related things and GTK, and we'll find the time to work on them. That's not always the case. Sometimes you can't convince someone that your issue is important and they've got other things that are more important to them. More often though, you can convince somebody who's maintaining a library that your use case is important, but they're not going to find the time because they've got 10 libraries they maintain and that's one that's in maintenance mode and that kind of thing. So this is not a good versus evil sort of thing. But font selection. Why is that an issue? Because so many other things break down. And what I mean is if there was an awesome font selection widget in QT and GTK, you wouldn't have to write your own for inkscape and scribes and all those things. But you do. And you do because people using those applications, doing design work, have a very different use case than is covered by the generic font support on the desktop. And I gave this sort of like in talking about last year that there's a link to it right there. I haven't watched that. It could be terrible. I don't want to recover the entire thing. Now that was sort of what is it like when someone chooses a font because designers and publishers and people who use heavyweight font necessities have this process to go through and the way things work on a desktop and on a system now doesn't work for a lot of them. So that's sort of a problem that can be solved and affects a lot of people. The gist of it though is that when you have a document you're working on as a designer or something, you have requirements that come from or are imposed by the document and what you need to do. And then you have the fonts you have and then you end up doing this search to find something that meets all those requirements and then from whatever is making the requirements picking the one that you like the best and that works aesthetically and things like that. And when all those pieces are in place for the search process that you go through it's fast and it's intuitive and smooth and when those pieces are not in place it's impossible to do. And that's kind of the tricky thing when something is impossible to do the users just go elsewhere. I should mention like since I don't work on a project and I don't have an application to show I just put random looking in the diagrams together so don't pay too much attention to what they look like but the words are important so it's don't spend a lot of effort trying to figure out the meaning there. So yeah like the problem when you're searching for the font can be things like what language is supported and you don't want to necessarily pick two unrelated fonts that you have to have French and Arabic. You want them to work together you don't want to fiddle with the line height every time. So knowing that one font supports both of those is a good thing to know from step zero. Are there a tabular numbers that you have to do tables you need to know that, right? And like do the scripts match well visually? Is it the same weight and things like this. So a lot of possible things you might want to search around on and I do know that search should be fluid. And yeah right now people go elsewhere because the tools as you can see this is font manager the GDK app doesn't show you a lot and you can't see much there other than some fields that are pulled right out of the binary and what you can see on a font you haven't installed is even worse. And those are just the things that you can see. The actual searching is more difficult than that. And I think it sort of groups into two categories. There's the technical awkwardness the fact that stuff is split up into multiple places and then there's just the metadata that you need. Examples. So stuff is split up in different locations like you have your RPM and dev fonts and then you have fonts you've installed from the web you downloaded. There's information you need before installation, information post installation those are in different locations. There's metadata stuff like about a font's come up documentation you get them from the boundary and that's not captured. There's embedded information that could be read and maybe improved in some of the tools we already have. Metadata is sort of a nebulous term because people can mean a lot of different things by it. Some of the stuff that you might just like search on are names of people who signed up. An example here would be like if you have a font that works for everything but it doesn't have bold plates an easy solution is okay can I find something that's by the same boundary that might match better than something I ran on the shoes. But there's a lot of technical stuff that speeds the metadata to. So these are sort of nebulous categories like you can do math layout. You can't really see that in any of the font searching and management tools that we have, color formats and all kinds of stuff. It's worth asking whether or not this is going to be fixed in the font packages because there's free and old response in WN and Fedora and other distributions that just are lacking from this information and can be added to it. I think I've talked before about the possibility of just storing side cards that could be read when you can't modify the font because it comes from upstream. There are certainly fonts that we package for distributions that we could modify the font and add metadata to them. But there's also this awkward divide between the fonts that the district provides and the fonts that the user gets from somewhere else and I'll talk about that in a second. So yeah that complicates things in several ways like if you have one database that has all the stuff from the distribution is done the package manager now you end up having to have another copy of that or you have to read from both sources. Anyway, how would you fix that? There are several ways you can do this. There are improvements you can make just like a font testing app and you can try and capture some of those documentation files and other things that are sort of getting lost. And there's improvements you can make to the formats used for the metadata in the package format. And there's things you can do to improve what happens when they download that zip file off the web. As a tangent, it's interesting to think about what's actually in a package. Usually you get a binary and a license file. I'm going to talk again about the distribution package here. If there is other metadata here it gets dumped in this directory under the user hierarchy or it gets lost completely. And that at least is not true in the download from the web. So fixing this means it touches a lot of different things. The GTK FontChooser widget is different from the program FontViewer that launches when you open up a font file on the desktop. And AppStream is the format that the package is from the distribution and starts their information. And I spent a lot of time last year worrying about trying to get help files to work to fonts, which means mallard. And it turns out mallard, the way it links between files could be altered and maybe do a better job of that. So I did a lot of this sort of thing last year and not as much in the last half of the year as I unwisely decided to move to another country and sell everything and start a KGT program. So I let a lot of this stuff slide but I can tell you that my only personal interest in pushing these issues forward I've learned that it's going to be slow. Like the SPDX thing I have a long list of like 40 font licenses. A lot of which are single things and only used for one font. But things I wanted to add to SPDX. And I thought I would start with the easy one which is just getting the font name clause added because there's an exception mechanism that works well for that. That's taken a year and it's still not done. It's someone else's project and someone else's process. So I can't just like make that happen. The last two items on the list there are sort of other people who are looking at what we can do with font packages to make them better fit the needs of users. Pathome is actually the guy who we're just talking about from Shilong and who is in charge of the font package. We're all of this from somewhere else and it's sort of an authentication push system for getting updates of people. It's intended to like, I don't know, the use case I think originated with commercial foundries but it certainly could be used to the benefit of open fonts as well. Those are worth looking at if this is a sort of thing you care about. Even though I said the progress was slow, there had been a lot of improvements that I said in GDK because it's added support for variable font things and for seeing open type teachers in font chooser in GDK which is terrific. I think it might be possible to get stuff like the auxiliary help files working but like I said that's sort of further down. This is an example. This is a help browser from Penn. The trick with the help is you could have topics automatically linked to each other so that when a new package is installed it knows what its parent page is automatically which would be great for having something added per font as it's installed on your system but it doesn't cross that boundary between the user directory and then the home directory where you install something personally. So that's possible that requires some changes to the format. But yeah, I got that working on my personal system with a lot of hacking so I can search for a term that I know appears in the file and then it pops up and you know, which is fun. And then the big wrinkle happens. I think this was back about a month or think. There was a hack fest at the redhead office in London and there was about a meter of data like a meter connection and you want to make sure you don't go over too much. And some other features like that but it was a lot of good old people and some of them I knew and Richard Hughes in one of the downtime moments just asked me a question about how it could simplify what is in the font package. And I think he was thinking maybe condensing things into PTC files, two type collection files and some stuff like that doesn't really do what you wanted to. But just in talking to him, it came out that when these distributions are changing a lot and a lot of you know this there's formats like flatpack and snap and app image where the application runs in a little sandbox and it's self-contained and sort of an extension of that are things like bunch of core and four doors silver blue and those are sort of a different way to build the system image where it's immutable. It's a read-only thing and when you install an application, when you use it as well as an application in a snap or a flatpack it doesn't touch the base system, the base operating system at all. And they would like to do this for security reasons, for simplification of building and testing and all sorts of things. Doex is a little different and I'm pronouncing Doex. That's what I'm saying. Doex don't let anyone type otherwise. The key thing though is that with this immutable system where something is installed makes a huge difference and the traditional place of putting a font from a distribution package is under the user share directory and that means you have to reboot the system for every font to install. Apparently they don't think that's worth trouble or at least it's a problem to be solved. And so in talking to Richard this was sort of the key thing they're getting at is fonts have this bizarre place where they're sticking out the sore thumb in what they want the immutable OS future to be. And just in the course of a couple of minutes we came to this conclusion, what if the superfans didn't ship fonts anymore and wouldn't that solve a lot of those problems? Which is sort of the question I want to ask. And I guess I really mean like what if the distribution just cared about very small fonts. Just for language support. Because that is what they test on. They don't test every font that's available and they make sure the ones for the language communities work correctly. And then maybe like those ghost script fonts that they need for like documents and the compatibility for Microsoft documents and things like that. It's interesting to think about technically speaking when I say they always didn't ship font packages at all. What I mean is what if all the font packages were installed in the user's home directory instead of in user. I think that would probably solve some problems for one thing keeping track of two separate locations with all that metadata that goes away. And also just possibility of installing the same font twice accidentally goes away. Then there's some like further down there's this issue of recommended fonts. Which comes up all the time. It came up in every open font library talk I ever had. And every bot, we've done an LGM about fonts. There's just too many. There's thousands of fonts in the tech archive and in Fedora and in WM. And people want to know, I just want recommendations from someone who knows. And as long as the user has to go through this process that doesn't work with installing things, it's difficult. It's that you have to add a meta package that installs certain font packages for them. And that's just awkward. Whereas if all the fonts are going to end up in user anyway, you can download that from the web and it doesn't make a difference. So something like open font library can just put things in the user's home directory because it easily is a dead end package. Applications when you can install their own fonts easier. You don't have to worry about as much there. It's also possible to get new features like synchronizing what's in one desktop and a laptop for instance. You can't do that when you're dependent on the distribution to provide font packages. And then also it would simplify this issue of managing fonts that come from other places that are not under open licenses because right now those have to be in a different location. There's drawbacks to that. Obviously that you do want for pre-installation searchings to have to be somewhere. The big issue of course is that people have to learn where to look for the fonts in a different way or different place. And there's often a lot of packages that need to change. Certainly something to break that I haven't thought of. For now this is a thought experiment. Let me know what you think about that. If you're interested in this topic, I would say don't just like plus one of those issues but think about the questions that I sort of pointed to you otherwise. Like how do we handle zip files smoothly and are the font packages in type world issues interesting? And then maybe the most interesting thing that you could do is try and write some software that leverages font metadata in interesting ways. And I've got ideas for that. Like a way that you search for a replacement font that takes some interesting metadata into account. Or something that converts type one and good map fonts to modern formats. And maybe just an app data based install over fonts right now. One thing that holds up getting better richer font metadata into the app data and app stream specification is to make that only you know software uses it. And so if there's something font specific they might care a little more. Anyway that's my question to everyone what if the distribution stop installing fonts or just cut it down to bare bones minimum and everything else is just in the user's home directory wouldn't that be nice? Or am I way off? Okay let me know. Thank you.