Vertical metrics in variable font

I’m aware that Glyphs not supporting MVAR for variable vertical metrics, but I’m wondering if they shouldn’t be same between the exported instances and the exported variable file?
I have tried adding the variable as an instance and even adding the custom parameters there, but there is a very notable difference between variable and other static cuts. Is there any way to fix this?

What vertical metrics are you talking about exactly? Can you inspect/compare the exported static and variable fonts in an application like OTMaster, fontgauntlet.com, Font Goggles or fontdev.app? What differences are there?

The variable font will get the vertical metrics of the default master. Static instance will get the interpolated values from the masters. So if the masters have different vertical metrics, most static instances will differ from the variable font.

Hey guys, thanks for your answers.
I guess I have to explain it a bit better. So in this example(see screenshots) I have a 5 master font with 2 axes. All masters have a defined vertical metrics in the custom parameters. All instances look good, both OTFs and WOFFs. The problem comes when I export it as a variable font, then it seems to be jumping up, within the defined metrics actually. Any idea why this happens? It seems to be happening with all our fonts.


I don’t quite understand what I’m seeing in the screenshots.

Why do you have differing vertical metrics between typo and hhea? They need to be the same. The vertical metrics should also be the same in all masters.

What I’m trying to show here is the difference between a static instance and variable font, and how the font sits within the the boxes, like I explained, not sure what’s so hard to understand about that. Also, I’m no specialist on vertical metrics, but this is how I learned it and looking at many examples I can see that it’s not always the same. I also never said that the vertical metrics was not the same in all masters, because they are.

Maybe I can’t see where it is written, but which parts of the screenshots show the variable font, and which the static font? Or are they all of the variable font?

Hmm, this is getting weird. Not sure it’s this complicated to understand?. One is static instance, and one is variable. It’s actually not written on thescreenshots, but I’ve explained it few times now that the static is alright and the variable is not. And in one screenshot it’s sitting on the baseline, that’s static. In the other one it’s not on the baseline, which is the variable font, which I’m having troubles with.

So the first line shows the variable font for the first two, and the third one it’s the other way around (variable font on the bottom)? This is why I’m confused.

If you want, you can send me your exported font and/or your Glyphs file in a private message and I can have a look at what might be causing the issue.

No they don’t. If you have a different x-Height by design (for example), you usually would want the metrics to reflect that.

I also don’t think the request is hard to understand. Georg already said that (at the moment) the variable font will differ from the static instances.

And: my +1 for the quicker implementation of MVAR to make that possible. The variable fonts should not differ in any way from the static ones.

I should have specified that I only meant ascender and descender. In any case, the vertical metrics are identical in all masters, as Guðmundur pointed out.

Maybe I’m misunderstanding the issue here. The default master has the correct vertical metrics, which are identical in all masters, so all static exports should have exactly the same vertical metrics as the variable font. What does MVAR have to do with this?

In case you have different metrics like x-Height, then with MVAR you can reflect that in the variable font.

Do you set the “Use Typo Metrics” custom parameter? (I believe the default behaviour of Glyphs for this setting has recently changed)

Do both export formats have a STAT table?

And what tool/website do your screenshots come from?

Ah, I think I’ve seen this site before: https://vertical-metrics.netlify.app

I wouldn’t trust it. I get a wrong display even with OTFs:

Your fonts may actually be OK and identical.

I can see that there is a similar problem here in this thread from 2021: Different vertical metrics on a static OTF and a Variable font in Glyphs 3
I’ve tried to have “Use Typo Metrics: false” in the variable instance only and that seems to do the trick. But I still don’t understand why :upside_down_face:

Use typo metrics is a setting that is supposed to tell apps to not use the win values for linespacing, but hhea/typo values. In modern fonts it always has to be on. The win values are now only intended for clipping.

  • Make sure your hhea and typo values are in sync, and reflect how you want vertical spacing done in your font. Some apps will use hhea, some will use typo values, so they have to be the same.
  • Make sure your win values encompass the highest and lowest glyphs (at least those that you don’t want clipped).
  • Make sure the custom parameters are set in all of the masters in Font Info > Masters.

The Vertical Metrics Manager script can help you with that.

Verify the values with a tool like OTMaster, FontTableViewer or ttx. If the values check out fine, but an app does not seem to stick to them, you have likely found a bug in the app. Breaking your font to make it work in one buggy app is a bad idea because it may break it in others.

In which exact app do you have issues with variable fonts?

Hi Rainer, thank you for your answer. We have now understood the problem clearly. The reason was that hhea and typo where not in sync. Then when exporting the variable font it had “Use Typo metrics” and was “jumping up” compared to the static fonts we where replacing on our website. I’m sorry about mixing Vertial Metrics Netlify app into this, I just thought it would illustrate the problem we were having.

It think this is a fantastic summary (or “tldr”) for the Vertical Metrics Article. I have just recently read the full thing again, and would love if this quoted bit would be added there at the bottom or so :slight_smile: