Bug 127809

Summary: [httx] does not shows any candidate and status for non-UTF-8 locale
Product: [Fedora] Fedora Reporter: Leon Ho <llch>
Component: im-sdkAssignee: Leon Ho <llch>
Status: CLOSED RAWHIDE QA Contact:
Severity: medium Docs Contact:
Priority: medium    
Version: rawhideCC: eng-i18n-bugs, wtogami
Target Milestone: ---Keywords: i18n
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: im-sdk-12.1-9.EL Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2004-11-24 01:10:07 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 125997    
Attachments:
Description Flags
Xft patches to use wchar
none
minor fix none

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.