ESC ] 4 ; <i> ; rgb : <r> / <g> / <b> ESC ... in WindowsTerminal?

[vefatica]

That works in a console. Below I'm changing color 0, which is the background color.

Before:

After:

Should it work in WindowsTerminal? It doesn't.

[DHowett]

You are redefining color 0, which is one of the colors in the 16-color palette (usually assigned to black.)

The vintage console only supports having indexed colors for the foreground or the background.

All other terminals, WT included, support 18 paletted colors: the 16 from ANSI/VT, plus a foreground and background which are independent.

You'll want to use OSC 11 (if I remember properly) to set the background, not OSC 4 to overwrite black.

[vefatica]

My only reference is https://docs.microsoft.com/en-us/windows/console/console-virtual-terminal-sequences which doesn't mention OSC 11.

Is there a better reference, one that describes OSC 11 in detail?

[vefatica]

Hmmm! If I have the terminators right [0x7 (BEL) or 0x9C (ST?)], I find that

OSC]10;16;... changes the color of the background

OSC]10;17;... changes the color of the foreground

Are they the last two colors in the 18-color palette you spoke of?

And OSC]11;x;... changes the color of the cursor (the x doesn't seem to matter)

I wish I knew how it's supposed to work.

[vefatica]

While the sequences from my previous post work as stated, I guess I didn't try hard enough. These also work and are as I have found documeted.

ESC]10;rgb:r/g/bST ... foreground color
ESC]11;rgb:r/g/bST ... background color
ESC]12;rgb:r/g/bST ... cursor color

[DHowett]

So! The documentation for these is right under the "Operating System Commands" section in the inimitable xterm control sequences guide. We have a backlog item booked to update our docs with all our supported sequences and the versions they came out in.

Your finding is pretty interesting! This set of OSC can be "chained" -- if you start with 10, and specify multiple colors (For your sequence, E]10;16;XYZ, 16 here was interpreted as the first color, and XYZ the second!), you will set resources 10, 11, 12, ...

"`e]10;rgb:ff/00/00;rgb:00/ff/00;rgb:00/00/ff`e\"
       ^ FOREGROUND ^ BACKGROUND ^ CURSOR

The 10 indicates that we wanted to start with the foreground.

You could do the same thing with three sequences, E]10;, E]11; and E]12;.

[DHowett]

(We do not support all the resources specified in OSC Ps ; Pt ST)

[DHowett]

And finally, last note before I give you space to reply (!) (:smile:)

The venerated Console also supports this "separate" palette, though it does make some applications act strange.

It's in the "Terminal" tab in the old settings sheet, marked down as "experimental" terminal settings, with a link to a fairly wordy blog post explaining them:

[vefatica]

Thanks for all the info, especially about "chaining" the sequences.

I have never played with that tab in the settings. Do "separate foreground" and "separate background" act as two "extra" colors (perhaps in the 18-color palette you mentioned earlier)?

[DHowett]

Yep, they are exactly that! They are accessible in VT using SGR 39 and 49 ("default foreground", "default background"). There's also cursor color, which is settable with OSC 12 but does not map to a SGR.

[vefatica]

Yep, they are exactly that! They are accessible in VT using SGR 39 and 49 ("default foreground", "default background").

Are they what ESC[0m gives?

[DHowett]

Indeed they are. For console, they replace the old "default" colors in any place except the API (which doesn't report with a data type large enough to express more colors :()

[vefatica]

Aha! That's nice. So I can have "default" colors that are not a combination of two colors from the console's 16-color palette.

[vefatica]

Aha! That's nice. So I can have "default" colors that are not a combination of two colors from the console's 16-color palette.

In a console, I can set "DefaultForefround" and "DefaultBackground" in the Properties dialog. Can I set them on the fly with a control sequence? I tried SGR 39 and SGR 49 (with 2;r;g;b, as in 38/48); that didn't work. [If that question is answered above, I couldn't find it.]

[zadjii-msft]

I tried SGR 39 and SGR 49 (with 2;r;g;b, as in 38/48);

I'm sorry what did you try? You don't need to use the 2;r;g;b bits with 39/49, they'll suffice on their own:

printf "Default text \e[31;42m red on green \e[39m default on green \e[31;49m red on default \n"

[vefatica]

I'm sorry. I misinterpreted the purpose of SGR 39/49.

What I really want to do is SET (on the fly) the console's default foreground/background and/or WT's defaultForeground/defaultBackground.

Can either or both of those be done?

It's part of a (mostly academic) project to let the user issue a command to change the console's (or WT's) color scheme. Some of the schemes don't work correctly if those fore/back colors are not set.

And (off-topic) ... Are the Creators Update console colors still the default in Windows 10? If so, maybe a "Creators Update" scheme in WT would be appropriate. I added such a scheme myself, works fine. I'll post it if it will be of any value.

[DHowett]

Ah, I think I figured it out. If you installed in 2019, you've got Campbell. For sure.

What we're seeing here, though, is two translation issues!

First: the color ordering for console colors, as well as legacy VGA attributes (on which console colors are based) swaps red and blue (and derivatives like teal and cyan).

TRANSLATION ERROR ONE

                    1                   3         4                   6
          BLACK     RED       GREEN     YELLOW    BLUE      MAGENTA   TEAL      WHITE     GRAY      RED       GREEN     YELLOW    BLUE      MAGENTA   CYAN      WHITE         FORE      BACK
CAMPBELL {0x0C0C0C, 0x1F0FC5, 0x0EA113, 0x009CC1, 0xDA3700, 0x981788, 0xDD963A, 0xCCCCCC, 0x767676, 0x5648E7, 0x0CC616, 0xA5F1F9, 0xFF783B, 0x9E00B4, 0xD6D661, 0xF2F2F2,     0xCCCCCC, 0x0C0C0C},

          BLACK     **BLUE**  GREEN     **TEAL**  **RED**   MAGENTA   **YELLOW* WHITE     GRAY      **BLUE**  GREEN     **CYAN**  **RED**   MAGENTA   **YELLOW* WHITE         FORE      BACK
REGISTRY {0x0C0C0C, 0x0037DA, 0x13A10E, 0x3A96DD, 0xC50F1F, 0x881798, 0xC19C00, 0xCCCCCC, 0x767676, 0x3B78FF, 0x16C60C, 0x61D6D6, 0xE74856, 0xB4009E, 0xF9F1A5, 0xF2F2F2,     0xCCCCCC, 0x0C0C0C}

Translation error two is that the registry values are stored in 0BGR order, not 0RGB order.

In this example, I have lined up red and blue.

TRANSLATION ERROR TWO
ENDIAN SWAP

          ... 1         ... 4         
          ... RED       ... BLUE      
CAMPBELL {... 0x1F0FC5, ... 0xDA3700, }, 00BBGGRR
                 \ /           \ /
                 / \           / \
REGISTRY {... 0xC50F1F, ... 0x0037DA, }  00RRGGBB

[vefatica]

Thanks! I know all about the red/blue swap and just plain failed to see that that's what was happening ... and that I didn't take that into consideration in making my C array initializer ... or, more likely, that I swapped them twice. Doh!

I'm sorry I wasted so much of your time on this.

[DHowett]

I'm sorry I wasted so much of your time on this.

You've probably guessed by now, but I love answering questions like this 🙂

[vefatica]

And thanks again to @zadjii-msft. My color scheme sampler is working well both in a console and in WT.

[vefatica]

I discovered by accident that you can chain the OSC4 specs (16-color palette) without specifying palette indices (if the starting index is meant to be 0, I suppose).

For example, OSC4;rgb:xx/xx/xx;rgb:XX/XX/XXST will set colors 0 and 1. Is that right?

And when I was specifying indices, a bug in my code (failure to divide by 3) produced sequences like this

OSC4;0;rgb:xx/xx/xx;3;rgb:xx/xx/xx;6;rgb:xx/xx/xx ... 45;rgb:xx/xx/xxST

It worked anyway! When chaining OSC4 sequences, are specified indices after the first simply ignored ... and if none are specified, is the first assumed to be 0? It seems that way.

[DHowett]

Interesting! I think this is a compliance issue -- the xterm documentation does not mention this feature. I wouldn't rely on it 😄

[DHowett]

It looks like xterm and WT handle these degenerate cases differently:

OSC 4 ; rgb:x/y/z ; rgb:a/b/c ; rgb:f/o/o ; rgb:s/u/p ST
        index 0     #AABBCC     index 0     #SSUUPP <- xterm 
        ignored     ignored     ignored     ignored <- Windows Terminal 

It seems as though when xterm is expecting an index and gets a color specification, it parses it as an index. It always evaluates to 0.

Terminal

There's your baseline. Those are the default colors for 0, 1, 2, and xterm extended 45.

Omitting indices

There was no change.

Chaining color indices with discontinuities

This is not a degenerate case. Should work fine.

I've redefined them with: \e]4;0;rgb:0f/00/00;2;rgb:00/ff/ff;45;rgb:0e/ef/8f\e\\

xterm

baseline

Omitting indices

Chaining indices with discontinuities

[vefatica]

Where can I find the code for the handling of OSC4? I'm terrible at finding my way around the code.

I saw that several issues became "conversations". Can conversations be seen (en masse) ... searched?

[DHowett]

They are searchable, yes.

You can find the code for handling OSC 4 here:

terminal/src/terminal/parser/OutputStateMachineEngine.cpp

Lines 731 to 743 in 8b94676

	case OscActionCodes::SetColor:
	{
	std::vector<size_t> tableIndexes;
	std::vector<DWORD> colors;
	success = _GetOscSetColorTable(string, tableIndexes, colors);
	for (size_t i = 0; i < tableIndexes.size(); i++)
	{
	const auto tableIndex = til::at(tableIndexes, i);
	const auto rgb = til::at(colors, i);
	success = success && _dispatch->SetColorTableEntry(tableIndex, rgb);
	}
	TermTelemetry::Instance().Log(TermTelemetry::Codes::OSCCT);
	break;

That calls a function called _GetOscSetColorTable:

terminal/src/terminal/parser/OutputStateMachineEngine.cpp

Lines 945 to 976 in 8b94676

	bool OutputStateMachineEngine::_GetOscSetColorTable(const std::wstring_view string,
	std::vector<size_t>& tableIndexes,
	std::vector<DWORD>& rgbs) const noexcept
	try
	{
	const auto parts = Utils::SplitString(string, L';');
	if (parts.size() < 2)
	{
	return false;
	}
	std::vector<size_t> newTableIndexes;
	std::vector<DWORD> newRgbs;
	for (size_t i = 0, j = 1; j < parts.size(); i += 2, j += 2)
	{
	unsigned int tableIndex = 0;
	const bool indexSuccess = Utils::StringToUint(til::at(parts, i), tableIndex);
	const auto colorOptional = Utils::ColorFromXTermColor(til::at(parts, j));
	if (indexSuccess && colorOptional.has_value())
	{
	newTableIndexes.push_back(tableIndex);
	newRgbs.push_back(colorOptional.value());
	}
	}
	tableIndexes.swap(newTableIndexes);
	rgbs.swap(newRgbs);
	return tableIndexes.size() > 0 && rgbs.size() > 0;
	}
	CATCH_LOG_RETURN_FALSE()

...which despite being somewhat long is straightforward. It literally takes the list of arguments two-by-two :)

[vefatica]

I see! They're "discussions", not "conversations". Thanks.

[vefatica]

I'm having a hard time seeing palette color 0 in the current preview version. Below are the release version (left) and the preview version (right). Both are using the Campbell theme and have executed the same command. The one on the right also shows the utility I use to see screen coordinates and color at the mouse pointer. The command should produce palette color 0 (CSI 30 m). It does that in the release version (0C/0C/0C, equal to the background color). In the preview version, it produces color 4E/4E/4E. In fact, with the preview version it produces 4E/4E/4E with ANY theme. This has nothing to do with my programming.

Is this an issue ... known ... or just something experimental and beyond my grasp?

[DHowett]

I suspect you are seeing the results of this setting:

[vefatica]

Where is that setting?

[DHowett]

(Please try to reply in the sub-thread!

)

That's in Profile->Appearance.

[vefatica]

Yup! That was it.

[vefatica]

That's like "one size fits all". 4E/4E/4E works for all themes. 😁

[DHowett]

(Please try to reply in the sub-thread!

)

The value that's chosen is based on the contrast of the foreground color against the background, and it won't always be 4E/4E/4E 😄

[vefatica]

It's 4E/4E/4E with all the built-in themes.

[vefatica]

My program might be screwy. I have 0x83, 0x94, 0x96, for Solarized Dark default foreground. That doesn't seem bluish at all.

It was a small nightmare digging theme-color specs out of the source (which I have) and I could have easily botched it. Even finding them was hard. Please ... what file are the color specs for the built-in themes in?

[DHowett]

In Terminal? Hold down Alt while you click the Settings menu item.

[vefatica]

I think I dug them out of the JSON file. There I see

        "foreground": "#839496",
        "green": "#859900",
        "name": "Solarized Dark",

which is what I'm using.

[vefatica]

That's what's in defaults.json too.

        "name": "Solarized Dark",
        "foreground": "#839496",

[DHowett]

So in that case, it looks like something on your end is forcing the foreground color to approximately #8d8d8d.

It might also be changing what the black color is (which is the one that 0 maps to :))

[ClaireCJS]

I know it's 1.5 yrs later, but is there a way to query the current RGB values of any of the 16 colors?

[j4james]

No, unfortunately that's not supported in Windows Terminal yet, but you can subscribe to issue #3718 if you want to be notified of any progress in that regard. We don't have a framework for passing queries over conpty, though, so I suspect it may be a long time before we can do that.

[vefatica]

Hi, @ClaireCJS! 😁

[ClaireCJS]

Oh i didn't notice it was you! lol!
Yea, i'm kinda doing a lot of strange low level things this month. Revisiting past concepts.