Tools to design and produce Elementar

07 May 2021

Elementar is an unconventional typeface family. Several special tools were developed over the years to assist in the design and production of the fonts. This post offers a retrospective account of the main tools created for the project.

Brute force (does not work)

The very first sketches of the Elementar variation principle were made as bitmap images in Photoshop. I soon moved to working inside the font editor, which at that time was Fontographer 4.1 on Windows 95.

True bitmap font formats like .fon or .bdf were not widely supported. Screen resolutions were still very low1, and ‘pixel fonts’ (vector-based bitmap fonts) were very popular2 specially in graphics and hypermedia design environments such as Flash, Director, Fireworks. Custom webfonts in plain HTML were not supported yet.

The Elementar fonts were drawn as outline fonts on a grid of 125 units3. The beziers had to be created point by point, manually, and were aligned to the grid manually too. I used copy/paste extensively to turn one style into another. But because the process was all manual, there were a lot of errors and inconsistencies in the result. And if I decided to change one detail in a glyph (for example make the horizontal bar in f one pixel wider), I had to open several other fonts to make that same change to match.

It was a very dumb and slow process, and it would take forever to finish the fonts with this approach. I kept studying and searching for ways to build the system as I had envisioned it.

Pixel Brush

The first big leap in productivity came in the form of a custom drawing tool created by Hartmut Bohnacker, one of my teachers at the HfG Schwäbisch Gmünd in Germany. By then I had already switched to FontLab 4 on a Mac, but the drawing process was still the same, point by point. After seeing how I worked, Hartmut wrote a custom FontLab tool in Python which behaved just like a ‘pixel brush’ from drawing apps, only in vectors. This simple tool allowed me to work much faster and made the whole process a lot more enjoyable. I was super excited about it, and seeing that something like this was possible motivated me to dive deeper into scripting and making custom tools.

Hartmut was kind to give me permission to redistribute the script. Users of FontLab Studio 5 can still find it on GitHub.

I switched to RoboFont as soon as it was released in 2011. One of the first extensions developed by Frederik was the Pixel Tool, a drawing tool which reproduces the behavior of Pixel Brush and adds some functions of its own, such as drawing with components. This is the tool I use today whenever I need to draw with ‘pixels’ inside a font.

Elementar Synthetic

Elementar Synthetic was an experiment in recreating Elementar entirely as a program. It was developed in collaboration with Frederik Berlaen while we were students at Type&Media, and presented together at RoboThon 2006. Each glyph was described in Python in terms of vertical and horizontal strokes, using several variable parameters and with lots of extra logic to handle aspects such as rounded corners, center alignment, slanted strokes, etc. I’ve ported the program to RoboFont a few years later, and added an interface to control the parameters interactively.

This project was a rich learning experience. It provided me valuable insight into the difference between computer assisted design (dumb tools that are operated by the human eye-hand) and artificial intelligence (pure programming tools which do all the work with logic and code). I learned that (at least for this project) I preferred to work with the first kind of tool, where I can see and manipulate the result in real time. Elementar Synthetic remains interesting and useful on its own, and Elementar production continued in the semi-manual method which I had been using until then.

Point Shifter

With time, I became more fluent in Python, and created the habit of observing myself while working. In practice, the two main kinds of transformations in Elementar (height and width) were produced by selecting and shifting all points with coordinates greater or smaller than a certain treshold value.

For example, a 10px style would be typically produced by taking a 9px one, selecting all points slightly above the baseline, and shifting them up by one grid unit. Some glyphs would require manual fixing (those with a vertical centerline like a, e, s), but this simple operation alone would do most of the work very quickly.

The same principle was used to make a wider style of an existing font: select all points in the right side of the glyph, and shift them by one grid unit to the right, making adjustments or giving special treament to double-module glyphs (like m and w).

I was able to implement this tool myself using RoboFab in FontLab. It was later ported to RoboFont and absorbed into hTools2, and from there it was carried over to hTools3, where it is still available today as the Shift tool. I still use it every now and then in my work.

In addition to the Shift palette, I also created a more sophisticated version of this tool: a script which could apply shift transformations in batch to a range of fonts in multiple heights or widths, using different shift parameters for different groups of glyphs. It would also increment the related vertical metrics attributes (when shifting along the y axis) or the glyph widths (when shifting along the x axis) by the same shift distance. This version was very powerful and could do in seconds what would have taken days or weeks of very dull manual work – for me that was quite an achievement. Interestingly, this script did not survive until today: once the fonts were done I had no use for it anymore, and didn’t care to upgrade it and keep it running.4

ESpace / EGlyph

A large part of the production work on Elementar was done “blindly”, by running scripts on the font files and checking the result after the script was done. The batch shift script mentioned above is just one example, there were several other actions which were performed in batch. Most of the times, it worked great5.

These production scripts followed certain repetitive patterns: they usually involved selecting a subset of all Elementar fonts parametrically, and then applying either a simple function to each single font, or a more complex function involving two fonts (for example source and destination). This recurring pattern was abtracted into an ESpace object6, which I could use to quickly select some fonts using parameters and apply a certain function, saving the result. In code this looks more or less like this:

S = ESpace()
# define variation space with parameters
S.style  = [ 'B' ]
S.height = [ 9, 11, 13, 15, 17 ]
S.weight = [ 11 ]
S.width  = [ 2, 3 ]
# get the name of all fonts in the current space
print(S.names)
# apply a function to each font in the current space
S.apply(someFunction)

After a while I was able to use this with confidence, and it was like I had acquired superpowers. By that time the family had already grown into hundred of single fonts, and it had become very hard to find and open individual fonts in the Finder. With the ESpace API I could easily address specific fonts, thanks to the underlying parametric font naming system.

The EGlyph object was created later on top of ESpace, as a separate Python object for use in DrawBot. It creates a visualization of all variations for a given glyph, nicely aligned to a grid to make comparison easy. This was used for proofing purposes in the later stages of the production process, as the fonts were being finalized for release.

The original ESpace and EGlyph code was lost in time, and I recently had to write them again for use in the production of Elementar 2. Both tools remain essential to the Elementar workflow.

TempEdit

TempEdit originated as the other half of EGlyph, and later got a life of its own as it was useful for other projects too. While EGlyph displays all versions of a glyph in a given design space, ‘temp edit’ is a way to import all those different versions of the same glyph into a temporary font for editing, and then save them back into their parent fonts. This method allowed me to save an enormous amount of time and attention, which would have been spent opening several whole fonts in the interface, to edit only one glyph in each.

Elementar was published in 2011 as a family of 420 single fonts containing 665 glyphs each, with a total of 279.300 glyphs. It was produced with RoboFab in FontLab Studio 5. This was only possible because of the ‘temp edit’ approach, which allowed me to bypass the main performance bottleneck: opening large fonts in the interface7. To me this is the single most important tool in this collection.

I’ve tried to explain this approach a couple of times in mailing lists and forums, but it’s one of those things that need to be understood in practice and not just in theory through an explanation. I don’t know if anyone actually tried it out.

The arrival of variable fonts made the problem of large designspaces × large glyphsets even more relevant, which led me to (re)build TempEdit around the .designspace format, and make it freely available as an open-source extension for RoboFont 3. It’s been out there for a couple of years now, and I still don’t know if anyone has actually tried it out. I use it myself every now and then to fine-tune glyph masters in variable fonts.

ERasterizer

Finally, ERasterizer is a tool to split ‘solid’ glyph contours into separated elements. I use it in two distinct situations: in contour mode, as a kind of reverse remove overlaps to ‘detach pixels’ before using the Pixel Tool; and in component mode, to create the final disconected elements which are used in the variable font.

RoboFab had a glyph.rasterize() function back in the day, but it didn’t quite work in the way that I wanted. So I ended up writing my own scan and rendering functions, and over time this grew into a small module which was useful in various projects. A small interface was added a bit later, to make the tool usable for other designers too.

More recently, ERasterizer was updated to RoboFont 3 and rebuilt as an hTools3 add-on. It has been renamed to hRasterizer, and is now publicly available as a paid extension.


Notes

  1. The typical screen dimensions were 640×480 (VGA), 800×600 (Super VGA) and 1024×768 pixels. For comparison, the MacBook Air in which I’m writing this has a 1366×768 screen, and I use an additional display with 1920×1080 pixels. I’ve never worked with a Retina display, it must feel very different. 

  2. There were several font foundries specialized only in pixel fonts, like Atomic Media, Miniml and MiniFonts. There was the classic collection of bitmap fonts by Emigre. Etc etc. Bitmap fonts were very relevant then, and every typeface designer eventually tried his or her hand at designing one. The famous Apple system fonts by Susan Kare. The incredible designs by Miguel Hernandéz. And later I would get to know Fedra Bitmap, Unibody, Outbox, VijfZeven… Good times! 

  3. I’ve switched to 120 units per grid cell in Elementar 2, because it has more integer divisors. This is useful when drawing in double resolutions (2×, 4×, etc). 

  4. And also because it wouldn’t be too hard to rewrite it one day, in case I needed it again. The tools which survive and get polished are usually the ones which are reusable. 

  5. I also messed up finished glyphs several times by mistake. Every time I got too confident, I got punished for it. I learned my lesson eventually – today everything (fonts, tools, content) is under version control, and I have developed the healthy habit of committing my changes often. 

  6. This was before the .designspace format existed. But I was of course familiar with the concept of “design space”, and had already had some experience working with Superpolator. Any similarities are not a coincidence. 

  7. In FontLab Studio 5, opening and saving full UFOs was slow because they had to be converted between UFO and VFB with a script. In RoboFont, the slowest part is drawing all the glyph cells in the Font Overview.