 Hello. I started playing around with type when I was quite young. I had multiple variations of my handwriting and when I was 12 I started writing with a two-story lower case A. But I also was playing around with computers and programming and at that time the pixels were big and chunky and physical objects, not something that had disappeared back in the background. So in the early 90s the first computer fonts I designed were raster fonts but they were not one-bit fonts with pure black and white. They were fonts that were manually anti-aliased. So I guess this is kind of the extreme version of hinting. You're just shuffling around the desired anti-aliased result. And I guess you can consider kind of what I'm going to talk about here that we in a sense have a very very strict unit system similar to what Frank was talking about because I'm going to use the pixel grid with a font where the lower case alphabet is three pixels high. And then you starting out with this constraint and trying to design something reasonable within it. And it has to do with K-Magic which Frank already showed. This is something that kicked off after last year's LGM and I got to learn about something called UFO. Unified font object which is an XML-based file format for rigging up and manipulating fonts and collaboration between different programs. And since I'm after two weeks of putting together the basic infrastructure for K-Magic so I could start experimenting with spacing of type. And I figured out that well it's quite a simple format. So if I sit down and in GIMP I draw ASCII and one one long image and then just back annotate with dots where you have a separation between the characters. Well this is how you used to create roster fonts normally back in the early 90s. Then I can write a small C program which reads in this file spits out a UFO file and I can create a TTF file. That seems fun. And I drew that image in an hour late at night and then I spent another hour making generate XML and then another couple of hours fixing mistakes I made in the XML. But I had something I could actually run. I'll get back to some technical details for what I actually did was I made an outline font with transparent opacity areas for the grayscale pixels. But what I've been thinking about since the early 90s is that well the reason that those pixels are brighter than the others is that they don't have the same ink coverage. And the reason for that is when you rasterize the shape or the curves and within the square you have a different shape that doesn't cover as much. So I started saying well just shaving like with lines is not enough. I say well if I have quarter circles I can do better. Well quarter circles is not that nice. If you go even further and say that well to make the O or a C we want to have three by three square puzzle pieces that we can fit together. And what I'm showing you right now is first iteration when I had these three by three size circle and then a couple more iterations and I add up saying well this is at least something I can puzzle within those constraints. But then all these corner cases that I don't like it. So I start adding special purpose puzzle pieces and glyphs. And the fun thing is because I had just kind of defined saying that this is the puzzle piece that goes here. There's another puzzle piece that goes there. I could just swap out the entire set of puzzle pieces. So on the top there is an exaggerated graphic version of how I fake the grayscale. A much higher resolution diagonal half toning or what you should call it grid ends up with three type rendering big chunk of grayscale pixels. But I could also vary the puzzle pieces and then just use circles of different dimension and rely on that my separation that I have tried to design it. So it should be as readable legible when the lower case is three pixels high. That should mean there should be enough information to discern which character is which. Also when the end of it such a very graphic modification of it. But having these different puzzle pieces means I could also have many other sets of puzzle pieces. So just swapping them out would get a different weight. And they also see some more experiments. I'm going through roughly in linear time how the development was of this thing. And here we reach a stage where I've been refining things quite a bit. And this is the first stage in development this one where I had two-story lowercase A. And I experimented with alternatives. Some of them are bad. And I mentioned already it's with special case puzzle pieces. The DQB and P on the top. I've created some puzzle pieces for joining up the curve of the cusp with the vertical stem. But then I realize, well, I'm a little bit too strict in myself with the constraints here. I'm actually, well, let's step back and redesign the constraints because I'm baking both the constraints and the design within the constraints. So if the constraints are too bad, well, let's just lift some of them. So what I did in the difference between those two is that I want to be able to just stack the tiles on top of each other. Then I don't need a special case tile for where the circle curve joins up. It's just another thing that sits on top. And this is how it ended up looking. Still, this, when you render it with the lowercase three pixels high, we have roughly the same font as we started off with. And this is just one out of numerous different representations that could end up with the same reservation at time, a tiny little size. It's also fun because since it quantizes correctly there, I know that all bigger sizes, it should end up having the curves and positions, which makes you able to at least distinguish things from each other. Then I started throwing in even more little things to see how things would look. But at this stage, I also started re-evaluating some other things. But to just get back to the roots of it, and showing a screenshot of using the fake big chunky pixels thing, this is the MCGA resolution, which I was quite happy and familiar with in the early 90s. And you can actually fit a regular size terminal inside three 20 by 200. And if you know what you're expecting to read, but whether you can do the same thing with putting something on a mobile phone, and these slightly bigger fonts, and it's crisp. Okay, it's not really, really nice. But this was where I actually wanted to go and I meant really, really overboard. How was this sausage made? I ended up inventing my own version of Ascii art. So instead of just reading this image file, I spat out the contents with the different gray levels, we asked different characters. So on the left hand side, here we see how why and said were defined. And here's a palette where I gradually organically developed like a new key binding, so I knew there are hard things to have like a system, how things should work. And here's a preview. Where I run with the font in my terminal, where I just show the shape instead of the character. So I got the somewhat instant preview. And making those components is painful. I just manually edited text file with that's your curves and control points. And took me probably about 10, 15 seconds to see how things would end up. And for a large set of different variants of the family, I have text file describing and which source files to use for reading the characters and options for can magic and spacing it and a bunch of overrides. This is using not the table driven method in magic, but the more machine vision driven one that analyzes also the character shapes. And on the top is also command line options for TTF auto hint to auto hint the resulting fonts. But I was not happy. And actually, I wasn't quite happy with the font side made nor with the process. So how much time have we got left? Seven minutes. Seven minutes. I want this microphone here to work. It does. It doesn't explain it. Hello? So this process of doing things was quite tedious. And changing the component was troublesome. But working at 10, 20, 30 seconds, changing the component was troublesome. But working a text editor, I'm quite efficient. So I was wondering for myself, would it be better if I could stitch together my font from these puzzle pieces in a more rapid manner and actually have exactly what I want to have on screen quite quickly. And create a system where I could just plug things together in such a way. And other things which immediately become fun when you start playing it that way is to live see how tweaking the set of components to show will appear. But I did actually go even further on that as well. But let's see. So instead of the ASCII art version, I was thinking how would I prefer to throw things around if I'm going to explore how I'm going to do a type design. So here we have ASCII lower case going to the right. And this works like a spreadsheet. So the characters down there with diacritics are kind of cloned cells of where the tiles are. And I also encode different versions of the design. So this is for like a condensed version where I have overrides for some of the elements. And yeah, this is definitely working progress. And that includes the tool. And as well as the font, I haven't properly tried to repuzzle, for instance, the X. But let's touch up this P which also is wrong in jumps up there. And have a live preview of how that update affects rendering there. Or mark the P and saying that, well, I actually want to adjust the side bearings of it. Okay, then you see that. Whoops, there I include parts of the O in the P. But it started to be quite fun to play with this. And the distraction just got deeper. And so if we play then with... But what we're seeing now is playing around with vector shapes for these components. I think that I actually started thinking about and I think I discussed it with some people, even at the end of Interactivos in Madrid last year, that I actually want to paint directly on the characters. I don't like Bessier curves for rapid prototyping. It has the same problem as my former workflow had where I was constructing these fonts from these text files, these source files. And they weigh around that. So I'm going to use my touch pad and this is going to be ugly, but I haven't done this in a nice way anyways. If I enter this command line thing, type painter1. And then I start drawing on some of the characters. I'm not allowed to draw there because there's tiles overlapping each other. Then I can start trying to figure out what is necessary to refine and easily be able to experiment with how different positionings of such things would affect things. And one of the things that I wanted to do earlier when I was designing different components as of different weights, I really wanted to have the same horizontal metrics for the different weights. But I had only been growing my stroke width inwards in the cusps. And I had to define the topology in this very low resolution. But if it should be possible, also based on the experience with Hoke Magic when it tries to dynamically space and get different weight input in for the machine vision thing, I basically knew that it's not enough just to grow to the inside of the characters. You need to balance it somehow on both sides of the stroke. So here I spent a little bit of time, but I don't have the proper drawing tool there yet. I can just add and remove dots, but it actually somehow looks like the imperfections of lead type, so I didn't mind too much. But this is roughly the stage. This thing is at the moment. It is actually right now running on my local computer, but it is actually a collaborative online font editor. And if you throw slash add it after the web page of 0x0, the name of the font family is the start of video memory of a VGA card, which is originally we were pushing pixels and trying to put things together in the beginning of the 90s. But that's where I stopped.