WinAscent value

[RosaWagner]

Fontbakery is reporting some eventual clipping:

🔥 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 1270, but got 1200 instead [code: ascent]

@dy do you see any concern in raising the winAscent value?

[dy]

I don't see that failure in fontbakery report. But it comes from "overflow" characters with values above 100. In other words - 0-9 characters, as well as a-Z characters map to 0..100 values (main range), therefore ascent/descent are set as -200..1200 to meet line-height=1.4. But extended latin range maps to 0..127 (with 27 values of overflow, useful for 0..127 programmatic values, like MIDI range or int type). If we increase ascent to match 0..127 range instead of 0..100, minimal line-height will become 1.54, which is too big for displaying waveform from 0..100 range.

Is that very critical to increase that value?

[dy]

To illustrate, ascent=1200 (lh=1.4):

with ascent=1270 (lh=1.54):

If we take wavefont with ascent 1270 (min lh=1.54) and reduce line-height via CSS to 1.4, it creates selection overlap:

Bigger ascent makes wavefont less responsive/usable.

[RosaWagner]

I may have a more recent version of Fontbakery. Are you talking of the ascent value from typo/hhea, or win? Cause you can keep typo/hheaAscen to 1200, and have winAscent at 1270 to avoid clipping.

Otherwise it's okay to make an exception for this project I think

[dy]

It may have same issue for windows machines I'm afraid. Would be nice to make an exception for this particular case, it's sensitive parameter here.

[chrissimpkins]

OK to use designer defined Win metrics in this project. Discussed with Rosalie today.