2 ms·

I finally found a decent source of information: https://github.com/termstandard/colors https://github.com/termstandard/colors The most obvious case of missing

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.
- chrismorgan 4y ago
  When I wrote “five-and-a-bit colour”, I meant “five colours, plus very limited use of two more colours”. The word “bit” was unfortunate. “The standard ansi colors (including bright variants)” are a sham. Basically no one has used those specific values for decades. (Well, actually, I think the Linux framebuffer console might still be? In a quick test, it does look about right. But few ever use it directly.) The whole approach is a crock. What you have to realise is that the first 16 colours are in a sense semi-semantic colours, though that’s not quite the right term for what I want to describe; it’s more a provided palette of named colours, perhaps. Trying to translate from exact colours to semi-semantic colours is… well, it’s generally not a great idea, not how you should treat those colours. For best results, you want to deliberately design for 16-colour and 24-bit-colour, deliberately choosing values that may not be the same value. There are two classes of light terminal colour schemes: what I will call “true”, where black is black, white is white, bright/high-intensity yellow is brighter and higher intensity than regular yellow, &c.; and what I will call “flipped”, where black is white, white is black, bright/high-intensity yellow is darker and probably less intense than regular yellow, &c. The trouble is that the starting palette is ambiguous, because it was designed for dark terminals, but when you apply things to light terminals, some apps assume “true” treatment of colours (that is, that if I ask for white you’ll give me white, regardless of the default colours) and others “flipped” (that is, that when I ask for white, I actually just want a neutral colour that has high contrast with the default background colour); so both will be broken for at least some schemes. (But I should perhaps perform a survey of actual light colour schemes so that I can determine the prevalence of the two approaches. In my own, I went “true”.)

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.

chrismorgan 4y ago
When I wrote “five-and-a-bit colour”, I meant “five colours, plus very limited use of two more colours”. The word “bit” was unfortunate. “The standard ansi colors (including bright variants)” are a sham. Basically no one has used those specific values for decades. (Well, actually, I think the Linux framebuffer console might still be? In a quick test, it does look about right. But few ever use it directly.) The whole approach is a crock. What you have to realise is that the first 16 colours are in a sense semi-semantic colours, though that’s not quite the right term for what I want to describe; it’s more a provided palette of named colours, perhaps. Trying to translate from exact colours to semi-semantic colours is… well, it’s generally not a great idea, not how you should treat those colours. For best results, you want to deliberately design for 16-colour and 24-bit-colour, deliberately choosing values that may not be the same value. There are two classes of light terminal colour schemes: what I will call “true”, where black is black, white is white, bright/high-intensity yellow is brighter and higher intensity than regular yellow, &c.; and what I will call “flipped”, where black is white, white is black, bright/high-intensity yellow is darker and probably less intense than regular yellow, &c. The trouble is that the starting palette is ambiguous, because it was designed for dark terminals, but when you apply things to light terminals, some apps assume “true” treatment of colours (that is, that if I ask for white you’ll give me white, regardless of the default colours) and others “flipped” (that is, that when I ask for white, I actually just want a neutral colour that has high contrast with the default background colour); so both will be broken for at least some schemes. (But I should perhaps perform a survey of actual light colour schemes so that I can determine the prevalence of the two approaches. In my own, I went “true”.)