From owner-freebsd-i18n Fri Dec 22 0:38:38 2000 From owner-freebsd-i18n@FreeBSD.ORG Fri Dec 22 00:38:35 2000 Return-Path: Delivered-To: freebsd-i18n@freebsd.org Received: from sraigw.sra.co.jp (sraigw.sra.co.jp [202.32.10.2]) by hub.freebsd.org (Postfix) with ESMTP id EC2B737B400 for ; Fri, 22 Dec 2000 00:38:34 -0800 (PST) Received: from sranhf.sra.co.jp (sranhf [133.137.28.3]) by sraigw.sra.co.jp (8.8.7/3.7W-sraigw) with ESMTP id RAA24030; Fri, 22 Dec 2000 17:38:21 +0900 (JST) Received: from srapc342.sra.co.jp (root@srapc342 [133.137.28.111]) by sranhf.sra.co.jp (8.8.7/3.6Wbeta7-srambox) with ESMTP id RAA13540; Fri, 22 Dec 2000 17:38:20 +0900 (JST) Received: (from soda@localhost) by srapc342.sra.co.jp (8.8.8/3.4W-sra) id RAA19423; Fri, 22 Dec 2000 17:38:19 +0900 (JST) Date: Fri, 22 Dec 2000 17:38:19 +0900 (JST) Message-Id: <200012220838.RAA19423@srapc342.sra.co.jp> From: Noriyuki Soda To: i18n@XFree86.Org Cc: xorg_i18n@x.org, bsd-locale@hauN.org, li18nux@li18nux.net, tech-x11@netbsd.org, i18n@freebsd.org, tech@openbsd.org Subject: Re: Restart: better XI18N future API In-Reply-To: <20001221.160155.125112926.hiura@Eng.Sun.COM> References: <20001221.160155.125112926.hiura@Eng.Sun.COM> Sender: owner-freebsd-i18n@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG >>>>> On Thu, 21 Dec 2000 16:01:55 -0800 (PST), hiura@unicode.org said: > Here is the consideration. > If XmbDrawString takes "encoding" parameter, such as > XmbDrawString(....., encoding, string, ..), it perfoms > the same as > Xutf8DrawString(....., string, ..) > when the encoding parameter is set to UTF-8. > Let's call XmbDrawString(....., encoding, string, ..) as > XembDrawString, stands for X encoded multi-byte DrawString for > now for the sake of discussion. I believe this is not good API as I posted previous mail. Because Output Context is encoding dependent, thus, passing encoding parameter to XmbDrawString breaks current abstraction about output context. (What happens when a string which cannot be displayed by the fontset parameter passed to the XembDrawString?) And because of above reason, implementation is hard, and cannot be right. I think the right way to solve multi-thread/multi-locale problem is to create three APIs which have locale parameter (not encoding parameter). - XLocaleNameOfEncoding(locale_name, encoding_name) This is generalized version of XFree86UTF8Locale() which I wrote before. This function returns locale name which correspond to locale_name parameter, but changes its encoding to encoding_name parameter. The first parameter locale_name is Operating System dependent. The second parameter encoding_name should be standardized by X Consortium. The return value is Operating System dependent. The implementation of this function should be Operating System dependent unless X_LOCALE is used. Note that this function may return NULL, when the encoding_name is not supported on the Operating System. e.g. XLocaleNameOfEncoding("en_US.ISO8859-1", "UTF-8") -> "en_US.UTF-8" XLocaleNameOfEncoding("C", "UTF-8") -> "en_US.UTF-8" XLocaleNameOfEncoding("C", "eucJP") -> "ja_JP.eucJP" XLocaleNameOfEncoding("zh_CN.eucCN", "UTF-8") -> "zh_CN.UTF-8" XLocaleNameOfEncoding("ja_JP.UTF-8", "eucJP") -> "ja_JP.eucJP" - XOpenIMOfLocale(display, rdb, res_name, res_class, locale_name) This is a variant of XOpenIM() which has explicit locale_name parameter. - XOpenOMOfLocale(display, rdb, res_name, res_class, locale_name) This is a variant of XOpenOM() which has explicit locale_name parameter. Thus, a program which needs to display unicode string can use XmbDrawString and its variants with UTF-8 Output Context created by XOpenOMOfLocale(....., XLocaleNameOfEncoding(setlocale(LC_CTYPE, NULL), "UTF-8")); This only introduces three APIs, and the implementations of the three APIs are trivial for anyone who have clue. -- soda To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-i18n" in the body of the message