This story started in 2003 while preparing for a TypeMedia class. Or maybe it started around 1978 when my brother Petr went to URW in Hamburg for an internship, one of the first companies in the world to digitize letterforms. His teacher (and later my teacher) Gerrit Noordzij knew the founder of URW, Dr. Peter Karow. Petr experimented with interpolating digitizations of a single lowercase e, each with a different contrast, Noordzij had sketched the basic shapes. Later these digitizations became the iconic “Noordzij cube”. Big things were waiting for type design.
By the time that I came to learn about type, the cube had become an icon for experimentation. It showed that the processes that created letterforms were open for analysis. The type and amount of contrast had been conflated in physical writing tools. But the cube showed that these could be changed independently and that these changes were relevant in a design process. With the cube in mind, contrast took over from the pen as the most powerful tool in type design.
From early on, most digital type tools offered some form of interpolation. Fontographer could create a new font out of two. Adobe’s MultipleMaster went a step further and offered control over weight and width of select typefaces inside the layout tools, giving art directors and designers access to decisions previously made by punchcutters and typedesigners. A nice writeup of this specific chapter of digital type at the TypeKit blog.
If digital tools provided the means, then the cube provided the direction. Typedesign itself needed to become multi-dimenional. FontLab had implemented Adobe’s MultipleMaster (MM) system, it needed to generate those fonts. But when OpenType dropped support for MultipleMaster, echoes of its mathematical model remained in the app. MM had been designed to provide non-typedesigners with some degree of control over the letterforms. Therefor everything in MM was made safe for civilians, no unexpected results. no extrapolations. This meant that for every dimension added to a typeface, the designer needed to create exponentially more drawings: 1 axis needs 2 masters, 2 axes need 4 masters, 3 axes need 8 masters, 4 axes need 16 masters. Furthermore, once an axis was added, all glyphs needed to contribute a new shape. This did not facilitate experimentation because it was not intended for it.
Apple had developed TrueType GX as part of a rewrite of the graphics system for the Macintosh. This was in the difficult years before it acquired NextStep and started on OSX. GX fonts could interpolate, but using a different topology. Rather than interpolate between two fixed forms, GX could superimpose different shapes, a special kind of extrapolation. Whether or not these made typographic sense was left to the type designer: leave it in if it was useful, make local changes if it wasn’t. This really stimulated experiments with the design space: the technology was closer to the design process. As part of a program to show application developers what the GX system could do, Apple hired a couple of type designers to come up with ideas. Matthew Carter’s Skia started out as a GX font. Chuffed to be in such company, I knew my place and built a dirty typewriter with dynamic axes. Perhaps not as grand, but I got to understand the principles of the GX variations.
Together with Petr van Blokland and Just van Rossum, we added algorithm support for the basic contour and glyph objects in RoboFog around 1997. This meant glyph objects could participate in basic math operations. [see TypeSupply’s FontMath for a modern and fast implementation]. This resulted in a reduction in code and at the same time invited a new level of complexity. Remembering the fun I had had with GX and how close that model was to the logic demonstrated in the Noordzij cube, I wanted to see if I could build something like that in Python. I had only experienced the Mutator implementation, there was no documentation, but the principles were clear enough and so I started with a great deal of optimism.
It turned out to be a bit more complicated and just like that, a year passed.
Many, many dead ends, dumb bugs, wrong assumptions, sometimes drowning in complexity, slowly I learned the meaning of iteration in software development. It also showed that it is possible to write nice things, just have to keep trying. (Aside: this story could perhaps illustrate the value of a good education in computer science and math, less heroic and certainly more efficient). But eventually, in the summer of 2004 the algorithm began to work and it was beautiful.
MutatorMath became the engine of Superpolator and has, over ten years, generated millions of glyphs. Not only as a tool for production, but earlier in the process during sketching and design. Drop a new master on a new axis, see how it works out. Test ideas. Measure. Proof. Decide.
With support from the Adobe Type Team, MutatorMath is scheduled to become part of the Adobe OpenType FDK and take over the functionality offered by Multiple Master. Both terrifying and exciting, more than ten years of MutatorMath is now available on Github with a BSD-3 license.