Bug: macOS 14 Terminal rendering doesn't seem to work

[joelparkerhenderson]

macOS 14 Terminal rendering doesn't seem to work

macOS 14 Terminal rendering doesn't seem to work. See image.

[thomas-mauran]

Hi, thanks for your feedback I tested on my Mac OS with warp and got no issue can you give more informations about your terminal, font and eventually themes !

[jwodder]

macOS's builtin Terminal.app doesn't have 24-bit "true color" support, so any colors specified as RGB (like these) rather than as ANSI color names or indices won't show up properly. If this project wants to support such terminals, it would have to gain a variant color theme that only uses the 256-color ANSI palette; I am not aware of a way to programmatically detect whether a terminal supports true color, so this theme might have to be enabled by the user supplying a command-line or configuration option.

[joelparkerhenderson]

Good info thank you @jwodder.

@thomas-mauran here's a suggestion for a way to do what you're asking about... you could add a command line option to launch with just black and white. And even better, a command line option such as '--debug' that prints whatever information you want to know about the setup.

Here's a screenshot with iTerm2 that shows the colors do work, but the pieces seem deformed. And the same screen shows up in Terminator too.

I'm on macOS 14.1.1, M1, plenty of headroom. I code in Rust, including TUI apps, and have not experienced this kind of issue.

[thomas-mauran]

Great idea @joelparkerhenderson could be very useful, for the piece deformation it is because of the font size of the terminal, you can use ctrl or cmd + and - to adjust the size. If you need more informations about the commands of the game you can press h to open an help popup

[joelparkerhenderson]

Is there a way to make the pieces render using their Unicode characters?

What I see in the existing source is a multiline pseudo graphic:

impl King {
    pub fn to_string() -> &'static str {
        "\
      ✚\n\
    ▞▀▄▀▚\n\
    ▙▄█▄▟\n\
    ▐███▌\n\
   ▗█████▖\n\
    "

My preference is to use Unicode, which scales well, and is especially good for TUIs in my experience, such as:

https://www.compart.com/en/unicode/U+265A

(By the way, the multiline pseudo graphic code is a good candidate for using once_cell one-time static initialization)

[thomas-mauran]

@joelparkerhenderson that could be great to prevent some scaling problems and some issues caused by the terminal font. Do you want to make a PR ?

[joshka]

The problem is those characters are only going to be a single cell. Which can look good (see https://github.com/nickzuber/chs), but this has a much bigger board.

[thomas-mauran]

Yeah it might be better to keep the sprites for the board and the ascii for the move history

[joelparkerhenderson]

I tried the zoom keys (cmd + and -) and they make the entire iTerm2 view bigger; the pieces continue to be deformed the same way in the same proportion to their squares.

@joshka Yes you're right and CHS is a good example of using the Unicode characters.

@thomas-mauran Thanks for the question about me doing a PR; I'm at capacity. If you make significant changes to the sprite approach, and you want me to take a look on my macOS, I'm happy to do that for you.

[thomas-mauran]

Alright perfect, closing this issue I will ping you if I create a new one, thanks for your messages !

[joelparkerhenderson]

Are you sure you want to close this bug? The bug still exists on current macOS, current default macOS Terminal app. There's an opportunity for you to have this bug open, so others can see it, and learn or contribute.