Vertical Metrics

[vv-monsalve]

As we agreed in the last meeting, I revised the vertical metrics after the resizing (lang-build branch at commit bf1024c). I've tested the following new values for the variable vertical metrics.

Please apply them before the next build of the fonts for each country so we can check how they will work for each model, and see if that solves the current Fail reported regarding vertical metrics for all of them.

Metrics         |  Short  |  Long   |
                | Masters | Masters |
----------------|---------|---------|
sTypoAscender   |   1275  |   2040  |
sTypoDescender  |   -375  |  -1020  |
sTypoLinegap    |      0  |      0  |
hhea Ascender   |   1275  |   2040  |
hhea Descender  |   -375  |  -1020  |
hhea Linegap    |      0  |      0  |
winAscent       |   1313  |   2040  |
winDescent      |    400  |   1020  |

Comparative images

old = Vertical metrics saw at the meeting || new = proposed values (you can click on the image to enlarge it)

[vv-monsalve]

There are now a couple of Fails reported for Vertical Metrics.

🔥 FAIL: Checking OS/2 usWinAscent & usWinDescent. (com.google.fonts/check/family/win_ascent_and_descent)

> >A font's winAscent and winDescent values should be greater than or equal to the head table's yMax, abs(yMin) values. If they are less than these values, clipping can occur on Windows platforms (https://github.com/RedHatBrand/Overpass/issues/33). > >If the font includes tall/deep writing systems such as Arabic or Devanagari, the winAscent and winDescent can be greater than the yMax and absolute yMin values to accommodate vowel marks. > >When the 'win' Metrics are significantly greater than the UPM, the linespacing can appear too loose. To counteract this, enabling the OS/2 fsSelection bit 7 (Use_Typo_Metrics), will force Windows to use the OS/2 'typo' values instead. This means the font developer can control the linespacing with the 'typo' values, whilst avoiding clipping by setting the 'win' values to values greater than the yMax and absolute yMin. > * 🔥 **FAIL** OS/2.usWinAscent value should be equal or greater than 1348, but got 1313 instead [code: ascent] * 🔥 **FAIL** OS/2.usWinDescent value should be equal or greater than 626, but got 400 instead [code: descent]

However, the expected WinDescent value is based on a _circle glyph that doesn't seem to be used in any font (doesn't look like a component on another glyph in the source file either), so this could be a bad expectation. @josescaglione, is this glyph necessary, or could it be removed?

As for the WinAscent, it is related to the Abrevehookabove glyph. I'll need to investigate and test some new values since the current ones already consider the extreme point of that glyph for the extreme masters.

[vv-monsalve]

This Fail is reported for all the single wght axis variable fonts. It looks like something produced by varLib instancer.

🔥 FAIL: Checking OS/2 Metrics match hhea Metrics. (com.google.fonts/check/os2_metrics_match_hhea)

> >OS/2 and hhea vertical metric values should match. This will produce the same linespacing on Mac, GNU+Linux and Windows. > >- Mac OS X uses the hhea values. - Windows uses OS/2 or Win, depending on the OS or fsSelection bit value. > >When OS/2 and hhea vertical metrics match, the same linespacing results on macOS, GNU+Linux and Windows. Note that fixing this issue in a previously released font may cause reflow in user documents and unhappy users. > * 🔥 **FAIL** OS/2 sTypoAscender (1508) and hhea ascent (1275) must be equal. [code: ascender]

List of reports including the fail

- qaPlaypen/FB-reports-ea9393d/qaPlaypen-ARG-vf.md - qaPlaypen/FB-reports-ea9393d/qaPlaypen-AUS-NSW-vf.md - qaPlaypen/FB-reports-ea9393d/qaPlaypen-AUS-QLD-vf.md - qaPlaypen/FB-reports-ea9393d/qaPlaypen-AUS-SA-vf.md - qaPlaypen/FB-reports-ea9393d/qaPlaypen-AUS-TAS-vf.md - qaPlaypen/FB-reports-ea9393d/qaPlaypen-AUS-VIC-vf.md - qaPlaypen/FB-reports-ea9393d/qaPlaypen-BEL-VLG-vf.md - qaPlaypen/FB-reports-ea9393d/qaPlaypen-BEL-WAL-vf.md - qaPlaypen/FB-reports-ea9393d/qaPlaypen-BRA-vf.md - qaPlaypen/FB-reports-ea9393d/qaPlaypen-CAN-vf.md - qaPlaypen/FB-reports-ea9393d/qaPlaypen-CHI-vf.md - qaPlaypen/FB-reports-ea9393d/qaPlaypen-COL-vf.md - qaPlaypen/FB-reports-ea9393d/qaPlaypen-CUB-vf.md - qaPlaypen/FB-reports-ea9393d/qaPlaypen-CZE-vf.md - qaPlaypen/FB-reports-ea9393d/qaPlaypen-DEU-Gru-vf.md - qaPlaypen/FB-reports-ea9393d/qaPlaypen-DEU-LA-vf.md - qaPlaypen/FB-reports-ea9393d/qaPlaypen-DEU-SAS-vf.md - qaPlaypen/FB-reports-ea9393d/qaPlaypen-DEU-VA-vf.md - qaPlaypen/FB-reports-ea9393d/qaPlaypen-ESP-OrnateUC-vf.md - qaPlaypen/FB-reports-ea9393d/qaPlaypen-ESP-vf.md - qaPlaypen/FB-reports-ea9393d/qaPlaypen-FRA-Mod-vf.md - qaPlaypen/FB-reports-ea9393d/qaPlaypen-FRA-Tra-vf.md - qaPlaypen/FB-reports-ea9393d/qaPlaypen-HRV-Lefthand-vf.md - qaPlaypen/FB-reports-ea9393d/qaPlaypen-HRV-vf.md - qaPlaypen/FB-reports-ea9393d/qaPlaypen-IDN-vf.md - qaPlaypen/FB-reports-ea9393d/qaPlaypen-IRL-vf.md - qaPlaypen/FB-reports-ea9393d/qaPlaypen-ITA-Tra-vf.md - qaPlaypen/FB-reports-ea9393d/qaPlaypen-MEX-vf.md - qaPlaypen/FB-reports-ea9393d/qaPlaypen-NLD-vf.md - qaPlaypen/FB-reports-ea9393d/qaPlaypen-NOR-vf.md - qaPlaypen/FB-reports-ea9393d/qaPlaypen-NZL-vf.md - qaPlaypen/FB-reports-ea9393d/qaPlaypen-PER-vf.md - qaPlaypen/FB-reports-ea9393d/qaPlaypen-POL-vf.md - qaPlaypen/FB-reports-ea9393d/qaPlaypen-POR-vf.md - qaPlaypen/FB-reports-ea9393d/qaPlaypen-SVK-vf.md - qaPlaypen/FB-reports-ea9393d/qaPlaypen-USA-Mod-vf.md - qaPlaypen/FB-reports-ea9393d/qaPlaypen-USA-Tra-vf.md - qaPlaypen/FB-reports-ea9393d/qaPlaypen-VNM-vf.md - qaPlaypen/FB-reports-ea9393d/qaPlaypen-ZAF-vf.md

[josescaglione]

@vv-monsalve any more news regarding this error? Looks like VarLib instancer is not interpolating the hhea correctly. It would be ideal to have this fixed.

[vv-monsalve]

@josescaglione Yes, We saw that in a previous meeting, and I have that under my radar to go back to this after the rendering / visual round of checks. Which is why I haven't reported back about it yet.

[vv-monsalve]

🔥 FAIL: Checking OS/2 usWinAscent & usWinDescent. (com.google.fonts/check/family/win_ascent_and_descent)

@casasin This fail is solved by changing the win metrics to 1348 for the "short" masters.

[vv-monsalve]

This Fail is reported for all the single wght axis variable fonts. It looks like something produced by varLib instancer.

I've opened an issue for this in fonttools.

[casasin]

Changed win metrics is cac910fdb (ARG and COL wght variables)

[vv-monsalve]

A new Fail is reported related to VM.

🔥 FAIL: Check font follows the Google Fonts vertical metric schema (com.google.fonts/check/vertical_metrics)

> >This check generally enforces Google Fonts’ vertical metrics specifications. In particular: * lineGap must be 0 * Sum of hhea ascender + abs(descender) + linegap must be between 120% and 200% of UPM * Warning if sum is over 150% of UPM > >The threshold levels 150% (WARN) and 200% (FAIL) are somewhat arbitrarily chosen and may hint at a glaring mistake in the metrics calculations or UPM settings. > >Our documentation includes further information: https://github.com/googlefonts/gf-docs/tree/main/VerticalMetrics > * 🔥 **FAIL** The sum of hhea.ascender + abs(hhea.descender) + hhea.lineGap is 2079 when it should be at most 2000 [code: bad-hhea-range]

This is reported as a Fail for the ARG and the NLD model. And has a Warn status for many other models. The current VM values were settled to find a compromise between the standard accented Latin letters and Vietnamese stacked marks needs.

@josescaglione Below are images for other models with assorted values for the YEXT values. Please review them to determine if you want to decrease the Ascender values.

ARG

YEXT = 565

ISL

YEXT = 375

DEU Grundschrift

YEXT = 420

NLD

YEXT = 773

IDN

YEXT = 938

[josescaglione]

@vv-monsalve yes, based on the resizing we did to match Playpen Sans we are bound to end up above the 2000 threshold, hence triggering those Fails in some fonts. Right now we are working with the values you suggested, which are great IMO. If we tighten the vMetrics we will end up cropping Vietnamese accents.

Do we know what the implications of those FAILs actually mean in practical terms?

[vv-monsalve]

Right now we are working with the values you suggested, which are great IMO. If we tighten the vMetrics we will end up cropping Vietnamese accents.

@josescaglione Indeed, given the values I suggested were taken from the Master's values, we still needed to see how they would translate to each model. I also see them looking good; however, it was key to have your confirmation on how you see them concerning the font models, so I'm glad to hear you find them okay :)

Do we know what the implications of those FAILs actually mean in practical terms?

AFAIK we've established those limits based on "standard" font proportions to avoid previous cases of visually buggy vertical metrics, but not after a technical complication under any environment. I'll double-check in any case.

[josescaglione]

@vv-monsalve I am sorry to be bearing bad news. We encountered an issue when laying out the FR_Trad specimen. I fear there is a cropping in INDD. Please see the attached.

This only seems to be visible in the regular weight for the time being. It shows in INDD and it exports cropped as well.

[vv-monsalve]

Thanks, @josescaglione, for the report. This is significant news since this would modify the value of the long masters, and that will impact all the fonts. I'll perform some tests on my end and come back here afterward with added thoughts.

[josescaglione]

hi @vv-monsalve after a few additional tests we were unable to replicate the error and the fonts are working correctly. I apologize for not closing the issue again.

[josescaglione]

Closing it now

[vv-monsalve]

@josescaglione I've tested the font again on InDesign and I'm not seeing any clipping indeed.