[I18n] patches to luit for (hkscs + gb18030) support
Hi,
I have filed a bug and submitted patches for 'hkscs and gb18030 support'
for luit.
Bug ID is 1048. The patch is attached also. Please note that the patch
depends on the GB18030 fontmap to work properly, which reside in xfree
cvs 'xc/fonts/encoding/large/gb18030*'
Regards,
Zarick
--
ThizLinux Laboratory Limited
Address: Unit 502-505, 5/F, Tower 3,
Enterprise Square, 9 Sheung Yuet Road,
Kowloon Bay, Hong Kong
Telephone: (852) 2735 2725
Direct Line: (852) 3184 1311
Fax: (852) 2111 0702
diff -u xc.orig/programs/luit/charset.c xc/programs/luit/charset.c
--- charset.c 22 Dec 2003 17:48:12 - 1.8
+++ charset.c 2 Jan 2004 03:42:49 -
@@ -154,6 +154,8 @@
{GBK, init_gbk, mapping_gbk, reverse_gbk, stack_gbk},
{UTF-8, init_utf8, mapping_utf8, reverse_utf8, stack_utf8},
{SJIS, init_sjis, mapping_sjis, reverse_sjis, stack_sjis},
+{BIG5-HKSCS, init_hkscs, mapping_hkscs, reverse_hkscs, stack_hkscs},
+{GB18030, init_gb18030, mapping_gb18030, reverse_gb18030, stack_gb18030},
{0, 0, 0, 0, 0}
};
@@ -418,6 +420,8 @@
{ gbk, 0, 1, NULL, NULL, NULL, NULL, GBK},
{ UTF-8, 0, 1, NULL, NULL, NULL, NULL, UTF-8},
{ SJIS, 0, 1, NULL, NULL, NULL, NULL, SJIS},
+{ Big5-HKSCS, 0, 1, NULL, NULL, NULL, NULL, BIG5-HKSCS},
+{ gb18030, 0, 1, NULL, NULL, NULL, NULL, GB18030},
{ 0, 0, 0, 0, 0, 0, 0}
};
diff -u xc.orig/programs/luit/iso2022.c xc/programs/luit/iso2022.c
--- iso2022.c 8 Dec 2002 20:19:49 - 1.9
+++ iso2022.c 2 Jan 2004 03:42:49 -
@@ -623,7 +623,7 @@
is-parserState = P_ESC;
} else if(OTHER(is) != NULL) {
int c = OTHER(is)-other_stack(*s, OTHER(is)-other_aux);
-if(c = 0) {
+if(c != -1) {
outbufUTF8(is, fd, OTHER(is)-other_recode(c, OTHER(is)-other_aux));
is-shiftState = S_NORMAL;
}
diff -u xc.orig/programs/luit/other.c xc/programs/luit/other.c
--- other.c 17 Oct 2002 01:06:09 - 1.1
+++ other.c 2 Jan 2004 03:42:49 -
@@ -244,3 +244,182 @@
}
}
+int
+init_hkscs(OtherStatePtr s)
+{
+s-hkscs.mapping =
+FontEncMapFind(big5hkscs-0, FONT_ENCODING_UNICODE, -1, -1, NULL);
+if(!s-hkscs.mapping) return 0;
+
+s-hkscs.reverse = FontMapReverse(s-hkscs.mapping);
+if(!s-hkscs.reverse) return 0;
+
+s-hkscs.buf = -1;
+return 1;
+}
+
+unsigned int
+mapping_hkscs(unsigned int n, OtherStatePtr s)
+{
+unsigned int r;
+if(n 128) return n;
+if(n == 128) return EURO_10646;
+r = FontEncRecode(n, s-hkscs.mapping);
+return r;
+}
+
+unsigned int
+reverse_hkscs(unsigned int n, OtherStatePtr s)
+{
+if(n 128) return n;
+if(n == EURO_10646) return 128;
+return s-hkscs.reverse-reverse(n, s-hkscs.reverse-data);
+}
+
+int
+stack_hkscs(unsigned char c, OtherStatePtr s)
+{
+if(s-hkscs.buf 0) {
+if(c 129) return c;
+s-hkscs.buf = c;
+ return -1;
+} else {
+int b;
+if(c 0x40 || c == 0x7F) {
+s-hkscs.buf = -1;
+return c;
+}
+if(s-hkscs.buf 0xFF c 0xFF)
+b = (s-hkscs.buf 8) + c;
+else
+b = -1;
+s-hkscs.buf = -1;
+return b;
+}
+}
+
+
+/*
+ * Because of the 1 ~ 4 multi-bytes nature of GB18030.
+ * CharSet encoding is split to 2 subset (besides latin)
+ * The 2Bytes MB char is defined in gb18030.2000-0
+ * The 4Bytes MB char is defined in gb18030.2000-1
+ * Please note that the mapping in 2000-1 is not a 4Bytes seq = 2Bytes value
+ * mapping.
+ * To use the 2000-1 we need to 'linear' the 4Bytes sequence and 'lookup' the
+ * unicode value after that.
+ *
+ * For more info on GB18030 standard pls check:
+ *http://oss.software.ibm.com/icu/docs/papers/gb18030.html
+ *
+ * For more info on GB18030 implementation issues in XFree86 pls check:
+ *http://www.ibm.com/developerWorks/cn/linux/i18n/gb18030/xfree86/part1
+ */
+int
+init_gb18030(OtherStatePtr s)
+{
+s-gb18030.cs0_mapping =
+FontEncMapFind(gb18030.2000-0, FONT_ENCODING_UNICODE, -1, -1, NULL);
+if(!s-gb18030.cs0_mapping) return 0;
+
+s-gb18030.cs0_reverse = FontMapReverse(s-gb18030.cs0_mapping);
+if(!s-gb18030.cs0_reverse) return 0;
+
+s-gb18030.cs1_mapping =
+FontEncMapFind(gb18030.2000-1, FONT_ENCODING_UNICODE, -1, -1, NULL);
+if(!s-gb18030.cs1_mapping) return 0;
+
+s-gb18030.cs1_reverse = FontMapReverse(s-gb18030.cs1_mapping);
+if(!s-gb18030.cs1_reverse) return 0;
+
+s-gb18030.linear = 0;
+s-gb18030.buf_ptr = 0;
+return 1;
+}
+
+unsigned int
+mapping_gb18030(unsigned int n, OtherStatePtr s)
+{
+if(n = 0x80) return n; /* 0x80 is valid but unassigned codepoint */
+if(n = 0x) return '?';
+
+return FontEncRecode(n,
+(s-gb18030.linear)?s-gb18030.cs1_mapping:s-gb18030.cs0_mapping);
+}
+
+unsigned int
Re: [I18n] Re: [XFree86] PROBLEM IN X11R6
sudarsana narashiman wrote: I am Sudarsan.I tried for TAMIL LANGUAGE phonetic keyboard support in Linux(X11R6).But Linux does not support phonetic keyboard layouts. The current character displayed depends on the previous character and the current key pressed. Not only TAMIL language all other indian language also has the same problem. I don't think an input method is _required_ for Indic scripts. It could be handy and convenient, but not necessary. I guess you thought you need an input method because you want to translate 'phonetic' (alphabetic) keyboard input to glyph-based encoding like TSCII and TAM. Why would you do that? If you just use Unicode, there's little need (as I wrote above, it could be handy) for input method because you can make (almost) 1:1 mapping between Tamil letters in Unicode and keys. Jungshik ___ I18n mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/i18n
Re: Re: [I18n] Re: [XFree86] PROBLEM IN X11R6
hello, I am Sudarsan.I tried for TAMIL LANGUAGE phonetic keyboard support in Linux(X11R6).But Linux does not support phonetic keyboard layouts. By this what i mean is k+u=190 //character equivalent to 190 will be displayed. and if u is pressed again now it becomes k+u+u=200//character for 190 will be erased and character for 200 will be displayed. so above process needs some memory to store the previous character. The current character displayed depends on the previous character and the current key pressed. Not only TAMIL language all other indian language also has the same problem. Now i created a parse rule for it. I am in the process of writing a C program for it. I want to integrate this program in to the existing X11R6. can any one tell me how to do that?and the documents that i have to read for it. regards, sudarsan.
Re: [I18n] locale.alias for ko_KR.EUC-KR
On Mon, Dec 22, 2003 at 11:48:30PM +0900, Jungshik Shin wrote: On Wed, 17 Dec 2003, David Dawes wrote: On Thu, Dec 18, 2003 at 09:37:04AM +0800, James Su wrote: This patch fixes a bug in locale.alias which breaks the zh_CN.GB2312 locale. I've committed both of your patches there. Could you commit the following patch (to locale.alias) as well? Although I don't use ko_KR.EUC-KR locale so often these days (having switched to UTF-8 locale), it's one of things I have to 'fix' when I install Linux on a new computer. It's so trivial that I didn't bother to file a bug at bugzilla. Done. David -- David Dawes developer/release engineer The XFree86 Project www.XFree86.org/~dawes ___ I18n mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/i18n
Re: [I18n] XIM_STR_CONVERSION_REPLY message is strange
On Sat, Dec 27, 2003 at 01:10:31AM +0900, Choe Hwanjin wrote:
Hello,
I have a question about XIM_STR_CONVERSION_REPLY message.
On XIM spec, XIM_STR_CONVERSION_REPLY is defined as:
2 CARD16input-method-ID
2 CARD16input-context-ID
4 CARD32XIMStringConversionFeedback
XIMSTRCONVTEXTXIMStringConversionText
XIMSTRCONVTEXT is defined to include a CARD16 XIMStringConversionFeedback
too, so the separate field above looks redundant.
but xfree86 source does not conform to this.
xc/lib/X11/imCallbk.c:394 is :
_XimSetHeader((XPointer)buf, XIM_STR_CONVERSION_REPLY, 0, buf_len);
buf_len -= XIM_HEADER_SIZE; /* added by _XimSetHeader (HACK) */
p = XIM_HEADER_SIZE;
*(CARD16*)buf[p] = (CARD16)im-private.proto.imid; p += sz_CARD16;
*(CARD16*)buf[p] = (CARD16)ic-private.proto.icid; p += sz_CARD16;
*(CARD16*)buf[p] = (CARD16)cbrec.text-length; p += sz_CARD16;
~
+ this is not XIMStringConversionFeedback
memcpy(buf[p],cbrec.text-string.mbs,length_in_bytes);
p += length_in_bytes;
*(CARD16*)buf[p] = (CARD16)(sz_CARD32*cbrec.text-length);
p += XIM_PAD(2);
for (i = 0; i (int)cbrec.text-length; i++) {
*(CARD32*)buf[p] = (CARD32)cbrec.text-feedback[i];
p += sz_CARD32;
}
I'm not sure if the buffer length is calculated correctly either.
On the other hand, IMdkit comform to XIM spec, it define structure for
XIM_STR_CONVERSION_REPLY as:
xim_externaldef XimFrameRec str_conversion_reply_fr[] =
{
_FRAME(BIT16), /* input-method-ID */
_FRAME(BIT16), /* input-context-ID */
_FRAME(BIT32), /* XIMStringConversionFeedback */
_FRAME(BIT16), /* length of the retrieved string */
_FRAME(BARRAY), /* retrieved string */
_PAD4(2),
_BYTE_COUNTER(BIT16, 2),/* number of feedback array */
_PAD4(1),
_FRAME(ITER), /* feedback array */
_FRAME(BIT32),
_FRAME(EOL),
};
Which is right?
That's a good question. What do working XIM servers expect?
David
--
David Dawes X-Oz Technologies
www.XFree86.org/~dawes www.x-oz.com
___
I18n mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/i18n
