Suggestion: Reduce Ascent and Descent values

[CrendKing]

Currently the font leaves large amount of space in between lines, making it unfriendly to terminal applications. I experimented a few different usWinAscent and usWinDescent values in OS/2 table and found smaller values could produce a better user experience. Here's some illustrations (all taken with exactly same font size 14, same application and same content):

usWinAscent: 854 (down from the current 1004)
usWinDescent: 354 (down from the current 454)

Original with 1004 / 454 values

Comparing to other popular monospace fonts I happen to have right now:

Fira Code (has offest ascent and descent values of -600 and -400 respectively, EM size 1950)

Go Mono (has offset -292 and 0, EM size 2048)

A pattern I'm seeing is, most fonts have significant negative offset on the ascent/descent values, but Inconsolata has positive. I'm not sure about the aesthetic side, but from practical side a more compact font allows more stuff to be displayed in one screen. Could be productivity boost.

---

Another difference you can see from the comparisons is that Inconsolata is quite smaller. So even within the cell Inconsolata contains more space than other fonts. If user wants to see the same size of the glyphs, they have to increase font size, which consequently introduces more ascent and descent spaces between lines. But we can discuss this in a different ticket.

---

Test environment:

OS: Windows 10
Inconsolata version: 3.001

[downwith]

I came across pretty much the same issue because the Nerd Font patcher also uses usWinAscent/Descent to determine line height. The Microsoft Typography documentation (https://docs.microsoft.com/en-us/typography/opentype/spec/os2#uswinascent) seems to regard this as a discouraged practice. If you look at the other ascent values like sTypoAscender/Descender and the HHea pair, they are much closer to the values you came up with (859 and -190). My terminal, which was using HHea all along, didn't have an issue until the Nerd Font patcher started using and mucking with the values.

I'm definitely no expert, so I'm not entirely sure why the Inconsolata Win values are larger and also not sure if its actually a font problem or a terminal (or Nerd Font patcher) problem, although the Microsoft documentation has me leaning toward the latter if anything. My best guess is they are supposed to be larger because this is the area the font is to be rastered in and isn't meant to be used for the displayed line height at all. But, that being said, if you take the typographic or hhea ascent/descent and plug it in for Win (flipping the descent to positive 190), it fixes everything for me, as one would expect.

[CrendKing]

According to my test, some applications (e.g. ConEmu) exclusively use usWin*, some (e.g. Visual Studio) exclusively use sTypo*. cmd.exe seems to use both in a weird way. Considering that the USE_TYPO_METRICS flag is on, they should use the latter, so those use usWin* are maybe not wrong but better to be updated.

On the font side, I checked the OS/2 table of some other fonts, some (e.g. Fira Code) do the exact same as you described (usWinAscent = sTypoAscender, usWinDescent = -sTypoDescender). I'm also not expert so I don't know if usWin* is supposed to be larger or not. But 859 / 190 values seem perfect.