I'm quite curious here, because I added C1 (even in UTF-8) support to VTE (GNOME Terminal) because of this very bugreport. Later I think I regretted that decision, but it's likely to stay because the main developer wants to keep it. See https://bugzilla.gnome.org/show_bug.cgi?id=730154 and https://gitlab.gnome.org/GNOME/vte/-/issues/209. So... @boon, you have to have your terminal configured to use ISO-8859-1 or so, setting it to UTF-8 cannot work with your application. Is this correct? And if your terminal removed support for non-UTF-8, which might happen sooner or later with VTE, you'll be screwed at those raw C1 bytes. Right? You'd have to look for a different terminal emulator, or some other workaround. (Just for curiosity: does your app output any printable 0xA0..0xFF ISO-8859-1 accented letters and other symbols that need to be properly handled, or is it solely the C1 ones?) So suppose VTE / GNOME Terminal removes support for encodings other than UTF-8, which breaks your app. And suppose that you'd prefer to keep using VTE rather than switching to e.g. Xterm. --- My first thought: The obvious well-known workaround is to use "luit", a tool that's supposed to convert data between the terminal's UTF-8 and the app's ISO-8859-1 (or similar) encoding. However, it seems to me that if an application emits a raw C1 byte in ISO-8859-1, luit leaves that as that raw byte (hence producing invalid UTF-8) rather than converting it to the corresponding U+0080..U+009F character. The standard charset conversion method iconv() does this conversion correctly, and in Unicode the characters U+0080..U+009F are defined to be the same as the bytes 0x80..0x9F of ISO-8859-1. That is, it seems to me (without having checked its source) that "luit" explicitly, deliberately breaks these characters, rather than letting them through properly converted to UTF-8 and letting the terminal emulator decide what to do with them. Of course you might patch it to fix it, and if you decide to do so, you might as well add C1 -> C0 conversion to it, I guess it might not be that hard. --- An alternate approach is to use "screen". Start it up, press ^A and then type ":encoding iso-8859-1". This switches the inside encoding, but leaves the outside encoding (towards the graphical terminal) at UTF-8. It understands C1 controls (e.g. printf 'normal \x9b1m bold' works as expected), and it converts them to C0 towards the graphical emulator. (This latter claim I can confirm by running a "script" outside of "screen", but it also makes sense: "screen" cannot pass-thru these controls; in order to implement scrolling, detached operation, reattaching etc. it has to imagine what state its charcells are (e.g. bold) and has to implement that look in the outer terminal, there's no room here for remembering and would be no point in remembering what control operation resulted in that bold cell being there in its memory.) Maybe "tmux" also supports this kind of conversion, I don't know. --- Currently there's 1 person I'm aware of who uses C1 support of VTE, that's you. You use it with non-UTF-8, with UTF-8 it's useless for you. If VTE dropped support for non-UTF-8, the number of C1 users I'm aware of would drop to 0. If VTE dropped support for non-UTF-8, and you decided you'd prefer to keep using VTE, you'd have to look for some workaround. If you decided to use "screen", you wouldn't need C1 support in VTE. If you decided to use "luit", you'd have to patch it, and then presumably with a tiny bit of extra work you could patch it to do the C1 -> C0 conversion too and then again you wouldn't need C1 support in VTE. Am I on the right tracks?