I’m also wondering how to add an HVAR table? Is there a custom parameter or is it on your roadmap?
It’s required by Google Fonts, but their rationale for it seems to be potentially applicable much more widely than just in their ecosystem. Fontbakery points to the OpenType spec’s recommendation that all variable fonts should have an HVAR table because some platforms will need to make costly calculations without it.
HVAR is not necessary for TTFs. For TTFs, the horizontal metrics are stored in the glyf table already, and its variation in gvar.
There can be a tiny performance advantage with an HVAR table. But it usually contains value for the width (this is the useful part) but also values for the LSB. Relying on the variable LSB is bad and can lead to quite bad spacing (I can explain that in more detail if needed). So I’m reluctant to add the HVAR table.
But are google fonts not always build with fontMake? It will add HVAR.
If you use the builder from google fonts it will add an HVAR table.
Takes some time getting used to the thing, but so far I was quite happy with the results.
@GeorgSeifert @mekkablue It would definitely be helpful to know more details about the performance advantages of having an HVAR table. I haven’t been able to find any discussions or documentation as far as what systems can benefit from HVAR and in what scenarios the performance boost would be significant.
I’m not working on a project for Google Fonts, but this stemmed from a font family I’m working on where I was asked to run a variety of Fontbakery profiles to look for errors and potential improvements. Also, my project contains many GlyphsApp proprietary features like corner components so I cannot use fontmake. Is there a way to feed a .ttf into fontmake to build an HVAR table and then patch it into the font somehow?
About the performance implications, you might get some answers on typedrawers.com
You can try to run your font through fontMake anyway and then use ttx to put the HVAR table in your font.