Cascadia Code arrow segments not displaying correctly

[riverar]

Windows Terminal version

1.21.1272.0

Windows build number

10.0.26200.5001

Other Software

No response

Steps to reproduce

1. Create a text file on your desktop with the following content:

   Howdy! 🤠
   
   =>
   
   ==>
   
   ===>
   
   ====>
   
   =====>
   
   ======>
   
   =======>
   
   ========>
   
   =========>
   
   ==========>
   
   ===========>
   
   ============>
   
   =============>
   
   ==============>
   

2. Launch Terminal app

3. Display content in Terminal (e.g., Get-Content test.txt)

4. Observe arrow segments are not connected together cleanly

Expected Behavior

Arrows with cleanly connected segments (https://github.com/microsoft/cascadia-code/blob/main/images/arrow_support.png)

Actual Behavior

Arrows without cleanly joined segments

[github-actions]

Hi I'm an AI powered bot that finds similar issues based off the issue title.

Please view the issues below to see if they solve your problem, and if the issue describes your problem please consider closing this one and thumbs upping the other issue to help us prioritize it. Thank you!

Closed similar issues:

• Arrow ligature does not render consistently in Windows Terminal (#5158), similarity score: 0.80
• Terminal doesn't render light arc characters well (#6708), similarity score: 0.76
• Certain terminal characters not rendering correctly (#15934), similarity score: 0.76
• Box drawing characters contain gaps when viewed in Windows Terminal (#14654), similarity score: 0.75

Note: You can give me feedback by thumbs upping or thumbs downing this comment.

[DHowett]

Unfortunately, this is all down to how the font is designed. Even Chromium shows these overlap artifacts!

[riverar]

Note: This doesn't appear to occur at other sizes. Will open a bug on Cascadia, thanks @DHowett

[lhecker]

Ah, you're too fast! I was meaning to respond. 😅
I'm not sure whether the overlaps can be solved in the font at all. Maybe to a certain extent by having unique glyphs for every length of the ligature? ...but certainly not for the general case like above.

It is theoretically solvable in the text renderer. There are two approaches:

• Blend all glyphs in the viewport in pure grayscale together first, then colorize them cell-by-cell into the final image. This approach is simple but not particularly elegant and may not be very power efficient as it requires 3 passes instead of 1 (clear target, blend glyphs, blend glyphs with background). That's probably what we should try first and see how it performs. Maybe it's alright!
• Use a compute shader. This gives us complete freedom to use loops and branches per pixel. We could blend glyphs in a loop, then use branches to add underlines, flags to add selection overlays, etc. This is what I'd like to do, but it's probably something we should only try after the former, because compute shaders are only well supported by modern hardware.

I think it's fine for this issue to stay closed, but I think I'll finally open an issue for this idea. We may never get to it, but this does come up from time to time.

P.S.: If you open the settings.json file you can change the "cellWidth" in the "font" object. It supports basic CSS line-height units: 1.2, 120%, 1.2px, 1.2pt, 1.2ch.

[riverar]

I think we should identify what the Cascadia Code folks need to do to fix the font (linked issue above) rather than add workarounds to Terminal.

[DHowett]

It's not just Cascadia, and it's not just arrow ligatures. Lots of people have the opposite of the other experience you reported, where box drawing glyphs overlap and look bad. Yes, we could track down and fix every font. That would be prohibitively expensive in the long term.

There are always rasterization improvements that we could make.

Why not take a "yes, and" approach?

[riverar]

I'm okay with that, but you closed the issue blaming the font. So do we re-open this issue as an enhancement perhaps?

[DHowett]

I think it's fine for this issue to stay closed, but I think I'll finally open an issue for this idea. We may never get to it, but this does come up from time to time.

We'll track it as a separate issue. Thanks!