Set win metrics to avoid clipping in MS Windows

[thundernixon]

#148 solved vertical metrics across macOS, but it probably shouldn't have matched win metrics exactly to the others.

Today I checked Inter in Windows (with VMWare), in part because FontBakery was warning that the winAscent and winDescent metrics were too low.

🔥 FAIL: Checking OS/2 usWinAscent & usWinDescent.
com.google.fonts/check/family/win_ascent_and_descent
🔥 FAIL OS/2.usWinAscent value should be equal or greater than 3072, but got 2728 instead [code: ascent]
🔥 FAIL OS/2.usWinDescent value should be equal or greater than 764, but got 680 instead [code: descent]

Sure enough, tall accents were clipping, even in a very recent version of Windows 10 and MS Word:

The somewhat-good news is, things are already working well in Edge:

The solution?

I followed FontBakery's advice and set winAscent to 3072 and winDescent to 764. I left all other metrics as they were in the prior metrics PR.

I worried that changing winAscent and winDescent might regress things on macOS, but as far as a test in Sketch shows, things are still working well.

The remaining problem

Even though the win metrics haven't been changed that drastically, MS Word is now display it with a massive line height. Here's at line spacing of 1:

Compared to other fonts at the same settings, it becomes apparent how big the line height is with this change. Here's Segoe UI:

Things to test:

• Moving ascender & descender values back to their natural heights, but leaving the alignment zones as-is. Hopefully this will still keep things working on mac, but also make things more normal on Windows. ––– RESULT: still works fine on mac, but keeps extreme line height in MS Word
• try Marc's recommended v metrics once more, but with the high and low alignment zones added in Vertical metrics patch 3 #148
• Maybe this could be an unexpected result of the uncommon UPM? If other options fail, it might be worth scaling the UPM and trying out the result in Windows.

[thundernixon]

After some further exploration and reading on vertical metrics, I've come to the conclusion that the current settings are fine, and diacritics are simply cursed in MS Word. Inter isn't the only typeface that MS Word clips.

Roboto Clips badly:

IBM Plex Sans clips less badly, in part due to its condensed accents as well as its slightly-taller metrics:

On MS Word for Mac, SF Pro Text also gets clipped (as do Roboto & Plex):

Segoe UI, not surprisingly, does manage to avoid clipping. However, its bounding box is very large on top, and as a result, its bounding boxes are pretty bad on Mac (with poor vertical centering):

Conclusion on vertical metrics

As previously mentioned, text doesn't appear to clip in MS Edge. Here are Plex (left) and Roboto (right) in basic buttons, neither of which are clipping:

The vertical metrics in Inter v3.5 (not in this PR) are set to prioritize vertical centering and consistency in UI, rather than an extensive usage in MS Word documents. Because it is close to the conventions of SF and Roboto, I think it's a safe assumption that what is working well across Mac apps and browsers will work well on iOS and Android, as well.

Even in MS Word, it's probably more important to more writers that the general expectations of line height are respected than that clipping is 100% avoided in diacritics. I wish that MS Word didn't make it a choice, but here we are.

I'm closing this PR, as I no longer believe we should change things for MS Word.

[chrissimpkins]

@thundernixon here is what I am seeing in MS Word on Win10 at 72pt with single spacing:

[thundernixon]

Hey @chrissimpkins, thanks so much for helping to confirm that! It can be hard to tell for sure when fonts have or have not updated on Windows.

[chrissimpkins]

No worries at all. Happy to help!