Type Engineering: How to get into it?

mxyd

As opposed to type design, there are not many courses and or publicly available information on type engineering.

I have a decent command of Python and want to look into opportunities as a freelance type engineer. 

I'm self-taught and have been working on some fonts of my own for a couple of years. While I see opportunities for scripting, automation, I would imagine this is nowhere near what professional type engineers do on larger projects. My wild guess would be that main tasks involve navigating different font standards, metric systems, OS/device nuances and ironing them out.

My questions are:

- What is a typical skillset one needs to be able to freelance as a type engineer? 

– What are particular technical knowledge that a type engineer needs to posses and what are tasks that need to be done usually on a project? (Please be as specific as possible)

– Are there any resources for self-education in type engineering?

John Hudson

Firstly, this work requires attention to and good memory for detail. That’s true of type design too, but on the engineering side it is crucial. Being able to work systematically is also important. If you are doing engineering on a project that someone else has designed, you need to be able to analyse what has been done, what has not been done, and be able to come up with a systematic approach to completing the work.

Yes, understanding the font format standards is important. Today, that is usually OpenType, but that stanndard now includes a lot of different kinds of fonts, including variable fonts and varieties of colour fonts.

You need to understand OpenType Layout, and how it fits into the whole text encoding and display stack. A lot of people figure out the basics of how to code certain kinds of OTL features within particular font design tools without really understanding the technology. The best font engineers I know are the ones who really understand the structures of GSUB, GPOS and GDEF tables, so are able to come up with flexible and creative ways to do things with them.

Be aware that there is a grey area between design and engineering, in which you might be asked to do things like kerning and mark positioning that I consider design, but that some designers may prefer to pay someone else to do.

Having a ‘decent command of Python’ is definitely helpful, but I’ll note that I do not, and typically pay other people to write scripts and tools for me. So I would say that as a font engineer what is most important in this respect is being able to understand what you need and how it should work, and to be able to spec that, whether you are going to write the program yourself or have someone else do it.

On the subject of coding, familiarise yourself with all the existing libraries such as FontTools, as well as font QA tools, and understand how they can be used.

Simon Cozens

It's actually quite hard to answer your questions because the landscape of font engineering (BTW we tend to say "font engineer" rather than "type engineer", since it's really the binary font files we're producing) is always getting wider and wider.

A few years ago I would have said "Python scripting, good knowledge of relevant type modules (defcon/ufoLib2/fontParts, glyphsLib, fontmake, etc) and QA tools, good understanding of AFDKO OpenType layout language (syntax and semantics), deep knowledge of UFO, Designspace and OpenType font format specification".

Nowadays, there are so many additional directions things can go in. If you want to specialise in scripts with complex layout requirements, then quite a good handle on the linguistics and orthography of those scripts as well, and a fairly complete understanding of the Unicode Standard as well as how shaping engines like Harfbuzz and the USE work. If you're working on collaborative or large-scale projects, which many font projects are these days, then you need to understand git really well. (Oops, a designer just committed some files with merge conflicts - they're going to need you to fix it.) I don't think you can be a good font engineer without having at least a decent grasp of the Unix command line and toolkit - shell scripting, Makefiles, and so on. Increasingly I spend a lot of my time working on continuous deployment, wrangling GitHub Actions and the like. There is always more to learn.

And that's just the technical skills you need. As a font engineer you are there to work with designers, who may not be particularly technical, to make their design work and finalize it into a publishable font. You will find yourself debugging build issues on a developer's machine by asking them to type in unfamiliar commands into an unfamiliar black window over a video call. So you need humility, patience, and good communication skills.

Depending on the team and the context you're working in, there may be an element in which you have to take on some project management responsibilities; or if not, work well with people who are project managers. Sometimes you are going to have to lay out a clear architecture for how the font is going to work, be built, and what processes it will go through before it is ready to ship; other times, you will have to work within a designer's established workflow. So flexibility is important, as well as knowing when to take the lead technically, and when to fit in. You also have to have a certain amount of tenacity and initiative when it comes to solving problems; even today, I had a font which just wasn't compiling the way it should have done, and I had to trace my way through various libraries to work out where the problem was coming from.

You asked about the actual tasks that are done. This very much depends on the project. Sometimes I am involved at the start of the project to help designers think through and lay out the glyph set (particularly for scripts with complex layout requirements, having an engineer's experience of what works and the most efficient way to do things is extremely helpful), or to get them set up with a development environment which works for them. I like to get people used to iterative processes of testing and QA so that problems are picked up and resolved quickly, and so that a font is always "release ready", but oftentimes I'm brought into a project after all the design work is done and I have to turn it into a publishable font at that point. Sometimes the font engineer needs to produce proofs; sometimes the designer handles that themselves. Sometimes they're even responsible for specimen production, but usually not. Often the font engineer will be responsible for setting up the (reproducible, hopefully) build processes.

I sometimes describe font engineering as "everything but the outlines", yet there are times when I will jump in and fix e.g. interpolation issues in variable font outlines. Other times the designer makes it clear that I don't touch the source files without their permission! So you negotiate.

Once the outlines are done, the OpenType code is written (which may or may not be your job - but will certainly be your job to fix if the designer gets stuck!), the proofs are checked, then the main work of font engineering mastering takes place. This is the technical side of font production, working with tools like fontbakery or fontspector to identify parts of the font which either don't comply with the OpenType specification or which are going to cause problems in certain environments. Font compilers and editor do a reasonable job of producing a binary that works, but only if you set all the parameters correctly! (And even then, individual fonts might be fine but not work together properly as a family.) Name table entries, style linking, weight classes, fvar instance names and locations, axis mappings, and the STAT table are the main areas where incorrect settings will lead to an incorrect font. Other tasks that I have to deal with frequently are merging fonts (separate designers worked on the Latin and the Devanagari but they want to ship them as one font) and subsetting fonts (we put the Latin and the Devanagari in one source file, but now we want them as separate binaries), and converting between different font formats (both source and binary).

Is that specific enough? :-)

As for resources, sadly there are not many yet. There's my book, which may be helpful but is woefully unfinished and very much focused on the layout aspect, and there's the Google Fonts Guide, which is obviously GF specific but has a lot of font engineering wisdom in it. I often post some (hopefully useful) engineering tips on my blog. But I really want to sit down at some point and write an actual font engineering textbook. One day.

As to how you get started, you just dive in! Take a font file, compile it, run fontspector on it, read through the rationales to understand the problems that it throws up and see work out how to fix them. Explore OFL font projects on GitHub and see how they work. If you want to play with interesting OpenType challenges and scripts with complex layout requirements, grab some of the Noto font sources and a copy of the Unicode Standard, compile them and play with them in Crowbar and work out how they do what they do.

Follow this forum, the Glyphs forum, follow people on typo.social, and ask lots of questions. Just get started. Technically it's an interesting challenge if that's how your mind works, but as I mentioned above, a lot of the job is about people. And type people are, on the whole, pretty good people.

Thomas Phinney

John and Simon are two of the people whose advice I would trust a great deal in this area, for sure. Both of their answers are deeply considered, and me having limited time today, I will just add two specific points to their much broader advice:

1) One resource Simon didn’t happen to mention is VERY well worth reading, as it just does a great job in bridging the gap between the AFDKO syntax and what is actually happening “under the hood” in OpenType layout, in reasonably clear and reasonably user-friendly language with great diagrams as well. That’s Tal Leming’s OpenType Cookbook: https://opentypecookbook.com/

2) If you are interested in learning another language besides Python... Rust is the language to learn. A number of Python based tools are being replaced by Rust tools, and there will be more. I am not suggesting that all tools are going to switch immediately, nor that Python will become irrelevant. Just that there is a lot of Rust development going on (as Simon well knows, being the fellow who developed Fontspector, the Rust-based replacement for the Python-based Fontbakery).

Dave Crossland

Simon's recent BITS/ATypI talks, and Rosalie Wagner's talks, on font engineering, are worth tracking down on YouTube. 

Kent Lew

I have nowhere near the experience that John and Simon have on the deep engineering side, as I straddle more of the design/engineering boundary (not unlike John, but definitely without his great breadth of multiscript experience).

But, like Thomas, I will add another resource to bookmark if you haven’t already: the OpenType Specification.

Not necessarily something to try to read straight through start to finish, but useful to browse and then refer back to.

Dave Crossland

There's also stuff like https://the-sysadmin-book.com and https://homes.cs.washington.edu/~mernst/advice/agre-networking-on-the-network-20050814.html which, while not directly about font engineering, are about how to become a professional in an adjacent area.