Box drawing characters contain gaps when viewed in Windows Terminal #19191

Closed
opened 2026-01-31 06:36:22 +00:00 by claunia · 20 comments
Owner

Originally created by @riverar on GitHub (Jan 10, 2023).

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: https://github.com/gyscos/cursive/issues/709

Expected Behavior

Unbroken box drawing characters.

Figure 1 - Screenshot of expected appearance

image

Actual Behavior

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

image

Originally created by @riverar on GitHub (Jan 10, 2023). ### Windows Terminal version 1.15.3466.0 ### Windows build number 22000.739 ### Other Software _No response_ ### Steps to reproduce [repro.zip](https://github.com/microsoft/terminal/files/10378957/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: https://github.com/gyscos/cursive/issues/709 ### Expected Behavior Unbroken box drawing characters. Figure 1 - Screenshot of expected appearance ![image](https://user-images.githubusercontent.com/475132/211464570-dacc1f2e-77c5-4aa7-a571-b2d432cb5341.png) ### Actual Behavior Figure 2 - Example showing gaps (Cascadia Mono font family, default) ![image](https://user-images.githubusercontent.com/475132/211464627-954e7231-540e-449f-a5c9-1f14678297c7.png)
claunia added the Area-RenderingIssue-BugResolution-DuplicateProduct-Terminal labels 2026-01-31 06:36:22 +00:00
Author
Owner

@zadjii-msft commented on GitHub (Jan 10, 2023):

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:

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

@zadjii-msft commented on GitHub (Jan 10, 2023): 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: * #3029 * #455 * #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...
Author
Owner

@riverar commented on GitHub (Jan 10, 2023):

@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

image

Atlas yields

image

@riverar commented on GitHub (Jan 10, 2023): @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 ![image](https://user-images.githubusercontent.com/475132/211600095-9bac9059-681b-4473-9a67-8795a595084b.png) Atlas yields ![image](https://user-images.githubusercontent.com/475132/211600300-9837dd5d-0e81-47d2-87bd-de0143917653.png)
Author
Owner

@carlos-zamora commented on GitHub (Jan 18, 2023):

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 commented on GitHub (Jan 18, 2023): 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.
Author
Owner

@carlos-zamora commented on GitHub (Jan 18, 2023):

/dup #14098

@carlos-zamora commented on GitHub (Jan 18, 2023): /dup #14098
Author
Owner

@ghost commented on GitHub (Jan 18, 2023):

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!

@ghost commented on GitHub (Jan 18, 2023): 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!
Author
Owner

@riverar commented on GitHub (Jan 18, 2023):

@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.

@riverar commented on GitHub (Jan 18, 2023): @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.
Author
Owner

@DHowett commented on GitHub (Jan 18, 2023):

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.

@DHowett commented on GitHub (Jan 18, 2023): 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._
Author
Owner

@riverar commented on GitHub (Jan 19, 2023):

Here you go. https://github.com/microsoft/terminal/compare/v1.9.1445.0...v1.9.1942.0

1.6.10571.0
image

1.8.1444.0
image

1.9.1445.0
image

1.9.1942.0
image

1.10.1933.0
image

1.11.2421.0
image

@riverar commented on GitHub (Jan 19, 2023): Here you go. https://github.com/microsoft/terminal/compare/v1.9.1445.0...v1.9.1942.0 1.6.10571.0 ![image](https://user-images.githubusercontent.com/475132/213372480-b5462418-a8fd-4015-88fc-8b53ee55e4d8.png) 1.8.1444.0 ![image](https://user-images.githubusercontent.com/475132/213372995-7ef021de-7610-438f-b174-e9ad1fdcdd47.png) 1.9.1445.0 ![image](https://user-images.githubusercontent.com/475132/213373698-fc926695-32ff-4302-a81e-836fb832d0de.png) 1.9.1942.0 ![image](https://user-images.githubusercontent.com/475132/213373363-e3665c50-324f-40b5-ab5e-6f3ba2a2fd17.png) 1.10.1933.0 ![image](https://user-images.githubusercontent.com/475132/213373190-0606832a-6975-429b-ad6c-57e4ce5e13e0.png) 1.11.2421.0 ![image](https://user-images.githubusercontent.com/475132/213372763-e5fecb18-8b2d-4470-b222-69e0930a6d7d.png)
Author
Owner

@riverar commented on GitHub (Jan 19, 2023):

Seems to be isolated to Cascadia family font update that occurred in a7f2a8badd. 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.

@riverar commented on GitHub (Jan 19, 2023): Seems to be isolated to Cascadia family font update that occurred in a7f2a8baddfc664d2efde352c83c1aabc0cb958d. 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.
Author
Owner

@zadjii-msft commented on GitHub (Jan 19, 2023):

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

@zadjii-msft commented on GitHub (Jan 19, 2023): Ooh, good observation. We might want to bring this up on the Cascadia Code repo then
Author
Owner

@DHowett commented on GitHub (Jan 20, 2023):

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

@DHowett commented on GitHub (Jan 20, 2023): @riverar, thanks for the big dig on this :)
Author
Owner

@riverar commented on GitHub (Jul 17, 2023):

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
image

@riverar commented on GitHub (Jul 17, 2023): 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 ![image](https://github.com/microsoft/terminal/assets/475132/45d692fb-316f-42d7-842f-5644b75cff01)
Author
Owner

@lhecker commented on GitHub (Jul 17, 2023):

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.

@lhecker commented on GitHub (Jul 17, 2023): > 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.
Author
Owner

@jackfranklin commented on GitHub (Jul 17, 2023):

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.

in-wsl

alacritty

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.

@jackfranklin commented on GitHub (Jul 17, 2023): 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. ![in-wsl](https://github.com/microsoft/terminal/assets/193238/8b19cc6a-3cfb-46be-9c1e-63437318652d) ![alacritty](https://github.com/microsoft/terminal/assets/193238/44894ce1-6ae3-4418-bdfa-cbde3819e405) 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.
Author
Owner

@DHowett commented on GitHub (Jul 17, 2023):

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

@DHowett commented on GitHub (Jul 17, 2023): Thanks for the report! Just to confirm, you're using Windows Terminal 1.18 with the "New rendering engine" enabled in settings->rendering?
Author
Owner

@jackfranklin commented on GitHub (Jul 18, 2023):

rendering-setting

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

@jackfranklin commented on GitHub (Jul 18, 2023): ![rendering-setting](https://github.com/microsoft/terminal/assets/193238/5806735a-495e-40ab-aeb8-e7d289307b4a) Yep - and using the latest Terminal Preview. Let me know if I can provide more info for you. Thanks!
Author
Owner

@lhecker commented on GitHub (Jul 18, 2023):

@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: 31fe27b237/extra/man/alacritty.5.scd (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 🙂).

@lhecker commented on GitHub (Jul 18, 2023): @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 🙂).
Author
Owner

@riverar commented on GitHub (May 8, 2024):

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

image

@riverar commented on GitHub (May 8, 2024): Closing the loop here--now that Atlas Engine is _almost_ the default now, this is working well. ![image](https://github.com/microsoft/terminal/assets/475132/c0a19194-3f95-4b89-ab4f-5973cd4013cf)
Author
Owner

@DHowett commented on GitHub (May 8, 2024):

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

@DHowett commented on GitHub (May 8, 2024): (Almost the default? Is there a way we can make it even more the-default?)
Author
Owner

@riverar commented on GitHub (May 8, 2024):

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

@riverar commented on GitHub (May 8, 2024): @DHowett I was trying to articulate that non-preview still allows for non-Atlas usage 😅.
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/terminal#19191