 So we're actually starting now, okay? Usually I like to to begin by asking if there's anyone who speaks Polish In the audience I guess not okay. Well, it might come up later, but we'll just power on through so This talk's entitled rethinking font packages and It's rethinking only if you've thought about font packages in the past In particular The subtitle here is from the document down and the document part is the thing that I actually wanted to talk about It's actually my second debconf But it's the first one where I've said anything and it's because I have been thinking about this font packaging issue for a while But first before we get into that a little initial tangent Just to set some context if I look familiar to you It's because I spent about 15 years being a foster journalist most recently with LWN Which is still where you should get your news about free software and open source I still sort of think of myself as as it being a part-time contributor there Even though it's been ages since I've actually contributed something But about two years ago I left to go study typeface design in England at the University of Reading Which is one of the few places where they teach that that course lasted through September of 2017 After that I started consulting at least in theory on on a typographic related things so you know if you if you need help with Open type or Unicode or one of those things come see me I suppose But I got some contracts, but to set it I didn't want to try and fill every waking hour with that sort of work and instead I made a list of other things I could do with my free time that that dealt with fonts and type in the free software world and There was a lot of those everything from from actual design work to The document templates and what we ship with our fonts and that sort of thing But the one I kept coming back to was this big disconnects between how people in the design field Work with their font collection and the way we work with their phone collection on Linux That's because for that year that I was in Reading I spent a lot of time around graphic designers and Book designers and information designers and I got to see how they work firsthand How they select fonts in particular And I think that as far as the the font plumbing goes if we were to examine How things are set up from the workflow or through the lens of the workflow that people in this profession use We'd end up with something really different than the way it is currently configured If you want proof of that just consider the fact that free software fonts on services like Google fonts just dominate The web it's trillions and trillions of hits, but they don't really make a big dent anywhere else and Not a lot of people are using desktop Linux distributions to do typographic work So for the purposes of this talk I'm going to sort of walk through that workflow that I that I got to see firsthand from people and then we'll talk about Where it doesn't match what desktop systems do today and then finally we'll get into how that affects font packaging Because that's one of the big contributions that the Debian project has on desktop font architecture is Debian and Debian derivatives provide the vast majority of the packaged fonts to desktop Linux users so Right into fantasy land it starts here the user is working on a document, okay, and in fact It's a particular document, which is an important specific point to note because each specific project alters something and Whatever that particular document is It's it's going to set the constraints that follow and in this case Let's pretend that it's the annual report for your project and it's a large project So you care about the annual report make the GNOME foundation or I don't know open stack or some enormous project like that You might show this document to people that you hope to get resources from so you're gonna do it, right? and I think the thing to keep in mind is that The context the document is the context in which all further decisions are made and a lot of the workflow descriptions I've seen about selecting fonts sort of leave that out they just say these are selecting a font and I think that puts you in a blind alley and These constraints their requirements and restrictions on what you can and can't do and conditions need to meet Some of which are aesthetic some which are technical that really determines everything that follows So in this case our annual report We're gonna say we're gonna types it at this year in English and Persian We also need to have a few words in Spanish and German like let's say there's some names that we need to do So it won't be long stretches, but we need to make sure the right accent marks and special characters are there and Remember it's going to look good to people who read a lot and who will toss it aside if it looks unprofessional so when we say it's gonna set English and Persian and it's look balanced and it has section titles and it has Images with captions and it has tables of things and all those pieces need to look like they were done correctly Okay, so what is the workflow we use? Well, we open the font manager and If you do a lot of document creation, you probably have a lot of fonts installed a couple hundred maybe hopefully they're good ones And the first thing we want to do is search for fonts that support those design languages mainly Arabic and English and When we say that we search for these things to be designed together That's because they need to look right together on the page You can't have one of them look a lot darker than the other You can't have the lines be off and if you pick a font where the Latin and the Arabic were designed Together, you don't have to spend every waking hour making my new adjustments to the line spacing You can't have things be different optical sizes so that One paragraph takes up a much larger vertical space than the other that sort of thing What happens unfortunately? We don't have a billion choices when we set those constraints. We might find several Let's say several dozen fonts that have English and Arabic together But all of them or most of them are gonna be missing something like they don't have the asset or they don't have this till the over the end Or they are Arabic, but they're designed to support the Arabic language not Persian which is a different style Yeah, and by the way half of them are really funky display types are not for setting text So they look like graffiti or a bunch of balloons or a retro video game or something like that But this is just the start of the process. It's not a problem yet The next thing we do is filter those fonts that we have left four things that have the variations that we need So we need some metallics with some weights Maybe just a bold maybe more than one and we want those optical sizes because we need to have image captions Which are really really small and we need to have titles which are really really big Back to reality the number of alternative the drops obviously when we do this Now we think to ourselves at this point. We could start giving things up, right? We could say we'll just use a different font for the section titles and things that's a possibility It's not the normal workflow and it also just changes the discussion too much So we'll we'll keep searching for the perfect font Next thing we do maybe look at some samples I mean we have a few options left But we need to see that they actually work together in a document that there's nothing unusual about them when you look at a Whole page or a whole paragraph So we open the specimens that came with these fonts see them use And let's say that that causes us to toss something out because a couple of them are really too ornate and they look like Calligraphy like a wedding invitation not really a Document that we would use for business purposes Fine. We have some potential choices left. Okay, so things are not impossible yet We do still need to make sure we have our technical features and in this case because we're doing tables of numbers We need to make sure that we have tabular numbers in the font And we probably also want to make sure that we have lining and non-lining numbers so that when we have Years and things in the running text those look okay, too So what we do is we just keep searching in the font manager for those features And then we hit a dead-end. This is pretty deep into the process. So maybe we just Have only one font left that meets every other requirement, but it doesn't have one thing like it doesn't have tabular numerals That's not an impossible situation to find yourself in So what you do at that point you can pivot you can look for something else you can say well This is just one font Maybe we can find a font with compatible numbers and set the table in that instead So we would look for maybe a font by the same designer Like if the Latin is listed as being a castle on design or a Jensen or something. We've probably got another Jensen somewhere in those hundreds of fonts Or maybe we just know that this is from a particular foundry People don't do crazy things with numbers So we'll look and see if the foundry has another font we can use that will hopefully match and not stand out too much No dice though Maybe we find one other font release, but it's another one of those crazy fonts that we can't use So what do we do then? Well so far we've just been looking at the fonts already installed So we need to see what else is available that maybe we just haven't downloaded on to our machine yet So we use the package manager For the sake of time not going to repeat all those same searches, but it would be basically the same process you look for the The facets of the font family that you need in terms of the language and the features that it supports and the range of variations that it supports and We're just gonna say because it takes us all the way down the path here we don't get any better luck at this point and Maybe we don't actually have anything available to us through the distribution that will do what we want perhaps With a last bit of desperation if we pop open a terminal and we search around with apt cache and Find and that's located whatever else you want But that's not gonna find anything for us In fact, we're dead on this machine. We're gonna have to go somewhere else But that's life. So we start just searching on the web. Maybe we go to Google fonts. Maybe we just look at other sites that deal with fonts and Look at the little sites that the designers have put up describing what their font does Maybe there's more specimens to look at and this time we succeed What happens next is we get a zip file downloaded from this website that has the font We open it up and then there's a download helper that's associated with our web browser that installs upon locally to the machine And it finds that documentation and other stuff in the zip file and puts it in the right places And then we being smart tag this and our font manager so that we know This is what we're using for this particular project and next year when we're doing the report We know we've got at least one font that we can use Okay, so we're done. We found the perfect font How possible is this presently not at all Or maybe barely Why is that? Well, I would say there's a handful of factors starting with the fact that that font manager we used in the first stage doesn't really exist You might remember a program called font matrix a few years ago, which it did exist. It's no longer being developed In fact, I think there are people who make sure it still compiles, but it's it's got limited time left It's on an old version of Qt, so it's not gonna last forever. There is also something called GTK font manager Which is a little bit less full featured and I'll get more in depth into that in a little bit, but it's also not Exactly what we want in this situation In addition to that it's not it's a personal project by one developer, so it doesn't come By default in a GNOME installation even though it's a GTK related app Yeah, we'll talk about that The second factor which is the software center is much the same the software center doesn't have All that information that we were searching on that the font manager did Fortunately, it does have some information It has the names of the font so you can tell Sort of accidentally if it's a big family with multiple styles There's usually a human written description Which gives you information There's a screenshot, but that might be automatically generated And there's some kind of sample, which is a quick brown fox kind of pangram The third factor is the web installation, which is uniformly terrible On Linux today in the sense that nothing happens you get that zip file It looks like this you can open it with the archive manager This is an actual actual font. There's a ton of stuff there There's a lot of files. There's a documentation folder. There's a web folder As you can see there's actually Sources and PDFs of some of that documentation But nothing happens when you quote unquote install it except that It gets put into or the font files the binaries get put into a particular folder in your home directory Another tangent here the reason this is something i'm harping on is that there are only two ways that you get fonts onto a system these days With a little bit of an asterisk You either either comes through the package manager or it comes off the web Now the third option is that you build the font locally and install it But that's sort of a different piece entirely And hypothetically there would be a fourth one which is a synchronization service But no one currently offers that might come in the future. We'll see But that's why that matters because if it doesn't come through the distribution it comes from the web The fourth factor Distribution packaging infrastructure Doesn't really support the user's needs. It supports os integration In other words when you copy that font from the zip folder or wherever else into your dot fonts directory That makes it available to the operating system. It doesn't make it available to the user In the meaningful sense that we were looking at in that workflow example Which is kind of the big dichotomy Of fonts because there are software and content at the same time All right, they contain executable Instructions that get run by an interpreter But they are also a page element that the user is actively interacting with and manipulating as part of the design process And the software stack basically just supports the os part of that the software part The fifth and final factor is that font packages themselves tend not to be very rich items This varies a lot to be sure but on the whole they're minimal. They contain the binary and not a whole lot else Um or as unnamed source Richard Hughes put it we package them like their cli apps even though that's not what they are So, um I guess the thesis of looking at this example is that When we don't address that content dimension with the software stack Then we give users no choice but to go elsewhere for their information about what's in the font and what I can do What those features are there's a lot of websites where you drag and drop a font and it shows you what the features are and things like that Fortunately, I think all of those Factors are addressable. Some of them are already in the process of being addressed because people do care about this stuff And I would break it on it to sort of three dimensions although I should point out that the dimensions are not even euclidean and separate from each other But you know, we'll see the first one is is metadata Which is what we talked about in all those searching and filtering examples. The second one is those resources that come in the font Download packages that we don't don't want to do with and the third one is package behavior and although I'm kind of targeting this talk at people who maintain font packages The other things are important too because I think if you're a font package maintainer, you ought to know what Is happening elsewhere in the stack. So let's look at the metadata example first As we noticed most of the searching and the sorting in that workflow example was done on metadata not on actual glyphs in the font um this Is a screenshot of gtk font manager It has a little bit of metadata there. It has a weight width and style which are Directly read from the font binary tables and those are actually pretty old. That's sort of the microsoft way of dividing up fonts It's not necessarily helpful to you. What does medium mean exactly in this case? What's normal? It also shows you that it's proportional The spacing thing is just whether it's monospace or not that very rarely comes up in making documents You can also see a sort of a waterfall example little bit of context there It's automatically put there. So if you're looking at a font in a different language that doesn't really show you Accents and extended latin characters and things And it also fails around then so it's not It's detecting something and not showing you what things is there Uh But mainly I think The the issue here is that this is just reading static information from the binary and showing it to you It's a good start, but it's not what you need to work with a collection or a library and in my opinion, I think Working with a collection is something users are used to doing with like their audio their music collection And if you look at an audio player Most of the screen real estate there is devoted to showing you metadata And giving you ways to search it and sort it and and manipulate the collection through that metadata That's a rhythm box This is you know music. It's just it shows you there's more than one way to look at the same collection and then there's auxiliary tools like easy tag which allows you to You know correct that metadata that's kind of taboo in fonts historically because I think the commercial proprietary font Business is concerned about people falsifying information and changing the license and things like that But in a lot of cases there's just metadata that you could have in there that would help you when you're searching and sorting But we don't have tools for doing that on the desktop So you have to sum up the metadata for fonts can be hard to get to and And it's also sort of split up in different locations like at a practical level There's several pieces in the desktop environment that that read it But they're disjoint from each other There's a little bit in a software center. Like I mentioned, you might even have a screenshot which is metadata That's handled by AppStream, which is the specification that a lot of software center style applications use these days GTK font manager as I mentioned is just showing a few things from the binary And there's font config which knows some stuff about each font not everything Pango also if it's in a GTK stack is recording some metadata And then there's also some metadata in the font package. You may have screenshots and other information there too So yeah, those are different places and they're not unified So that means that some of that metadata is duplicated in different Places and some of it is just missing altogether. One thing it's missing though is a desktop wide or per user cache of the metadata And I think it's possible that there's interest in making that happen Which I'll Talk more about in a bit But yeah, because there's so many pieces that need access to metadata about the font It makes sense to not duplicate it So just for the for the context when I say metadata Here's a dump out of a table that I made trying to track what different Applications from that previous slide Store there's everything from the copyrights and the trademark notices in the font To what language is designed for just you know, the weight class Panos venridae there's urls for You know the designer and the foundry is a color font If it is a color font, how many layers is it? Is it for vertical layout that sort of thing the last one down there? Pretty important user tags If you want to see the table of this stuff, I put it on a Snip it on git lab It is a Markdown render into html, which means it's kind of ugly, but it's a start And so let's let's talk a little bit about the actual metadata options we have today app stream Which is that that pre-installation material you might see Fortunately fonts are a top-level object in the app stream spec. You have software packages And there's a few other things like codecs that have sort of a special category But the the font spec just defines a handful of a field source including Provides which is where you tell it what font face is included and you can have more than one of those So you can't indicate that the package contains multiple styles and variations and The other good news is that the app stream team has been open to Expanding this I opened an issue on this and suggested a few more sort of simple editions The designer name and Foundry name were pretty obvious because those are things that Are very high-level you could obviously go all the way down into those 50 metadata Elements, but that's probably not worth it I added The url type for the specimen there because there's a lot of websites that are a specimen for fonts And that that might be something you look at before you install it and and the reserve font name one there is sort of a another tangent AppStream uses spdx software packet package data exchange format to specify licenses That can make it tricky because there aren't a whole lot of font licenses currently supported And look at the wide range of weird fonts and weird licenses out there So I've I've tried to move that forward a little bit too and particularly I want to add support for showing that an OFL licensed font has a reserved font name because that can be important if you're needing to modify it or something But moving on other good news on this metadata front is that matias classon who's A gtk maintainer these days has been reworking the font selection dialogue And that should be rolling out in september with the 3.24 release This is a screenshot of one of his earlier attempts He's in particular been focused been focused on showing variable fonts support And on showing open type features. This is a newer screenshot where you can You see that you can manipulate things and the examples that he's showing there of the Letter case and actually in the next screenshot you can see some of the stylistic alternates That's kind of important because that allows you to see what the open type feature actually does And it turns out that can be tricky knowing what sample string the show I mean it's pretty obvious for slash zero what you want to show but For these stylistic alternates and for some of these contextual chaining things You could either look into the font and try and parse the whole G sub table, but that's a lot of work and a lot of time Or you could maybe just try and find a good word, but then you have to have a dictionary at words So we've we've Decided it may be necessary to extend the spec and include a little sample string in the open type table That's possible. That's already available to you in the character rearing it feature, but not everywhere But there's more happening as well more potentially good news From the gnom community. I should apologize that I don't really know the kde side of the story very well But I did bring up at gwadak a few weeks ago This can we do better with that downloaded zip file question? And the answer is probably exactly what form that's going to take is a few releases away. Maybe There's interest in handling that better in particular You can install things like documentation within the user's home directory and dot local slash share slash doc So it's possible It's just not obvious necessarily how to automatically do that for any browser that the user might choose and also Yeah, there was some interest in maybe having a database of the font metadata at the at the desktop level I mentioned when I was talking there that this is the kind of thing that tracker normally does in the gnom system It handles all your photo metadata and all your music metadata That might not be the way forward because Tracker is really for user level applications And this is stuff that needs to be accessible to pango and these lower level libraries as well But there's interest in moving forward on that which is really good news Uh, the next major dimension here is What we actually do about those resources in the downloaded zip file, which also exists In a lot of ways or sorry in a lot of cases In distribution packages too and when I say resources we're talking about anything other than the font binary That comes packaged with it from upstream For example manuals Sometimes there's user documentation. It's like a guidebook It can include specimens which are showing the font and use it can include maybe Uh, png screenshot, maybe several There might be a little miniature website That's a resource and at least having a link to it is something and there can be Sort of example code in particular for web content Wow, that's really acting odd, isn't it? Keith, Keith, why didn't you say something? It looks really nice on this screen Um, so there's a wide variety of pieces of uh Ancillary auxiliary material here is what I'm getting at and um In a lot of cases distro packages will include some of this and for debian The material has to meet the free software guidelines So if it's a pdf, but we don't have the source that rebuild the pdf Then it might get taken out by the packager Um, almost always when the font Designer makes the package themselves you get a ton of stuff I'm going to show you some examples of the kind of material That's in one of these this is from um An arabic font called awami and it has a lot of detailed information in the manual about how to access certain alternates Uh for stylistic variation And this is kind of the kind of thing that's important for linguistic reasons Uh Sort of the other end of the spectrum. This is a font called bungee Which is uh one of the very few open source color fonts It has multiple layers And there's about an eight page Micro website about how to combine those and this is why we call a documentation if You were to just dive right in without reading that you would not figure out how to combine all of those and get all the styles that you want so that can be important stuff and uh Not just for aesthetic reasons This is from eb garamon which it has a manual that's probably 20 pages long I think And there's detail on here about not just what the ligatures and things are but in some cases why they exist Which is sort of interesting background information um And and you know understanding the intent can be helpful to you You wouldn't need to know If you do know that this font is designed to look like a renaissance typeface That's worth knowing When I say specimen that was listed separately from documentation that generally means something like this. This is from gentium Which is a really famous large open source family And these are usually designed as pamphlets or booklets They look like marketing material because in the commercial world they are marketing material But even for open fonts you'll typically get it as a pdf as opposed to some other Document format It might be really simple and just show you the characters in the big block But more often it showcases the font and use In paragraphs and in whole mock documents and things and that's really the value of it is it allows you to see context for entire sentences and words A lot of times these days this will be done on the web as well. This is from Yersa and you know, we can at least link to those even if we don't have a copy locally And this is not purely an aesthetic thing Specimens can make or break your ability to tell if the font is functioning correctly This is Bengali And If you can see there are characters that are attached above and below There are some things that combine together But if you were to look at gtk font manager in that grid, you can't tell if any of those functions actually work So seeing the specimen lets you see that it works correctly in text As you need to set text Anyway Whatever you think of any particular document type all of those resources currently if they end up anywhere Get dumped at the user share doc and I guarantee you no one looks at them again We could do better It's my only point there You could capture their existence and treat that as metadata to show the user in different places We could maybe even tie them into system services And here's where we enter the third dimension Which is to say that it doesn't have to be just a static reference What i'm really thinking of here is that If the file resource is something readable by the help system We could place it in user share help will automatically get picked up By the help browser like yelp I know that's a huge change But I will say like that change alone putting a help document In a different place makes it accessible to the user in the desktop help system And that's huge type foundries complain about this mac os users complain about this because no other operating system does this It's a source of frustration the trick is Whether you have something readable or not and we're really getting into the package changes now It's a real issue Yelp is capable of reading a few formats like man and info natively html is fortunately one of those But in all likelihood For debian font packages there could be some work involved And of course, it's not entirely clear sometimes what constitutes help and what constitutes just general information Do you need the renaissance references? Is that help or is that just documentation for your own edification? It's it's nebulous Here's another example from the same ebgaramon This one is a little bit more like help in my opinion um So he mentions Here for instance j was not a separate letter at the time And so one of these character variant features replaces all j's with an i Okay, that actually might be helpful to know and so it's Not just telling you what the feature does about why And I think that's right on the border between Something that's documentation. That's something that's helpful when you're trying to choose the font Um sort of the other side of this another example from the the arabic font is that Okay, one of these is arabic style one of them is urdu style You need to know that if you're a native speaker of the language you might recognize it automatically Otherwise this helps the user um, but yeah that That notion of taking documentation out of user shared doc and putting it into user share help or wherever else probably means work because It means pulling some information out of pdfs. Maybe um The upstream maintainer may not want to do this. They may not have looked at the font in 10 years And changing install paths means You know monkeying with your package And it's always possible. There is someone who knows that you have something in user shared doc and will get upset to find it gone And and the other thing I have to acknowledge here is that Changing this to tie into system help is a big chicken and egg issue because Users are accustomed to not having any help Are they going to discover it? I don't know At worst, it's a no op if they don't know that it's in user share doc. They won't know that it's in user share help But at least in this chicken and egg issue Someone knows where the eggs are And that's that's that's yelp or whatever the kde equivalent is Uh, so there's a few other things just moving on still on the package behavior front where I think we can improve Consistency is not perfect when you look at your font library as a whole And I mean it's fine down to a point, but this is just a random selection of font package names So the first one there cross core is a set of like unrelated style Fonts that just sort of come from the same Uh development projects Dejabu core is one font george williams is a designer's name Guccier is a language Fonts awesome is a web resource. That's not a font at all Indic actually Guccier and indica both meta packages, but there's issues with that too Sil Ezra the s i l is a font foundry Ezra is the name of the typeface gs fonts is totally different Any font it doesn't even have the same prefix as everything else. So yeah, we could probably do better there Same is true with the install paths In a lot of ways people Install to use your share fonts and then the file type, but it doesn't always work that way here again, uh no toe at the top is A mega family from google Lay to orlanto and this is where we need someone to speak to polish is one particular Small family by the same person And then you have low heat which is split Bengali and awesomes into two directories there even though it's the same writing system Bang extra is not a meta package like guccia was that's a set of unrelated fonts that just happened to support Bengali Semiac ends up in two different places and then joint fallback doesn't even end up under The same director is everything else and then the last one down there sorts mel that is the uh, let's see what is that? gaudy book letter maybe but the issue is that it has a sort of Dump everything in the same place Approach including some otfs some ttfs and some sfd's which are a font for source files They all end up in user share fonts Yeah, sure. There's nothing insightful about me saying let's fix some bugs in packaging We all want packages to be excellent. I agree I'm only mentioning it here because this having better consistency across the font library can't help with that big font dichotomy about the software and and content issue because well, um, that even has a large influence here and These are rough numbers google fonts about 848 families open font library Almost any one can upload things there So it's got more but that means Is third on the list and it's a little hard to count some distributions um, so consistency is a good example for other people and but also The name and of the package and the fallback path Are are in the path are our fallback mechanisms. So ideally the font manager will exist and give you the ui you need to find stuff Failing that the software center helps you find stuff failing that you can drop down a command line and figure out where something might be if you have it And there's also maybe some technical reasons to think about Being ultra ultra consistent on this sort of thing Like the gtk font explorer example I mentioned earlier if you want to provide a link to a pdf specimen or documentation in that then you have to Find your way backwards from the font explorer to where that directory is in user share or whatever That's not obvious that the faces that Are available that high up in the stack might be virtual faces like serif And that means going through font config. So if there's a little more consistency, it's a little easier to maybe find your way down to the right place Personally, I would like to see Debian font packages adapt the two-tier scheme where you include the foundry name And I know that's controversial It's sort of weird To some people but some packages do it already I've got a couple reasons for that the first is that you can always have name collisions Because people aren't necessarily creative about choosing their font names and most people don't really search to see what names are taken Also, it sort of mirrors the the metadata structure of audio tracks, which is artist album track and in this case There's not really a good way to put the the artist in there because fonts have multiple designers It also just communicates that relationship to the user which is helpful in certain situations And reality is that you want to coexist with these fonts people are downloading from the web And when people download from the web, they put them in folders and organize them in this fashion You might dump all your fonts into separate folders The first few times that eventually you realize that more than a screen worth and it's too complex So you start sorting them yourself And and yeah, that would involve Adopting this method adopting this model would involve packages changing some things and I want to be careful About just telling people that they should go do this. I understand it could be a sensitive issue So I'd love to get some feedback on it The final I think it's the final sensitive issue I would bring up is that when we talk about metadata, we don't always have everything we need in the font and It'd be nice to say well, we'll just add it All right, but if the upstream author doesn't want to make a help file for you And if they don't want to add fields to the name table that include the designer name and URLs and things like that What do you do and well Making your own html help file is one thing patching the font binary really different You might just be adding to the font with with metadata, but For an ofl font with a reserve font name that triggers You having to rename the font and also it can just irritate people So yeah, it could be controversial to actually do that if you're the packageer I would say that's one of the main challenges And it could be hard to get the information you need from upstream At all like why exactly does this feature exist? Upstream may not even have Version control that you can get them to agree to use in which case you're going to be maintaining that patch against the font perpetually And then yeah, you just by doing this you could upset the upstream author You could upset downstream users you could upset strangers, I guess And then it's just going to be a compatibility issue perhaps for people who Get your patched version of the font with excellent metadata And then they talk to their friends who don't have that metadata metadata and they get confused But I I think it's still worth considering because All of these little changes to packages Including some extra metadata fields including some bdfs Making some help files that is what incrementally moves you towards the white screened fantasy land examples early on And then it's it's all I have to say on the subjects As I said This is me saying Hey font packages you should do stuff So I would really like to hear back from other people who are maintaining font packages As to what parts of this sound crazy and what parts of it Sound slightly less crazy So if you don't have a question right now There's lots of ways to contact me Any method you choose is fine by me But we've got about five minutes if anyone has comments or questions right now They're welcome Thanks Uh-oh All right. Yeah, I do know that you maintain some font packages I do maintain a font package. Um, I think your idea of putting the font packages in in well-defined directories is a great idea Um, we can just put that in debbing policy. It's really easy to do I don't think it'd be any controversy there The nice thing about policy is that it's it's a place where people look to see what they should do Policy is never a place that says what you must do Um having guidance for packages is always helpful packages are always looking for what should I be doing here Not what I must do Could we put the metadata this extra metadata just in the same directory as the fonts there is a well-defined location for each face Now for each family Yeah, could we just put the could we construct a file format to put the metadata Alongside the fonts in the same directory because we given that they're given that we have the font path information We could construct the file name for the metadata and go find it pretty easily with that work in theory. Yes, absolutely The the trick there is and this this has come up before the gtk folks ask this question. Yeah um For the general use case if you're the font publisher having to maintain those two fonts is not ideal But if you're the font publisher put it in the font file, right? So for us who are downstream There's not already an obvious Metadata sidecar format we could probably find one that's compatible somewhere and that would be interesting to do But let's see what else was I going to say about that Yeah, I think at this point that's that's probably the the big hurdle is that we have to determine what format to save that in So somebody with font expertise Might want to actually come up and specify a format And then build a library that would allow you to get at that right and yeah So somebody with experience the field of typography right a degree in that area that kind of person Yeah, well And you know the thing is that you you want to do that in conjunction with whatever's happening with Trying to track it in a local local database So is is font config a place to is is font config a database that should contain that additional metadata information? um So my impression from a brief conversation with font config folks is that's a little too much It's a little it's a little bit outside of font config's original Intent and so maybe that's not Maybe that's overkill for having font config do it, but I think like there was interested in having somewhere in the Not config where no other stuff you anticipate that metadata being used for font matching or font location Or is it just really for User just user some user interface discovery mechanism. Well, there's a lot of potential uses for it and The other the other big one other than just the user facing stuff is what do you do when you need to replace a missing font in a document Exactly And so some of that metadata could be used if not to automatically choose a replacement font to guide you Towards a good replacement font And and then there's potential uses that are in other fields like linguistics and translations I don't I'm not a translator, but I know that translators have a lot of tools their disposal and Good language support and knowing stylistic things can be important to them So I would say those are orthogonal use cases It's not all just showing the user stuff to to play around with So there may be some synergy with font config, but it might not be the same thing But you might have a tool that would run over the font config database and discover and and construct or discover this additional metadata Okay, yeah Parts of the the metadata you mentioned like you supported character sets supported languages This would be something that I think would be very interesting to have in font config because this is important if I select the font right and and In case I wasn't clear the the The git lab Table that I mentioned includes what font config currently does track and it does include some of that stuff I don't remember that if it's a language thing or not that the language terminating language support can be tricky And because people don't always agree on what support means So in this in the sense, I would strongly support to to add Even though it's an ad hoc decision to a specific definition for a sidecar for fonts Where we can save to meet that that of course we can if there is support from other libraries However, we can always change the sidecar definitions, whatever It sounds good. I was just given the flag that we all need to rush outside for the group photo So I guess we're out of time But thank you for your comments and we can keep talking During the group photo, maybe even no we're going All right. Thanks. Thank you very much