Box drawing characters contain gaps when viewed in Windows Terminal

[riverar]

Windows Terminal version

1.15.3466.0

Windows build number

22000.739

Other Software

No response

Steps to reproduce

repro.zip

1. Expand repro.zip to a temporary location
2. Execute target/debug/app.exe in a Terminal window
3. Observe results

Alternative, you can compile from the included sources.

See also: gyscos/cursive#709

Expected Behavior

Unbroken box drawing characters.

Figure 1 - Screenshot of expected appearance

Actual Behavior

Figure 2 - Example showing gaps (Cascadia Mono font family, default)

[zadjii-msft]

Pretty sure this is #7158 ...............

Hmm. Maybe I'm not so sure about this. I know that line drawing still isn't perfect in the Atlas engine, but I thought it was fine in the DX engine. Since you're on 1.15, I can be sure this is a DX bug, since atlas isn't on that build.

Previously:

• Vertical joining of box drawing characters has gaps #3029
• Remember to have block and line drawing characters fill their cells properly #455
• Block graphics and line drawing characters not rendered with AtlasEgine #14080 (for an Atlas riff on this).

It's like it's only the top corners though... the rest all seem fine. I wonder if this is a Cascadia Mono issue...

[riverar]

@zadjii-msft Doesn't seem confined to the corners after all.

Here's a new repro using the text characters from the window above.

      ┌──┤ Cursive ├──┐
      │ Hello Dialog! │ 
      │               │ 
      │  <Foo> <Quit> │ 
      └───────────────┘

DX yields

Atlas yields

[carlos-zamora]

Going to /dup this to #14098 and consolidate the two. I know that one is talking about the AtlasEngine, but it's all around the same area anyways.

[carlos-zamora]

/dup #14098

[ghost]

Hi! We've identified this issue as a duplicate of another one that already exists on this Issue Tracker. This specific instance is being closed in favor of tracking the concern over on the referenced thread. Thanks for your report!

[riverar]

@carlos-zamora Sounds good. My only concern is that the linked issue does not track the regression in the production engine and that experimental engine work could get deprioritized.

[DHowett]

Ah, interesting. In which version of Terminal did this work?

The production engine in Terminal has always been DX, whereas in the vintage console host it's (always) been GDI. We've been struggling against issues like this one for a while, admittedly, so I have lost track of whether this case used to work with the DX engine.

[riverar]

Here you go. v1.9.1445.0...v1.9.1942.0

1.6.10571.0

1.8.1444.0

1.9.1445.0

1.9.1942.0

1.10.1933.0

1.11.2421.0

[riverar]

Seems to be isolated to Cascadia family font update that occurred in a7f2a8b. Contrary to what the commit msg says, the Cascadia Mono font was upgraded from 2102.025 to 2106.017.

Seems to still repro in 2111.01 as well.

[zadjii-msft]

Ooh, good observation. We might want to bring this up on the Cascadia Code repo then

[DHowett]

@riverar, thanks for the big dig on this :)

[riverar]

Adding a repro. note here as the question came up in another discussion on social media.

Does not repro. with experimental(?) AtlasEngine turned on.

Latest terminal 1.18.1462.0, Atlas=off

[lhecker]

Does not repro. with experimental(?) AtlasEngine turned on.

Mostly not experimental anymore starting with 1.18. 😅 It still has a small number of bugs and imperfections, but the intended functionality at least is probably pretty solid now. Our plan is to quickly but gradually make it the default text renderer in the upcoming versions.

[jackfranklin]

Hey,

I came across this issue today using the latest experimental terminal but with another font - in my case, IntelOne Mono.

These are screenshots of a Neovim floating window which uses these border characters. In Alacritty and WezTerm, they render as one border, but in Windows terminal there are gaps.

I am not sure if this is font-specific issue, but I thought I would raise it, given that other terminals on Windows seem to deal with this particular font OK.

[DHowett]

Thanks for the report! Just to confirm, you're using Windows Terminal 1.18 with the "New rendering engine" enabled in settings->rendering?

[jackfranklin]

Yep - and using the latest Terminal Preview. Let me know if I can provide more info for you. Thanks!

[lhecker]

@jackfranklin That's because those two terminals don't actually draw those glyphs from the font at all. They ship with their own built-in box drawing glyphs that are always pixel perfect.
You can find the setting for WezTerm here: https://wezfurlong.org/wezterm/config/lua/config/custom_block_glyphs.html
and for Alacritty here: https://github.com/alacritty/alacritty/blob/31fe27b237708ec5f18eee2b326c3efc112216bc/extra/man/alacritty.5.scd?plain=1#L221-L226

We intend to do the same too (#5897). Unfortunately, while I really want that feature, I personally won't have time to do this in the near-term (unless more people are suddenly interested in this of course; if anyone reads this and wants this as well: contributions are 1000% welcome 🙂).

[riverar]

Closing the loop here--now that Atlas Engine is almost the default now, this is working well.

[DHowett]

(Almost the default? Is there a way we can make it even more the-default?)

[riverar]

@DHowett I was trying to articulate that non-preview still allows for non-Atlas usage 😅.