Bug 173102 - unicode input with SCIM
unicode input with SCIM
Product: Fedora
Classification: Fedora
Component: scim (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Jens Petersen
: FutureFeature, i18n
Depends On:
Blocks: SCIM
  Show dependency treegraph
Reported: 2005-11-14 01:05 EST by Lawrence Lim
Modified: 2014-03-25 20:52 EDT (History)
3 users (show)

See Also:
Fixed In Version: scim-1.4.4-9
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2006-03-13 09:16:16 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
The patch to fix this issue. (1.52 KB, patch)
2006-01-18 00:49 EST, James Su
no flags Details | Diff

  None (edit)
Description Lawrence Lim 2005-11-14 01:05:35 EST
Description of problem:
Is it possible for SCIM to support the input whole repertoire of Unicode 3.0?
Specifically, tried to enter 000A and noticed nothing happen.

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

How reproducible:

Steps to Reproduce:
1.start gedit
2.choose RAW CODE IME from Others group
3.enter 000a
Actual results:
Nothing happen

Expected results:
000a == New Line, hence, cursor should go next line

Additional info:
Comment 1 James Su 2006-01-10 23:11:59 EST
It works for me.
Comment 2 Lawrence Lim 2006-01-16 01:35:09 EST
That's strange. With scim-tables-0.5.5-2 and scim-1.4.2-9, choosing RawCode with
Unicode or UTF-8 both does not respond to 000a.
Comment 3 Akira TAGOH 2006-01-17 03:17:33 EST
I tried RawCode IME in scim-1.4.2-9. it looks like assuming 6 digit characters
but not 4 digit characters. so if you want to input \n, 00000a works.
James, you mean even 4 digit characters works for you?
Comment 4 James Su 2006-01-17 23:37:07 EST
Yes. At least, 000a works in gedit. However you need press space after inputting
000a to commit it.
Comment 5 Akira TAGOH 2006-01-18 00:05:37 EST
Hmm, ok. it works for me as well. but it's an undocumented behavior and isn't
what we expected. in common practice to describe the Unicode codepoint like
U+10000, zero is getting suppressed when it's over 4 digit characters. so how
about assuming 4 digit characters when the beginning of character is 0?
Comment 6 James Su 2006-01-18 00:19:41 EST
So that the code like U+20547 can only be inputted with 20547 rather than
020547? Hmm, I think it should be ok. I'll post a patch as soon as possible.
Comment 7 Akira TAGOH 2006-01-18 00:39:43 EST
yes AFAICS. and it saves your time to support another range when Unicode x.y
grow up their supported Unicode code range.
Comment 8 Akira TAGOH 2006-01-18 00:41:48 EST
well, with keeping the backward compatibility anyway.
Comment 9 James Su 2006-01-18 00:49:02 EST
Created attachment 123353 [details]
The patch to fix this issue.

Please test this patch. It's for scim 1.4.4
Comment 10 Akira TAGOH 2006-01-20 07:59:02 EST
Comment #9:
I've tested scim with your patch. it fixes this problem. thanks.
Comment 11 Jens Petersen 2006-02-03 04:16:00 EST
Thank you.  Adding patch to scim-1.4.4-2 build.
Comment 12 A S Alam 2006-03-13 09:16:16 EST
with OOOA, cursor shift to next Line in gedit (Raw Code input), this is expected
Tested with: scim-1.4.4-9 on FC5test3 (Rawhide)

Closing bug

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