Note: GF may have an issue with the changed vertical metrics.
What you did makes sense to me (and others).
But GF is always concerned about re-flow from metrics changes.
Sometimes their solution is to change the name (e.g. from Source Serif to Source Serif 4)
The same issue is being discussed now regarding GF updating to Inter v4 from Inter v3.19.
Not a biggie, but just be aware it is going to come up.

thanks @kenmcd. I am aware and concerned about this as well. I actually changed the vertical metrics back to what is currently on GF. winAscent and winDescent match GF, it's hhea and typo ascenders and descenders that are different, to center the font. I believe there is GF documentation for this scenario (expanding/changing vertical metrics) somewhere but can't locate it at the moment. But it wouldn't surprised me if all they care about is win metrics.

But, maybe there needs to be a Barlow Neue for some reason, or it needs to keep unideal metrics, I don't know. If I changed the name I'd be able to change many other things that I would like to, if not for existing usage %s. Specifically the way the round letters interpolate from Regular width to Condensed

thanks @kenmcd. I am aware and concerned about this as well. I actually changed the vertical metrics back to what is currently on GF. winAscent and winDescent match GF, it's hhea and typo ascenders and descenders that are different, to center the font. I believe there is GF documentation for this scenario (expanding/changing vertical metrics) somewhere but can't locate it at the moment. But it wouldn't surprised me if all they care about is win metrics.

It's here now: https://googlefonts.github.io/gf-guide/metrics.html

Ah, here it is:

6. If the family is being updated, the line height must visually match the previous release.
   Some applications do not allow users to control the line height/leading of their fonts. Word processors and text editors are common culprits. It is essential their documents do not reflow.

I'll have to look into what that implies. I need to double check on winAscent and winDescent, too. If it's different by width it'll need to become the same

If I changed the name I'd be able to change many other things that I would like to, if not for existing usage %s. Specifically the way the round letters interpolate from Regular width to Condensed

I saw you mention that previously, and it caught my eye because it is something I need to deal with too (so was wondering how you are doing it in Glyphs).
I am converting an older well known font to variable and I have some inside rounded corners that I want to "get right" in the variations.
Some other updated versions dropped the rounded inside corners.
Don't want to do that.

Oh, that's a differerent interpolation - above, I meant the round-to-straight sides on letters like o and b

Regarding inner rounding, as far as I know, this is in its infancy as of Glyphs 3.2 stable. Rounding doesn't even work on variable fonts with brace layers yet. But, I plan on rounding whatever can be rounded by filter, and having different, compatible glyphs that get swapped in at certain designspace coordinates for those that will have issues. There's probably a better way, possibly using corner components instead of filters in some places

cc @simoncozens maybe? Apologies if you're the wrong contact for this / please reroute if appropriate - tagging because I saw you in a Barlow related issue not too long ago
I think the 1.5 branch (pre-VF bugfixes) is basically ready but I want to make sure GF is OK with the vertical metrics. Looking at what's available as a TTF download from GF, a few questions:

• winAscent and winDescent are different across condensed and regular width on GF now, it seems like. Is this OK? might not be OK thinking ahead to VF? Glyphs doesn't support variable metric tables yet
• Is it OK to vertically center the glyphs? Can I modify hhea and typo metrics (ascenders and decenders)?
• Does GF now require non-interactive builds and if so can that include a headless Glyphsapp build for filter-dependent font families? Or would a new requirement like that only apply to new families anyway?

Apologies if you're the wrong contact for this / please reroute if appropriate - tagging because I saw you in a Barlow related issue not too long ago

Yep, I'm interested and able to get the Barlow VF update onboarded to GF.

winAscent and winDescent are different across condensed and regular width on GF now, it seems like. Is this OK? might not be OK thinking ahead to VF? Glyphs doesn't support variable metric tables yet

I'm never 100% sure on what constitutes a vertical metrics regression but I have a feeling that winAscent and winDescent changing is fine.

Is it OK to vertically center the glyphs? Can I modify hhea and typo metrics (ascenders and decenders)?

This one is harder; we have another case like this (Overpass) where we need to decide if we are OK with this, as it will technically be a regression for some pages using it.

Does GF now require non-interactive builds

Yes

and if so can that include a headless Glyphsapp build for filter-dependent font families?

No. "Because of our commitment to Libre font culture, all Google Fonts projects must be built using a reproducible, libre toolchain. We do not onboard binaries exported from font editors."

One option would be to supply "dumb" production sources alongside the design sources; another would be for me to implement the filters in libre code. I'm more interested in the second...

Thanks @simoncozens !

This one is harder; we have another case like this (Overpass) where we need to decide if we are OK with this, as it will technically be a regression for some pages using it.

Got it. I will try to keep vertical metrics the same for now, then, and then some time after you've gone through this with Overpass / have a decision-making framework we can see what makes sense for Barlow. Are the TTFs downloadable from fonts.google.com the most reliable place to check vertical metrics as they exist in production today?

No. "Because of our commitment to Libre font culture, all Google Fonts projects must be built using a reproducible, libre toolchain. We do not onboard binaries exported from font editors."

It would make sense to me if fonts that have been editor dependent in the past can be grandfathered in, as there is no regression as a result (in fact if I added a non-interactive Glyphs build it would be an improvement), but also, sure, I get it.

One option would be to supply "dumb" production sources alongside the design sources; another would be for me to implement the filters in libre code. I'm more interested in the second...

That would be ideal (and awesome) to bring Glyphs filters into glyphsLib, but it's complex for a few reasons. While I would prefer to stay in Glyphs, I am not averse to moving Barlow to UFO if a UFO build is necessary, and I kind of think it might be: looking at it now, I'm not sure if the VF rounding filter Glyphs introduced in v3.2-stable can actually handle the case where glyphs that would become incompatible after removing overlap to run the negative rounding filter need to be swapped out with alternate glyphs at certain designspace coordinates (e.g. Ø at condensed vs regular width will have a different number of points). Which could mean it might not make sense to implement in glyphsLib... I've written to Georg to try to understand how the app itself allows (or doesn't) users to deal with the incompatible glyph thing

Because Barlow 1.5 (24 bug fixes for static fonts, not variable yet) doesn't depend on any of that, there will probably be a period of time where this repo is ahead of GF while the "how" of a non-Glyphs-based build gets sorted out

Of course, there's always

One option would be to supply "dumb" production sources alongside the design sources

🥲

Are the TTFs downloadable from fonts.google.com the most reliable place to check vertical metrics as they exist in production today?

Yep, and that's what fontbakery will check. Indeed, fontbakery check-googlefonts is the best way to check for vertical metrics regressions...

in fact if I added a non-interactive Glyphs build it would be an improvement

To do that reproducibly would mean installing a Glyphs license on a virtual machine runner, and urgh, it gets messy both technically and legally.

That would be ideal (and awesome) to bring Glyphs filters into glyphsLib, but it's complex for a few reasons.

I can look at the VF issues, but I can certainly see the need for a rounding filter - maybe not in glyphsLib, but in my babelfont which has better support for font filtering across masters.

A generalized rounding filter would be great. Even in the UFO ecosystem people generally use a proprietary tool (roundingUFO). I wasn't aware of babelfont, I'm going to have fun kicking its tires

The issue with Glyphs-native rounding on VF brace layers got fixed, but it's still not clear to me what Glyphs actually intends for people to do RE: swapping for compatible glyphs at the coordinate where they become incompatible in a VF, if that incompatibility is caused by a filter. To solve it manually (e.g. create that dumb production VF file), it would still require glyphsLib#800 to be addressed.