What are ideogram escape codes used for in ANSI-compatible terminals - terminal

ANSI X3.64[1] and ECMA-48[2] video terminal escape codes define a set of parameters for Select Graphic Rendition that have to do with ideograms. Specifically:
60 ideogram underline or right side line
61 ideogram double underline or double line on the right side
62 ideogram overline or left side line
63 ideogram double overline or double line on the left side
64 ideogram stress marking
65 cancels the effect of the rendition aspects established by parameter values 60 to 64
Wikipedia lists these codes as "rarely supported" but doesn't go into any detail, and from what I can tell, ECMA-48 is very sparse about the intention behind escape codes.
I'm trying to figure out what these escape codes were intended for, what an implementation for them would look like, and if any video terminals ever actually implemented this.
Any clues would be greatly appreciated!
I've actually only been able to find copies of ECMA-48, so please correct me if I'm making a wrong assumption about X3.64.
https://www.ecma-international.org/publications/files/ECMA-ST/Ecma-048.pdf
https://en.wikipedia.org/wiki/ANSI_escape_code#SGR_(Select_Graphic_Rendition)_parameters (permalink)

Related

Terminal control sequence for character display width?

Correct display of Unicode in a terminal would appear to benefit from the displaying app knowing the number of character cells used to display text. Functions like wcwidth() are a reasonable start, but there can be a lot of variation, for example what a terminal displays for invalid characters, ambiguous width Asian characters, combining characters out of context, etc.
Would it be reasonable to extend terminal apps with a new control sequence to measure with display width of a string, which display apps could use to characterize the terminal? If so, what details are worth considering, e.g. what sequence to use, whether to specify UTF-8, also how to handle terminals that do not know this hypothetical new control sequence? Would it have any likelihood of wide adoption?
If not, what is the flaw in the idea? Is perhaps reading the cursor position after display a better (and already supported) option? Or is there a good different approach?
There's no need, because the existing cursor position report (which can be used to get the position before and after printing a string) gives the length.
Adding a new control sequence to get the attributes of a character (width, combining, controls such as tab) wouldn't help much because the application still has to work with the system's locale information for performance reasons: it would drastically slow down an application if it had to ask after each character where the cursor really was.

Is it possible to separate STDOUT context by its colour?

I'm using the output of the excellent package icdiff (https://github.com/jeffkaufman/icdiff) to check for differences between updated iterations of files. I'd like to parse out just the significant differences though. From the package --help I can't see any in-built options (and for full disclosure I've 'cross posted' at the github issues page to see if it can be added or I've missed something).
This has got me wondering whether a hacky solution might be to parse out the lines by their colour, since they are also colour coded by 'severity of difference'. Is this at all possible in bash? (Alternative approaches are welcome too!)
Here's a sample of the output (I can only think to add a picture here since the markup wouldnt show colour). I'd like to get just the lines where the whole line is solid red/green for instance. Excuse some of the screen wrapping, my monitor isn't wide enough and the text is small enough already.
with GNU Grep, for example
grep -Po $'\e\[31m\K.*(?=\e\[\d+m)'
to extract text in red,
\K to keep the left outside match, like a lookbehind
(?=..) lookahead assertion 0 length match
you can grep on the ANSI escape sequences, e.g. (with 31 for red):
grep '^[\[31m' # make the escape character (^[) by typing ctrl+v ESC
but you need to make sure your output stays colored if it is not sent to a terminal : (many programs will make their output B&W when output is not a terminal. - you can check it with less, which will show you the escape sequences)

Get mouse position in pixels using escape sequences

I'm trying to obtain the position of the mouse in pixels within an application running in a terminal.
The top answer to how to get MouseMove and MouseClick in bash? explains how to get the mouse position, counted in character cells, not in pixels.
I'm looking for a solution which also works if the app is running on a remote server and accessed via SSH (using xdotool will not work in this case, unless ssh -X was used).
I guess the solution will therefore involve escape sequences or an IOCTL.
It's okay if the escape sequences only work with one or few terminal emulators (I can use a detection mechanism to provide a fallback on the terminals which lack support for the escape sequence).
If the escape sequence only works on a few terminal emulators, I'm also curious to know the "group" of escape sequences that allow graphical output on these terminals (e.g. Sixel, Tektronix or ReGIS).
The goal is to embed small GUI elements in mostly text-based applications. It is currently possible on quite a few terminal emulators using Sixel, Tektronix or ReGIS do draw things, and \e[1000h or similar escape codes to get mouse events, unfortunately these mouse events are low-resolution (the coordinates in character cells, not in pixels).
xterm reports the mouse position with pixel resolution with the following escape sequences:
switch on pixel resolution: \e[2;1'z
report mouse position: \e['|
Details are described at http://invisible-island.net/xterm/ctlseqs/ctlseqs.html

As a letter / character may have color? like this: ✔️

I have found this letter / character in facebook, but how can this have a color? is just insane for me, look this: ✔️
Added image (From Firefox on windows)
It's not an ASCII character, it's likely an emoji. Emoji are part of Unicode and the actual glyph displayed to the user is open to interpretation by the platform displaying it. The spec suggests a name/description, but the implementation varies.
So while you may see a colored check mark, I see black & white. Other times, a single glyph will have multiple styles made available on a particular platform; for example, I can select multiple "skin" tones when I use a smiley face on my iPhone, but your Android device may only show a generic one.
Edit: The image edited into the original post is a perfect example. Using Chrome on Windows, I see a black check mark. The screenshot from Firefox shows green.
The symbols used here aren't ascii-encoded. They use the much more vast range of Unicode encoding. Ascii(extended) is restricted to a 256 symbol set.
The unicode interpretation for symbols/glyphs(small pictorial representation)(these ticks aren't characters), can vary for different platforms as some the range of unicode is open for usage and isn't set as global.
Which is why, while the unicode encryption remains the same for every device irrespective, the decryption is differently interpreted by different devices/online-platforms, allowing us to perceive either a coloured or a black symbol.

Displaying temperature symbol

I am trying to output degree centigrade symbol from atmega2560 from serial port. I looked up at ascii table. The ascii code it said was 167. When I tried it there was another symbol instead which I can't show here. After doing little bit of research, I tried 0167+248. It displayed '○' instead of '°'. Other posts said that Alt + 167 works but could not find ascii code for Alt. Any suggestions ?
I am trying to output degree centigrade symbol from atmega2560 from serial port. I looked up at ascii table. The ascii code it said was 167.
The format of the extended ASCII table (symbols from 127 to 255) depends on the code page that is used.
When I tried it there was another symbol instead which I can't show here.
You should figure out on what code page you are currently working. Like ISO 8859-1 (Latin-1) for example.
Other posts said that Alt + 167 works but could not find ASCII code for Alt.
What they meant is to press the ALT key and enter 167 on the numpad. This prints the character on position 167 (decimal) from the current code page.
Remember that the ASCII value that is send from the micro controller is just interpreted on the receiver side according on its code page.
You can refer
U+2103
Image
Server-generated
℃
Decimal Escape
℃
℃
Hex Escape
℃
℃
UTF-8

Resources