The automated creation of variable fonts from elementary fonts

Ray Larabie

This is a spinoff from a thread about variable fonts on the web.

I suggested it was economically unfeasible to turn existing non-variable fonts into variable fonts and suggested an idea for a tool.

Absolutely. Once the staple typefaces have VF versions, demand will go up. A system which would let foundries reverse engineer existing families into VF could accelerate this process. I don't expect a tool where you can feed it a bunch of styles and it burps out a perfectly fucntional VF with no extra work, but specialized software could make it economically feasible to create variable versions of existing typefaces. Currently, for me, transdforming existing typefaces into VF makes no economic sense.
Even for my typefaces where MM masters exist, creating a VF from them with currently available tools is daunting. My typical MM-to-instances process involves manual tweaking and cleanup of intermediate weights. For example, if the crossbar on the "e" looks correct in UltraLight and Black but too light in medium, I manually tweak it rather than devise a interpolation solution. Since the masters are essentially disposable, it was the most practical way to get the job done. There are countless little edits for intermediate weights. Sometimes if my idea for the heaviest weight didn't fit the interpolation plan, I'd create a custom font that's outside of the axis range. Often when I add extra characters such as new monetary symbols to a MM typeface that has already been expanded, it'as quicker to use the blend tool and manually clean them up than bother updating the MM. With the ideal, specialized reverse engineering tool, I think it would be viable to turn these familes into VF in a way that makes business sense. With current tools, it would be foolish to attempt.

@Simon Cozens replied

OK, I'm interested in this. I'm potentially interested in building this. Because I don't think it would actually be that difficult. (Bear in mind, I am (a) usually wildly optimistic and (b) not a very good designer.)
One of my assumptions is that in discussions like this we tend to wonder whether such a tool would do the right thing for the most difficult of cases, but actually maybe 80% of cases are simple. Sure, there are two- or three-axis fonts with lots of manual tweaking going on, but equally there are a lot of single-axis fonts with minimal (if any) tweaking. So, what if we handle the 80% case and accept that complicated fonts are going to require manual handling?
It should be fairly easy to build a tool which can evaluate what degree of tweaking has gone on: take input of a bunch of styles, examine two or three masters far away from one another, compute the interpolations and see if the interpolated glyphs differ from the instance glyphs, and if so, by how much. I imagine that for the vast majority of glyphs in the vast majority of fonts, they wouldn't differ at all.
The tool then finds a minimal set of masters which globally minimises the differences, marks up the glyphs which interpolate perfectly and don't need to be tweaked, and then warns you with differing colours in your font editor about glyphs which require checking. It could even create the interpolation layers (bracket/brace layers) for those glyphs for you.

...and asked

Would that be the "specialized reverse engineering tool" you're talking about?

Precisely. I think a critical feature would be dealing with the automatic substitutions which occur when shapes can't be interpolated. The most common example is how a Q loses its internal tail when it gets fat. Or course, the designer would have to do some preliminary work. I don't think there's a way to reliably automate that. An alternate version of the Q to be substituted would need to exist in the source fonts. I could see the workflow for this situation going like this:

The tool indicates that the Q can't be interpolated. The designer adds an alternate Q to all of the original fonts. One version has an internal tail, the other does not. The user runs the tool again and can specify at which point along the axis the substitution will occur.

I think you can't do too much hand-holding in terms of start points and number of nodes. The user will have to make some changes to the source fonts. For something like an Ø, they would likely want to separate the O and slash elements but if the majority of the rest of the work were automated, those minor adjustments wouldn't be much of a burden.

Then we have the substitutions for minor variances that are technically interpolable but stray from the original glyphs when interpolated. For example, the lowercase "e" crossbar in medium weights that I mentioned in the other thread. If the tool, as you suggested, can create substitutions for these it creates an interesting possibility which would otherwise be very impractical using current tools. Imagine you have a client who has been using your custom typeface for a long time. They want a variable font and file size is no problem because they don't intend to use it on the web. The client's top priority is that the variable font behaves exactly like the non-variable version. The user could use this tool and be really fussy about the bias settings which might generate hundreds of substitutions. It would be inefficient but the end result would be a variable font that behaves exactly like the original fonts.

Craig Eliason

What @Simon Cozens describes there reminds me a bit of what @John Hudson said in this comment to an older thread of mine (re: automating a comparison between hand-done glyphs and the interpolated results at those coordinates). FWIW

Peter Constable

Ray Larabie said:

... I think a critical feature would be dealing with the automatic substitutions which occur when shapes can't be interpolated. The most common example is how a Q loses its internal tail when it gets fat. Or course, the designer would have to do some preliminary work. I don't think there's a way to reliably automate that. An alternate version of the Q to be substituted would need to exist in the source fonts. I could see the workflow for this situation going like this:

The tool indicates that the Q can't be interpolated. ...

Or the tool says the Q can only be interpolated for a certain range of weights. Then maybe notes that a complementary range of weights has a Q that can only be interpolated across that range of weights. Then confirms they are a complementary set, confirms which range includes the default instance, and advises that it will extrapolate each Q variant to the entire range but that a substitution will be set up so that they behave as a complementary pair.

Ray Larabie

@Peter Constable
That makes sense to me. The result with that technique should be better than manually creating those targets since we have the original fonts as a guide. We know already know what the results of the interpolation will be so the extrapolation will be correct. It doesn't matter what those extrapolations look like since they'll never be seen by the user.

Peter Constable

Ray Larabie said:

It doesn't matter what those extrapolations look like since they'll never be seen by the user.

Just so.

Dave Crossland

Simon, I'll be happy to commission you to make this tool next year. In 2018 and 2019 I've commissioned dozens of weight (and a few width and slant) axis upgrades to popular static font families in Google Fonts, and having better semi-automated tools for this would be welcome as that programme continues to harvest the 'compress' benefit of variable fonts.

If you're self-hosting a few static fonts on a little zero-million-views blog, that compress benefit won't matter, but when you're serving the world's most used typefaces, it all adds up

I probably won't be able to help organize you to talk about it at ATypI next year though, as a new father I don't have enough time for these fun things, so you're on your own for that

I'm really looking forward to seeing the reception to many upcoming expressive variable fonts, that have been developed privately in the past few years.

I hope this tool will encourage more people to upgrade their back catalog to weight/width axes and then add more expressive axes too - especially as more and more design apps implement better and better VF support - when they see how useful expressive axes are, and how much better a post-vf design workflow is.