Unicode Full Block (U+2588) missing color

[pmmmwh]

Issue

Unicode Full Block (U+2588) always renders as black, regardless if colors are set, when minimum-contrast is not 1 (default).

I think this might be related to #2117 - all the other Unicode block glyphs work fine.

Steps to reproduce

Set minimum-contrast to something higher than 1 (e.g. 1.1 / 3 as suggested in the comment in the config file).

Both of these two commands prints the character in black - not as the black set in palette 0, but just pitch black regardless.
The characters render properly when it's highlighted.

printf "\u2588\n"
printf "\033[0;37m\u2588\n"

Expected behavior

First command should print the character in whatever theme's foreground color is, and second should print the block in palette color 7 (which is usually white).

[jcollie]

What do you have set as palette=7 in your theme/config? \033[0;37m is not "set the color to white", it's "set the color to palette color 7" which happens to be white in a "standard" palette.

[pmmmwh]

What do you have set as palette=7 in your theme/config? \033[0;37m is not "set the color to white", it's "set the color to palette color 7" which happens to be white in a "standard" palette.

Good point! My palette 7 in the screenshot is set to #FFFFFF.

Upon further investigation, this seems to be an issue when minimum-contrast is set - as long as it's not 1. I've updated the issue description as I think this is still an issue - a setting that's supposed to make text more readable is making text harder to read.

[jcollie]

Oh, yeah minumum-contrast really messes with colors in unexpected ways. Enough that I think we should consider removing the setting. I'm sure that if you search GH and Discord you'll find dozens of instances where people report bugs that end up being minimum-contrast issues. I think that there's going to be a flood of similar bug reports once Ghostty goes public.

[pmmmwh]

What's weird about this is that playing with contrast works well for all other block glyphs and U+2588 is the only one that instantly break. I guess one way to address this is to also special case box / block glyphs similar to powerline glyphs?

I think that there's going to be a flood of similar bug reports once Ghostty goes public.

For sure - I think this one would hit quite a few people, given how block glyphs are often used with powerline + stuff that prints QR Codes into the terminal, for example.

[qwerasd205]

This is a regression I think- we had this problem before. It's an interaction between the padding color extend and the minimum contrast. Right now, hackishly, the padding color extend sets the bg of full block cells to the fg color, so that they can be extended as expected, but they're supposed to be exempt from minimum contrast because they're "powerline-like" symbols, but I guess for some reason they're not being exempted.

[mitchellh]

Would be helpful to see if this happens on both OpenGL and Metal renderers. Min contract is a renderer concern so may only apply to one.

[fionn]

I could reproduce this on Linux, so it's not a Metal-only issue.

[cwrau]

Might this be similar?

The following prompt:

╭─  
├─    m
├─   /ho
╰─ λ vi

renders like this:

See the > glyphs in the first line and before the vi

gnome-terminal renders it like this: