 So, I'm now employed by Google, I work as a program manager in the Google Fonts team. And so I'm responsible for the fonts part of Google Fonts. And over the last few years, I've been contributing, I initiated and been contributing to a project called Font Bakery. And Font Bakery is a project to make it easier to check that fonts are good. And not just fonts, but font projects, that they're, you know, reliable, that when users are using them, they're not going to send me angry tweets saying this is broken. And with over 800 font families and over 2,000 font files in the Google Fonts collection now, then having software to automate doing these kinds of checks is essential for us to move forwards. So I'm going to jump straight into a demo. We have a web interface to use the Font Bakery checker at fontbakery.com. And if you go there, you can drag and drop your fonts from your desktop into the browser. And as you drop them into that little square area, it will list the files you've dropped in. And then you click run the checks. And then you'll get a check report. And you can see currently this is checking over 100 checks. Some of them are sort of maybe, you know, not too important. We have this fail result at the top here that the OS2 table's vendor ID is unknown, UKWN, which is a font editor default. And so it's a good thing if you're making fonts to have your foundry code registered with Microsoft, they make it easy to do that. And so, yeah, very simple, you know, small check, the kind of thing which could easily be overlooked. But it's good to do. The second check you can see here is a kind of much more complex kind of check. And so we did an analysis of a lot of fonts. And we resolved that the typical number of contours in a glyph. And then we check if that glyph has that typical number. And so you can see that three glyphs in this font actually had an unexpected number of contours. And sometimes, for example, if you have a light master, a bold master, and you have a glyph like a double quote, the two contours can be there. But if the contour order is different, then in the interpolation, they'll cross. And where they're overlapping, that will become a single contour. Obviously, a double quote should not have one contour, it should have two. So this is sort of an attempt to write a technical check, which will capture these kinds of production issues in a more sort of general way. The example that I gave, you could write different checks for that. But this was something we felt would be useful in general to know. And then the third check here, you see the OS2 table, US Winterscent values are unexpected. Vertical metrics, it can be very tricky to get all that stuff set up, correctly, and it's important for us to maintain that consistency. So this web UI page, you can see that those 132 checks, they were run, 100% of them have been run. If you have a bigger family, for example, something like Montserrat, with 18 styles, when you run all of those checks, that balloons to nearly 2,000 checks that have to be made. And so this system is running in a server environment, so that all of those checks can be run in parallel and hopefully faster. And so here you can start to see the fonts have equal number of glyphs. That turns out not to be true, maybe that's worth looking at. The glyph names are sometimes also not the same, that can be a problem. And so you can see over time, the number of checks is going to run up to 100%. And with a family like that, there are also checks that you could do, not just per font, but across the family. And fortunately of the 23 checks that we have so far for a family, all of those have passed. And so there's no results there. And you can see underneath there's a list of jobs. And so that's at least 13 little workers running the checks in parallel. The buttons at the top allow you to kind of filter the results. And so if we select the pass results, then we can see those seven pass results. So that's the web interface. And obviously, you can run that from anywhere on any computer. You don't have to install anything, you just have your font file, you upload it to get it checked. What if you want to run it on your own PC? Maybe you don't want to upload your important font to some strange server, fontbakery.com. There are some other font checking tools which have been published recently, for example, wakamaifondue.com, which are using JavaScript to check the font files. But we're using a server-based system so that we can have that parallelism that we can run thousands of checks on dozens of files in parallel. But if you want to install the program locally, it's very easy to do. If you have Python installed, you just run pip install fontbakery. And it will all be installed for you. And then in the terminal, you run it. You can run the help command to get some information about how to use it. And there are some kind of sub-commands. The main one is check specification. And what we mean by specification is a set of checks, not just one check. And so we have checks for the open type specification. So we can say we want to only run that set of checks. And then we have the listing to the font files that we want to check. Similarly, we have a specification that's specific to Google Fonts, which is what I've just shown. And we have a little kind of shortcut command, so you don't have to type all of that out. Make it a bit easier. And then we also have a GitHub markdown output, because this process of developing a font, handing it off to a font distributor to publish, is typically a conversation. And so Google Fonts is using GitHub to manage that publication process. And GitHub uses the markdown markup format to kind of structure its comments. And so here's a recent full request that was made by freelance font engineer Mark Foley, who does some contract work for Google Fonts. And here's a new font family called Notable. And you can see there's this kind of font bakery report. With a summary table, we can see that there are some different kinds of results from this checker. So an error would be where the program actually failed. It's not a problem with the font. It was a problem with the program. Fail is where there's a problem with the font. And that's a serious problem. It's a burning fire. You have to put it out. Of course, there are a lot of things, which you could warn somebody about, but it requires some human judgment, that maybe it's okay, maybe it's not okay, it needs to be considered. And of course, a lot of checks can be skipped. For example, this is just a single style font family. And so all of those family checks can just be skipped. Some things are just for information purposes. And then it's a good thing a lot of fonts have passed here. And so this font bakery report is actually expandable. So you can expand that out. You can see what the checks were at the family level. And font bakery is offering not just checks for font files, but font projects. So for example, the description file here was missing. And we want a description longer than 200 bytes. And in that font bakery report on GitHub, there's a link to the check itself. So all of the code for font bakery is online. And that link goes to a code search for that check ID. And you can see there are actually two pieces of code for every check. There's the check itself. And then there's a test that checks that the check is working correctly. And that means that as changes are made to the check over time, we can be more sure that it's still going to be functioning correctly. So under the hat here, we have this QA framework for testing fonts. It can test, you know, TTF and OTF binaries. It can check source files, whether they're for glyphs or UFO, and related kind of project files, descriptions, even things about, you know, if you have a project in GitHub, do you have a readme, do you have a little sample image, things like that. And so we kind of want this to be batteries included. We want to have it all of the useful checks that people can rely on. And so we've broken down the open type table, the open type Microsoft spec table by table. We also have distributor specifications. And at the moment, we just have the Google Fonts distributor checks. But I'm hoping that other distributors will see this as a good solution and that they will be able to write their own specific checks. Say, you know, a font distributor may have, like, JPEG images of the fonts in use. Big Google Fonts, we don't offer that in our directory, but many distributors do have those kinds of sample images. And so you could check that a project does have that kind of stuff in it. And then, of course, custom checks. The way that all of this has been built is by writing these checks. And so making it easy to write custom checks is important for us. And so the way that that works is instead of referring to pre-built specification, you create a Python file and you write your checks in there. And so it's very, very easy to do this. First of all, there's a few little bits of boilerplate which do some kind of fancy Python dependency injection clever stuff, which I don't totally understand. Not being a software engineer myself. But then you write a check. And so you give your check an ID and then you define your check function. So this example, we're going to check for a non-breaking space. And this is something which is important to fonts in the Google Fonts collection, but you can have a valid open type font without that glyph. It's just that some systems, you know, are going to not be able to lay out text properly without it. So it's a very simple check. We have a convenience method for getting a glyph. We try and get that glyph. And if we can't get it, then we return a fail. And otherwise, we return a pass. And for those of you who are familiar with Python, if you wanted to check to return multiple results, then you can yield those results. So a quick note on naming. If you do write your own check, then naming your check is sort of important. And so what we're recommending is to use reverse name, reverse domain name notation, and to use actual names, not numbers. And so, yeah, it's a good example, a bad example. So we also wrap existing QA tools if they're available on your system. And so the OTS validator is in Chrome and Firefox. If your font doesn't pass OTS, it will not render in those browsers. So it's very important to not have that fail. If you're an Apple system, then there's a tool that you can install from Apple called the FDX validator, which is the same checking routines that the font book uses. So you may have experienced trying to install a font and the macOS refusing. So you can get ahead of that. You can run those checks, get those results. Also, Microsoft font validator was recently published under a Libre license, and so if that's available, we'll run those checks. Fontforge also has some kind of validation functionality. And the Adobe font development kit also has some checks, which we're hoping to wrap. There's a command line interface. This is all Python 3 code now. As of the release this week, it's all Libre licensed. It's all on GitHub. We also have the web dashboard, which I've demonstrated, with this kind of drag and drop interface. And the reason that, as I said, we run this on service is to run many thousands of checks. And so for a publisher, for a distributor, then as a distributor, then I want to be able to run those checks at every stage of the publication process. And so this web dashboard actually has a quite large system behind it, using the Kubernetes system with a mix of Python, Node.js, you know, it's a web framework. And so the web dashboard has over 2,000 servers behind it running on the Google Cloud platform. And so I'll give you a quick demo of this. This is the dashboard, as it is today. And it's pretty overwhelming. There's a lot of numbers. There's a lot of columns in this table. So let's break it down. On the left, we have a list of over 800 families. And on the right, we have the check results for the font files that are in Google's production servers. So those are the files which are being used live on the web on millions of sites today. And there are a lot of people download every day. And so we can see some things are failing, which is bad. And the sort of input point for those fonts is from the github.com slash Google slash fonts repository, which is a sort of mega repository for all of the font files in Google Fonts. And then the way that we make updates to that set is through the GitHub pull request system. And so you can see here that there are a few families that are open pull requests. So they're pending updates which are kind of ready to push through if everything looks good. And then we have the designers upstream projects on GitHub. And so by running checks at all of those locations, we can kind of see the flow of improving the quality of the fonts on a technical basis. So to pick out one example, here we have Laminada. And we can see that on the designer's repo, with the pending pull request, there's only 11 things which are failing, which is not quite good enough. But in the production service and in the main GitHub, there's actually 20 fee things which we can now automatically detect as a failure. And so you can sort of see this flow of the publication here. Moving forwards, we're going to get the designer to bring that down to zero and then flush that through the publication process. And so over the whole collection, that's going to allow us to eventually bring everything up to zero failures. And that'll be a good thing. I'll get a lot less angry tweets. So the web dashboard, as you can see, is providing this comparison of version to version. And so we have version comparison software under development this year. And so that starts with technical comparisons. So here was a quick technical diff that Mark made for the Roboto slab project. And you can see OS2 table attributes were modified. We also test mark to mark positions. Obviously that's a big deal, accent shifting around. We can see where new ones were added. We can see glyphs that are missing. We can see glyphs that were modified. And we have a little function that tries to measure how much they were modified by. We check the name tables, see if any name table items got dropped out, if things were modified, what was changed. Even the kerning is being checked. And so we can see that this was completely respaced by the designer in the latest update. We can see some kerns were missing. A lot of kerns were modified and there's some new ones too. That's good. And so if you want to install this and play around with it, again, it's very easy to install if you have Python, just pip install the font divinator. And we're also working on visual comparisons. And integrating that into the directory is on the roadmap. So this project exists because we want to be able to accelerate the onboarding process. As many of you who have contributed to Google Fonts may know, updating fonts can be very slow. And that's because it has to be done carefully. So the only way we can scale as a distributor is to have more automation in this process. And by making it available under a Libre license you can run on your own computer that hopefully you can start to run these checks yourself and even contribute to them. Everybody cares about quality and nobody is going to benefit by shipping buggy fonts. The open type spec is becoming more and more complicated. And a lot of foundries in-house QA tools are often old. The Microsoft Font Validator hasn't been updated in many years until it was open sourced. And using it, you kind of had to know which things you could ignore, which things were actually real serious failures. So we wanted a modern tool, which is complete, that wraps all of the other checkers. The project has evolved over the years and last year, Larsa Fista has completely rewritten it to be this modern, strong tool. The core idea, I think, is that writing the next check is now quick and easy. And we would love to see everybody adopt this and use it across the board. So really what we want to see is more users. We love people reporting issues and we want more contributors. And so if you are a font engineer, you're familiar with Python, then we'd love to have your contributions. And if you write your own specs, please share them with us. Thank you.