Bug 96280 - Character set selection no longer operative; breaks backwards compatibility; xterm vs Linux console
Summary: Character set selection no longer operative; breaks backwards compatibility; ...
Status: RESOLVED UNMAINTAINED
Alias: None
Product: konsole
Classification: Applications
Component: emulation (show other bugs)
Version: 1.4.1
Platform: RedHat Enterprise Linux Linux
: NOR wishlist
Target Milestone: ---
Assignee: Konsole Developer
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2005-01-04 11:54 UTC by H. Peter Anvin
Modified: 2017-02-13 02:52 UTC (History)
1 user (show)

See Also:
Latest Commit:
Version Fixed In:
Sentry Crash Report:


Attachments
Non-UTF8 test case (39 bytes, text/plain)
2005-01-05 03:09 UTC, H. Peter Anvin
Details
UTF-8 test case (93 bytes, text/plain)
2005-01-05 03:10 UTC, H. Peter Anvin
Details
Non-UTF8 test case with G1 setting (45 bytes, text/plain)
2005-01-05 03:27 UTC, H. Peter Anvin
Details

Note You need to log in before you can comment on or make changes to this bug.
Description H. Peter Anvin 2005-01-04 11:54:04 UTC
Version:           1.4.1 (using KDE KDE 3.3.1)
Installed from:    RedHat RPMs
Compiler:          gcc-3.4.2 
OS:                Linux

It seems that the use of ISO 2022 codes - including <SI> and <SO> to select the DEC graphics character set - to select character sets has been completely disabled in konsole 1.4.1, with the sole exception of <ESC> % G and <ESC> % @ to switch in and out of UTF-8 mode.  As far as I can tell, it looks like recent xterms behave the same.

Unfortunately, this severely breaks a number of older applications, some which aren't even running on Linux, and are not possible to change.

As an additional complication, Linux window terminals like konsole tend to be compatible with xterm, as opposed to the Linux text console.  This is somewhat awkward, especially since there are any number of xterm versions out there, and the newer ones seem to have broken what little commonality one can count on when one sees TERM=xterm.

The Linux implementation of ISO 2022 is severely broken, but at least it is self-consistent.  Perhaps as a result, Linux emulation is now a standard feature in decent Windows terminal emulators!  Perhaps konsole should, at least as an option, emulate a Linux console instead of an xterm?
Comment 1 Waldo Bastian 2005-01-04 12:35:28 UTC
SI and SO are being handled, see TEmuVt102.cpp

    case TY_CTL___('N'      ) :      useCharset           (         1); break; //VT100
    case TY_CTL___('O'      ) :      useCharset           (         0); break; //VT100

Perhaps the required graphical characters are not available in the font that you are using?
Comment 2 H. Peter Anvin 2005-01-05 03:09:53 UTC
Created attachment 8928 [details]
Non-UTF8 test case
Comment 3 H. Peter Anvin 2005-01-05 03:10:17 UTC
Created attachment 8929 [details]
UTF-8 test case
Comment 4 H. Peter Anvin 2005-01-05 03:26:32 UTC
Okay, after groping around for a while I think the problem is that the default setting of the G1 character set is not the DEC graphics character set, which is the VT1xx-compatible setting and as far as I know the VT2xx reset state.  Furthermore, however, there is still a number of characters missing from the translation.  I have posted three files:

test1.plain - Just reset and trying SO/SI
test1.utf8  - The whole thing in UTF-8 mode
test1.setg1 - Same as test1.plain, but explicitly configures the G1 character set

In my understanding, these files should all produce the same output starting from the terminal reset configuration.

Comment 5 H. Peter Anvin 2005-01-05 03:27:14 UTC
Created attachment 8930 [details]
Non-UTF8 test case with G1 setting
Comment 6 Robert Knight 2008-03-18 02:42:26 UTC
> Unfortunately, this severely breaks a number of older applications,
> some which aren't even running on Linux, and are not possible to change. 

What applications?  Is this still a problem?
Comment 7 Robert Knight 2008-05-23 21:56:37 UTC
Without a response to comment #6 I will have to assume that this is no longer a problem.  Please reply if you wish me to reopen.
Comment 8 H. Peter Anvin 2008-05-24 00:58:26 UTC
Hello,

Sorry about this.

I just tried this on konsole 3.6.6 from Fedora 8,kdebase-3.5.9-7.fc8.x86_64.rpm. It's still broken, I'm afraid, which means that trying to connect to a pre-Unicode system gets garbled output from any applications that tries to draw borders or other lines as part of its user interface.

For DEC VT series compatibility, as well as Linux console compatibility, the G1 character set at reset should be the DEC VT set; and as you should be able to see from the output difference from the test cases, the translation from DEC VT to Unicode is incomplete; characters are missing.

Please reopen.
Comment 9 Robert Knight 2008-05-24 01:42:02 UTC
Re-opening as per comment #8
Comment 10 Adam Hunt 2015-10-07 17:00:21 UTC
KDE 3.x and Konsole 1.x are ancient. Recommend close bug WONTFIX.