Bug 127809 - [httx] does not shows any candidate and status for non-UTF-8 locale
Summary: [httx] does not shows any candidate and status for non-UTF-8 locale
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Fedora
Classification: Fedora
Component: im-sdk
Version: rawhide
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Leon Ho
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks: IIIMF
TreeView+ depends on / blocked
 
Reported: 2004-07-14 04:39 UTC by Leon Ho
Modified: 2007-11-30 22:10 UTC (History)
2 users (show)

Fixed In Version: im-sdk-12.1-9.EL
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2004-11-24 01:10:07 UTC
Type: ---
Embargoed:


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

Description Leon Ho 2004-07-14 04:39:16 UTC
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-14 02:56:06 UTC
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 05:05:23 UTC
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 09:18:29 UTC
Created attachment 105428 [details]
minor fix

Comment 4 Leon Ho 2004-10-20 03:49:29 UTC
Xft patches are merged and this problem is fixed in im-sdk 12.1-2

Comment 5 Lawrence Lim 2004-10-20 09:40:54 UTC
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 14:59:24 UTC
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 09:00:02 UTC
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 10:28:20 UTC
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-24 01:10:07 UTC
Bug 140657 filed for GB18030 locale.


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