Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
bavis-m opened this issue Sep 23, 2021 · 20 comments · Fixed by #587
Open

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

bavis-m opened this issue Sep 23, 2021 · 20 comments · Fixed by #587

Comments

@bavis-m
Copy link

bavis-m commented Sep 23, 2021

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:
image

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:
image

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

@aaronbell
Copy link
Collaborator

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.

DHowett pushed a commit that referenced this issue Oct 29, 2021
This is a fairly comprehensive (and spooky!) 🐛💀 update resolving many
open issues.

### Arabic bugfixes
- [x] Closes #532 👻 - Additional positional variants added
- [x] Closes #535 🍂 - Corrected hamza form
- [x] Closes #540 🎃 - Dot arrangement corrected
- [x] Closes #541 🧹 - Was due to the use of anchors on those glyphs.
  These have been removed so the glyph can render as spacing.
- [x] Closes #542 🌕 - This was partly due to a [bug in Harfbuzz]. It
  has been resolved both on the font side (through a different
  implementation) and in Harfbuzz. 
- [x] Closes #549 🦸‍♀️ - Design corrected
- [x] Closes #555 💀 - All letter glyphs removed from Arabic
  Presentation form unicode slots to avoid situations where the glyphs
  are not behaving as expected.
- [x] Related to #543 - uni0615 removed as Cascadia Arabic not intended
  to support Quranic

### Other bug fixes
- [x] Closes #488 🔪 - Finally made the www ligature have the proper
  number of `w`s. 
- [x] Closes #436 🧟‍♀️ - Extended length of Powerline 'caps' to
  avoid situations where rounding can prevent overlap. This may cause
  problems if the caps are used next to one another, but that seems an
  unlikely scenario given what I've reviewed of Powerline styles. 
- [x] Closes #521 🤖 - enlarged the size of the grave character to make
  it more recognizable / legible in code. 
- [x] Closes #524 ☠️ - Added some more differentiation in stroke, and
  also created more space using hinting. 
- [x] Closes #525 🧙‍♂️ - tweaked the braces to be more twisty and
  create better differentiation from the parens. 
- [x] Closes #529 🧛‍♀️ - Changed year :P
- [x] Closes #546 👹 - ij no longer masquerading as a mark. 
- [x] Closes #563 🧟‍♂️ - corrected `locl` feature for proper
  Serbian rendering
- [x] Closes #571 🦹‍♀️ - corrected overshoot
- [x] Closes #572 🕷 - ratio symbol added
- [x] Closes #577 🍁 - shifted heights of box drawing lines to better
  align with block glyphs. Will reduce risk of non-joining forms under
  certain conditions. 

[bug in harfbuzz]: harfbuzz/harfbuzz#3069 (comment)
@albertus82
Copy link

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

image

Thanks.

@ChristianGfK
Copy link

ChristianGfK commented Dec 13, 2021

@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:
image

Cascadia Code Mono 2110.031 10 pt light:
image

Cascadia Code Mono 2110.031 12 pt regular:
image

@ChristianGfK
Copy link

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

@zadjii-msft
Copy link
Member

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
Copy link

riverar commented Feb 10, 2023

Ping, requesting re-open @DHowett

@riverar
Copy link

riverar commented Jun 1, 2023

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

@DHowett
Copy link
Member

DHowett commented Jun 2, 2023

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 DHowett reopened this Jun 2, 2023
@DHowett
Copy link
Member

DHowett commented Jun 3, 2023

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

image

Terminal:

image

@ChristianGfK
Copy link

ChristianGfK commented Jun 6, 2023

That is very strange indeed. I present:

Terminal Preview 1.18.1462.0, Cascadia Code 2111.001 Regular 12 pt
image

Putty 0.78, Cascadia Code 2111.001 Regular 12 pt
image

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

Uhhh...

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

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
Copy link

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
Copy link
Collaborator

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
Copy link
Collaborator

@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
Copy link

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

@aaronbell
Copy link
Collaborator

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

@ChristianGfK
Copy link

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

@DHowett
Copy link
Member

DHowett commented Jun 6, 2023

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

@riverar
Copy link

riverar commented Jun 6, 2023

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
Copy link

riverar commented Jun 30, 2023

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

@riverar
Copy link

riverar commented Jul 17, 2023

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

7 participants