30 Mar, 2011, KaVir wrote in the 2nd comment:
Some clients allow the user to specify RGB values for each of the ANSI colours, and I guess this could provide a means of doing the same thing from the server end - although IMO the user should definitely have the choice of ignoring the server's suggestions.
I suppose it could also be used to produce colours that aren't normally available, for example changing black (which I've only ever seen used to hide the Diku credits) to brown for use in ASCII maps and such. However this would only be useful for clients that support OSC and not XTerm 256 colours.
I suppose it could also be used to produce colours that aren't normally available, for example changing black (which I've only ever seen used to hide the Diku credits) to brown for use in ASCII maps and such. However this would only be useful for clients that support OSC and not XTerm 256 colours.
31 Mar, 2011, Scandum wrote in the 3rd comment:
Utilizing black would be interesting, though in the case the client doesn't properly handle OSC it'd be particularly annoying.
One other minor use I can think of is increasing the readability of dim blue on black backgrounds, not sure if I'm the only one who finds that color particularly annoying, though that problem can be handled client side in most cases.
All in all it's pretty useless, though the ability to change the color scheme with minimal server side effort is interesting.
One other minor use I can think of is increasing the readability of dim blue on black backgrounds, not sure if I'm the only one who finds that color particularly annoying, though that problem can be handled client side in most cases.
All in all it's pretty useless, though the ability to change the color scheme with minimal server side effort is interesting.
01 Apr, 2011, Tyche wrote in the 4th comment:
Google fails me. I turned up One Shot Color and Open Sound Controller and other stuff less than useful.
What is OSC?
What is OSC?
01 Apr, 2011, Tyche wrote in the 5th comment:
Is it this?
From ECMA-048 also probably ANSI-x86:
8.3.89 OSC - OPERATING SYSTEM COMMAND
Notation: (C1)
Representation: 09/13 or ESC 05/13
OSC is used as the opening delimiter of a control string for operating system use. The command string following may consist of a sequence of bit combinations in the range 00/08 to 00/13 and 02/00 to 07/14. The control string is closed by the terminating delimiter STRING TERMINATOR (ST). The interpretation of the command string depends on the relevant operating system.
From ECMA-048 also probably ANSI-x86:
8.3.89 OSC - OPERATING SYSTEM COMMAND
Notation: (C1)
Representation: 09/13 or ESC 05/13
OSC is used as the opening delimiter of a control string for operating system use. The command string following may consist of a sequence of bit combinations in the range 00/08 to 00/13 and 02/00 to 07/14. The control string is closed by the terminating delimiter STRING TERMINATOR (ST). The interpretation of the command string depends on the relevant operating system.
01 Apr, 2011, oenone wrote in the 6th comment:
I think the linked page describes what it is:
Quote
The OSC color palette is an extension to the ANSI color standard, documented in the Linux console manual as early as 1996.
01 Apr, 2011, Tyche wrote in the 7th comment:
oenone said:
I think the linked page describes what it is:
I suppose in the spirit of April Fool's Day, I could source the article to this thread. :-/
02 Apr, 2011, Tyche wrote in the 8th comment:
Tyche said:
Is it this?
From ECMA-048 also probably ANSI-x86:
8.3.89 OSC - OPERATING SYSTEM COMMAND
Notation: (C1)
Representation: 09/13 or ESC 05/13
OSC is used as the opening delimiter of a control string for operating system use. The command string following may consist of a sequence of bit combinations in the range 00/08 to 00/13 and 02/00 to 07/14. The control string is closed by the terminating delimiter STRING TERMINATOR (ST). The interpretation of the command string depends on the relevant operating system.
From ECMA-048 also probably ANSI-x86:
8.3.89 OSC - OPERATING SYSTEM COMMAND
Notation: (C1)
Representation: 09/13 or ESC 05/13
OSC is used as the opening delimiter of a control string for operating system use. The command string following may consist of a sequence of bit combinations in the range 00/08 to 00/13 and 02/00 to 07/14. The control string is closed by the terminating delimiter STRING TERMINATOR (ST). The interpretation of the command string depends on the relevant operating system.
Yes this is what it is. I'd recheck your examples because they don't have the string terminator, which is ESC \ or ESC (05/12).
So they use P (05/00) for pallete, which makes me wonder what other OSC sequences are allowed by XTERM (or possibly they are actually used by XWindows).
03 Apr, 2011, Scandum wrote in the 9th comment:
From man console_codes
Xterm doesn't require a string terminator, and given the length of the escape code is static there's technically no need for a terminator.
ESC ] OSC (Should be: Operating system command) ESC ] P
nrrggbb: set palette, with parameter given in 7
hexadecimal digits after the final P :-(. Here n
is the color (0-15), and rrggbb indicates the
red/green/blue values (0-255). ESC ] R: reset pal
ette
Xterm doesn't require a string terminator, and given the length of the escape code is static there's technically no need for a terminator.
03 Nov, 2014, SlySven wrote in the 10th comment:
As it's just past Halloween can I necro-bump this :ghostface: and point out that Scandum's link to MUDpeida has rotted slightly so that it is now: http://www.mudpedia.org/mediawiki/index.... - however I have reservations that the Linux console usage does not worry about such nice things as the ST (2 bytes: "?/" or 1-byte: U+009C ) terminator - what happens if more than one colour is to be redefined, does a P every eight bytes introduce a new colour (re)definition? The interpretation of what is within the OSC delimiters is system dependent but that requires the end to be marked as well does it not? For reference about OSC I refer to the ECMA-048.pdf and the particulars on page 65 of 108:
The reason I ask is that I am looking over some aspects of colour handling in Mudlet and I believe I can make it obey (with the permission of the user) MUD server requests to redefine the standard 16-color set - we allow the user to modify the standard color set already and it is fairly simple to implement in a GUI application so allowing the server to do it also by decoding a 7 hexadecimal string does not seem beyond my capabilities. The only thing I must remember is that this is to set the colours for the "console" where the MUD input/output occurs and not the other set of colours we maintain separately for the Mapper. :grinning:
Only other thing is, I suppose: does any MUD server make use of it and do they add the terminator byte(s) {or use OSC R ST to restore default colours afterwards}?
Quote
8.3.89 OSC - OPERATING SYSTEM COMMAND
Notation: (C1) Representation: 09/13 or ESC 05/13
OSC is used as the opening delimiter of a control string for operating system use. The command string following may consist of a sequence of bit combinations in the range 00/08 to 00/13 and 02/00 to 07/14. The control string is closed by the terminating delimiter STRING TERMINATOR (ST). The interpretation of the command string depends on the relevant operating system.
Notation: (C1) Representation: 09/13 or ESC 05/13
OSC is used as the opening delimiter of a control string for operating system use. The command string following may consist of a sequence of bit combinations in the range 00/08 to 00/13 and 02/00 to 07/14. The control string is closed by the terminating delimiter STRING TERMINATOR (ST). The interpretation of the command string depends on the relevant operating system.
The reason I ask is that I am looking over some aspects of colour handling in Mudlet and I believe I can make it obey (with the permission of the user) MUD server requests to redefine the standard 16-color set - we allow the user to modify the standard color set already and it is fairly simple to implement in a GUI application so allowing the server to do it also by decoding a 7 hexadecimal string does not seem beyond my capabilities. The only thing I must remember is that this is to set the colours for the "console" where the MUD input/output occurs and not the other set of colours we maintain separately for the Mapper. :grinning:
Only other thing is, I suppose: does any MUD server make use of it and do they add the terminator byte(s) {or use OSC R ST to restore default colours afterwards}?
03 Nov, 2014, Tyche wrote in the 11th comment:
You should send the ST terminator, because that's what ANSI-86 requires.
There are multiple implementations of xterm. That a particular xterm handles the absence of ST is not a guarantee that they all will.
And I'm guessing that if a particular xterm doesn't require an ST, it likely means it can't handle multiple commands.
If you should happen to send OSC to any VTxxx client that doesn't implement the command, it could only ignore it if there is an ST terminator.
I'd test it on a xterm client.
There are multiple implementations of xterm. That a particular xterm handles the absence of ST is not a guarantee that they all will.
And I'm guessing that if a particular xterm doesn't require an ST, it likely means it can't handle multiple commands.
If you should happen to send OSC to any VTxxx client that doesn't implement the command, it could only ignore it if there is an ST terminator.
I'd test it on a xterm client.
04 Nov, 2014, SlySven wrote in the 12th comment:
Ah, you misunderstand me Tyche, Mudlet is a GUI MUD Client and does not interface in any way with a terminal (well other then to dump debug and other warning messages to on some OSs). It currently does not respond to the reception of OSC codes to redefine what colours it uses to display MUD output on it's own GUI what we call "console" for the MUD session - there is no "sending" things to an X or other *Term involved. What I was confused about is that whether we should process an "OSC P #rrggbb" {="?]P#rrggbb"} code (where #rrggbb each represents a hexadecimal digit) when there is NOT the terminating "?/" ? For example, for a Mud Server trying to redefine black as white and white as black should the client handle this "?]P0FFFFFFPF000000" or only this "?]P0FFFFFFPF000000?/" given that each redefinition starts with a 'P' and has 7 hex digits afterwards?
N.B. For those with limited fonts '?' should be a graphical representation of the "ESC" character a.k.a. 01/11.
N.B. For those with limited fonts '?' should be a graphical representation of the "ESC" character a.k.a. 01/11.
05 Nov, 2014, Tyche wrote in the 13th comment:
Read backwards…
You should accept the ST terminator, because that's what ANSI-86 requires to terminate the OSC command.
There are multiple implementations of mud servers. That a particular mud server doesn't send ST is not a guarantee that they all won't.
After all it wouldn't be the first time that mud servers have broken protocols.
If you're feeling liberal you would also handle the absence of ST, for that particular command (]P).
You should accept the ST terminator, because that's what ANSI-86 requires to terminate the OSC command.
There are multiple implementations of mud servers. That a particular mud server doesn't send ST is not a guarantee that they all won't.
After all it wouldn't be the first time that mud servers have broken protocols.
If you're feeling liberal you would also handle the absence of ST, for that particular command (]P).
05 Nov, 2014, Kaz wrote in the 14th comment:
It's a quality of implementation issue. The default answer to all questions of this type should be: first, do what the spec says to do. Then, if you can, extend to improve quality and tolerance of poor implementations (or alternatively lobby for poor implementations to be improved.)
05 Nov, 2014, Tyche wrote in the 15th comment:
BTW, I don't know of any mud servers that do use it.
I had put in a VTxxx stack in TeensyMud and looked up to see what I do with it.
It does recognize OSC in the input stream but skips over everything contained in it.
It never sends it.
I had put in a VTxxx stack in TeensyMud and looked up to see what I do with it.
It does recognize OSC in the input stream but skips over everything contained in it.
It never sends it.
06 Nov, 2014, SlySven wrote in the 16th comment:
@Kaz Ah yes that good old recommendation "Be liberal in what you receive and conservative in what you send". Thing is - it sounds like we may never actually encounter it in RL…
Sightly OT but somewhat related has anyone seen in the wild SGR code containing "38"{for foreground or 48 for background}";2"{direct RGB colour space specifier}":<r>"{integer made from ASCII '0' to '9' characters for red component}":<g>"{green component}":<b>"{blue component}":<dummy>"{value not used for first sub parameter ='2'}":<tol>"{tolerance(?) integer}":<tolCSpace>"{integer, '0'="CIELUV", '1'="CIELAB"}" - with every sub parameter after the first being optional and zero if omitted? I understand that broken usage for the first sub-parameter being '5' has resulted often in that case of the sub-parameter separator of ':' being replaced by ';' so I guess I might see the same happening with this bit of the ITU Technical Recommendation T.416 (1993 Edition) available from here…
@Tyche and as for "?]P … ?/" so as for "?]R?/" that resets to "defaults" the effects that the former has!
Sightly OT but somewhat related has anyone seen in the wild SGR code containing "38"{for foreground or 48 for background}";2"{direct RGB colour space specifier}":<r>"{integer made from ASCII '0' to '9' characters for red component}":<g>"{green component}":<b>"{blue component}":<dummy>"{value not used for first sub parameter ='2'}":<tol>"{tolerance(?) integer}":<tolCSpace>"{integer, '0'="CIELUV", '1'="CIELAB"}" - with every sub parameter after the first being optional and zero if omitted? I understand that broken usage for the first sub-parameter being '5' has resulted often in that case of the sub-parameter separator of ':' being replaced by ';' so I guess I might see the same happening with this bit of the ITU Technical Recommendation T.416 (1993 Edition) available from here…
@Tyche and as for "?]P … ?/" so as for "?]R?/" that resets to "defaults" the effects that the former has!
07 Nov, 2014, Kaz wrote in the 17th comment:
SlySven said:
@Kaz Ah yes that good old recommendation "Be liberal in what you receive and conservative in what you send". Thing is - it sounds like we may never actually encounter it in RL…
I did indeed have Postel's Law go *ping!* in the back of my head as I wrote that. I have encountered that in precisely two places in my professional and non-professional career:
1) Where the Spec is ambiguous. For example, in early iterations (and possibly still – I haven't checked in a while) of the Bluetooth test spec, certain requirements were left underspecified (e.g. using the word "average" without mean/median/mode/rms qualifier), resulting in different implementations by different vendors.
2) Baked-in ignorance + cargo-culting. (note: not an insult; just a descriptor. Everyone is ignorant of everything until they somehow become informed). I think the most relevant example of this is the \n\r fiasco (NB. should be \r\n). This incorrect behaviour is so baked-into some servers that clients special-case the \n\r as doing the same thing, even though it is not specified. And then more server implementors who haven't read up on it make the same mistake. Indeed, I recall some implementors implying that they are afraid of *making it correct* just in case it breaks clients (which it wont. Really. You're using a versioning system, right? Git? Svn? Anything? Go change it, and you can back it out with just a few keystrokes as soon as someone complains.)
Random Picks
http://www.mudpedia.org/wiki/OSC_color_p...
It seems like an interesting option to dim colors late at night when your eyes get tired, or to provide players with different color schemes. This could be accomplished using 256 colors, but it would require more work.
If anyone can think of other uses I'd like to hear them.