Out-of-date lists

I came across this question from Roel Nieskens a while back, asking:

Anybody maintaining a list of variable font bugs, quirks, workarounds and gotchas for the web?

He listed a few example issues, which is a great starting point:

• Opsz snap bug Safari
• Windows 10 botching metrics like MVAR
• HVAR table needed, even if unused for Chrome
• Defining italic/slant
• Etcetera?

The replies also included some offered partial, out-of-date lists, and links to browser bug trackers. Considering when I originally noted down this question, I’m sure the details of this list would have already changed.

So, the answer seems to be: no. There isn’t a single, consolidated list of bugs to think about, as you are making Variable Fonts.

This reminded me of the introduction of OpenType features via font-feature-settings to the web. Different browsers supported different features, but because all of them supported the top-level font-feature-settings property itself, it could be difficult to know if, say, a feature specific to Chinese, Japanese, and Korean fonts was as well supported as some Latin-centric features like standard ligatures.

The most comprehensive attempt to answer this question Bram Stein’s State of Web Type, which was excellent, but is no longer online.

It worked a lot like Caniuse: the majority of the data was manually maintained, except most of the responsibility fell to Bram.

Some of what Bram was hoping to test might not have been practical to automate at the time, and I know he had plenty of experience at this. But I am interested in learning from this example, as people will try and take on these kinds of projects again.

While Caniuse has some automated workflows for contributors, but the subject matter covers the entire spectrum of web development, and therefore has a much larger pool of potential contributors to draw from.

A database for a specific set of typesetting issues likely won’t be able to draw a critical mass of contributors. Regardless, even if something is able to attract a huge number of issue-submitters, the maintenance of the project will still fall to a single person.

For people implementing pushing what Variable Fonts can do on the web, something very similar to Caniuse or State of Web Type might be exactly what they are hoping to find: an easy-to-search database of potential bugs and issues, and links on how to fix them.

But maintaining a database like this is much easier said than done.

The information has to be largely reliable and up-to-date for the project to be valuable. Otherwise, if a bug is listed that isn’t a bug anymore, you’ll start to questions whether it can be trusted at all.

Thinking through the possibilities of how this could be solved made me think that Roel captured the best format in his original message: a list.

Collecting other’s articles, code repositories, etc. on the subject (whether that is “Variable Font bugs” or something else), can still be extremely valuable if it gets someone closer to solving the problem at hand, for a fraction of the effort of maintaining some kind of community-sourced or automatically tested database.

And the article collecting other articles is always going to be at least a little out of date, but in a way that is easy to understand.

Until next time,
Kenneth