I'm writing an application for the non-GUI text terminal in Raspian Linux in C++ using the ncursesw library. I found out by accident that if you print anything with mvwaddch using A_ALTCHARSET (e.g. mvwaddch(stdscr, 1, 1, A_ALTCHARSET | 65);
), then the entire Extended ASCII character set (0 - 255) becomes available to mvadd_wch starting from index 0xF000.
It doesn't look like 0xF000 is an official mapping for the UTF-8 locale that my terminal is configured for. Somehow the ncursesw library triggers the system to load up these characters.
How is this done? Is there a way to load up this character set without first writing junk data using A_ALTCHARSET?
It may be enough for my purposes to use a mvwaddch(stdscr, 0, 0, A_ALTCHARSET);
to print a null character when the program initializes. But I would still like to know what is happening behind the scenes here.
ncurses has to support certain terminal descriptions which send "8-bit" codes for the alternate character set feature. The Linux console happens to be a commonly-used case. There's a few places in the source-code which you would find helpful to understand, e.g., in the update-code.
/*
* If the character falls into any of these special cases, do
* not force the result to a blank:
*
* a) it is printable (this works around a bug in wcwidth()).
* b) use_legacy_coding() has been called to modify the treatment
* of codes 128-255.
* c) the acs_map[] has been initialized to allow codes 0-31
* to be rendered. This supports Linux console's "PC"
* characters. Codes 128-255 are allowed though this is
* not checked.
*/
The Linux console has no special knowledge of PC-character sets (the console_codes manual page mentions only UTF-8 and ISO-8859-1), but the showconsolefont
command uses a Linux ioctl to allow it to print a table of 256 codes, which depending upon the font which has been loaded, will match some PC code-page (see my answer to Why does showconsolefont
have different output in tmux
?).