 So, good morning everybody, welcome to the Font Packaging Team BOF, Christian Perrier, and enjoy it. Enjoy. Well, actually, originally I wanted this to be a talk, bits from the Font Packaging Team. I turned it to a BOF, mostly because I didn't have enough material for a talk, to my opinion, and I felt like quite uncomfortable to make a talk without having all the material and knowledge and whatever. So, I decided to turn it more into a Font BOF discussion, particularly with the Font Team members. Some of them are around, some of them are not. So, I prepared a few slides as an introduction to Font Packaging and the work we are doing in the team, talking about the team, what are our challenges. And I expect a small discussion after, hopefully it happens, about what's happening. I did set up, just in case, a Gobi page, which I will give the details later on. So, okay, move. So, well, okay, this is traditional in my talks, so you, many some people expect that, my son may expect that, so he will see my SpongeBob in my talk. Here we go. This is not a talk, but even in a BOF. If you want to play with a Gobi, I did set up a session with Gobi, with the usual recommendation for using Gobi. Install Gobi-05, launch it. Open Gobi.debian.net, and you can open the page named, depthconfig11 slash DC11 Fonts BOF. This is, this one's meant to be the Gobi, and this is it. So, in case after when we come to discussion, in case there are ideas exchanged, I would appreciate if someone just take notes, because I can do both things at the same time. So, what about font team? Well, the team, it's quite a big team. It was founded in 2007, more or less before depthcon7 in Edinburgh. Nicolas Spalinger, and mostly myself, we talked about font. The fonts before they were spread all around the archive, maintained by many people without real connection, without knowledge sharing, etc. So, we decided, along with Nicolas, has a great knowledge about fonts, about font licenses. Knows many people around the world who are doing font design, a free font design. So, we founded this PKG-Fonts team, which is hosted on Alliot, since four years. The goal of the team is obviously to maintain font packages and related tools. There are 44 members. I come to this morning, I was surprised, so many members. Indeed, about 11 are really active. May you around those people who are members of the font team, raise your hand, please. Thank you. We have DKG over there. We have Hideki Yamane over there. Arne Goyde here. And Kanru Chen here. And myself, I think. Whoops, and Daniel Glace. Oh, sorry, I wasn't seeing your hands, Daniel. And here's a new team member coming. Welcome, Paul Weiss. And Carolina is not a team member. So, yeah, about 11 people really active, some maintaining fonts, some are maintaining font-related tools. This is about the team. What I didn't put on the slides, we mostly work as most team on the mailing list, and this list is set as maintainer for whatever packages we maintain or team maintain. I did a brief survey about font packages in the archive. We have 129 source packages maintained by the team. I was very surprised by this number. I didn't expect we are maintaining so many fonts. I don't know about you team members who are here, but I was expecting like 50 or 60, 129. We also maintain some utility packages such as font forge and related tools. Mostly font forge is one of the most important because it's used to compile several fonts. I counted all over the archive, which is a little bit more difficult because what is a font package? Theoretically, a font package is in section fonts. So that's easy to count, but sometimes this is not a font package. This is a font utility package. So I counted 210 source packages in section font. Out of these, probably 156 are named ttf-something or otf-something and fonts-something. Those are very, very likely to be font packages and always source packages. So more or less, the font packaging team is maintaining most of the fonts we have in Debian. I think we maintain probably the most used of them. So in short, these, the characteristic I would say of these font packages, they are very, very well hidden. We have few bug reports because there are no problem with fonts. Most developers use them. But he has fonts on his or her laptop, but we don't really care about them. We don't even care sometimes about the default font. I was asked during breakfast, but what is the default font in Debian? And the answer I gave as a long-standing packaging font team member is I don't know. And this is, I don't know. Really, this is something quite hidden for many people. But this is something very important for many other people, particularly those people whose language is not Latin based. This is what brought me to the font management because internationalization, which is my main activity in Debian, is closely related to fonts. If we have translation to Uigur, we need a font to display Uigur. Otherwise, it's good. We have a translation and we can't use it. So that was, but this is something quite hidden, you know. And it explains also this thing that why the maintenance team is very, very international. We have many people concerned by Asian fonts, mostly. Because the need here is higher to display Japanese. I would take Japanese as example. You need high quality font, well-designed font for readability. This is probably the same for Chinese. Arnie can confirm, I guess. So this is something really, really more, really important. And we have one more font team member. Please welcome Tep. I will never try to pronounce Tep's full name. Sorry for that. Tep is one of our developers from Thailand. And maintains the Thai fonts, if I remember well. Basically our work in progress. This is meant to be introduction to a more wider discussion. I said this is a buff. This is not a talk. So this will become a buff. We are working on removing this old thing named Deforma, Debian font management. This is something now we can define as old, useless, full of bug and not maintained. So very, very good candidate for removal. The problem is that many packages were depending on Deforma. So this is quite a hard work to do. And work mostly led by Paul Weiss. We did set up some pages, some tracking, some bug tracking. And we did a lot of work during that camp. I planned to put how many packages are left. Actually I was waiting for some input by Paul. We'll have the answer soon. Live update. Live update, yes, definitely. By the way, if someone could monitor maybe the ISC channel round room. I don't know if you know about this one. If someone can relay questions from here. Okay, thank you, Andrew. Yeah, I see there are some contributions. We are also working on renaming font packages. It sounds silly. Why do we want to rename font packages? This is mostly a consistency with other distribution. This is one of the reasons. Also because most font packages are named TTF-something, which means true type file. But some of them are providing open type fonts. So that sounds a little bit silly. We had a long discussion in the team about how to name fonts. And now we have more or less converged about how to name font. This is part of the font packaging policy we're working on. And the work is going on to rename the fonts packages. And 39 are done. I counted this morning. We have 39 font dash something. Most of the work has been done by Hideki Yamane. We've converted most of his fonts about one or two every day during DevConf, I think. Yes, that was a hard work. More complicated than it seems. Renaming a source package is quite not complicated, but you have to be very careful about the transition, of course. We are working or not enough working on the font packaging policy. This is a work that was initiated, discussed by Nicolas and myself. And then Rogerio Brito took it over. He's not attending DevConf. There is a document I can show you if I don't mess up with my stuff. We have a kind of draft document. I will not read that document, of course. It is meant to explain how a font package should be named. What guidelines we can give for stuff like Debian rules or things like that, et cetera. Mostly one of the points you can see this point, see the work that Fedora has already done. Other distributions also worked on such standardization of font packages. We need to exchange with them. It's not completed status at this moment. There has been some work tracking or how to call that about embedded fonts in PDF documents. Am I right to talk? Mostly DKG, you did some thoughts. That would make a more interactive session if you can pass the mic. There is a mic somewhere. Who has the mic? That becomes a buff and not a talk. I haven't actually done a lot of work with the embedded fonts, but I understand the problem and I can try to explain it. The PDF can contain a subset of the fonts that are in use. One concern is that we may be shipping PDFs from other packages that embed glyphs from fonts that are not themselves free. That can be a problem either because we're violating the license of that font because it may not even be redistributable or it may be a problem because it simply doesn't meet the DFSG guidelines. You can run PDF fonts on any PDF that you find and have a look at them. You can have someone do that in an archive-wide fashion to at least try to get a list of what's available. Unfortunately, when you run PDF fonts, the things that are embedded, they have a sort of mangled name. There's no guarantee that the name that is embedded in the font is actually the exact name. So there's some fuzzy matching that would need to be done to make sure we know what's going on with that. Are there any PDF files or are there more formats that may embed fonts? I only know about PDF files, but I'm not going to make any claims about any other formats. PostScript? Maybe PostScript? SVG? Yeah, maybe, I don't know. So yeah, doing that, it opens a big can of worms, you know? It can become quite a large work, but that's probably part of the stuff. This is one of the tricky things, I think, with fonts. The tracking, whether something is free, according to DFSG, or not free. Paul? So an update on the Defoamer numbers. There's 18 source packages depending on Defoamer. 18? Yeah, and I think four Defoamer backends, so four packages that need to be converted to use font config for finding out about fonts instead of using Defoamer. Yeah, I didn't go into details about Defoamer, et cetera. Basically, one of the reasons I didn't want to make a talk is because there are some things I don't really know about all this stuff. Defoamer became useless because all the magic that it was doing is now included in font config. So installing a font to make it work with the desktop environments basically means now you just throw up the TTF or OTF file. I'm mostly talking about vector fonts, more than bitmap ones. You just throw up the TTF or OTF in usr-share-throughtype, I think, and that's it. All the magic is going and you have the font in normal, KDE or whatever. That's basically the point. So Defoamer becomes useless. That was the first point, useless. Non-maintained, definitely. You can look at bugs.dbn.org-defoamer. You will be scared. And the code is horrible according to everybody who has looked into it. No offense intended for the original author, but nobody can maintain it except the original author. So Embedded Fonts is one of the topics, and another topic is all this stuff about tracking non-free fonts, license variations, and duplicate fonts. Several packages, often games, are providing fonts with the binary package, and sometimes these are duplicates of fonts that are packaged into font packages. So this is mostly one of the points. And freeness when it comes at fonts is very sensitive. You can find fonts all over the web. Some are called free, but you won't know what. Free how? What license? Sometimes they are just a web page. Okay, this font is free. That's all. And some of them might be in some packages. There have been some issues with the Indic fonts, the fonts for the languages of India. Some of them have a status that's not completely clear. So this is also sometimes a sensitive topic. And packaging fonts, most of the time, the most difficult work when one wants to start packaging a font is to check about the license. I don't know much about font licenses, so I don't want to go into details because if I'm asked about open font license and why it differs from GPL or whatever, if someone knows in the audience, please speak because I am not able to explain these details. Please, Andrew. The main issue, as I understand it with font licensing, is that if your font is used in a document, there are situations where it can be embedded differently to... The GPL has got its included codes thing, but you don't want the font license to extend to the documents that use that font. So that's the main reasoning behind the differences in the fonts. The free fonts are freer than that generally. Paul Sladen speaking at the back. In a nutshell, if you use a font in a PDF file, and it's GPL, it makes the PDF file also GPL. And unfortunately, people's theses, which are normally copyrighted, their university obviously can't necessarily be GPL, and this basically means that a font becomes unusable. So virtually every single font license, open font, the UFL attempt and various other things, GPL plus font exception, they all have an additional exception, which is additionally, when this font is used in an embedded document, the font license does not apply to the document. Yeah, that's one of the points. Yeah, this is a point you find in the OFL. Yeah, that's something. So this is quite tricky stuff, and sometimes it brings some discussions and stuff like that. Well, I think I might have yet one slide. Yeah, that was a few nice places to look at. There has been some nice work. I may be failing at promoting it more. Particularly, I went over the last days over the Debian font review. This is something we are hosting on our website. I can show this. This one, this is our VCS. Of course, I lost that one. So I need to take it again. Hopefully, nope. Let's type it. This is a buff. No, not this one. It's about spam review. Nothing to do. pkgfonts-fonts.aliot.debian.org. Yeah, is it coming? Oh, yeah. So this is an automated tool that goes over the Debian archive. I don't really know about the details. I'm not even sure about who wrote this at first. Maybe Nicholas or you? You were the culprit for that. Maybe Mike. So originally, the script was written by Miriam Ruiz. Oh, yeah. And then Nicholas took it over and I've worked on that a little bit as well. Okay. So first by Miriam Ruiz, then Nicholas Palinger and then Paul. So you can take, well, whatever font. Is this one you want to see? A nice one. ttf-dkgnriding. Where is it? ttf-dkgnriding. This one. And you get more details when clicking on the font. And, well, several font about family and all this stuff. And yeah, this is quite elaborated stuff too. It's interesting to get a rough idea of what's covered by the font, et cetera, et cetera. I wanted to show the... I don't know. My favorite one is... Oh, isn't it here? Oh, it's fonts. Now it's named fonts, because we have many ttf-something, but now we have fonts-something. Fonts, kitsch, Uigur. And yeah. I even have some missing stuff. This is meant to represent the Uigur language. And many, many... There are many fonts in this package. So you can easily check the differences between the fonts, mostly with the... I don't know about the algorithm, how it chooses which glyph to show, because, for instance, for Uigur, the important part is to show the Uigur glyphs, not the latent ones. People who want that font basically wanted to display Uigur. Oh, Ebru, if I want to take another example. Thank you, Leo. And it's probably right-to-left language, I guess. Uigur. Yeah, so that was a few nice places to look at. There is also another one. Yeah, please. So the images are generated using fonts for issues that are commonly found in fonts, like glyphs that intersect with themselves and stuff like that. And we have also a font, well, by... Oh, sorry for that, Kano. Please. So I think it's possible to provide web fonts. Yeah, we have so many fonts in the archive, but these days, web fonts are... Yeah, on the web page, you can use the system font. Well, it has been discussed, I think, the KGB. I don't know that there is an initiative within Debian at the moment to provide our own web-based fonts service, but now that you bring it up, I think that would be actually a really great thing because one of the things that web-based fonts can be used for is a type of surveillance and tracking across websites. And if we were to run a service that was guaranteed to not track, then we could provide all free fonts for all web pages that people could potentially cache, which would allow automatic font updates for any web page on the internet-wide. So I think that would actually be a really neat service for Debian to try to provide, even for people who don't use Debian, if their browsers can support the various forms of web-based fonts. Yeah. I can't do it, but it would be great if somebody wanted to do it. So question opened. I noted that in the Gobi, but at the moment, there is no effort. Peter, please. One thing that occurred to me, I'm not sure if it's actually possible to do at the moment, but with Ubuntu and browser plugins or multimedia plugins, when the browser tries to visit a page needing a plugin, it will pop up a window asking if you want to install the packages that support the memotype that's missing in the browser, similar with video codecs and stuff like that. Would it be possible and is there anything present in the moment in the TrueTight library, for example, that when the font is missing, will it pop up something and install whatever is missing? Can we implement it if it isn't? Before Paul answers, at the moment, we obviously have nothing like this. It's obvious for anybody, but... So this sort of thing is provided by a program that Fedora has been working on called PackageKit. They publish font metadata in their repository metadata, and then the PackageKit tool has a GTK plugin thing that looks at the fonts that a program is using and then pops up if there are some other fonts needed that aren't installed. In Debian, we have PackageKit, but we don't yet have the metadata published in an appropriate way for PackageKit to use. We now have the version of font config that Fedora added their patches to, so we could potentially work on that. I think all the bits are there, but we're not using them yet. These are probably among those cool things to do with fonts and get further than we are doing now, which is mostly maintaining font packages. Andrew, please. Just a comment from IRC, that there's a plan to add SDF scripts to Debian Helper, like SFD scripts, to Debian Helper, like DH AutoBuild. Okay. Can someone please go to the Gobi and note that? It would seem to be a statement on IRC, but from X by TMX. Who's that? Can someone do a slash who is on that? Tony Palmer. Or introduce him or herself, maybe. I don't know. Okay. Well, if someone has a Gobi opened and take notes, it would be nice because I can do in the same time. Yeah. You see, there are ideas floating around and my point, my own point would be to go further than just font packaging, but for that it needs people who have quite some skills in fonts much further than mine because my skills in fonts is basically knowing what a font is, that I can open it with font forge. I know about packaging fonts but that's nearly it. So it's a little bit small for leading some efforts and drawing things. Leo, please. A more general question. I maintain a few fonts for Hebrew and Arabic and I was thinking to move it to the group repository. My question is, is everyone in the group just maintain his own fonts a team work which everyone can maintain everyone's font? To find out if I just do the same work on another group because I do it in Hebrew, Arabic or would I actually get help from others? Well, other team members you give your opinion on this but what's happened up to now is we do put the team in the maintainer field in Debian Control so the bug reports go to the PKG fonts development list which is open for posting and we put in uploaders those people who are more responsible for the font. So there is a kind of lose priority of those people mentioned here but that's nearly it. So the agreement in the team is that yes anybody in the team can maintain another font but for instance I will probably leave Hideki Yamane maintain the fonts is maintaining most of the time is working stuff on that and I will not interfere with this work except if we well and if there is something wide or if has no time for that or something like this. So it's very open and we can probably cope with everybody's needs. If you prefer being really responsible for this font it can be still maintained in the team repository and benefit from the team discussion and that's all. The credit or who is the maintainer who is maintainer who is actually about team work and benefits from moving into the team instead of doing it by myself on the side. For the maintainer I'm not really sure there is a big benefit honestly speaking one of the benefits is that we can know that at least someone will feel responsible for the font if something has to be done. Take as example the deformer removal it was very easy for those who were in the team repository because we just made the changes and re-uploaded the package and that's it. For other fonts we have to propose an NMU etc etc to send a patch etc so that makes things more complicated. The benefit is more overall than the maintainer herself. Thank you. About the deformer removal anybody knows about the status of the latex and ghost script? You mean about what we are trying to achieve and make I'm not sure I did really get the question. The deformer was used to configure these font packages in the latex and ghost script but since now the ghost script can use the font config but we still need some files in the ETC CRD map. Maybe Paula has a better answer than me. So for text I don't think it ever supported deformer at all. Ghost script had had better support for font searching under deformer than it does now. That needs to change maybe someone would like to write a script to generate the files but ghost script itself needs help. Where's Jonas he's not here. So Jonas is maintaining ghost script along with the printing team now and he's quite overloaded so if people want to help maintain ghost script that'll be good and it does need better support for font config currently it doesn't have that great support. But other distributions like gen 2 and stuff I think they have patches that we could use to make that better. I don't know if that answers your question but I think Paula has a better answer than me you know. So yeah basically the point of the team really is to bring the common knowledge in Debian to the team and share that knowledge because of these hidden nice things that are going around it also helps identifying un-maintained stuff. So yeah we have five minutes left. Just in the spirit of throwing out interesting things that I think the font team could do in addition I mean along the lines of the web fonts or the PDF looking for embedded fonts I know that Inkscape in the latest version now has SVG font capabilities but it's very clear to me at least how to use them to generate a font. And I really like the Inkscape interface in general and I wonder if anybody is interested it would be I think a useful thing to do to look at how Inkscape SVG fonts work and maybe to feedback suggestions upstream to Inkscape about how they could improve that interface and maybe write up a tutorial about how to use it. Inkscape SVG font support in a Google Summer of Code project that's on at the moment so I think it's probably a moving target right now. Paul you have something to add? No, okay. Anybody has other comments or whatever topic we can fit in four minutes or something? Just to clarify that point from ISE earlier this one was asking whether there was a plan to add SFD scripts to Deb Helper. To add SFD scripts? He says that when a font upstream with SFD is used to build a Debian package the maintainer must add a script to make a TTF or other font type. SFD is the type of forge format. To provide the kind of standard script to build a font from an SFD file. I think that's the domain of upstream they should be providing a make file which DH will automatically use. Yeah there's not much point in Debian having a specific way to build fonts. We should just use the upstream way. Paul. It does bring up the whole question about to what extent fonts actually want rebuilding from source if the source is available. I'm going to appreciate I have bias here, I open hands I work for Canonical at the moment and we make a font called the Ubuntu font family which is going to get pillar for being non-free and etc and made by Canonical and made by non-free tools and stuff we looked around for a long time trying to find a font house which would make a professional font using only Inkscape and font forge and there weren't at the time any realistic possibilities of large enough companies that could do kind of five scripts and 13 weights using the free fonts free tools so we have theoretically a free and open font but built with Windows tools which of course in Debian we can't rebuild from source now because we've got source code that's the worst situation if we just have the TTFs because if you just got the TTFs the TTFs in many cases are considered source code but because we have got source code but we can't rebuild from it so it's definitely not something we're going to main at the moment because we can't rebuild it from source but it does open up that question about to what extent we do want to rebuild if there is or if there isn't the option to is it free should we actually be more strict or less strict or yeah this is kind of a discussion we had already in the list and some of fonts we rebuild from the source some we don't it's not at all standardized definitely yeah maybe one last comment probably and we will probably close up so I think that those fonts should that we can't rebuild from source belong and contrib and I understand that canonical tried to find a font house that would use free tools and we're unable to and I wonder if we can use this as a moment to say okay well can we can can we transition this font from a non free toolchain to a free toolchain so that we can put it in free in main I would like to see it in main and if we could help the font house that created it use free you know have a have a free source to build it from I think that would be good so if we can use our leverage to push towards a better more usable free font toolchain I think that's a positive result that's what I would like to keep as a final comment and one of the goal we can have is to promote the use of free software for creating building etc font and this is one of the reasons personally speaking that I prefer rebuilding from source with font forge it also helps in finding nasty bugs in font forge itself which is I think a good thing well I have to conclude this both I am amazingly surprised how alive it was I was very scared about having a non-live both I hope I didn't turn this too much into a talk and I would like to thank you everybody for making this a live both thank you very much