2 ms·

Just what I said in my original comment: the colours are unreliable. Bold might change the colour or might be almost indistinguishable. Bright white might be hi

Just what I said in my original comment: the colours are unreliable. Bold might change the colour or might be almost indistinguishable. Bright white might be higher contrast (on dark terminals) or zero contrast (on some light terminals). Blue might be easy to read (on most newer dark terminals) or very painful to read and almost invisible (on most older dark terminals). Yellow might be brighter than the default colour, or low contrast and not great to read. You just don’t know about any of this stuff unless you check it (which is possible in some terminals, but even then it’s a bit risky as a strategy). The technical aspects of colour support are fairly uninteresting. The inconsistency of the actual colours is the problem.

eesmith 4y ago
> the colours are unreliable And as I asked in my followup, in which terminals ? In any case, my point was that once you checked them, it looks like Rich can handle the configuration, and you can set up a theme to use, and textualize will let you pass in a Rich configuration.
- chrismorgan 4y ago
  > once you checked them You can’t guarantee that you can check them, and that’s the problem. I haven’t directly surveyed terminal support for the relevant OSC sequences (I wish someone would make a thorough terminal feature comparison—in theory terminfo databases would be part of this, but in practice the scheme is thoroughly broken), but from what I’ve heard I would expect a reasonably strong correlation between support for that and support for 24-bit colour. That is, you are unlikely to be able to check the colours on the very environments where you most need to. As far as static checking of terminal capabilities is concerned, I think it’s reasonable to say that everything’s completely broken by design there too. Everything builds upon the idea of a $TERM variable being right and terminfo databases having relevant entries and matching reality, and they’re just not. $TERM will be missing or wrong extremely often, and terminfo databases are regularly out of date, and if you try to use a “correct” value for $TERM you’ll often find various software (especially old software, but even new stuff sometimes) falls over, normally in the direction of claiming that your terminal is incapable of doing something that it is actually capable of. This got to be such a problem that $COLORTERM was introduced, which is more likely to describe the true capabilities of your terminal, but still not quite always even if it’s there, and much important software doesn’t look at it either. If you’re familiar with web history, it’s a similar sort of issue to what happened in the User-Agent header, and for similar reasons. So then, you’re left with maybe some notion of the terminal’s capabilities, and maybe the ability to find out what the colours actually are, but you can’t depend on either of these, and so you can’t in the general case depend on the values of any colours.
  - eesmith 4y ago
    > You can’t guarantee that you can check them, and that’s the problem. Understood. I misread your mention of "checking" as meaning for an organization which wants to deploy a TUI internally, where they can check all of the supported terminals. > That is, you are unlikely to be able to check the colours on the very environments where you most need to. Which terminals are these? Do modern TUI developers need to support them? Or can they be ignored like how most modern web developers ignore IE 4 support? That's why I keep asking you which terminals you refer to. Experience from 30 years ago may no longer be relevant. > and much important software doesn’t look at it either. Rich does. https://rich.readthedocs.io/en/latest/_modules/rich/console.html?highlight=COLORTERM# https://rich.readthedocs.io/en/latest/_modules/rich/console....
    - chrismorgan 4y ago
      I finally found a decent source of information: https://github.com/termstandard/colors https://github.com/termstandard/colors The most obvious case of missing support is macOS’s Terminal.app. Years ago I imagine you could theoretically at least query the colours by some side channel, but sandboxing will doubtless have prevented that. And maybe it does support the querying, which to my mind is the more important of the two pieces of functionality when it comes to accessibility.
      - eesmith 4y ago
        I started Rich in Terminal.app. It reports: >>> rich.get_console() <console width=109 ColorSystem.STANDARD> If I read https://github.com/Textualize/rich/blob/33040731973d44cf6326d4b88e697f79dbdc4e9a/rich/color.py#L513 https://github.com/Textualize/rich/blob/33040731973d44cf6326... correctly, if you specify a truecolor it will downgrade with the following code path: # Convert to standard from truecolor or 8-bit elif system == ColorSystem.STANDARD: if self.system == ColorSystem.TRUECOLOR: assert self.triplet is not None triplet = self.triplet else: # self.system == ColorSystem.EIGHT_BIT assert self.number is not None triplet = ColorTriplet(*EIGHT_BIT_PALETTE[self.number]) color_number = STANDARD_PALETTE.match(triplet) return Color(self.name, ColorType.STANDARD, number=color_number) which does a nearest-neighbor match using the method at https://github.com/Textualize/rich/blob/33040731973d44cf6326d4b88e697f79dbdc4e9a/rich/palette.py#L45 https://github.com/Textualize/rich/blob/33040731973d44cf6326... (described at https://www.compuphase.com/cmetric.htm https://www.compuphase.com/cmetric.htm ) to "The standard ansi colors (including bright variants)" defined at https://github.com/Textualize/rich/blob/33040731973d44cf6326d4b88e697f79dbdc4e9a/rich/_palettes.py#L27 https://github.com/Textualize/rich/blob/33040731973d44cf6326... . There are 16 of these colors, which I visually confirmed using the demo "python -m rich" and counting the number of dissimilar colors. This is in line with your suggestion to treat the terminal "as a five-and-a-bit-colour terminal" -- though 4 bits in this case. HOWEVER, you added "they may be high contrast or zero contrast. You can also use bold, which may give brighter colours, whatever that means, but shouldn’t use colours 7–15 directly." I confirmed that Terminal.app shows reasonable colors for this case. > Don’t even think of bright yellow, because that’s back to being almost invisible in most light terminals. I confirmed that bright yellow is clearly visible with a light terminal. The two other missing features I could spot were lack of italic and strikethrough ANSI styles. Bold, underline, reverse, and blink are supported.

eesmith 4y ago

> the colours are unreliable And as I asked in my followup, in which terminals ? In any case, my point was that once you checked them, it looks like Rich can handle the configuration, and you can set up a theme to use, and textualize will let you pass in a Rich configuration.

chrismorgan 4y ago
> once you checked them You can’t guarantee that you can check them, and that’s the problem. I haven’t directly surveyed terminal support for the relevant OSC sequences (I wish someone would make a thorough terminal feature comparison—in theory terminfo databases would be part of this, but in practice the scheme is thoroughly broken), but from what I’ve heard I would expect a reasonably strong correlation between support for that and support for 24-bit colour. That is, you are unlikely to be able to check the colours on the very environments where you most need to. As far as static checking of terminal capabilities is concerned, I think it’s reasonable to say that everything’s completely broken by design there too. Everything builds upon the idea of a $TERM variable being right and terminfo databases having relevant entries and matching reality, and they’re just not. $TERM will be missing or wrong extremely often, and terminfo databases are regularly out of date, and if you try to use a “correct” value for $TERM you’ll often find various software (especially old software, but even new stuff sometimes) falls over, normally in the direction of claiming that your terminal is incapable of doing something that it is actually capable of. This got to be such a problem that $COLORTERM was introduced, which is more likely to describe the true capabilities of your terminal, but still not quite always even if it’s there, and much important software doesn’t look at it either. If you’re familiar with web history, it’s a similar sort of issue to what happened in the User-Agent header, and for similar reasons. So then, you’re left with maybe some notion of the terminal’s capabilities, and maybe the ability to find out what the colours actually are, but you can’t depend on either of these, and so you can’t in the general case depend on the values of any colours.
- eesmith 4y ago
  > You can’t guarantee that you can check them, and that’s the problem. Understood. I misread your mention of "checking" as meaning for an organization which wants to deploy a TUI internally, where they can check all of the supported terminals. > That is, you are unlikely to be able to check the colours on the very environments where you most need to. Which terminals are these? Do modern TUI developers need to support them? Or can they be ignored like how most modern web developers ignore IE 4 support? That's why I keep asking you which terminals you refer to. Experience from 30 years ago may no longer be relevant. > and much important software doesn’t look at it either. Rich does. https://rich.readthedocs.io/en/latest/_modules/rich/console.html?highlight=COLORTERM# https://rich.readthedocs.io/en/latest/_modules/rich/console....
  - chrismorgan 4y ago
    I finally found a decent source of information: https://github.com/termstandard/colors https://github.com/termstandard/colors The most obvious case of missing support is macOS’s Terminal.app. Years ago I imagine you could theoretically at least query the colours by some side channel, but sandboxing will doubtless have prevented that. And maybe it does support the querying, which to my mind is the more important of the two pieces of functionality when it comes to accessibility.
    - eesmith 4y ago
      I started Rich in Terminal.app. It reports: >>> rich.get_console() <console width=109 ColorSystem.STANDARD> If I read https://github.com/Textualize/rich/blob/33040731973d44cf6326d4b88e697f79dbdc4e9a/rich/color.py#L513 https://github.com/Textualize/rich/blob/33040731973d44cf6326... correctly, if you specify a truecolor it will downgrade with the following code path: # Convert to standard from truecolor or 8-bit elif system == ColorSystem.STANDARD: if self.system == ColorSystem.TRUECOLOR: assert self.triplet is not None triplet = self.triplet else: # self.system == ColorSystem.EIGHT_BIT assert self.number is not None triplet = ColorTriplet(*EIGHT_BIT_PALETTE[self.number]) color_number = STANDARD_PALETTE.match(triplet) return Color(self.name, ColorType.STANDARD, number=color_number) which does a nearest-neighbor match using the method at https://github.com/Textualize/rich/blob/33040731973d44cf6326d4b88e697f79dbdc4e9a/rich/palette.py#L45 https://github.com/Textualize/rich/blob/33040731973d44cf6326... (described at https://www.compuphase.com/cmetric.htm https://www.compuphase.com/cmetric.htm ) to "The standard ansi colors (including bright variants)" defined at https://github.com/Textualize/rich/blob/33040731973d44cf6326d4b88e697f79dbdc4e9a/rich/_palettes.py#L27 https://github.com/Textualize/rich/blob/33040731973d44cf6326... . There are 16 of these colors, which I visually confirmed using the demo "python -m rich" and counting the number of dissimilar colors. This is in line with your suggestion to treat the terminal "as a five-and-a-bit-colour terminal" -- though 4 bits in this case. HOWEVER, you added "they may be high contrast or zero contrast. You can also use bold, which may give brighter colours, whatever that means, but shouldn’t use colours 7–15 directly." I confirmed that Terminal.app shows reasonable colors for this case. > Don’t even think of bright yellow, because that’s back to being almost invisible in most light terminals. I confirmed that bright yellow is clearly visible with a light terminal. The two other missing features I could spot were lack of italic and strikethrough ANSI styles. Bold, underline, reverse, and blink are supported.