My name is Just van Rossum. I'm trained as a graphic designer with a focus on typography, specifically type design, and even more specifically technology within type design. Even during my studies, this focus began to develop.

Over time, my practice evolved from graphic and type design to software development. Initially, I used coding as a supportive method to create things that were otherwise difficult to make. This eventually led to me becoming a full-time programmer—or coder as it's commonly called today. All my coding work is still related to type design, graphic design, and typography.

On the side, I also teach. I used to teach at the graphic design department at KABK, but I stopped a few years ago. However, I still teach at TypeMedia, our one-year master's program in type design at KABK in The Hague.

Yes, the collaboration started after we finished our studies. Erik was just one year behind me at KABK; maybe he was still in his internship year. (You would do your final exams before your internship; it was an odd structure then.) We knew of each other at KABK, but we were not in the same class, and it took us a while to connect. We were actually introduced by Erik's older brother. My teacher, Gerrit Noordzij, advised me to contact Petr van Blokland, who graduated about ten years before me. Petr said, "Hey, you're interested in computers. Go talk to that Erik because he knows everything." Petr had his own practice and studio and was an interesting figure to talk to about using coding in the context of type design, making tools for small and big projects, and everything in between.

It was amazing that MoMA did that. We made a little video for it, and it's part of their permanent collection. I don't know how often it will be exhibited. But yeah, it's there as permanent proof that we made that, which is cool for such a digital, almost ephemeral object. You can’t call it a font; it's a tiny file with bits and bytes.

While it was artistically one of the more successful results of the collaboration, it hasn’t been a commercial success as a typeface. Success can be defined in different ways. Artistically and culturally, it is quite a success, but commercially, less so. Perhaps that's for the better.

It’s using PostScript. Every time you print it, it modifies the typeface. Was that a new thing at the time? I was aware of Metafont by Donald Knuth. Donald Knuth, the prominent computer science figure, developed TeX and Metafont as a typesetting system and a font system because the available options weren't good enough. He wrote a little book about Metafont, which is quite entertaining. It contains suggestions and an example of a playful typeface that includes random vectors for outlines, so it wobbles a bit. I was aware of that, although not all that consciously. In retrospect, I was totally aware of that.

When we developed Beowulf, we were just experimenting with PostScript and learning how it works. I had already learned a bit of PostScript during my studies because it was the only way to get high-resolution output through coding. PostScript is a very learnable language. It's quite small, and the graphic primitives are easy to understand. It was neat to learn.

We realized that certain types of PostScript fonts are literally PostScript code, and each glyph is a bit of code that gets executed and can be manipulated. We discovered that it's possible to construct a PostScript font that applies a random factor to coordinates in the outline. Initially, we chose to work with straight lines. Later, with BIO Sans, a follow-up project, we also did some curve manipulation.

This all came from messing around with PostScript, learning about it, and slowly understanding its capabilities. I want to stress that these things emerge when you have the opportunity and take the time to experiment and play with new ideas. Technology was quite primitive at the time, which made it easier to get into because there weren't tools like Processing or RoboFont. You had to go deeper on your own since sometimes there was no internet to search. I actually had to buy a physical book about PostScript to learn it. While that seems almost weird today, the information was available and learnable if you looked for it.

I'm a co-maintainer. I wrote the original version in the early 2000s, around 2003, as an educational tool for students. About ten years later, Frederik Berlaen, encouraged by Petr van Blokland who funded the effort, stepped up to modernize and improve it. He rewrote about 90% of it. So, in 2013, there was essentially a full rewrite. Slowly, I became involved again, and now we co-maintain it.

The Daily DrawBot Tumblr. Starting around 2015, I did some coding sketches every day. For a while, I did it literally on a daily basis, but later it became more occasional. It was a phase in my life and career where things evolved. You do that for a period, but nothing is forever, and that's totally fine.

It was directly inspired by "Design by Numbers" by John Maeda from MIT Media Lab. Maybe even more by early Processing because Ben Fry and Casey Reas had already released that at the time. Processing was based on Java, which I wasn't working with and didn't want to work with. I saw that John Maeda's work had some great examples of simplifying coding for less coding-oriented people. This is beneficial as a thinking and educational process. Processing showed the concept of the text editor and a live canvas where something happens if you don’t make a big code mistake. That idea comes directly from Processing.

It would be nice to have something similar for Python, so in a way, we reinvented the wheel. Initially, DrawBot was only a teaching tool for our students at TypeMedia. For a practicing type designer, it's handy to know a bit of Python scripting as it is widely used in type design tools. In the early 2000s, it became clear that the language allows you to do many things within type design.

I started using Python in that context around '97, together with Petr van Blokland. It became obvious to us that offering a small Python course to our media students would be beneficial. DrawBot helps everyone understand that Python exists and provides some experience in thinking in code. With coding, you have to be precise. Unlike sketching, where you can just doodle on paper, coding requires attention to syntax. If you create a syntax error, nothing happens. The approach is different, even though you might wish for more sketch-like ways with code.

DrawBot helps with that sketch-like approach. It got some students interested in coding that otherwise might not have gotten into it. The success was varied though; some people just don't really like coding and that's fine.

I actually have to respond to another questionnaire that I got sent by someone. One of the questions on it is, “Do you think that graphic designers or art designers should code or should learn to code?” From what I did in the early 2000s, it may sound like I think that everyone should code—and sure, it's nice to be able to if you have felt that need—but I don't believe that every designer has to become a coder to be able to run a successful practice at all.

Fredrik Berlaen is a great example. He was a student at TypeMedia and graduated in 2007. Despite having no coding background, he had a strong mathematical intuition. His dad was a mathematician, so he grew up in a math-heavy environment. His thinking was perfectly suited for coding. He created a calligraphy emulation machine in Python using Drawbot, which was really impressive. That was a highlight for me in a stream of other talented students who excelled in scripting. I hope I have guided them in the right direction.

Nina Stössinger in Brooklyn uses Python scripting at a high level in her work at the Frère-Jones type foundry. Many people have adopted Python in their daily type design practice.

It helped lower the threshold to get into coding. Processing is also a great example of this. Imagine how many people would have otherwise ended up being creative coders or coders.

DrawBot was initially an educational tool, but it became more advanced, especially after Frederik's rewrite, which added many features. I created the original version in 2003, and it was limited. I wasn't interested in enhancing or spending much time improving it, so it remained as it was.

Frederik had some great ideas that turned DrawBot into a much more versatile tool. The canvas became more powerful, allowing zooming in and out of results, and there were better export options, including multi-page and animation exports. These changes set the tone for what DrawBot could achieve.

Though it hasn't become hugely popular, it has seen increasing use outside teaching. We were early adopters of good variable font support and OpenType features. For those wanting to create static or animated designs programmatically, DrawBot was a good choice because it supported all OpenType features. Once variable fonts were introduced, we soon had good support for them.

Together with animation capabilities, DrawBot was one of the first platforms where you could create animations using variable fonts programmatically. For a time, many foundries producing variable fonts used DrawBot to showcase them with fancy animations. Nowadays, such presentations are more likely to be done on the web in real time, overshadowing the role of DrawBot.

I was freelancing for Black Foundry, a medium-sized font foundry in Paris that also does a lot of Python scripting. I got involved to help them with some projects. They use RoboFont as a font editor and have developed several extensions, including RoboCJK. RoboCJK is an extension that helps create East Asian fonts in RoboFont using variable components and technology to reuse shapes easily.

For example, you can reuse a shape within a font when building an accented letter. If you have an A and need an Ä, you can combine the A and the ¨. These are called component references. Whenever you change the A, it will be reflected in the Ä. This is a static relationship.

In East Asian fonts, strokes are often reused across many characters. Although the character sets are large, the strokes themselves are repeated with slight variations. It makes sense to have strokes or even radical characters, which are combinations of several strokes that can be placed in other characters.

You get this multi-level hierarchy of component references that you can adjust a bit. That idea is familiar to RoboCJK, but they found a way to use it effectively. They had commissions to build East Asian fonts and discovered that using what we started calling “variable components” was a useful tool to speed up the process, especially with large character sets like Chinese, Korean, and Japanese fonts.

I got involved with Black Family not directly for that, but we ended up discussing it a lot. We noticed that the RoboCJK was becoming very slow with more complex characters. We were looking for a better way to handle this and considered making a better RoboFont plugin. However, we realized we wanted to build variable fonts from the core of our process.

Variable fonts mean that the concept of a glyph or the entire font being variable is central to the design from the beginning. RoboFont, however, is not very variable font-oriented. It's mainly an editor for static fonts, where you draw a regular and a bold, but they are separate files. There are ways to combine them into a variable font, but it's not the primary focus of RoboFont.

But while drawing, you're really only drawing the regular area. You're only drawing the bold. And there are some plugins that kind of put them together so you can have more live ideas. We were looking for a more variable approach from the basics from the starting point. And we considered a bunch of different approaches, like building another better Robofont plugin. In the end, we did a couple of tries. A wish that our main client also supported, was that we would open-source any tool that we would develop.

We wanted things to be cross-platform. We considered building another desktop application, possibly using Python with cross-platform UI toolkits. We had experience with Mac desktop applications. Eventually, we thought, why not use the browser as the UI for the platform's front end?

We did some experiments to see if this was feasible. For me, this was new because I had only followed web technology on the side and wasn't a web developer. I hadn't built modern or dynamic websites before. However, our experiments showed that using the browser could also enable a more live collaborative setting, even though that wasn't our initial goal. So, we decided to create a browser-based font editor.

Currently, there's a server part written in Python and a front end written in JavaScript. They communicate with each other. The Python server can run on a different machine or a remote server. We use it in two ways: as an application called Fontra Pack, which is a Desktop application containing a web server. You still work in the browser, but the application also works with local files.

We rely heavily on Python for many functionalities because it's dominant in the type engineering and design fields. Python has many libraries for reading and writing various formats, both source and binary like .ttf. These Python tools are either unique or more powerful than their JavaScript counterparts. In JavaScript, we have tools like OpenType.js, FontKit, and libfont, which are great and improving. This is why we have a hybrid approach.

For the communication between the web browser and the server, we use two technologies: regular HTTP and WebSocket. WebSocket is nice because it allows two-way communication. With HTTP, the browser asks for something, and the server responds. With WebSocket, the server can also initiate communication. For example, if two clients are on different machines and one makes a change, the server can notify the other client to update their screen to reflect that change. The server acts centrally to initiate communications with the browser. Once the browser establishes the WebSocket connection, it's an open channel for messages to be sent back and forth.

My personal coding practice is old-fashioned. I played around with ChatGPT last year when I had some math-intensive Python code using various libraries. I needed a version of that code in JavaScript. After some nudging, ChatGPT helped me get a working JavaScript version.

I don't use ChatGPT daily. I don't use VSCode, so I don't have Copilot integrated. You have to buy it; a colleague of mine has a small subscription. We shared the screen, and the auto-complete feature seemed nice, but I don't use it myself.

I have colleagues who aren't primarily coders but use ChatGPT successfully. For example, one colleague at Black Foundry creates lovely JavaScript applications or single-page experimental things with JavaScript and HTML, thanks to ChatGPT's help. It's very successful for him.

For me, I don't feel the need to use it much. It might take more time to correct its mistakes than it's worth. It's good at generating boilerplate code, but ideally, you shouldn't need much of that. The more boilerplate code you need, the more ChatGPT might help. I'm a bit cynical about these tools. It probably depends on how you use it.

I try to stay up-to-date. I don't dislike technology; machine learning techniques can be incredibly useful, and the accomplishments are amazing. For instance, the development of COVID-19 medicine and vaccines is partially thanks to such technologies. I see their power and validity.

However, the current extreme hype and the enormous amounts of money being invested in areas where we're not convinced of their usefulness is concerning. There are numerous examples where these technologies can be harmful due to biases in the models. Additionally, the energy consumption required to create these models is significant. This aspect of the hype raises many questions for me, and I think this bubble will burst at some point.

I'm curious about the applications of machine learning and fascinated by its capabilities. Yet, the scraping of artistic material without explicit permission from the authors is morally dubious. Big companies often act without regard for ethical considerations because the hype allows them to. They focus on spending as much money as possible on this technology to come out on top, which isn't good for society. This behavior is typical of big tech, which also has ties to political sponsorships.

I grew up being a bit of a nerd. As a teenager, I worked with electronics and learned about computers. I love working with this technology, but now I'm at a stage where big tech feels like a highly political topic. I'm very happy to see young people pushing back against it. I hope others, not just the young, will also question the blind admiration for tech, especially the so-called "tech bros." This cultural phenomenon is highly disturbing to me.

I'm concerned that those with big money will do whatever they think will make them the most money. It's all about profit in the end, not about creating useful things for society. In that sense, the world is more messed up than I would like it to be.

I feel that some AI developments are exciting, especially image generators. I remember when you were experimenting with machine learning, creating album covers that animated into each other. That was fascinating. I don't know how you trained the model, but it showcased its potential. Now, this technology has advanced significantly. Thanks to increased scale and improved technology, image generators are incredibly powerful.

Regular people find these tools interesting. In my Facebook feed, I can usually spot AI-generated images immediately. However, many of my non-graphic designer acquaintances can't tell the difference and often find them amusing. The results can be impressive if you prompt the AI correctly. The initial wow-factor is high, especially when the technology is new. But after seeing many generated images, it quickly becomes less impressive. It's sad to see how a groundbreaking technology can lose its charm.

Additionally, these images can be used to manipulate people, making it a political issue. The novelty is in its potential, not necessarily its practical use for humans. It's unclear if this technology is a net benefit for society. In a country with poor healthcare and health insurance, investing heavily in such developments is questionable without knowing their true societal impact.

That's kind of weird, especially in the USA, where there's a huge contrast. A lot of the big tech sector is there. But simultaneously, the disparity between rich and poor is extreme. This is also getting worse in Europe, but it's really severe in the US. That is scary, for sure.

I'm working on Fontra, so obviously that's something I believe should exist, coming from practical needs in an actual work environment. Still, my heart is in it, but that's not where your question is leading me.

II don't know. Maybe I'm not that forward-thinking outside of my own niche. Sometimes I wish I could understand machine learning better so I could apply it to smaller data sets.

If you, as a company, have a data set, the problem is that large language models and other machine learning models usually work well with big data sets. But what interests me more is what can be done with a smaller data set, like the one a company or a person owns. For instance, the fonts you have designed so far—what if that's all you put into your model? How could that tiny data set help you in your future designs? When drawing a letter, your previous designs might influence it. Of course, you don't want to repeat yourself, but some decisions might still be guided by past designs.

Maybe it's an auto-create feature in a visual way. I'm not sure how well that is possible. It would work like Copilot, but mostly trained on your own code base. It learns from what you already have, either as a company or just within a project.

As for the tools I wish for, I just turned 58 last month. In the context of technology, that's considered old. I've seen amazing progress in the last 30-40 years of my career. It's really cool to be part of things like font technology and how it evolved, including font marketing and the font market. It's interesting to see from the inside.

I don't have big visionary ideas for the next tool or website. One vision for Fontra, and it's far from clear whether that's economically possible, is to make a public version where people can just log on and work. Google Docs and Figma are like that in that they're free to use, even for private things. There isn't much cool about Google itself, but this free access is a major benefit. For Fontra, it would be nice to offer a similar service, perhaps with a paid option for private use. We're working on building such a platform.

We know this kind of technology is useful on a small scale, like for a foundry to have its own online collaborative font editor. We're developing Fontra so it can be replicated for other font foundries. Ideally, there could be a public platform, like GitHub, where people can create accounts, design type, and collaborate with others.

FontStruct is an excellent example of this, and it's wonderful that it still exists.FontStruct has evolved and become more powerful over the years while staying true to its original mission. It's mainly run by one person, Rob Meek, with occasional sponsors. I hope he's making a good living doing what he loves.

Creating a similar environment for a larger audience would be ideal. However, the question is whether it's possible to host and scale such a platform for a broader public. This is a significant challenge, both technically and economically. At Black Foundry, our small team is working on Fontra, but scaling it to thousands or tens of thousands of users is a different kind of effort and a technical challenge, not to mention making it economically sustainable.

One final thing: there's something that makes me hope we can pull this off at some point. It could lower the threshold for type design. If you could, especially as a student or non-designer, create an account, start drawing, and collaborate with people, it would be great. This is especially true for endangered languages that lack fonts or have very few. There are many small languages in the world with poor or no font support. Since there's not a lot of money in creating fonts for these languages, it involves a lot of work for very little economic reward. It would be nice if things like this could be more open to a community with cheaper or free tools. That's my minor idealistic hope for what something like Fontra could achieve.