Bug 243495 - konversation does not support CP949 encoding still.
Summary: konversation does not support CP949 encoding still.
Status: RESOLVED DUPLICATE of bug 243513
Alias: None
Product: konversation
Classification: Applications
Component: general (show other bugs)
Version: 1.3
Platform: Arch Linux Linux
: NOR wishlist
Target Milestone: ---
Assignee: Konversation Developers
Depends on:
Reported: 2010-07-03 15:04 UTC by darklin20
Modified: 2010-07-03 19:28 UTC (History)
1 user (show)

See Also:
Latest Commit:
Version Fixed In:


Note You need to log in before you can comment on or make changes to this bug.
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.
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 ***