Corrupted Wave Art

[ryansurf]

On some clients, the art is corrupted.

Using my Windows 10 Command Prompt, when i show the large wave art(slw), I get this

However, the default small wave is not corrupted. Look into this

[Michiel-Vanzeir]

Reproducing the Issue

I've set up a new Windows 11 Pro system and was unable to replicate the reported issue. This lack of reproducibility complicates efforts to diagnose and resolve the bug.

Potential Causes

The inconsistency in Unicode character rendering across different Windows terminals could be due to several factors:

• Terminal Compatibility: Not all Windows terminals support the same range of Unicode characters. Some characters may appear as boxes or question marks if the terminal or font does not support them.

• Encoding Differences: Different terminals may default to different text encodings, which can affect the rendering of Unicode characters.

Suggested Solutions

To mitigate these issues, we could consider developing alternative wave art that can be displayed in terminals with different encoding or limited Unicode support. Alternatively, we can implement a fallback to display smaller wave art if the larger version fails to render correctly. This can be dynamically detected by checking for proper Unicode support at runtime.

However, we would need to know which fonts or encodings aren't compatible with our current wave arts. I'm not sure how to further investigate this.

[ryansurf]

@Michiel-Vanzeir thanks for looking into this. Indeed, that lack of reproducibility does further complicate things.

The issue still persists on my machine. I like you're idea of a fallback display.

I'll investigate this further in the next day or two to figure out what is the root cause of my machine's issue

[Michiel-Vanzeir]

Hey @ryansurf

Could you try entering chcp in your command prompt? This should return something like Active code page: 437 which tells me more about the encoding of your terminal.

Other than that, if you right click anywhere at the top of your command prompt that isn't a tab, you should be able to go to its settings. Could you check what settings you have under the category Rendering? I'll add a screenshot of mine below.

[ryansurf]

@Michiel-Vanzeir so, I made a mistake.

I reread the issue and realized I said windows 11... I was on Windows 10. I decided to upgrade to win 11 and it works fine now.

Sorry for the mistake. However, I can confirm it does not work on win10 and should still be investigated further. Sorry about that

[macnult]

I decided to poke around at this issue this morning and made some interesting findings.

On Windows 10, the default active code page can vary depending on the environment. Legacy console applications may use code page 437 (OEM-US), but Windows-1252 or UTF-8 is more common for modern applications.
On Windows 11, UTF-8 (65001) is the default for many modern environments, especially with Unicode support enabled.

The default on my Windows 10 machine is 437 (OEM-US).

When I changed the code page on cmd.exe to 65001, the corrupted wave art was still there. I gave 1252 a try, but that didn't change anything either.

However, cmd within vscode, as well as cmd within Windows Terminal, display the wave art with no issue. I tested this with both the OEM-US and UTF-8 code pages mentioned above.

Hopping back into cmd.exe, I went ahead and changed the default font (Consolas) to Cascadia Mono (the default font on Windows Terminal). That worked!
The following fonts available to me also worked:

• MS Gothic
• NSimSun
• SimSun-ExtB

It's worth mentioning that in Windows Terminal, changing from Cascadia Mono to Consolas did NOT corrupt the wave art. This font hiccup appears to only happen on Win10's cmd.exe

[ryansurf]

@macnult Interesting.

I suppose recommending users to use cmd within a text editor (assuming it works for all & not just vscode)/windows terminal or changing the default font to any of the ones you listed would be the move. I wonder why the latter is a fix

Thanks for looking into this one, sorry for the late response.

[macnult]

@ryansurf No worries!

Aside from encoding issues, I know that some fonts are just better equipped to handle more glyphs. Good examples would be NSimSun and SimSun-ExtB, which are primarily used for Chinese characters.

This doesn't explain why one font works in Windows Terminal and not in Win10 cmd though. I think Win10 cmd's lesser rendering engine is the culprit.

Because of this, I don't see a problem with the solution being to recommend people either use cmd in their text editor, or just download Windows Terminal.
Windows Terminal especially is just better in general. I didn't even know it was available on Windows 10 until I hopped into this issue, otherwise I would have installed it ages ago.