Bug 127809 - [httx] does not shows any candidate and status for non-UTF-8 locale
[httx] does not shows any candidate and status for non-UTF-8 locale
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: im-sdk (Show other bugs)
rawhide
All Linux
medium Severity medium
: ---
: ---
Assigned To: Leon Ho
: i18n
Depends On:
Blocks: IIIMF
  Show dependency treegraph
 
Reported: 2004-07-14 00:39 EDT by Leon Ho
Modified: 2007-11-30 17:10 EST (History)
2 users (show)

See Also:
Fixed In Version: im-sdk-12.1-9.EL
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2004-11-23 20:10:07 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Xft patches to use wchar (7.63 KB, patch)
2004-10-18 01:05 EDT, Leon Ho
no flags Details | Diff
minor fix (7.98 KB, patch)
2004-10-19 05:18 EDT, Akira TAGOH
no flags Details | Diff

  None (edit)
Description Leon Ho 2004-07-14 00:39:16 EDT
Description of problem:
Currently user in fedora-i18n-list reported that they couldn't able to
get IIIMF working in KDE with ja_JP.eucJP. Candidate glyphs do not show.

Version-Release number of selected component (if applicable):


How reproducible:
everytime

Steps to Reproduce:
1. LANG=ja_JP.eucJP httx
2. LANG=ja_JP.eucJP XMODIFIERS=@im=htt kedit
3. ctrl-space
  
Actual results:
no status text

Expected results:
have status text

Additional info:
Reason being the httx is calling XftDrawStringUtf8(). We may need to
convert text to utf-8 if it is a non-utf8 locale.
Comment 1 Leon Ho 2004-10-13 22:56:06 EDT
Pretty important for at least backward support on legacy encodings for
enterprise customers.

Got a cycle... Will look into this tonight.
Comment 2 Leon Ho 2004-10-18 01:05:23 EDT
Created attachment 105362 [details]
Xft patches to use wchar

Here is the initial patch to support using wchar and wchar drawing functions to
render strings. UTF-8 and non-UTF-8 locales should look better with this patch.

Tagoh-san, Shao, would you please have a breif sane check if it is possible to
include into the package. Thanks.
Comment 3 Akira TAGOH 2004-10-19 05:18:29 EDT
Created attachment 105428 [details]
minor fix
Comment 4 Leon Ho 2004-10-19 23:49:29 EDT
Xft patches are merged and this problem is fixed in im-sdk 12.1-2
Comment 5 Lawrence Lim 2004-10-20 05:40:54 EDT
Candidates in the candidate window in now showing. However, we have
some problem. Saving the document in kedit and open in gedit changes
the chars in the document. 

Question:
Does the patch convert the committed characters to UTF-8? Or
everything is done in eucJP?


Thanks.
Comment 6 Leon Ho 2004-10-20 10:59:24 EDT
If you already did a save, then it is up to application level not
input level already, and it is outside this bug's scope.

Please check what encoding have you saved, and what encoding you used
in gedit to open the file.
Comment 7 Lawrence Lim 2004-11-23 04:00:02 EST
Confirmed fixed for ja_JP.eucJP, ko_KR.eucKR, zh_TW.Big5 and
zh_CN.GB2312. However, I cant get it to work properly in
zh_CN.GB18030. Is this the correct behaviour?
Comment 8 Leon Ho 2004-11-23 05:28:20 EST
Lawrence, it is not correct behavior but it is a seperate bug as this
solely used IIimpMbstoWcs() in IIIMP and that function uses
_XlcConvert() in X to convert from multibyte to widechar. It is up to
those functions so problems may lie around on that path. Please submit
another bug so that we can keep track properly. Thanks!
Comment 9 Lawrence Lim 2004-11-23 20:10:07 EST
Bug 140657 filed for GB18030 locale.

Note You need to log in before you can comment on or make changes to this bug.