Jean: Hi, my name is Jean. I’m a designer and developer. I mainly work with web technology. Web development has been at the center of my work for the last few years. But since I started with graphic design, I have always worked with typography. I’ve designed my own fonts, font systems, and type design tools.

Each is a language in itself. One is visual, the other machine-readable. This makes working with each very different. While designing, you can usually see your changes immediately. While coding, you first imagine and describe what you want to change. Then, you check whether it works as you intended or whether there is something you want or have to change.

When these two disciplines are combined in a project, they influence each other. The design has an impact on the code, and vice versa; the code should have an impact on the design. If you only work on the design first, you will end up with problems when you translate it into code. The design should be based on certain functionalities and possibilities of the code. However, it is not a good idea to build the design solely around a particularly simple piece of code. Each project requires a certain balance. Both disciplines should be considered simultaneously and with the other in mind. This can lead to good solutions and save time in the end. In such a context it is very helpful to understand both disciplines.

This is often the case with client projects. For example, when you get into more complex forms, it can sometimes make sense to split them into several smaller parts. This simplifies the code and also improves usability by not having one big monolithic form. 

You may have seen this on platforms like Are.na or GitHub. When you create a new project or group there, you first have a simple form for the initial creation (name, description), and then you get to the project or group page where you can manage everything—like adding and managing contributors. From a design point of view, it might be desirable to have everything in one form where you do all the management. However, breaking it up into many smaller ones makes it less complex, and you have dedicated code for smaller tasks that are easier to maintain. Also, projects like my Open Type Face project take you step-by-step through the process of designing fonts rather than having a Control Centre-style screen where everything is covered. 

Coding is not rocket science. Everyone I have had the chance to work with has done a great job in a short time. The biggest hurdle at the beginning is yourself. The way you work is completely different from what you are used to as a designer. Another thing I have noticed is that thinking gets very complex very quickly. Simple things are often overlooked in programming because there is much to explore. However, the possibilities of simple things are usually far from exhausted. The goal should not be to program something amazingly complex but to develop impressive designs with simple means!

I would say it makes sense to start with Python or JavaScript. Python is an easy language to learn and does not have a very difficult syntax. But as a designer, I would prefer JavaScript because it goes hand in hand with HTML and CSS, and most of the time, you have a visual output. In my opinion, this is very rewarding for designers.

The aim of my work was to see how AI could be integrated into font design tools. In particular, I wanted to see how well it could be used to generate vector paths. We all know models like DALL·E, Midjourney, and Stable Diffusion. Unfortunately, there are very few models that deal with vector generation. I still see a lot of potential there. I was able to use Large Language Models to generate some good paths. Sooner or later, such models will be integrated into font design tools, and repetitive processes in type design could benefit greatly from them.

It is difficult for an AI to generate good letter paths because few models can handle vector data. Sketch RNN, a model that works with vectors, can only generate lines. This means a curve is represented by many lines. With this I still was able to generate some interesting letters, but these serve more as inspiration than anything else. They should not be used 1 to 1 because you will get messy paths.

With the large language model GPT-2 I was able to generate quite good paths. I trained it on many paths variants of a lowercase »a«. In the end it was able to generate new letters. However, a path recognisable as a lowercase “a” was only produced by GPT about once in every 100 attempts. But perhaps that is due to my basic approach to these models as a designer. 

So take it with a pinch of salt. We’ve come a long way in the last few years. Image generation and large language models are now very powerful. Thing have changed.

Another thing I realized during my thesis is that we can do a lot of things without AI. There are many wonderful Glyphs plugins that help us with several tasks in the design process. They are based on very powerful non-AI algorithms. So, we should always consider whether using AI is the best option for a particular task.

The scaffolding is in place 🙂 I would be very happy to see a font designed specifically for this algorithm. I think it has a lot of potential, and there is still a lot to explore!

Schwitters and Tschichold developed font systems that only worked for the German language. Herbert Bayer, who moved to the States in 1938, developed the “Fonetik Alphabet” (phonetic alphabet) in 1959, representing a version of the English language.