ANSI Bright Colors (90-97) Not Rendering on Linux Framebuffer Console (TTY)

[wilrodriguez]

Hello! I'm developing a Textual application that needs to run on hardened Rocky Linux 9 systems, directly on the Linux virtual console (TTY) without a graphical desktop.

I've had success getting the console into a high-resolution framebuffer mode with 32-bit color depth (video=1280x1024-32 kernel parameter), though there's basically nothing that actually can make the vt linux terminal go above 16 color support.

The bug

When running textual colors or my own app, the console correctly renders the base 8 ANSI colors. However, it fails to render the high-intensity "bright" colors.

• ansi_bright_red renders as ansi_red.
• ansi_bright_green renders as ansi_green.
• ...and so on for all 8 bright colors.

A test script confirms the console is capable of displaying at least 16 distinct colors (the 8 base colors + their bolded versions).

for i in {0..255}; do printf "\x1b[38;5;${i}mcolour${i} "; done; echo

But in textual colors... well... things aren't so great.

Hypothesis:
This suggests that Textual/Rich is emitting the modern ANSI escape codes for bright colors (e.g., \x1b[91m for bright red), but the underlying Linux kernel virtual terminal (vt) console driver does not interpret these codes correctly, falling back to the base colors.

The vt console typically uses the "bold" or "intensity" attribute (\x1b[1m) to produce bright colors (e.g., \x1b[1;31m).

Feature Request / The Question:

Would it be possible for Textual's color rendering system to have a fallback mechanism? When it detects a terminal that supports 16 colors but might not support the 90-series codes (like TERM=linux or linux-16color), could it attempt to render bright colors by emitting the bold attribute (\x1b[1m) instead of the base color code?

This, in conjunction with the textual-ansi theme should help improve compatibility and appearance on the linux virtual terminal. The conversation still, of course, continues in many discussions like #5011 on how to make the glyphs work better, but having functional colors is a pretty important first step.

Textual Diagnostics

Versions

Name	Value
Textual	3.5.0
Rich	14.0.0

Python

Name	Value
Version	3.9.21
Implementation	CPython
Compiler	GCC 11.5.0 20240719 (Red Hat 11.5.0-5)
Executable	/redacted/.venv/bin/python

Operating System

Name	Value
System	Linux
Release	5.14.0-570.21.1.el9_6.x86_64
Version	#1 SMP PREEMPT_DYNAMIC Tue Jun 10 18:07:35 UTC 2025

Terminal

Name	Value
Terminal Application	Unknown
TERM	linux
COLORTERM	Not set
FORCE_COLOR	Not set
NO_COLOR	Not set

Rich Console options

Name	Value
size	width=160, height=64
legacy_windows	False
min_width	1
max_width	160
is_terminal	False
encoding	utf-8
max_height	64
justify	None
overflow	None
no_wrap	False
highlight	None
markup	None
height	None

[github-actions]

We found the following entries in the FAQ which you may find helpful:

• Does Textual support images?
• How do I center a widget in a screen?
• Why doesn't Textual support ANSI themes?

Feel free to close this issue if you found an answer in the FAQ. Otherwise, please give us a little time to review.

This project is developed and maintained by Will McGugan. Consider sponsoring Will's work on this project (and others).

This is an automated reply, generated by FAQtory

[wilrodriguez]

Ok, while experimenting with things with the textual-ansi theme enabled... I think it's possible that things might be working right and I might just be seeing an issue with the textual colors app.

EDIT:

For future viewers of this ticket, if you're in the same situation as I am and you have to work with the linux virtual terminal, be sure to set self.theme = "textual-ansi" and then the colors will work as expected. No idea why they don't work for me in textual colors, but setting the theme seems to make textual support ansi better overall.

[TomJGooding]

Changing the theme to textual-ansi will also automatically set ansi_color=True so "Textual will not attempt to convert ANSI colors". I'm not sure how you're running the colors demo but that might explain it?

[wilrodriguez]

Yeah, I tried running it with TEXTUAL_THEME=textual-ansi textual colors. As you noted in #5862 that brings it up in light mode... but, I only get 8 colors and no brights. I think it's just probably a bug in textual colors though; I haven't really investigated the source code. I'm contemplating closing this issue and just opening one directed at textual colors.

[TomJGooding]

How does this look after swicthing the anei_color or theme?

from textual.app import App, ComposeResult
from textual.containers import HorizontalGroup
from textual.widgets import Static

COLORS = [
    "black",
    "red",
    "green",
    "yellow",
    "blue",
    "magenta",
    "cyan",
    "white",
]


class ColorPreview(Static):
    DEFAULT_CSS = """
    ColorPreview {
        width: 1fr;
        padding: 1 2;
        content-align: center middle;
    }
    """

    def __init__(self, color_name: str) -> None:
        super().__init__(content=color_name)
        self.styles.background = color_name


class AnsiColorsApp(App):
    CSS = """
    Screen {
        align: center middle;
    }

    .color-group {
        width: 48;
    }
    """

    def __init__(self) -> None:
        super().__init__(ansi_color=False)
        # self.theme = "textual-ansi"

    def compose(self) -> ComposeResult:
        for color in COLORS:
            with HorizontalGroup(classes="color-group"):
                yield ColorPreview(f"ansi_{color}")
                yield ColorPreview(f"ansi_bright_{color}")


if __name__ == "__main__":
    app = AnsiColorsApp()
    app.run()