Font catalog development notes

24 November 2021   fonts tools

Work on the nuclear font collection continues to advance in steady steps, with important updates in the type design and font production fronts during the last weeks and months.

Type design

Designspace changes

The designspace of Mechanica Mono was rebuilt with a different setup of variation axes. Previously, the overall colour of the type was defined by two stroke width axes, which controlled the vertical and the horizontal weights separately.1 That approach had the benefit of making stroke modulation more playful, with reverse contrast styles more readily accessible; but it also made it cumbersome to increase/decrease the weight while keeping the overall contrast constant (a more common usage scenario). The new version follows the same schema employed by all other fonts in the collection: a combination of the standard weight axis and a custom contrast axis. The reverse styles were removed from the designspace for now, but they will probably return later at some point.2

The proportional counterpart Mechanica was expanded with a similar contrast axis which greatly increases the versatility of the typeface, allowing for very fine details at display styles and subtle stroke modulation at text styles. In addition to that, the advance widths of all variations along the weight axis were made to match, making it possible to change the weight of the typeface without causing the text to reflow.3

Finally, the weight axis of Jornalistica Sans was expanded with four new light masters, so that the font’s variation space now matches the two parent serif styles and most other fonts in the collection. I like the new lighter styles very much. This project continues to be a lesson for me on how small unpretentious exercises can grow into beautiful useful things.

Standardizing variation axes

Another important step was making the variation axes of all fonts adhere to the standards defined by the OpenType Specification. This is important to make the fonts interoperable between each other and with other fonts and typographic environments. In practice, this means that it is now possible to change the font family without affecting the overall weight and proportion of the type. Users can now also specify font weight and width numerically using the CSS attributes font-weight and font-stretch, and get predictable visual results.

The standards compliant axes were achieved by adding appropriate map values to the axis descriptions, to convert between user values (input) and design values (output). This data is then used to insert an AVAR table into the generated variable fonts.

The current mapping values will be fine-tuned over time as more proofs are made.

Improving numerical consistency

All families are undergoing a process of checking and fixing interpolation discontinuities along the weight and width axes. During this process a custom proofing tool is used to visualize glyph dimensions and spacing as series of numerical values.4 These values are manually adjusted until they form a consistent distribution curve across all master glyphs. The result is a smoother transition between interpolation steps.

Font production

Font generation out of the box

Up until very recently, I was generating variable fonts in RoboFont 3 with Python using the Batch extension’s API. Batch does a lot of work under the hood to automatically convert design sources (with loose interpolation compatibility) into variable font sources (which have strict compatibility requirements). This workflow is very convenient and saved me a lot of time early on, but over time I realized it was trade-off in terms of speed, portability, and control over individual steps of the process.

Earlier this year, I had already ported a specific variable font generation workflow from Batch to ufo2ft and fontmake while working on the production of Elementar 2. That worked quite well and gave me confidence to move the main variable font generation code to a pure Python pipeline too. This change, in turn, required me to check and update all font sources to make them pass the stricter compatibility requirements of the conversion with cu2qu. This was done in 1-2 days of work with the help of a simple visualization script – a slow and manual process which I found very enjoyable, and which gave me precious insights into the letter shapes of each typeface.

The main advantage of the new workflow comes in the form of speed, both in terms of processing speed (quicker font generation) and in general work speed (I can work in RoboFont while the fonts are being generated in the background). It also opens up the possibility to integrate variable font generation into version control systems and automated build pipelines in the future.

A side effect of the new workflow is a noticeable change in rendering quality in the browser environment, with crisper rasterization at small sizes. This is likely due to different default settings in the gasp table. I was surprised to see that current browsers respect and use TrueType hinting instructions to some extent on MacOS. The new settings produce better results for single instances, but they also introduce x-height jumps on weight changes. More refined instructions will be needed to properly align design features across weights. Testing and hinting for Windows environments is planned for the Beta phase further down the line.

Switching to WOFF2 format

Another technical change worth mentioning is the switch from from WOFF to WOFF2 as the default packaging format for webfonts. I haven’t measured the gains in terms of kilobytes, but visitors of the Hipertipo Fonts website will notice significantly faster font loading times and a better experience overall.

The work continues… Keep an eye on this space for more news and updates!


Notes

  1. This is the same approach I’ve used in Elementar, minus the snapping to the pixel grid. 

  2. I like how coding fonts with reverse contrast make color coding patterns even more visible, and help to make the structure of code more abstract and easier to understand at a glance. 

  3. I am not sure about this second change. While monowidth weights allow for interesting typesetting effects, they also introduce a difference in behaviour between different fonts in the collection, going against the idea of having a common API or foundation for all fonts. At this time, 3 of 11 variable fonts have monowidth weights: Mechanica, Synthetica and Calligraphica. The megalomanic in me is tempted to add monowidth weights as an optional toggle to all fonts, with freely spaced weights as the default. This would require a considerable amount of work though, and there are several other more important tasks already waiting in the line. A more pragmatic and more probable route to standardization would be the removal of monowidth weights from the 3 fonts that have it, for an eventual return later as a global feature available in all fonts. 

  4. This tool’s output is somewhat similar to that of Autopsy