Inter-line height is not the same as it used to be. (2.002 vs 1.013)

[fearthecowboy]

(apologies for not knowing the 'font-terminology'... )

I recently downloaded a new version of Inconsolata and it has some significant changes from the previous:

There is a ton of extra whitespace in there... it doesn't feel right anymore 😢

Is that what you intended?

[davelab6]

Where (what programs/OS) are you seeing that?

[fearthecowboy]

Windows 10 (the built-in font viewer),

after installing the new version of the font, my console windows seemed way out of whack, so I did some investigating.

[fearthecowboy]

Hmm. I think VSCode (which is electron-based) isn't doing the same thing...

Weird: the console window (which I made translucent) is rendering different than the vscode editor (behind, and fainter)

You can see they start off around the same, but they eventually end up different:

[fearthecowboy]

It feels like the console window is squishing the font when it renders

[fearthecowboy]

Hey @bitcrazed is it possible that the font renderer for the console window is doing something weird here?

I'd think I shouldn't see differences in the same font between VSCode and the console.

[fearthecowboy]

Both the Font Viewer and the console use GDI, which we may have run into a funny bug in the latest font.

[alexeiva]

Left: Inco 1 | Right: Inco 2

Regression test shows identical v-metrics

[alexeiva]

My guess is the renderer uses winAscent(1004) to calculate line-heights instead of typoAscender(859). winAscent is meant for preventing clipping in tall glyphs, while typoAscender should affect line-height.

[bitcrazed]

It's likely that GDI is calculating max height for a tall char because fixed width fonts are usually used in grid layouts (e.g. Console/terminal apps). Will check

[fearthecowboy]

@bitcrazed any progress on this?

[davelab6]

I'm going to close this as I assume the metrics are staying as they are now. Please re-open or file a new issue if this is still a problem for you :)