Bug 243495

Summary:	konversation does not support CP949 encoding still.
Product:	[Applications] konversation	Reporter:	darklin20
Component:	general	Assignee:	Konversation Developers <konversation-devel>
Status:	RESOLVED DUPLICATE
Severity:	wishlist	CC:	hein
Priority:	NOR
Version:	1.3
Target Milestone:	---
Platform:	Arch Linux
OS:	Linux
Latest Commit:		Version Fixed In:
Sentry Crash Report:

Description darklin20 2010-07-03 15:04:11 UTC

Version:           1.3 (using KDE 4.4.4) 
OS:                Linux

There's two encoding for Korean, EUC-KR and CP949, and Qt4 supports both of them.
But konversation 1.3 which is based on KDE4, so also Qt4 supports EUC-KR only.
CP949 is superset of EUC-KR, so when the the IRC server encoding is CP949, konversation with EUC-KR cannnot display or transport some characters.

Is it difficult for konversation to give another selection of CP949 for Korean encoding?
I think if konversation uses QTextCodec, it is simply possible by adding CP949 item.

Reproducible: Always

Steps to Reproduce:
Input a korean character which included in CP949 not EUC-KR like '잌'.

Actual Results:  
I get "Encoding Conflict Warning" message box.

Expected Results:  
By enabling CP949 encoding, there should be no problem.

Comment 1 Eike Hein 2010-07-03 15:37:56 UTC

Should be simple, yes, we just weren't aware of it / nobody else had asked for it so far. Thanks for your report, we'll look into adding it quickly.

Comment 2 Eike Hein 2010-07-03 15:49:21 UTC

Might actually not that simple -- we get the lists of character sets from kdelibs' KGlobal::charsets(), and KDE doesn't seem to support CP949 there right now. So the fix probably needs to be made in kdelibs, then Konvi would pick it up automatically. Since we ultimately use QTextCodec though we could special-case on Konvi's end until kdelibs gets fixed.

Comment 3 darklin20 2010-07-03 16:51:03 UTC

You mean that it's the problem of kdelibs rather konversation, right?
It looks like KCharsets also uses QTextCodec, so maybe this problem easily.
Anyway, I'll report this problem to kdelibs again.
Thanks for replying, Hein.

Comment 4 Eike Hein 2010-07-03 18:23:48 UTC

Yep, if KGlobal::charsets()->descriptiveEncodingNames() would return CP949, Konversation would make it available automatically.

Comment 5 darklin20 2010-07-03 19:17:46 UTC

I registered this problem as new feature of kdecore.
https://bugs.kde.org/show_bug.cgi?id=243513
Thanks again.

Comment 6 Eike Hein 2010-07-03 19:28:26 UTC

Thank you, I'm going to close this one as a duplicate then.

For the record, if you are building Konversation yourself and want to fix the problem locally until kdelibs is fixed, take a look at irc/irccharsets.cpp, specifically the IRCCharsets constructor. That's where it gets the list from kdelibs. You could easily put a hack there to add CP949 to the list.

*** This bug has been marked as a duplicate of bug 243513 ***