Thin vertical line box drawing character U+2502 does not fill the line height

[bavis-m]

Cascadia family version

2108.26

Cascadia family variant(s)

Cascadia Mono (the version without ligatures)

Font file format(s)

.ttf (variable)

Platform

Windows 10

Other Software

No response

What happened?

Some of the box drawing characters, such as U+2588, the full cell solid block, fill up the entire vertical line space:

However, I can't find a thin, centered, vertical line that does the same. U+2502, the centered thin vertical line character from the same box drawing set, doesn't do so:

This makes terminal UI look pretty awful (for instance, TMUX vertical splits):

[aaronbell]

Hmmm. Interestingly, 2502 is actually taller than 2588, but the height is arranged slightly differently. I suspect that your coding environment is clipping the bottom off of the glyph, causing it to not connect properly. I think I can shift the positioning of these to be more aligned with what you're looking for without causing regressions.

[albertus82]

Hello, I'm still experiencing this issue with v2110.31, Cascadia Code PL SemiBold, size 12, ClearType enabled:

Thanks.

[ChristianGfK]

@DHowett, can we reopen this? It seems this issue was not fixed by #587.
I'm seeing the same thing with the Unicode line drawing characters, on Windows 10, using PuTTY.
Additionally, the vertical lines seem to overlap a bit as well (see the bulges on the horizontal line).

Consolas 11 pt regular:

Cascadia Code Mono 2110.031 10 pt light:

Cascadia Code Mono 2110.031 12 pt regular:

[ChristianGfK]

Additionally, I guess this might be similar to:
#586
microsoft/terminal#11574

[zadjii-msft]

Hmm, this Terminal thread seems related: microsoft/terminal#14654

I haven't been following this repo as closely, so idk if this is the most up-to-date thread on the topic

[riverar]

Ping, requesting re-open @DHowett

[riverar]

Re-requesting re-open @DHowett @zadjii-msft

[DHowett]

I'm still not certain about this issue! When I look at this font in FontForge, this glyph for sure fills the entire cell height and then some.

Of the lines that extend across the entire image: the top horizontal line is the top of the bounding box. The one below it is the baseline, and the one below that is the bottom.

The glyph for sure extends beyond the bounds by more than a few design units.

Are we sure this is a font issue and not an application issue?

Regardless, until we figure that out.. sure, I'll keep this open.

[DHowett]

Furthermore... this is what I see for PuTTY 0.78 with Cascadia Code at the same size.

Terminal:

[ChristianGfK]

That is very strange indeed. I present:

Terminal Preview 1.18.1462.0, Cascadia Code 2111.001 Regular 12 pt

Putty 0.78, Cascadia Code 2111.001 Regular 12 pt

But while grabbing these I noticed that if you put them side by side:

Uhhh...

Adjusting the line height in Terminal to 1.3 almost makes them line up:

In any case, that half-answers "What is Putty doing differently?" (line height, apparently) and leaves "Why is Putty doing it differently?"

Spoilers: I'm not using OS-level scaling, i.e. "Settings -> Display -> Scale" is at 100%, screen resolution matches physical resolution of the display, "Settings -> Ease of Access -> Make everything bigger" is at 100%, so is "Make text bigger" in that same place.

[ChristianGfK]

Addendum: I hope this is not a case of https://www.chiark.greenend.org.uk/~sgtatham/putty/wishlist/typographical-metrics.html / googlefonts/Inconsolata#35 because then it would probably be a dead end.
Considering it works for @DHowett, there's a chance it's not related...

[aaronbell]

If I had to guess, Putty is getting the shorter sTypo versions of the lines but rendering using the larger winAscent/winDescent values. So it is falling through the cracks so-to-speak.

Many older software assumes the winAscent / winDescent values to be set tightly in coding fonts, but that isn’t the case for Cascadia.

[aaronbell]

@ChristianGfK ahh I just saw your links. Yes I believe it is the exact same problem. I put a “trick” in to try and get around the issue but it appears that Putty’s text render respects my trick but still locks to the larger metrics.

[ChristianGfK]

Alright, so that leaves this at "a future version of Putty might do this correctly" stage...
@DHowett, are you from the future?!

[aaronbell]

Might also be that @DHowett has his line heights set differently?

[ChristianGfK]

Line height is not configurable in Putty, yet, his Putty somehow Does It Right™.

[DHowett]

I'm quite surprised by that! I have no idea why. 😄

[riverar]

Let's please not get distracted by Putty. This is an issue that was introduced when Cascadia Mono font was upgraded from 2102.025 to 2106.017 and affects Windows Terminal too.

microsoft/terminal#14654
microsoft/terminal#11574
#586

[riverar]

@aaronbell @DHowett Any hope for progress here? Coming up on two years now.

[riverar]

This issue does not reproduce in Windows Terminal using the new Atlas engine, soon to become the default per conversation. Probably best we categorize this as "known issue in old engines" and move on.

[nscavalier]

will this be solved?

[aaronbell]

As I think I mentioned previously, this issue is due to different ways that text rendering engines display text—the font is not inherently built wrong.

A fix for the issue will require a breaking change to how vertical metrics work in the font. I plan to implement this fix in the next major version of the project.

[riverar]

@aaronbell As mentioned earlier, this was introduced in a newer font update. Is rolling back the change on the table? Or would that break other things?

[aaronbell]

@riverar it would, yes