 Hi everyone, I'm Adrien Adedard. It's nice to be here in London. So I come from a scientific background and it's mainly the use of latex that prompted me to go into tag design two years ago. But the tools will always be a problem for me. Two weeks after entering tag design, I joined the FondForge development team. And over the course of 2014, we did a lot of work to fix many stability issues and stuff. And there were many basic things that were crashing at the time. So yeah, there was a lot of work to bring stability and to bring support for the FondForge format. But for me, there was always a crash behind the crash. And there was a huge C package that was almost impossible to maintain. A non-standard and rather inconvenient UI. So I decided to work on a replacement. So while I saw quite a few people complaining about FondForge, it looked like not many people were actually considering working on a replacement from ground up. With the out of respect for the 600 gigabyte of FondForge, which implements everything on top of C, I don't know. But originally I stayed there in 2012 after over 12 years of working on it almost every day. And it always was rather hard to keep me doing the software. So here's me explaining one of the issues with FondForge. Because even in the professional tech design community, it was often the case that people told me, oh, but you don't have a voice there, you don't have an administrator with FondForge. So yeah, I cannot actually explain what were the issues I found both as a user and developer of FondForge. So as soon as September 2014 I started working on a replacement. This pull request was the first step in my journey, working with Qt and PyQt to be accurate. Here's the actual content of that PR. It's basically adding what's called a pen. And a pen is a way to transfer, like, control data between different representations. And here what it's doing is taking the data from the back end and drawing it into the Qt Paint The Bath object, which is the Qt object for basically a bath. So once you've got that, you can draw it on screen. So like every key from QtFond goes through that pen first before being drawn on screen. But of course you can do much more with the pen protocol because it's a way to stream your data and you can also do modifications to the control. So for those who were at my workshop, we did, we saw the Remove of Curve pen, which simply calls the line to function from the curve function. But you can do many elaborate things with pen. So here it was my first running result that I then sent to Dave Crosslands of Google Fonts. They've been trying to talk me into making something with web technologies or using the Python interface of PhoneForge with PyQt to kind of extend instead of rebuilding something. So both of these were a no-go for me, especially in the PhoneForge solution because it would still not address most of the problems. We still have PhoneForge and the Python interface of PhoneForge, which also is subject to birth sometimes. So it's in April 2015 that I started working full-time on what would become TrueFond. And it released on October of that year. So at the time, back in 2014, I looked into UFO file format, which is the basis of the RoboFond editor. So here you have a glyph file. So it's one of the properties of UFO that it's human, readable and editable. Compared to binary file format, when it's correct, you can actually see the data and edit it. UFO is also meant as a kind of interchange format between various applications. So there is a standardization of the most common elements like curling, cliff data, of course, layers and so on. And then each application can put its own data into either the PhoneForge API or you can also put your app files into the data folder. And first up, you have also lived into each glyph file. So you can store, let's say, hint data. So UFO had gradually spun out from PhoneFed in its scripting APIs. That was the RoboFed library. It's worth noting that the next gen PhoneFed editors, those who lived in 2012 for RoboFond and 2011 for Glyphs, were both made by type designers and developers. So at first, UFO version one was a sort of format for use and export from into PhoneFed in scripting APIs. And it was mirroring the capabilities of PhoneFed scripting. But then it turned into its PhoneFed. And with the release of RoboFond in 2010, which was entirely written in Python, the gap between scripting and the main application was becoming almost seamless. The UFO specification was primarily made by Taldemey, who also released unbearable tools that are at the basis of RoboFond and also his own software. So there's the idea of sharing the groundwork that's common to all PhoneFed applications. So you can focus on actually making your app instead of doing with making a file format, making a backend, making a notification system. So PevCon, you can see here, provides all that. It's a backend, so it gives you all the font and Glyph objects so you can actually have your data in code. It also gives you a notification system to refresh widgets when the data is changing. It gives you a representation factory system that allows you to cache all representation of your objects because otherwise it takes a lot of time to draw on screen. So I kind of wondered, why didn't anyone try to make something out of this? I mean, it's all liberal here. So here is Taldemey's website. And so the larger goal of UFO was to make maintenance easy by splitting the layers of functionality into individual packages which were each maintained by different people. So because these guys were not developers by trade, they were designers who at some point felt the need to build their own tools. It's for quite another reason that I myself went to tech design, I guess. So we've got the history, so let's talk about two fun things. So first, the download numbers. So here as you can see OS 10 is still like most of the downloads. So B030 was making these, these were the numbers from the other platforms. But let's say when someone's complaining about this OS 10 widget looking weird in OS 10, I can't really ignore it. So yeah, keep in mind those numbers are just binary downloads. So it's hard to track all precise numbers. So here we have the object model of the application. So between the UFO and the user, we first have a library called UFO that reads and writes UFO and validates the data. Then you have DEF CON which provides you all the objects and various facilities like I said before. And then you have the DEF CON QT package which provides all the base widgets to use in DEF CON and QT applications, regardless of the application. So it's a refactoring that idea out of the TruFont package. So you have all the widgets and things you may use for your app. So it's always this idea of shared layers of functionality. And only the last block is specific to the app. Also, we have quite a few supporting packages. For instance, Boolean Operations package was made by the Robofont author. And if all opens was in it because Boolean Operations is not a future that's specific to an application. So it can be shared between people and the maintenance can be shared as well. Likewise, we have quite a few packages. For instance, UFO to STN phone tools are maintained by Google. Some other packages are maintained by television. So there are actually quite a few parts of TruFont that I don't need to maintain myself so to speak. Though I still needed to put a few packages to get them to work. And Phone Tools is a library that's useful for dumping binary data into text. And it also has a lot of useful little tools and things that you will use in all your font applications. So it's kind of here all the time if you're doing a font application. So this is what makes TruFont a lean application. We implement the list. So we try to share blocks of functionality with other applications. I don't try to make fancy UI or anything. We just use the native UI of the widget kit. Then we implement the list. We just provide a set of core functionality that's going to be used by all the users. And then we allow customization, that's the third point. So everyone can write their own plugins which will then be maintained by those people and not by the TruFont people. So it's always this idea of modularity and sharing the functionality. Also, I may say the initial goal of TruFont is mainly to display and edit all the parts of the UFO. And much more than that, which will lead to extensions. Especially STUP, which is a little echo main deck, which is processing data according to an arbitrary algorithm. Let's say to set up your metrics automatically or stuff. This is left to extensions. It doesn't blow in your head if you're not willing to use it. So here we have the object model of the RoboFab library, which is actually a precursor to Defconn. Because RoboFab is like a high-level library and Defconn was made later as a lower-level library that could be used as the basis for TruFont software. So Defconn is a little different than that. We don't have any points or special segment objects. The segments are just list of points. And then we have, of course, a layer object coming out from the font. So you can actually fetch from different layers. But basically that's what gives you access to all the objects in scripting. For instance, you can iterate over the font to have all your glyphs looped in. And then you can do automated treatments of the data in your font. So demo time. So here, for instance, I've got the extension I call... Sorry, we started it up. In the meantime, if someone asks questions, you mentioned that you want to give a lot of functionality and extensions. So that sort of implies that TruFont as an editor in itself will be rather compact and lean, as Robo's literally mentioned. But for end users, of course, some features are quite nice to have, like auto-curing, stuff like that. You get most of the coding right to begin with, so you can fine tune it later on. And I'm aware this is more like a future thing, but are you considering basically shipping some of the well-tested scripts in the base package of TruFont at some point, even after still extensions, right? But just shipping them as an convenience? Yes, so there might be a sort of batteries included approach. Maybe not for auto-curing, because many people don't use that. Because you don't exactly control all the outputs and stuff. But yeah, basically, if there are some very cool extensions, which are not required for editing the stuff, but are very much useful, they may be included in the... If all by the way, distribution of TruFont. Thank you. So, if it works, I'll show you. So it's actually stuff I'm presenting at the workshop, neighbors. So the neighbors extension, we put the cliff names here, and they're drawn on the size of the cliff in the view. So how that works is... The cliff view widget here, it sends notification when it draws. And so what we're doing with this widget here is we're subscribing to this notification. And when we get that, we also get the painter object, which is the QT object to draw on screen. And when we do that, when we come here, we can draw our own content, custom content on the widget. So that's how it works. And basically, in QT, you have a main object that's called QApplication. And it's the parent of all objects which you can access all the time. And so we store an event dispatcher into that object. And so you can subscribe or remove your subscription just by taking this application object and calling the appropriate function. Also, there is a... The other way you may access the cliff view is by writing a tool. You can write custom tools, and you have an installed tool function. And for instance, here this extension is suppressing the selection tool, the one that holds a rectangle. Except it's drawing a path and selecting the points that are in the path. So actually here we can subclass the selection tool. And for the moving points functionality, we just let the base tool do its thing. And we only override the rectangle selection thing. So those are the two ways you may access the cliff view. And otherwise, you get many notifications from the font. Like when it's saved, when a font is opened. And you may do things like... I'm sure it would. So here for instance, we're listing all the open fonts. And if I open another font, just a few seconds... So you can see here in the panel on the list because we're subscribing to the font-opened notification. So when the font is open, we add it to the list. So what this extension is doing is it's drawing the overall weight of the font in the background. So you can compare between fonts. You can have the other font on the background. So with these extension stuff, you can do many custom things that may be influential to your workflow. Because some people might be working with the neighbors for the background and some people may not. And so you can install functionality depending on what you're doing. So it avoids applications where you have hundreds of buttons and lots of features that you may not need at all. So yeah, here we go. Thanks.