Treat Code as Process: An Interview with Hoefler & Co. Typeface Designer Andy Clymer
TypeThursday sat down with Hoefler & Co. typeface designer, Andy Clymer. We talked about his love for coding, how it can help your design process, and developing the shaded typeface, Obsidian. Enjoy!
Type Thursday: Andy, thank you so much for being here.
Andy Clymer : You’re welcome.
Getting Started Using Code in Type Design
TT: What I love about you is you have this really graceful attitude about technology. It seems very natural to you. It seems for you it’s a very holistic, natural process.
AC: I’ve just learned so much by watching others in the industry. Especially when I studied type design in The Hague at The Royal Academy. I studied with Just van Rossum and Erik van Blokland who were writing software and working in a manner where every bit of design was kind of touched by code. For example, when I was studying type design at the Hague, we were using a early beta of Preporlator that Erik was testing out.
So I saw this and I really liked that way of working. That was exciting for me. But I do admit it takes time to get comfortable mixing code in with your design.
It’s not like it’s something that comes naturally, just to be able to jump in to programming. But something that’s special about being a type designer is that it’s available if you want to, you have to find ways to look at the kind of patterns in your design work and your production work and think, “there might be a way to do this differently.
Why do we work in a certain way? How can I change it?” You get a different look at your design knowing that you could draw with a new kind of tool, or take an annoying step out of a process. So it helps you to kind of take a step back and think about the way that you work everyday.
Being a type designer where I can write some code to help me just makes you think differently about the process.
TT: Can you talk more about why is this programming way of thinking is important to you?
AC: When I was studying type design and we had programming exercises, something kind of felt right about it. I think it makes perfect sense when you write your first few lines of code that you understand and that actually did something helpful, the door opens to realizing that with enough work you could probably make a script do anything.
It just makes you think differently about the process, you notice that there’s a task you do often that’s slow and frustrating to do, and you start to imagine that there might be a better way. Even if it doesn’t result in writing a script, just knowing that there might be a different way around a problem gets you thinking.
TT: Do you feel like you have a certain perspective you gain in your way of thinking or do you just enjoy that process? Do you just enjoy that kind of feeling of mastery?
AC: Well, I’ll ask you as a type designer, do you use code?
I think type designers think a lot about process, because things take so long. You’re working for years on something and you really have to plan ahead in a special way.
AC: I would wonder how you’d answer the question as well. I don’t think it’s anything special about just me. I think type designers think a lot about process, because things take so long. You’re working for years on something and you really have to plan ahead in a special way. You do have to feel like you’re in control of the process.
As a type designer, you’re going to be working on for years on a project, and you want to be sure you’re doing it the right way so that you’re not setting off now worrying if you’re going to lose three months of work when you realize you did something wrong. Things can be very tedious.
For example, kerning can be a very tedious process. You think about it as, “I have to look at everything. I have to look at every single combination of glyphs” and it can feel insurmountable. There isn’t just one way to kern a font or proof all of these combinations of glyphs, designers have run into this same problem made new tools to help when they thought of a better way. So you think a lot about process as a type designer and the tools that you use influence the process. If you take away the word “code”, just talk about process, then maybe it sounds a little bit less intimidating to a non-programmer.
TT: I think a lot of type designers, see this divide, see this separation in their art making versus their code. What makes you unique is you don’t see that difference.
Realize that you’re not working in the design industry, you’re working in the software industry.
AC: Well, it looks like a mystery, a completely separate part of the process, until you get comfortable with it. Until you’re actually writing some code that’s doing what you want it to do and that isn’t breaking anything. Programming mistakes can get in the way, like, making a mistake that accidentally removes all the overlaps in your entire design when you really expected the script you wrote to do something else. It’s not going to feel like programming and design fit together so easily if your code is breaking your design, but if you start small and get comfortable with writing a little bit of code to do something, you can start to see how the two fit together.
I know that the software side can feel like a mystery, and it just takes time. Designers put a lot of trust into the tools to do the right thing. Someone might just want to design type and then they realize they’re actually — This is something that Jonathan Hoefler told me a long time ago — realize that you’re not working in the design industry, you’re working in the software industry.
You’re actually building a little piece of software that someone has to install on their computer and it has to work in the right way, otherwise they’re going to be calling you and wanting their money back. I think learning to program can help you learn how this piece of font software that you’re building actually works.
Using Code to Design Obsidian
TT: What’s the background about Obsidian? Where did it come from?
AC: Yeah, it came about at a time when we were finishing up Surveyor. I wasn’t there when Surveyor had started — Surveyor’s design had started in the ’90s. But then it was picked back up into production again about three years ago to extend the family to include more weights and styles and to fill out the character set to prepare it for a wider release, and I was working on that project.
I really liked the historical reference material that we were looking for Surveyor’s design. You might for instance find inspiration for Surveyor’s heaviest weights in a specimen book near other decorative types. Surveyor’s design wasn’t going to in that direction, but I thought it would be fun as an exercise to try a little bit of sketching with code. I wanted to be a better programmer and I needed a project, if I want to learn something new I need to have a way to apply it. I’m not going to learn German unless I’m going to go to Germany. Because I tried that and it didn’t work.
I wanted to do something different with code, I wanted to draw more with code instead of just automating tasks. But it was a lot of fun to think of the kinds of decorative designs that would be just too difficult to really want to draw by hand. I think that was also a place where these elaborately decorative designs I was looking at had come from, advances in printing and engraving may have only just at that time made it possible for these typefaces to exist.
I wanted to be a better programmer as well and you always need a project, if you want to learn something new.
It started as kind of a sketching process in a way, over time I ended up with a lot of really small tools that decorated parts of letters differently and we narrowed it down to the one that we thought looked the most exciting.
What’s great about drawing with code is that when you get to a letter where your system stops working you have a chance to make a change, you don’t care about having to redo older drawings. I started by shading a prototype set of letters, the same set that you might start with when sketching. Maybe like a cap-H, cap-O, cap-D, lowercase-N, lowercase-O, lowercase-A, these kinds of things. And then you add a few that are fun to draw. You start with those and think, “Oh, wow those are great.” And then it’s a lot later on that you get to the cap-X and realize it’s not going to work.
I wanted to do something different with my code and I wanted to draw more with code instead of just automating tasks with code. It started as kind of a sketching process.
TT: That’s a big problem one?
AC: Yeah, with Obsidian it was because of the angles in the letter and the angle of the light. It just needed to be lit a different way. Like, how do you draw light coming from the top left when the main stroke of the letter that you’re shading in points in the direction of the light source? Because in reality, maybe it would either be completely dark, completely light, or a flat gray. It’d either get all the light or none of the light, depending on which way it’s leaning. But that wasn’t really going to work out if in a word a dark X comes up next to a bright O, this kind of thing. So you kind of have to break the laws of physics.
TT: But that’s the beauty of it. That’s what I love about the project is that it’s breaking the rules of your system for the sake of your system.
The fact that code was helping along the way meant you could go back and make some adjustments and change the system, do something a little different.
AC: Yeah, that’s exactly the point. If it doesn’t look right you get to go in there and tweak the parameters and try it again. And now that change might have an influence on all of the letters that you drew up until that point, it would either be a pain to start over drawing it all by hand, or you’d just have to force the “X” into the system that was already there.
The fact that code was helping along the way meant we could go back and make some adjustments and change the system, do something a little different, without feeling like you have to completely redraw everything every time. It was really nice to be assisted in that way.
TT: This idea that you’re commanding the tools. The tools are not commanding you.
AC: It goes back to process. You think differently about the process. We normally draw in a way where you start with a cap-H and a cap-O, lowercase-N, lowercase-O and lowercase-P to figure out what flat and round shapes look like, and the overall dimensions of the design, so that the next letter you draw can learn from them. But with a tool like the one I was building you could start anywhere because sometimes the letters that you would leave for the end could have more influence on how the first few basic control characters looked. You get to work in a different way.
TT: So, you would say the Obsidian project was not the traditional type design process?
AC: Not exactly our traditional process, yeah. But in a way it kind of still followed the same process where we do want to start with a smaller character set to make sure that things are going to work and to already start testing the results. Obsidian started from Surveyor’s sources so I was kind of free to jump around a little bit and see what was going to be difficult.
But when you do compare Obsidian to Surveyor, a lot of glyphs were redrawn to work. Sometimes it’s very, very subtle and you really wouldn’t notice that we just moved a few points around. We made something a little bit heavier, a little bit lighter.
TT: Can you think of a character that would be an example of that?
AC: The dagger and the double dagger were just hairlines in Surveyor Fine. They had the lightest amount of weight on them, which is no fun to shade. It just wouldn’t have translated into an attractive three dimensional shape, so we made them quite elaborate.
TT: There’s a lot of editorializing, in terms of aesthetic decisions as well as programming decisions.
AC: Yeah, the design evolved quite a lot along the way. And, every step of the way we were still reviewing the design the same way we would with any other project. The way that we work a designer works with an editor to talk through problems and questions with the work they’re doing. Even though there was a tool helping with the drawing, we were still meeting talking about the actual design itself, and we were proofing it in the same ways that we would as if it was any other design. The comments and ideas that I would get from Jonathan might turn into a change in the code, but it was still the same design review. You usually go through hundreds of rounds of revisions to a design over the course of a project, but the only difference here is that for most of the project the revisions were for the code.
It takes a long time to really truly change the way that you work. Obsidian was the start to something new.
TT: What do you think is the biggest takeaway from working on Obsidian?
AC: It takes a long time to really truly change the way that you work. Obsidian was the start of something new. It wasn’t the most traditional design brief so I think I felt more comfortable with working in non-traditional ways. It takes some time for the lessons you learn from one project to find their way into another one, but for one thing it’s changed the way I think about the actual contours that I’m drawing.
Take interpolation for instance. We’re used to the idea that you can draw two weights, and if you put the points in the right place the magic of interpolation will give you as many intermediate weights as you want. These weights are completely flexible, you can decide later that you want your Medium weight to be a little bit heaver, for example. After Obsidian I’ve been thinking more about the masters that you do draw as being a little bit more flexible, too. I’m thinking more about what other magic I could I do with an outline, or how I can build a larger family of type, other than just interpolating intermediate weights. But it might take some time to get new ideas out of the things that came out of Obsidian.
TT: This is very similar to the story of Pixar. In the sense that, since Pixar was at the very start of digital animation. All these different aspects of animation had to be developed by Pixar.
Pixar was one of the great examples of technology being humanized, of technology being really commanded for a larger purpose. Not just for its own sake, but to take it and tell stories. At least, that’s my impression of what Pixar is.
I see a similar attitude about your type. It’s for the service of the design, not for the sake of itself.
Technology has changed substantially over the years since the earliest days of making type and using type. I think it’s always going to.
AC: The technology of making and using type has changed substantionally over time. I think it’s always going to. And each step of the way there’s something new and different becomes possible to do, but, yeah, it’s more interesting to make something for a greater reason than making it just because it’s possible.
But on your point about Pixar, keep going on that. What can I say on that? It’s an interesting observation.
TT: I think a lot of people focus on technology on a means to itself. When in reality, technology is a means to an end. It’s actually for another purpose. To do something you couldn’t do before. And for the sake of Pixar, in the early days of Pixar, it was to tell stories. To tell human, real stories.
The work we do — and something that even gets presented as very technology-focused — can still convey a lot of story and a lot of soul.
AC: In type, it’s very easy to get caught in the technicalities of it.
The designing the type, the programming, the process, but ultimately, like you just said, it’s for the purpose of it to be used, to tell a story, to help people with their own work. It’s just a tool on its own. That’s kind of, for me, is one of the larger lessons I have learned. The work we do — and something that even gets presented as very technology-focused — can still convey a lot of story and a lot of soul. But that’s still all up to the person who uses it, I can only hope that it’s used in a positive way. The end result is bigger than just the font file itself.
TT: We produce hundreds of hours of work that gets distilled into this entity that someone types on a computer in two seconds.
AC: Yeah. 32kb worth of data that you spent years working on. But I dont’ want dwell too much on this kind of way of working, that I describe with Obsidian, because people have been making incredible typefaces forever without Robofont and without any amount of programming. I’m not saying that everyone has to work this way, it’s just something that I like to do and that I found works for me. But as an exercise for having code assist design and working much more quickly and to create something that I feel like I couldn’t have made with another process, it was a lot of fun.
TT: I think that’s the perfect place to end our conversation.
Andy, it’s been a pleasure.
AC: Thank you so much for inviting me to do this.
Want to learn more about Andy’s work on Obsidian? Watch his Type@Cooper lecture about Obsidian.
Love these interviews? Sign up for our mailing list to be the first to know about our next interview.