Re: [I18n] CJK UTF-8 locale's X locale db
>You should have dropped either Korean (Japanese are not supposed > to understand Korean script unless they're interested in learning) > or used 'glyphes of CJK Ideographs widely used in China or Korea' > in the following. You are right, I had to use exact word. > > Japanese people may even fail to recognize or understand some of > > Chinese and Korean characters. > > By keep saying that, I'm afraid that you're making a 'mockery' of > your fellow Japanese people's pattern recognition ability without > any intent to do so. Well, this is not a pattern recognition problem. There are very different CJK Ideograph Variants while there are very similar but entirly different ones. You have to *know* which difference is significant as "character", which difference is significant as "variant", and which difference is not important. Unless being familiar with these variants, you cannot distinguish them. If you think you can easily recognize, it is because you were grown in an environment which you have many oppotunities to read variants. Moreover, if X were a system which require people such pattern recognition and guessing, nobody would not use X for serious purpose. foR ExaMPle, I Don'T wAnT TO wrITe mY RepORT TO mY bOsS iN Such A FunNy (eVEn iF READabLe) TeXT. --- Tomohiro KUBOTA <[EMAIL PROTECTED]> http://www.debian.or.jp/~kubota/ ___ I18n mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/i18n
Re: [I18n] CJK UTF-8 locale's X locale db
Hi, > *If* people in different countries prefer different font sets, > a locale seems a reasonable way to express that. Japanese people would think the system is broken or misconfigured if non-Japanese fonts were used. Japanese people may even fail to recognize or understand some of Chinese and Korean characters. Thus, if someone wants to develop a unified international font, it must be Japanese style (if Chinese and Korean people agree). --- Tomohiro KUBOTA <[EMAIL PROTECTED]> http://www.debian.or.jp/~kubota/ ___ I18n mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/i18n
[I18n] xterm, terminfo, DEC character, and G1 slot
Hi,
In a certain condition, xterm won't display G1 (in ISO-2022 meaning)
characters properly.
- using xterm with automatic luit-invocation in east Asian locales
which use G1 slot (such as EUC-JP, EUC-KR, GB2312, and Big5),
like "LANG=ja_JP.eucJP xterm" or "xterm -u8 -e luit -encoding eucJP".
- after using DEC characters (such as line-drawing elements) via
terminfo enacs/smacs/rmacs (such as dialog, whiptail, and so on).
There are sample screenshots.
http://www.debian.or.jp/~kubota/mojibake/xterm-eucjp-1.png
http://www.debian.or.jp/~kubota/mojibake/xterm-eucjp-2.png
The first image shows EUC-JP character is displayed properly.
This image was taken using xterm (with luit) in EUC-JP locale.
However, after using DEC characters ("dialog --msgbox abcde 5 10"),
EUC-JP characters will never be displayed properly, like the
second image. This reproduces completely 100%.
This is because definition of enacs/smacs/rmacs conflicts with
character encodings which use G1 slot. It is an already-known
problem for more than one year. Here is Juliusz's mail to point
out this problem.
http://marc.theaimsgroup.com/?l=xfree-i18n&m=101664160902706&w=2
In the mail Juliusz said that Thomas said that the very simple
solution in the mail might have a backword compatibility problem.
However, I don't understand what is a problem.
The solution is, to modify enacs/smacs/rmacs definition like following:
:smacs=\E(0:rmacs=\E(B:
(enacs is not needed). It works for all encodings including
legacy 8bit, legacy multibyte, and UTF-8.
I would like Thomas to adopt Juliusz's very simple solution.
---
Tomohiro KUBOTA <[EMAIL PROTECTED]>
http://www.debian.or.jp/~kubota/
___
I18n mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/i18n
Re: [I18n] Howto submit Lao xkb?
Hi, From: <[EMAIL PROTECTED]> Subject: [I18n] Howto submit Lao xkb? Date: Thu, 9 Jan 2003 10:35:01 -0500 > Hi All, > > I would like to submit Lao XKB map to Xfree86 to be included in the next > distribution. Please do let me the procedure. > Thanks, Though I don't know about how XKB is handled (because I am Japanese speaker and XKB is not useful for CJK = Chinese, Japanese, and Korean), I think it is a good idea to submit the file to i18n@xfree86 (here) to be checked by experts and then to patch@xfree86. --- Tomohiro KUBOTA <[EMAIL PROTECTED]> http://www.debian.or.jp/~kubota/ ___ I18n mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/i18n
Re: [I18n]Xutf8LookupString and KeySyms > 0x010000000
Hi,
At Mon, 11 Nov 2002 09:57:43 +0100,
Jean-Marc Lienher wrote:
> So can I modify the X11 Xutf8LookupString function ?
> I don't think that there is compatiblity issue because KeySym
> greater than 0x0100 where unused in past.
I think it is a good idea, though I am not an expert of XIM.
It would be better if you could modify not only Xutf8LookupString
but also X{mb,wc}LookupString.
And, please, please test with existing XIM servers and existing
XIM clients (not only xterm but also xedit, kterm, rxvt, and so
on because xterm's XIM implementation is somewhat special).
---
Tomohiro KUBOTA <[EMAIL PROTECTED]>
http://www.debian.or.jp/~kubota/
"Introduction to I18N" http://www.debian.org/doc/manuals/intro-i18n/
___
I18n mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/i18n
Re: [I18n]Xutf8LookupString and KeySyms > 0x010000000
Hi,
At Sun, 10 Nov 2002 19:32:42 +0100,
Jean-Marc Lienher wrote:
> But my question is always unanswered.
> Will Xutf8LookupString supports Unicode KeySyms without strings
> or must I patch Xterm ?
>
> The Xterm patch should look like this :
> --
> ret = Xutf8LookupString(ic, event, buf, 20, &keysym, &status);
>
> if (ret == 0 && keysym & 0xFF00 == 0x0100) {
> ret = unicode_to_utf8(keysym - 0x0100, buf);
> }
> ---
>
> If I work on this patch will I be accepted or I'm wasting my
> time ?
I don't think it is a good idea to force XIM client to be
modified, because Xterm is not the only one XIM client but
there are many XIM client softwares. You will have to
modify all of them. However, if you think it is not impossible,
please go ahead.
When you really try to modify XIM clients like above, pleaswe
don't forget to test the modified XIM clients with east Asian
XIM servers like kinput2 and xcin. East Asian people are
tired to find some softwares cannot use east Asian XIM although
older versions of these softwares can use it.
---
Tomohiro KUBOTA <[EMAIL PROTECTED]>
http://www.debian.or.jp/~kubota/
"Introduction to I18N" http://www.debian.org/doc/manuals/intro-i18n/
___
I18n mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/i18n
Re: [I18n]Compose and XIM
Hi, At Thu, 17 Oct 2002 09:32:31 +0200 (MEST), David Monniaux wrote: > I also noticed that if XMODIFIERS="@im=kinput2", kinput2 still does not > work if the application is not launched in a ja_JP.* locale (fr_FR.UTF-8 > does not work). Please try ja_JP.UTF-8 locale. The locale limitation is only when the application (XIM client) calls XOpenIM(). (This locale is used to communicate strings.) Thus, it is possible for softwares to support multiple XIM servers which requires different locales. > Some things I thing should change: > * It should be allowed to use several XIM methods in the same application > at the same time. Please try mlterm. (http://mlterm.sourceforge.net/) It can use multiple XIM servers by switching. It is not a good idea to use multiple XIM servers *at the exactly same time*, because you will need multiple key binds for invocation of each XIM server. Anyway, mlterm can input mixture of (for example) Japanese, Chinese, and French, which Mule/Emacs had been the only software which could do this for long years. BTW, I am concerned that GUI guidelines such as GNOME Accessibility (http://developer.gnome.org/projects/gap/guide/gad/) don't mention key binds for XIM. > * The locale should bear no influence on whether an input method is used. I think this can be achieved in toolkit level, so that application developers don't need to know about XIM. (Otherwise, because very few developers know about XIM, very few application softwares will support XIM.) --- Tomohiro KUBOTA <[EMAIL PROTECTED]> http://www.debian.or.jp/~kubota/ "Introduction to I18N" http://www.debian.org/doc/manuals/intro-i18n/ ___ I18n mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/i18n
Re: [I18n]Compose and XIM
Hi, At Thu, 17 Oct 2002 12:22:48 +0200 (MEST), David Monniaux wrote: > That's what I use. kword and the like are able to use kinput2 if they are > launched in the ja_JP.UTF-8 locale but not in they are launched in > fr_FR.UTF-8. Though I have no experience nor knowledge on writing XIM servers, I think there should be some ways for Kinput2 to communicate with clients under fr_FR.UTF-8 locale. How about adding fr_FR.UTF-8 in the line of *IMProtocol.locales: ja_JP.SJIS, ja_JP.EUC, ja_JP, japanese, japan, ja in /etc/X11/app-defaults/Kinput2 file, though I have not tried? (Note that Kinput2 itself must be run under ja_JP.eucJP locale.) --- Tomohiro KUBOTA <[EMAIL PROTECTED]> http://www.debian.or.jp/~kubota/ "Introduction to I18N" http://www.debian.org/doc/manuals/intro-i18n/ ___ I18n mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/i18n
Re: No objection? (Re: [I18n]Test implementation of luit extension)
Hi, At Wed, 02 Oct 2002 14:13:40 +0900, Tomohiro KUBOTA wrote: > Are there no objection? (I waited about three months...) > Then I will send this to patch@xfree86. I did, and got seq: 5416. --- Tomohiro KUBOTA <[EMAIL PROTECTED]> http://www.debian.or.jp/~kubota/ "Introduction to I18N" http://www.debian.org/doc/manuals/intro-i18n/ ___ I18n mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/i18n
Re: [I18n]Re: [li18nux:1094] BACKSPACE behavior
Hi, At Thu, 3 Oct 2002 16:53:02 +0700, Theppitak Karoonboonyanan wrote: > Another possibility is that bash or any other shells be modified so that > they don't emit 0x08 in case of backspace upon combined cells. > Hmm.. This may be more sound. In *any* cases, bash (or any shells) don't emit 0x08 alone in case of BACKSPACE key push. For example, after normal (singlewidth) character, 0x08 0x20 0x08 is emitted. Thus, you don't need to regard "deviation" from "BACKSPACE key equal 0x08" as something bad. To erase last combining character element, i.e., to implement your favorite behavior, the shell must emit 0x08 . If the previous combined character consists of one base character and multiple combining characters, combining character codes (without the last combining character) must be emitted additionally. The shell must erase last one character from its internal buffer. Of course it may one byte (for example, TIS-620) or more (for example, UTF-8). On the contrary, for BACKSPACE key to erase whole combined character, the shell must emit 0x08 0x20 0x08 and erase whole combined character from the internal buffer. I think both behaviors can be possible technically. I don't have any opinion on which behavior should be implemented (or should be default if both will be implemented). I think it is a good idea to consult people who wrote bash-2.05b i18n patch about Thai people's expectation of BACKSPACE key behavior. --- Tomohiro KUBOTA <[EMAIL PROTECTED]> http://www.debian.or.jp/~kubota/ "Introduction to I18N" http://www.debian.org/doc/manuals/intro-i18n/ ___ I18n mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/i18n
Re: [I18n]Re: [li18nux:1094] BACKSPACE behavior
Hi, At Wed, 2 Oct 2002 23:21:12 +0700, Theppitak Karoonboonyanan wrote: > This may look awkward for the definition of 0x08 to move back > inconsistently. But the situation can still be defined more gracefully > if we allow the cursor to stop at each combining character, and moving > left through a combined cell means moving through the combining > characters one by one to the base character before advancing to previous > cell. This implementation has been adopted by some locally-patched > terminal emulator, such as xiterm+thai (available in debian sid). This idea is inconsistent with already existing softwares, where cursor moves one column (half character) even when it moves across doublewidth characters. There are also existing softwares which treats combining characters in this way (against your idea). I think your idea can be implemented to be enabled only when some option is specified. However, in future, I think one internationalized software should work well for all people in the world. To achieve this, terminal's behavior must be defined consistently. At least, definition of 0x08 must not be modified. In this case, new control codes would be added for character-element-based movement of your idea. --- Tomohiro KUBOTA <[EMAIL PROTECTED]> http://www.debian.or.jp/~kubota/ "Introduction to I18N" http://www.debian.org/doc/manuals/intro-i18n/ ___ I18n mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/i18n
Re: [I18n][patch] XTerm Unicode font settings
Hi, At Sun, 15 Sep 2002 11:05:18 +0900, Tomohiro KUBOTA wrote: > I wrote a patch for XTerm to add font configuration set > for UTF-8/locale modes. No objection for this to be sent to patch@xfree86, too? --- Tomohiro KUBOTA <[EMAIL PROTECTED]> http://www.debian.or.jp/~kubota/ "Introduction to I18N" http://www.debian.org/doc/manuals/intro-i18n/ ___ I18n mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/i18n
No objection? (Re: [I18n]Test implementation of luit extension)
Hi, At Fri, 05 Jul 2002 00:44:23 +0900, Tomohiro KUBOTA wrote: > Hi, > > At 04 Jul 2002 13:40:59 +0100, > juliusz chroboczek wrote: > > > TK> I wrote a new patch by following your advise. > > > > That's really cool; thank you so much. > > I am happy hearing you like my patch. :-) > Here is a new patch. I erased all static variables from > other.c as I wrote in the last mail. > > > Unfortunately, I do not have time to review it right now; I know how > > frustrating it is to get no feedback, but please be patient for a few > > days. > > Ok, no problem. Are there no objection? (I waited about three months...) Then I will send this to patch@xfree86. --- Tomohiro KUBOTA <[EMAIL PROTECTED]> http://www.debian.or.jp/~kubota/ "Introduction to I18N" http://www.debian.org/doc/manuals/intro-i18n/ ___ I18n mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/i18n
Re: [I18n]unicode
Hi, At Mon, 30 Sep 2002 16:26:23 +0530 (IST), Viveka Nathan K wrote: > Hi all.. > I wish to use the unicode encoding. > How can I know, which applications are supporting the unicode. > What should I need to do, to make an application to support unicode ? Please read http://www.cl.cam.ac.uk/~mgk25/unicode.html Please note that there are softwares which promote themselves as they can use Unicode while they can use only a small subset of Unicode. --- Tomohiro KUBOTA <[EMAIL PROTECTED]> http://www.debian.or.jp/~kubota/ "Introduction to I18N" http://www.debian.org/doc/manuals/intro-i18n/ ___ I18n mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/i18n
Re: [I18n]Re: [li18nux:1094] BACKSPACE behavior
Hi, At Fri, 20 Sep 2002 14:24:06 +0700, Art - Arthit Suriyawongkul wrote: > I +1 to Theppitak's proposal to fix BACKSPACE behavior for Thai text. > > (from: erases "the whole combined cell" in single BACKSPACE > to : erases only last character typed in single BACKSPACE) I think this choice is shell's responsibility, not terminal. This is because now "single BACKSPACE" means keyboard typing, not submitting of 0x08 to tty. Submitting of 0x08 to tty should *always* move cursor left one column, regardless of what character is written on the left column. This is because terminals cannot tell the context of accepted 0x08. Many softwares uses 0x08 to move one column left. For example, even if the left column is doublewidth character, 0x08 moves *one* column and the cursor will be located at the right half of the doublewidth character. Bash-2.05b is aware of this behavior and, when BACKSPACE key is pressed after doublewidth character, bash issues 0x08 0x08 0x20 0x20 0x08 0x08 to the tty to erase the whole doublewidth character. (It is more complex in real, to handle line folding.) --- Tomohiro KUBOTA <[EMAIL PROTECTED]> http://www.debian.or.jp/~kubota/ "Introduction to I18N" http://www.debian.org/doc/manuals/intro-i18n/ ___ I18n mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/i18n
Re: [I18n]euro symbol in antialiased xterm
Hi, At Sat, 21 Sep 2002 11:28:55 +0200, Frank Louwers wrote: > I got the Euro symbol working in X, and in xterm when using a > non-antialiased font (when not starting xterm with the -fa font option). > > However, when using antialiased fonts, it won't work. If you use CVS version of xterm with CVS version of luit, invoking xterm in one of ISO-8859-15 locales will be OK. (You will need "XTerm*Locale: true" resource.) You will need Unicode font (either non-antialiased or antialiased). --- Tomohiro KUBOTA <[EMAIL PROTECTED]> http://www.debian.or.jp/~kubota/ "Introduction to I18N" http://www.debian.org/doc/manuals/intro-i18n/ ___ I18n mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/i18n
Re: [I18n]BACKSPACE behavior
Hi, At Fri, 20 Sep 2002 11:06:24 +0700, Theppitak Karoonboonyanan wrote: > Hmm.. Looks like it needs some additional configuration, because it > works properly on my friend's machine, but not on the one I'm using > (both are debian sid). Did you prepare th_TH.UTF-8 locale (or other UTF-8-based locale) by editing /etc/locale.gen and invoking /usr/sbin/locale-gen ? --- Tomohiro KUBOTA <[EMAIL PROTECTED]> http://www.debian.or.jp/~kubota/ "Introduction to I18N" http://www.debian.org/doc/manuals/intro-i18n/ ___ I18n mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/i18n
Re: [I18n]XTerm Unicode Character Erasing
Hi, At Wed, 18 Sep 2002 11:10:15 +0700, Theppitak Karoonboonyanan wrote: > I've been happily using Thai on XTerm with UTF-8 support. The only > problem is that characters with length of more than one byte (in UTF-8) > aren't deleted completely with a single backspace. Instead, only the last > byte is removed, while the display shows that the total character, or > even the total cell in case of multi-char cells, are removed. This > results in inconsistency between what is shown on screen and what is > stored in the buffer. The "only last byte" is stored in the buffer in your shell, not in XTerm. Thus, XTerm is not responsible for this problem. If you are using bash, please try version 2.05b . This problem is solved. If you are using tcsh, this problem is solved only for east Asian doublewidth characters but not for Thai. zsh seems to have no support for multibyte characters nor combinig/doublewidth characters. PS. The current CVS version of XTerm can handle combining characters of Thai in TIS-620 encoding, by using CVS version of luit. If you have to run softwares with such problems, this may partly help you. --- Tomohiro KUBOTA <[EMAIL PROTECTED]> http://www.debian.or.jp/~kubota/ "Introduction to I18N" http://www.debian.org/doc/manuals/intro-i18n/ ___ I18n mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/i18n
[I18n]Default fonts for xterm
Hi, So far, XTerm uses *-iso8859-1 fonts as default. Though the default settings have been good, I think it is not always good now or in future, because current XTerm supports UTF-8 mode and it can activate UTF-8 mode automatically. I think it is a good idea that UTF-8 mode is invoked automatically in UTF-8 locales. However, if users have to configure fonts to use UTF-8 mode of XTerm, the merit of automatic UTF-8 mode decreases. This is in case not only for UTF-8 mode but also locale mode (which is implemented based on UTF-8 mode) which is recently integrated into CVS tree. I think there are two possibilities of solutions. The first is that simply using *-iso10646-1 fonts as defaults. This means that XTerm will use *-iso10646-1 fonts instead of *-iso8859-1 fonts when no font configuration is available. The second solution is to implement UTF-8-specific font configuration items, like "uFont", "uFont2", "uWideFont4", and so on. I think the second one is better, though the first one is simpler and not very harmful. However, I don't have enough time to work on these solutions. Any comments? --- Tomohiro KUBOTA <[EMAIL PROTECTED]> http://www.debian.or.jp/~kubota/ "Introduction to I18N" http://www.debian.org/doc/manuals/intro-i18n/ ___ I18n mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/i18n
Re: [I18n]Displaying chinese in an xterm
Hi, At Thu, 1 Aug 2002 22:51:39 + (UTC), Bruce M Beach wrote: > > The patch for xterm: > > http://www.xfree86.org/pipermail/i18n/2002-June/003265.html > > I have XFree86 version 4.2 and tried to apply your patch > but the code in xc/programs/xterm bears no resemblance > to your patch. I couldn't even apply the patch by hand. > Are you using a different source tree or are there other > patches involved. The base xterm must be taken from XFree86 CVS. There is also a web page which summarize patch and so on. Please see http://www.debian.or.jp/~kubota/xterm.html . > I downloaded some fonts from somewhere and If I try > > xterm -u8 -fn \ > -misc-fixed-medium-r-normal--16-120-75-75-c-0-unicode-0 \ > -e luit -g2 'GB 2312' I don't know about the font. Please use *-iso10646-1 fonts which are shipped with XFree86. If you want to use CJK doublewidth characters (I am sure you want to do), there are some limitation on font selection. Please see the above web page for detail. --- Tomohiro KUBOTA <[EMAIL PROTECTED]> http://www.debian.or.jp/~kubota/ "Introduction to I18N" http://www.debian.org/doc/manuals/intro-i18n/ ___ I18n mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/i18n
Re: [I18n][patch] xterm to call luit
Hi, At Thu, 18 Jul 2002 11:41:18 +0900, Tomohiro KUBOTA wrote: > Here is a patch for xterm to call luit to support LC_CTYPE locale. > This patch was discussed in i18n@xfree86 mailing list. Please > refer the following messages and replying messages for them. I got patch seq number of 5328. Please refer this number on discussion. --- Tomohiro KUBOTA <[EMAIL PROTECTED]> http://www.debian.or.jp/~kubota/ "Introduction to I18N" http://www.debian.org/doc/manuals/intro-i18n/ ___ I18n mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/i18n
[I18n][patch] xterm to call luit
1;$:FRYQ,#8QQJX@&1+XI`9,BEP&IB'@(?"1^0I[*VA?`&W8
M3FP(I#K51'7`W:9TQP@#;TE-0<$=?'"(SL=:DP5@ZZ+$7%P`F[6Q>49B]J"@
M>RX"U!RRY=M:V%86!\5C2CD>;)"0LK$SJHO56(64SP-)2A.7U('#BARNOU&>+\I?1LM-7@BWX58P,_PB
M._\DD2Z-W5HBE`-N8\X@#`
M8?R07(SW(2_7?DO_FD<_5%4T^KCE+.N&;32.@&&6@*OO@^D`Q0#M4),$F
M`2@*!*B[]#%8Z;:V--D2],@6W$2YE**3+%%_LC,;?#\>8FE``A-47QRJ?W,:`(`2D[T$G.'0R:SU6@Z),3DV&)
M;AYA+8"B!<`"C2HE);0,02F=54XKV9":T(OA?M%;R0V[1G/)MEMVF7N<0E7L;E5[
M*ZU$U;"=U4W`C%JC!"49GY81/>)H'J%E'1WN*\M"N6ELX3V`EL!!XK`C@J3#
M1;J@2)3XQV@@R[]@;Q9"$[.=K,F".`@
M./#!]'"K#)2:>'T)A&,_.9FJ4!#Z_N6ER%,B?1Z]V8$I:1V@7L:<_+^[EMAIL PROTECTED]
M(#4)T.4'/AFT=*CJ?4PQ]PT#Q-'(J0)^"U)\J-V)75)N>'336-&I?4@QI!>.
MO2^.?_Y,[_CK.SOJ==;^OGR>]?9(B00R,+X*Y*M7FP(B_DNRU2I*+ZDE"K&/
MK:-&U=8`LPI92VZX(I;I$]E>%GM6*)9A\@&]TLAP^%P-5TI2&-&RC:LR`0"B
M,;T:PR",Z9-07A%(('^$:\XA8DV>5KP(6<[,-_PGY&ND^S)ZPQFBN0=Z_+!<
M052AE_6>U#G):Y_+-"]B3%VQ^4"]@FM'G5G`*H470T`R8\H>S0QJF"CYIF04
MTW@B'GPN;8;RCVT-9\A!PU*?XWW'/+:['!:/[3_S6(S#:1;C[XVKLBSV@`MX
M6_A_Q>2LUNG[L3:W*&17=?S'EI+-$%ND7N[L:)FZ<0$)AX-)AY#_B$(>1-C2
MXQ,M$($A'W6I@**1(O;^*>E5I]MJ7[7ZU97,J=D97V&W358:N-,#N##RO>`*
M',PC:-<'WPYXY`ED'J4I%0&?5Z2:S8<,F4H[QW"_".D;X]*\?Q,=3P0>J`##
M%YID:D0<)"8/<84>Y6F2<6_I"D[?;QQI+=DMI;1-O?V90X;A"I5(K`L`B^A4
MN:?Z5UGED>T95+!QG,0`.5$G-"H5-*QX5(?
MR>Q=Y1/%:KQ/S:;Q`A28<<-%C(@I0KM8KSPR&I8\'
M_=>GA@I'8`8W&V-_BE^[IXIJ:LKXCIPKJDF#?L[#V'HK-?$D-E.'X0#*O)1S
M(?301H5,#$\@J9$D=G93+`A<*ZRD)IICZRJ>R^*GTC?+#\=J?1(,IYJU=O+.
MG-!$D6]))I;11M0_E,;K4W+)+I*XRF1B73&.Y&3R)1AVN^V>U\05RRVA,KLE
ML:$I=EXCA%#JD@8+MI"-*J",M:H.R`&/P2&9SR8GF[G?8JMH)7(1LB.=M^!R
MR+H3N"Y2?WW'-0+$S>SI7#GK6"[<\D2NS%"*<4_3"$4B1FG.H-CB+LW\D&"&
M7GE''N_8:%".W.J)=@@T!@2(#IBH<#@<]GJVF,;:]1?,H*&2CT,[+:4U$L`E
MJ?NR@H"`HJ59U#+9AIS)DN9I4K%-D?B?$]CNZ13;B[;U3G[1TR.=>XBQ?J00
M=Y=0LQ'.NC'2T1PCSI]SV02/5SHO/6)092=HRW2I:!4YQY!6P/>JN-E?[8WF
M:^41C)ND6>>>9/7EI-5-9J4?@4;8H+B@Y%
MEZ)GFJ(J+%'523EXR5:EI!V/)(&U+BF_:2_]<]SSV1F?E?BLQ&>3<(DIW$^7RZ);3%?$R7H2N
MET8D!9]Y8O=2];\&PW+)`]AXOJY1K:F;RGC,A,$EJ,]N-HO_CL>X>K?=5WR\
M;^5=S(XM0!/[^)*J?KO)'#T:=%&UP*J:[+14MKG(FW0]VD+=[Y/Z,H%V_0,*
'LR6:-DH`
`
end
---patch till here
---
Tomohiro KUBOTA <[EMAIL PROTECTED]>
http://www.debian.or.jp/~kubota/
___
I18n mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/i18n
Re: [I18n]Displaying chinese in an xterm
Hi, At Tue, 16 Jul 2002 11:17:00 + (UTC), Bruce M Beach wrote: > For several days I have been trying to get chinese(mainland GB2312 zh_CN) > to come up in an xterm, but am not having any luck. So far, xterm does not support GB2312 nor other multibyte encodings (other than UTF-8). I am now working on writing a patch for xterm to support multibyte encodings such as GB2312, Big5, EUC-JP, EUC-KR, GBK, and Shift_JIS. The patch also supports TIS620 Thai (which is 8bit and needs combining characters). Also, xterm will follow LC_CTYPE locale to determine encoding. I have almost finished writing the patch. The patch needs a program 'luit' which is found in XFree86 version 4.2. The patch for xterm: http://www.xfree86.org/pipermail/i18n/2002-June/003265.html You may want to apply the following patch for luit to support GBK and Shift_JIS: http://www.xfree86.org/pipermail/i18n/2002-July/003304.html Please note that the patch uses UTF-8 mode internally and use luit to convert UTF-8 and other encodings (GB2312 in your case). Thus you will need *-iso10646-1 fonts. Invoke the patched version of xterm in zh_CN.GB2312 locale and xterm will use GB2312. There are also several terminal emulators which are sensible to LC_CTYPE locale. Rxvt (version 2.7 series) Eterm (version 0.9.2 series) mlterm --- Tomohiro KUBOTA <[EMAIL PROTECTED]> http://www.debian.or.jp/~kubota/ "Introduction to I18N" http://www.debian.org/doc/manuals/intro-i18n/ ___ I18n mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/i18n
Re: [I18n]Test implementation of luit extension
>MR+=2U6E2)HA7U"DUE*\]/6ENN0-[<7_5$+3XS?F.Z]Y7F68V/2!1HS`6[A3D#SX+;QF#YQYC0.
M7YA%XCMD8G\C:YB)`<&Y\R<6ANUD`JN&];><`J#^$NAXSMS_.G%-@)Z1B>#E%""[\3"O`:P6R;T#G8W?)I5L
MO;E;6=ZR2&86TK[;^%#H8>'4M!$+)'GNN,0S5\`8D+"`=2INR!\%0N[7J%2?
MJ\G#DJ]+YSXJBP4?0-C^9X"6AA.Z+.:N5\Q6E@W79S$*A
MO#/LN!%43NZ<+R:5A_6U[?C`+N,"NV$==BZO\I:3U8K%W-*
MISOJ(=5.?T!:Y*8U&'7;.&>3F]O!37]H``.70+?7[74&T(SQUNB-GA%H%PJ)
M\0>\D>'K%@1ST%A.:=V"!`/DD;3[-^\'N%PEK_O7EP847AC`7.OBVF"-@6#M
MZU;W;9%ZC08@O^M4?=?@]%:?=[HP&\%D'2
MP2C`?=<=&D72&G2'J)3.H/\6A$2E`DJ?4@'$GL'(H,))I%\`!-]OAT9`D5P:
MK6L@!IW4B_8B=.O)<^Q:V5W/5M9=](HI%EI.HDS<7U52[J\J3[B_JJ3Z;LK=
MW,8%!2Y]PWF51N#@3/FDHH0UQNV@/];46J5&`_]6&ROQ>IPB[O[E8W>]P@MC
MF,&Z^_R,7PLB+\+%)!X>,NSIV\FZ8]FS/!Z1HC<].]"/8Z/7[J,5CV][77B"
M'BQI[#]=KX=9N9^C#12DG*`2X2"\@80-0ZL#'A'%""1)BT`SDS2L5O$&MA:]
M*Z3QNT**'/7G%.F29'07V8[O(DM:C`"Z(8LV.2>:W@A8L^4J6'[+=6$O"CZY
M+J`3!BR%(0$
ME/'@6NJNDP=1OJ5N/X_%Q?>UGN,.B%<[FWU0@B`E,=KWY4N-NXW6"GUO4U;,N;/4;B:`4J#4A[;:@*4N!$[V,5A,6RV'F$99M4RNAZE'U'%.U%TH-`@\=T?!=X==Q)Q-K_$".J*!^Y
M>TD2K7&BE+K`6YDVV[958HE;@5476+4$5GD+5H-CU1-8E3C67NH,O62@3TE7
M/\=5^22:>^LUI3//92F3W<:3IA$8\9,3$]"!?A9RMT&/*C?P0?U()=7`T8-[
MA3'R-XG4:ZP^'&F[50`B;`+;#KEE/<+?-TV)P_(^'*J,0TV/31)_Q\!#AIE`
M"6@96/\AZ?84K[*7>&4F7N,@\79J0]^EC0AT.8!^@CZ86]^ED<<]I\Y2,'>&
M$0,$@)UWWB("1U@*S&'GXP9T@9@/%I/`1`Q.^U2[-$49Y9)II%.AMGC
MIX0]4I/)?XK:*`?6P%3`'E^^Q$^%E5"SK!H%:C=U:E$/%UK$NH$D!SY&Q-_P
MF5DLVN]OS#;/Z)15H-]U(V9Z8/_RF$Y/;^S<3EMNW?9:;MM.
M6SY].RVR]:V7SRKZ6;F2V$ZKZ?_LIOVSF_;/;MH_NVD_O)L6.P##YP(>`>`,
M%_W1N6AH@/71WYNCL\YF3G\3<[)YP/Q_,[N9Q*V=\!P-)X1A<9&L3#N@B,ZR
MN1?G\JJQF5JK[1).7NEL!=*VJP'GI@C3&QO'*N>9*XHP98D2%)1P:449TB&<
MV*.T%!&_-RK6)4V^E"'IFXBX#HHL?;,VSE)^ZS2Z79:Q.Y6"1\\ZI>\)I4!+
MW"=W'S+93Z3]]^5_'\10@&3.>[L$R0Q)I@2)\&5?"?9!#"5(+FW3)/A?(_GO
%PMA<
`
end
---
Tomohiro KUBOTA <[EMAIL PROTECTED]>
http://www.debian.or.jp/~kubota/
"Introduction to I18N" http://www.debian.org/doc/manuals/intro-i18n/
___
I18n mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/i18n
Re: [I18n]Hello, I have a question about IMdkit.
Hi, At Wed, 03 Jul 2002 10:38:06 +0800, James Su wrote: > I'm developing an input method with IMdkit. But I cannot find any > way to obtain the input spot position when the client uses > PreeditCallbacks mode. Do you have any idea on how to obtain it? I think Li18nux people know well, because developer(s) of IMdkit are now working in Li18nux. Please check the following URL. http://www.li18nux.org/subgroups/im/ Please not I am not a member of Li18nux. --- Tomohiro KUBOTA <[EMAIL PROTECTED]> http://www.debian.or.jp/~kubota/ "Introduction to I18N" http://www.debian.org/doc/manuals/intro-i18n/ ___ I18n mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/i18n
Re: [I18n]Test implementation of luit extension
Hi, At Thu, 04 Jul 2002 02:06:33 +0900, Tomohiro KUBOTA wrote: > I wrote a new patch by following your advise. > I also added SJIS as a new "OTHER" encoding. I forgot the following point: > Finally, I object with the stacks being static. I've gone to quite a > bit of effort to make the ISO 2022 parser reentrant (there's nothing > that prevents multiple ISO 2022 parsers being used simultaneously), > and that means that global variables should be avoided. You should > put the stack in the ISO 2022 state, and allocate/free it on demand. I will prepare a new patch. --- Tomohiro KUBOTA <[EMAIL PROTECTED]> http://www.debian.or.jp/~kubota/ "Introduction to I18N" http://www.debian.org/doc/manuals/intro-i18n/ ___ I18n mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/i18n
Re: [I18n]Test implementation of luit extension
Hi,
At 29 Jun 2002 10:45:55 +0100,
juliusz chroboczek wrote:
> Yes. is->other should be a pointer to a Other charset.
I wrote a new patch by following your advise.
I also added SJIS as a new "OTHER" encoding.
begin 644 luit-utf8-20020606-2.diff.gz
M'XL(".4I(ST"`VQU:70M=71F."TR,#`R,#8P-BTR+F1I9F8`[3S[=]K&TC^7
MOV+K>^J"!8DDWB9)@[%P:!SP`=PT-\WA8!"@!$M<2>1Q4__OW\P^I-6+A_/=
MW^J3VM+NS.SL[.SL/+2=6XL%*;G;/EEO+;\T^^SIJJJK-;7VM'<__60NK+69
MZ"IM_44C[,^52J4=Z#]U78OTG<^$Z$33S]7:>:5,`$S+*8JRC_9/X]66_+Y=
M$U(AJG:N`W(3D?7DI*G%)E'H[YQ;`][!DC\IR\F?JK
M:^O.G;K?R-5_K0U_!M#2:-A!"!S_R8Q8GJ.KN@Y/L]74]4QLV^"#"P_>-^_)
M+*<=_G5P[L^G:;*^MJ=<%(?]U`DCS;$T()YB^6D%_NB8$
MW7PQ;4)J1"^?J]5SM<$6,UL3XL@9FJ#7BS6BP.\ZU81_6?9LO9V;Y-F?FO9T
MX=B^1W^;]NS)ZH74?R+HKT[D5BY::%3"1B9@!$30A3TW%Z1_>WT-;_!HV29]
M(RI33:V*'&E:C;.$/]]/>J,!:32JS9)6/2F2\:19*Y)?[WXMDA-8X;!#_=I0
MX3?\>R@F46LAZB*"6LM`?3WH-4I&B/42L3XY5J-DQC$4AC'N_-$/X?^-\/[L
MLUU2$R.(,:XN8$TUG2%5FA5`:R/:\@Z;GVC-ALJQ5?B)<_A[;T3^)+#P#9G`
M!1+X:'E?L0-(-%-)4'&7<>D5K=PLZFHH;PXD_WO(D8<6;LF;B\23OW&=PL1>J[YV82.0\$]?SK[)`$CEPCQ0.0Y#,U9D9S)
M+4`(H,"X1*&8[>#OWOL/8#B^"TVXNG@-(L?Y3I9WGXJ$3XR]<+;9"V4*'T,U
MNAUW2PV!COLYQ&=O@@![8Q3P.20Q`M40%#S0A9`">Q,4V!NC@,\!A=CJ*W3U
M$="W9BC.')DY][#AS3Q;:Z#"'OP",RT5'55+KPKCPG3+6N1_7LQ*+U`U"JP)
M?US3W[HVM02M7`E;0-ZT9P92O9^NU\XL[UG_-9U%/ER``BR>H`IPSRE^%E5F
M[\K4X#4:13A-A;YSL!D0`S7/*7R2X>+GE*7IRXN?#_6[D%/XHL);>3TE/PLI"\`BX2"%T)H_+ESS>FG
M5MBVF"D*?WT0G$271$D5'@?=MQA*/)8/S*&(;M
M<&1,U]"AADVN.7/F@@K7<[F7JCKOYF]A-]5]WDF?PZ[YU)_2GE9<5KBO\H7(
MXL@L=]O@,5RVLB8?$?]L.EN9@5X)(88ZJ2"DK$,Y`MIX:W^RG2^VP$/[AJ.#
M\G^GFE[6ZL4RJ'JYUBQ6*H&JX]H4!%.)C8([(%SHN,Y3_9#6.*2C).DHD:V5
M9!@/JP+?<(0Y5I)A7&;=GXUE!N`<)38ZV$*L=>C#JG6
M5&T'$X^9\X6UK*[EMAIL PROTECTED]&4X\^)!.Z1IT4"_Q%G1B:-(TZ.3!I'G!^9-(XX
M13)I''&69-(XXD3)I''$N9))XXC3)9/&$6=,MHX=<])D4SGFO$E0.?K4R>;C
MF+,GF\HQ)U`VE6/.H6PJQYQ&"2K'G$E)$WC,R91<5);-2L?EG:F(QQCY!/)1
MQUO:T#]XR*61//RH^_^5Q<''7@)S>?!?IHLB;2+@],R"\>
MR=N.78)-7<*J0S!\`<8NDH`"!,<_T1@;)F/96U-*$SSD4NF>DZMK4GI!KGZ9
M%\G5D#\RFBSW`P_+-?OCBFF&G"_50D`/"*CG0)-A0T\26HM`:Q*T5F!YM'*]
MBLF]2KE9;-#%@0"?!?$C?^J+E""3K\@+\I)!,4=B/YB[.%NN)RQ74.3OKGA/
MP$NK?[94`[1(LQ9@EW9AZ^G89=X<2Z8=B5W7/7])SU9W/.
MLERT(Y(B00(;MA(5M4%7HEZ6]TDH`);'X7@7W_J@+7FQDAQ4WP.JAZ#E/:!E
M`"T%&:)`XT-!1*:=0278)8A@KCTS&YWET^1,D\IS2@?4Y59[:F>KW76YU4]O
M885H7:Z*=3F]=JY6#JW+K6)U.:UZ#LL7UN4:+$TMZG*\4(9UI6:-5'/DZ1FA
MAP`Y>QKIKFA-G=1R2MA$LZ>DCFDV0!J[6Q/MGZB'>L1?37VRF7H>M4>NLV9=
M9&O#7WMI@L4!@+4Y]7S8F536L`9D8;G0(941@T;@%H/48R"*E)86ZO:VJQ
M0I1:N5BE[*$H?L1B/\9J_[CE/MIZMQ(&^,=-^$XSWMIE=L(O'])-0]"?;G:"
M[I3/`9K[S$X<.?@B3NPE,
M,UW#*S4/!*#M2A,/NG@H\P>I,G((.+5J$502LL(^0Z!Z#=TWD_Y@^*8M\^JM
MK(4O^D=!/[6\W/3"'WZ>HB')P:0WCNOWF!SS_"]J@$4/;W'D<;X*Y&=>_Y+=
MQ07WJCQ_;KHNN,2_>$62ZC$^H1ZC(,9+E=C70/,940M"NJ*PQZ@5HB;<<%W'[>9/WDY=
M&S3T'-R%[7IN_^J#*V#/!0N@#"UR$JFU@S'1M,":4'\N((K[N<#FE5$?#'96
MW),,=AJOHJ?ZBQ*0J#NS60I[=8I/[Y?K#ZVPPY4ZW`\)]Y+Y9TTZMV:#QS_!
MA/3\G%LL3Q(TS!.;$Q\H\';\ZTFE5<:VC!&;T3RT@?(P-PJGZM=MM$=JL0;,E6KZX%NCT`AQ.["L2B#L>!!WV481:
M"#U;-EPY&$Y)'4ZK)<9+84.7V0A()1@J,X:470Q5]C"D5](9BC&J)Q@-V:(`
MY5V2JZ0Q&ELH;7(S:=Q9?GX#OEM!R#GD=E.(K%'Z\J01K!*3-^0K.#0,+EDUAZ\9Q^RH<4HGRVU4(A8DO%#Y=-2$/.
MN02?CP39H$CS0W0RH8OAI?L8XB<2>LUDCRGX!";DIQCVICG-N")4D%6(+`H,[!#MT+W"@$QF,/;"&491I@2D8MEE6CTP%IY*^N([(HR,)@??%%
M`BE8=/%3U]C[8OFS54"6?HO#/\6IT$_@E$JC(GG5._C;J0VE.$L>?HRTV?K=
M]73ID5/2ZTZ,WM6K\45O7"!QS=B+D#(S%-=5MN9<#=.$M5]@LM"&2:%5FS2=
M4,/\;SE5:D#^S,/];(PZF2.`I5J8;AZ_<3SS%"6-S:RH`,2?`W)3Z$!9="E1[K*
MG>6YYG.38&\#"8"7!+
M=VK[F.]=N*9)G`6-Z9807OH.F=K?R`9,/R`X=_[4PA"03.&8VGS+*0#JKX".
MYRS\+U/7!.@YF7J>,[-`)^;@#L^V]Q!P3'T<$.\G>22/2>23$3ARU?5LY]="X6<+2`0!(&-2D2A`J>0\?\:,+NA1::
M77?6:^<+S@X<@;F%D_+.<>'&T#F]9>WFJ[7
MY,[D4J->84[!-C$E%SF`0PF\CNF:8*H+AXQ/]0EEX95!1H/N^&U[:)#>B-P,
M!W_T+HU+K$\36@A^VQN_&MR."4`,V_WQ.S+HDG;_'7G=ZU\6B?'GS=`8CP8T]OJ=Z]O+7O\*MN>8]`=C)1D/"([(:>']-*#VQAC"
MF=$?MR]ZU[WQNV).Z?;&?:3:'0Q)F]RTA^->!\\2_WN
M$(8QWAC]\1,"XT(C,?Z`-S)ZU8;```;+*>U;F,$0>22=PU,DE^TW[2N#8E$KE%,0CG%(WKXR:"4&1FS#O\ZX
M-^CC5#J#_G@(KT68Z7`3#?T
M-+O[-`GO`?".(7->17]X$8!F%:$%W(I6.(1Q.QQ,-+56J=$8M-W!,?#BBR)N
M];"+3,']#VE0\CSTBG!TPYX!`UW+GN?QRPQZ':L+"S\Q^IT!JOWDMM^#)UCR
MDL;^HQYEF!+Z6:)>D+)12CAV>,\A.N&\C!JC*,*?=(H@$+P,J47O)&C\3H(B
MQY@Y1;KA%*G3D6AQA=;H`IE%`-V0.1LB:DUO!'S96\6Y/L;HCO4`VS]B4,$.L$]>ID>R.JNE:"O?JU@'H?0
MJT'JUWHW$=FD:%S*O9*4N",ZN:_=+LW-\.?XA2@,_@/H9P063(G0C2:0!4J$
MHPQ&.9-WX06?Z"ZA:X+^'2(S=QME)5HF&]\MLK>U:;>BU@:;8^9&QI.N0T4W
M:?H6I=0.5FY)H9/;Y#A2?)]@_BQY,\QN)8!2H-2O';4!GB_X]_8IZ%%'+3Q[
MIN,JTO=RMQ`GH^&UUS1"!A"22'41[-FS2B%LR20>T.A2&A(5K:,R.K603EDB
M'=&M7;GN.".)WB`"./+]2R84W)5>/(M!!!7MZV*59+_$XDCHY;X8"F!1GP%DO%+@DC:`-F13%P/#IBP!A.NUWYDPMK^
M"6M[)ZSMF+"V9\*/BMVHNCPN>/L(POBH%XD'?ST]%OP(M0^8#10^!AA1]P`Z
MJNA)-S$]Z**%VC8MU`(@OEQV`\A$?)@E$CUI.>@+%C@%L'(S
MIU\U9"JI<\U_U)X]HV$/7:Z4O97T\G]$+XK[52,:%@MER5*-*'1$8XY0C9BE
M3L8'\8T6B_$"
M?RNLA6I>U2A0U:A3I?EZH444&$ARX%-$_`V?F5*BBO[&U.^-@259V4O$1@K3(3$PW,&_!Z*-_0LV!#IR8M)`OXO\Y:I!G;@],6
M\MP/R%N$X(]+7&3QFIZYV%L66^TL7ZUVE<56CR^+K6)EL7(YK2Q6KO]3%?NG
M*O9/5>R?JM@/5\78UPQRR:<5]9])5NDC_G^BHT6.C/I"&FQ
patch seq 5313 (Re: [I18n]bug in gbk-0.enc.gz)
Hi, At Thu, 20 Jun 2002 01:18:53 +0900, Tomohiro KUBOTA wrote: > Ok, here is a patch for gbk-0.enc to fix problems. Unicode PUA > characters are not removed. I just sent the patch to patch@xfree86 and seq 5313 was given. --- Tomohiro KUBOTA <[EMAIL PROTECTED]> http://www.debian.or.jp/~kubota/ "Introduction to I18N" http://www.debian.org/doc/manuals/intro-i18n/ ___ I18n mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/i18n
[I18n]ksc5601.1987-0.enc.gz
Hi, I found curious mappings in ksc5601.1987-0.enc.gz file. For example, 0x30C1 0xCF02 appears in the file. Since KS C 5601 is an ISO-2022-compliant 94x94 character set, 0x30C1 must not appear. Can someone explain the origin of such curious mappings? --- Tomohiro KUBOTA <[EMAIL PROTECTED]> http://www.debian.or.jp/~kubota/ "Introduction to I18N" http://www.debian.org/doc/manuals/intro-i18n/ ___ I18n mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/i18n
Re: [I18n]bug in gbk-0.enc.gz
Hi, At 18 Jun 2002 17:55:27 +0100, juliusz chroboczek wrote: > TK> XFree86's table has additional codepoints to U+E7xx and U+E8xx, > TK> which CP936 does not have. I don't know how to handle these > TK> codepoints. (left unremoved?) > > I suggest going ahead and removing them. If somebody complains, we'll > know what they are for. I see. However, do you know some Chinese (simplified Chinese) speakers are subscribing this list? Otherwise, when do they have chances to know this modification and to comply about this? Not until the release of next version of XFree86? Or, does someone know any simplified Chinese community to be consulted with? And I found a difficult problem. In GBK encoding, 0x80 is a singlebyte character and it is EURO SIGN (U+20AC). How can I write it in fontenc file? (In luit, I can implement an exceptional processing). If it is just impossible, I will ignore this problem --- Tomohiro KUBOTA <[EMAIL PROTECTED]> http://www.debian.or.jp/~kubota/ "Introduction to I18N" http://www.debian.org/doc/manuals/intro-i18n/ ___ I18n mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/i18n
Re: [I18n]bug in gbk-0.enc.gz
Hi, At 17 Jun 2002 16:37:23 +0100, juliusz chroboczek wrote: > Quite possible, I'm the body who compiled the tables, and my knowledge > of East-Asian encodings is superficial at best. > > I'll let you send a patch (and take responsibility for it). I am now preparing a patch. I found that GNU libc's GTK mapping table and CP936 table from www.unicode.org are completely identical. Thus, I used them as reference. I found that almost all differences between XFree86's table and CP936 are the continuity problem which I wrote. XFree86's table has additional codepoints to U+E7xx and U+E8xx, which CP936 does not have. I don't know how to handle these codepoints. (left unremoved?) --- Tomohiro KUBOTA <[EMAIL PROTECTED]> http://www.debian.or.jp/~kubota/ "Introduction to I18N" http://www.debian.org/doc/manuals/intro-i18n/ ___ I18n mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/i18n
[I18n]bug in gbk-0.enc.gz
I am now working on improvement of luit to support GBK and TCVN.
During the work, I found a problem on GBK mapping table in
/xc/fonts/encodings/large/gbk-0.enc.gz file.
For example, the gbk-0.enc.gz file has the following line:
0x82FE 0x8351 0x50BC
This line seems to intend the following (correct) mapping:
GBK ISO10646
0x82FE 0x50BC
0x8340 0x50BD
0x8341 0x50BE
...
0x8350 0x50CD
0x8351 0x50CE
However, since Fontenc does not understand that the next code
to 0x82FE in GBK is 0x8340, mapping behavior in this region is
wrongly shifted:
GBK ISO10646
0x82FE 0x50BC
0x8340 0x50FE (note that 0x8340 - 0x82FF = 0x50FE - 0x50BC = 0x42)
0x8341 0x50FF
...
0x8351 0x510F
Another type of discontinuity in GBK encoding exist in 0x**7e and
0x**80. Thus, the following line in gbk-0.enc.gz
0x8273 0x8280 0x4FFF
is also a bug.
Such lines are easily detected using the following script:
#!/usr/bin/perl
while(<>){
next unless (/0x(..)(.).*0x(..)(.).*0x.*/);
$h1 = $1; $m1 = $2; $h2 = $3; $m2 = $4;
if ($h1 ne $h2 ||
($m1 =~ /0|1|2|3|4|5|6|7/ && $m2 =~ /8|9|A|B|C|D|E|F/)) {
print $_;
}
}
The script reports that gbk-0.enc.gz has 119 such bugs.
Is this already-known bug or is anyone working on this bug?
---
Tomohiro KUBOTA <[EMAIL PROTECTED]>
http://www.debian.or.jp/~kubota/
"Introduction to I18N" http://www.debian.org/doc/manuals/intro-i18n/
___
I18n mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/i18n
[I18n]XTerm patch to call luit (2)
Hi,
Here is a new patch.
- Default of "locale" resource is changed from "true" to "false".
(I still have no idea which is the best... See below.)
- Locale-related resource set-up is separated from VTInitialize()
to a new function VTInitialize_locale().
- Added "vi" (Vietnamese) for luit-using locales in "medium" mode.
- Use nl_langinfo(CODESET) if available.
(Definition of HAVE_LANGINFO_CODESET is not implemented yet.
Could you help me, Bruno?)
- Use MB_CUR_MAX if available.
- Implemented mystrcasecmp() instead of using locale_str.
I heard that from a Japanese person that "locale" resource should
be "false" for some time till the resource will be famous to avoid
confusion. When it will be famous, (he said) many people would
think the default should be "true" and then the default can be
changed to "true" without annoying people.
I think this opinion can be integrated into Juliusz's opinion that
when some new font mechanism will be dominant, the default should
be changed to "true".
So, how do you think about the default of "false"?
The following is the new patch. Please note this patch is for
my previous patch.
begin 644 xterm-20020604-luit2.diff.gz
M'XL("/?F!ST"`WAT97)M+3(P,#(P-C`T+6QU:70R+F1I9F8`K5E]4^)($_\;
M/L4<6W6`.&P"OJ"<5XN(J_>H6(*[>W=KQ1@FDMN0\"1!U]OSNU_WS.0-"$$]
M:VM)9KI[>KI[NG^=&5FF2:@WNR#?`^9-:$-1&LJ.LD7MF16\-\:Z-_5%X1GZ;.83LD$9SO[&WKS0)$A=KM5J>_(A9;1)%W6\"OR*8
M/WP@=+NE;NZ2FOCY\*%(\._'E^!B%IBM3?(EZ%[+AZM3)]@DOO4W<\V*Y035
M34$,4WW3]!G\7_F"JGRV1O8TX=96D3=\02/%>#P+.<^TU2:I:>
M-XL41P<>\T'&A>T:NLWXZF?R<6+Y1EV,:W[@`5O@S5@)!-9>S&GJML]9R2+K
ML67#'A("PH&$&%,.'?6.S_K=SEGO^/1LV+L*!1Y*@8_6B'7!#3Z7]CE^DU;!
M>=LT%O7L!#H"K*1T^?CBU#"/DT3(U(09Q.NX^&AU?7*`O=N]7<;F[N
MD!K_5165N_C="+;@,&(Y5J#Q[3OZA%7)H\,>Z:_X3`Z(Q_X_8WX@WH&'.2/+
M+))B[9UEDO[E4/M\>M33NB>=JT&Q]GZ#&.YDJGN,^-RMH(5U[[CX2`S=9V3C
M?;%VZ+HV`=)CM#\Y.""PA&Z#ON!)?'7<0`QQZLD3B$)>8S*MH)E@"7"M4;'V:7@*KK%T&PZ;)F(N>;1"W\3;GCD^F)N-A%TV!(O<-UJ=
MZ0ZQ?`W/8:0%[J(B*,%<()8Y#Y7265?KG)V5P!S@$(7\\T\H#=_+7Y5RE4@+
M+.7M#G^_[.5QKUB]<_$QC[L0<5U'/>U;O^H-^@-I;V$_8"X@H$)0>G8FJT[]Y9CNA5)
M6H7TDMIG(>YH129%@PX[J,_8M7L?W>&[R*KW,][*<8I:U7L*BAK0FKQ-S9MM/Q+UC3^CJ,$:)M#]F&A[.TC7QN5T94`7ATSQ2%4FC^?EJ
M"`0-&9S/!`6^R*.\9*1,)9/^NY2E[N(UF?L+B@8<*2@"
M#[H-+G1-$AO,\@DS368$UH-T79Z?T*(K''!`FD*/\#PEPB#7<9Q)!L)*8J[)
M\ZL]?=X[.KT^?XNO!KWST\3)2IM^PD;6;")L+T^)/!RN`R<'2R!/141W1J3C
M6U!+N.FCHL.+KA[E46[SI>D-2ZV8J))?B1J>-M.<.
M:.2N/->G:+)8>>)=(`$)_*%%_E;GJ
M9;V,Q2L:_B:'W7+LO&CR;SDY+DNY(L.GB8(D43S\((>M\EI645]JE?_*TF^,
M_V1!?57X@X#6TM`7<8V1+YZXOFOEE1]T;P?'1
M(:F%2(2#[ZGN^S`>N`1[N5Q]UBHRA97P1PTU1FCQG,`9"-<[5Q\'UX/>$2I"
MDCB5)'%J16+31[E0V'_LM*#O@`9D:P<;D;###$&IX=JNI[G?VG&'@7\"QOKM
M(EW2;=`5B)=&W'$`P!;_;"@W*"QL8O@BL+4_F.<2=Q80\`TX(;#`+R5AP1+O
M:%P'1K$&E;`Y*I%'OLE-I'?(R)7=[`8Q+6:/Z-T3Y0_@4M1N$O*&$OFD#\QZ
MP$,`O8WI$\4)<^TT=S=;*IAKMP%VVQ/M6J1UEC%X(\>[QH76LBIM\GJT3]^$
M]NF;T#Y=0/LTZLJL`Z5-K%_4/?@?6[`?:4U#SULW).[-LG($4$D]JE+C.X_I
MW^1RS^(G+5?=NQ&Y@.9G2+I._T%C1TD0E5IP$B;9'"#/
MI$NBH@[S@MK.#C7)3$2I[E(G!:>U_7A`O#.L_02G$W?
MB+/I(LYNSQ^6;(@-HU+I+#,?1$=-$D("78G'.4OY-PD].^6$72)@^C\YVT_C
MU:$NM%5?%/'S
M4#LOX.>0-S[0C!@XIB,N'!0E@0O'M?(XB
M[06,@I'EZW=PM,V9Q^,!V)U['G.D,+SJ='N52LF*C#]*Q.57!U!HVD\RP#*7
M5!(;R](<$@C_Q%^-='=F$VT:\$U5H-YKW?YYXX34"-Y1A#!_M/):<1H\?:^/
MEU_YB;G,ZT0QG;Q*5)5]I;FO[.9<)4K&SV`S?HW8((JRO]V*[B"Q<5&;6RKO
M\\('WK@LMBN)[L[4'MMS[W?2"5%W&$7^W$0RXI--WT8>P9;2
M)U6=ZL$X)3UJ%4/+GUY<7@^U\][PI'^4MO7W=DZD\;'Z!':[-"BBZYO)2ZOU:W&-MY>RU^,N3X_^P+(^C-C
MC#7@]I:?]7*9(ZO;V]-!O]7:WJ,-&'FT;)O<,>S89P#0BNA%?'7F*H?@1.T2
M3")&>#WQH<%T/?XAH1BQU@GIN@XDA@`"R?+YQP!)"%PAE4]&;`J.`Q@8+5$O
MTN&8P82IS^P`4?CM+089SM069CB4QRE2'UZ2%OP;%=+13*8,L,R+>;SSR`08>++!`\M\6%$6L)PG0?FH3S3
http://www.debian.or.jp/~kubota/
"Introduction to I18N" http://www.debian.org/doc/manuals/intro-i18n/
___
I18n mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/i18n
Re: [I18n][call for comments] XTerm patch to invoke luit
Hi, At 06 Jun 2002 18:05:45 +0100, Juliusz Chroboczek wrote: > I would suggest modularising the parsing of the argument. The > officially sanctioned way is to define a converter, say > CvtStringToTristate, and register it with Xt. See lib/Xt/Converters.c > and man XtAppAddConverter(3x). Or modularise it by hand (just putting > it in a separate function). You mean, parsing of request->misc.locale_str in VTInitialize() in charproc.c (line 4638 - 4717) ? I have to study about your suggestion and how to use XtAppAddConverter. > Why do you copy the argument into locale_string, rather than directly > doing a strcasecmp on the argument? I thought strcasecmp was not portable... --- Tomohiro KUBOTA <[EMAIL PROTECTED]> http://www.debian.or.jp/~kubota/ "Introduction to I18N" http://www.debian.org/doc/manuals/intro-i18n/ ___ I18n mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/i18n
Re: [I18n][call for comments] XTerm patch to invoke luit
Hi, At Fri, 7 Jun 2002 15:06:09 +0200 (CEST), Bruno Haible wrote: > CP1255 (Hebrew) > CP1258, TCVN (Thai) > > Either you hardwire them, or you document that xterm should not be > used with 8-bit fonts in these encodings. (Are there 8-bit fonts for > CP1255, CP1258, TCVN at all??) For TIS-620 (ISO-8859-11) Thai, I don't like documentation way because luit already supports TIS-620 and Thai people apparently benefit from it. For CP1258 and TCVN Vietnamese, I think luit will easily support them, though it doesn't support them now. For Hebrew, I don't think we have to care about it so far, because XTerm doesn't support bidi and we are still not agreed whether to support bidi or not. I can add ISCII for complex 8bit encodings list. However, since XTerm doesn't support complex Indic scripts, I think it can be neglected so far. IMO, documentation way should be avoided as far as possible. It is because, if we need to write a documentation for a language, speakers of the language will probably need to read tens of documents to use tens of softwares. It is just Japanese people are localted and I imagine people from other countries such as Thai and Vietnam are also. Thus, I think hard-coding of "th" and "vi" is a good way so far. And also, I heard that systems without locale (with X_LOCALE) do not have MB_CUR_MAX. If it is true, we also have to have a fallback for this. --- Tomohiro KUBOTA <[EMAIL PROTECTED]> http://www.debian.or.jp/~kubota/ "Introduction to I18N" http://www.debian.org/doc/manuals/intro-i18n/ ___ I18n mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/i18n
Re: [I18n][call for comments] XTerm patch to invoke luit
Hi, At Thu, 6 Jun 2002 18:53:34 +0200 (CEST), Bruno Haible wrote: > The default should follow the locale settings. In detail: > > - If MB_CUR_MAX == 1: > > Look at the specified main font. If it is an 8-bit font, > use mode 1. Otherwise use mode 3. > > - If MB_CUR_MAX > 1: > > If nl_langinfo(CODESET) is "UTF-8", use mode 2. > Otherwise use mode 3. I think your opinion is to use this algorithm for "medium" mode and use this mode for default. This algorithm is better because it does not hard-code any locale names. However, this algorithm does not work well for Thai, for which I'd like to use "3. UTF-8 with luit" behavior. Do you have any idea to include 8bit encodings which need special processings such as combining? --- Tomohiro KUBOTA <[EMAIL PROTECTED]> http://www.debian.or.jp/~kubota/ "Introduction to I18N" http://www.debian.org/doc/manuals/intro-i18n/ ___ I18n mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/i18n
[I18n][call for comments] XTerm patch to invoke luit
;;^FN?,MU
M+MUC[PYFRH8^GWM3O\)*+6S-`$SU'3`-:N?`/K8A862X>@4*/9T"K+X+\`PS
MZ'A+!`TA9=>GI$7@8[XB^!@V$?^PVQ07V:3CY==T`@8@*
M[5*5&/'DFS&J;)%0!H(R=K"=&`=*'9(*?Y%&5,(+`$HXW`@'^,4'[F%>42ZM
M=_Y8J:).'PI5GCB+0$6?:>Y`')U;8F5#+,62S9ESST93A:R'A!DQ%/O,GX^_
M]*?7DXLK*;B#3EMK-4!R!YT#Y?D+JN7!9+K"BK6L"*#Z91/(*3#1H\PKP7=P
M]X$]9S.@0I:,L^@REQ/E$B6#H#A/\>J>#8FOM-E6HXT2K\)G4VNW56>Q<.,#
M75^P_D^2I7MW<-Q6)=**J$5%D70]959-.(QW2&YB32HK_D_68H=0,(1U[%J0
M2K0'`),35CAAK`M_`\?*SL>&QHR/:PB.&*QB3K4*<]@9C#``44L@UC7*98=5
M61O^#RIL.[QXD#M4*D>)[H01%L@5-GX6?<^#7?NCT7`T'5^-^GC/UHO6+_G2
M6#V7C6JK&FALC2B-E9UJ<\-NAM2>!-.2MP5)F@+)H8(!U3A`8/R0G"T=R>%6
M)B*LVD(T?T:;-JN!1%(K191L2!J,C"(VE8S@NC]VOX6XZ.=[#T9`F6>CFQ*
MEE:UGR?\OK]$JZ"^X!&98ON@2:;8/FAWM>:>],*(BZX2R^42I8G,T!W']>'`
MMLU6_C.S?$$Z=.N44'M4T$"O+""!?1!L,ACVQE\'E^/?Z=Y7R@C2<=TNCP>?
M/E]?:0P^IZ=GYVE5SV."DDJ**K1C!@$YM8,WQ$0KV557S!ID0E>&^(B7MK]0QRRGNYL`2#1
MP'``"`>R<7V!W.44H_:F8VC8":&=R_"WXZIC9>ZF!">"U0J+H&?::`A]6[#62$K]OP;S3)'UY@RI"[Y
M^EVP)-5$`!`3>%H6"Z1GNK0@)4QF6FE"#N4$02C)Q`EB[-T'EQ/IW0>?+BM'
M&SLLB_Q^R"*WP[(HC"'(0%G*V`%K-@X;^X>M5_I0"FZMP](Z;#3C#DN[HT$V
M!G^'_0/5=H!"Z60X.NV/"H56:O0,/.#E\46_4,`X_F)J//@=IB`V5U7]DW@S
M!&/QXF09UBH_50I_>\J=;^)\!DPN0*'P`D/R[1(K[HHG(\
M)'!P>74]F5[T)Y^'IVF2GHZ*0[S$LYPLSAPRR9HZ!K1B[TVO'GU^[T.1+7*?
M/H8+WH@O<"P#*_0\=&K^C=@>_,W$J?D\M:2?.7JIYK(44TV]7S-S`--/V-I[
M,AN'CV[*">%3*DL$NGT"20T88ORCE%Z4?&]5**5^IE4Q+O3@#A%_SF*8>WL&2\Y=,2[W*BY9D,"U^<*?V
M>LDT6I*@Y@73>C<1TVY"IFVT"$@[EMAIL PROTECTED];!4Q2B+T`A]0Z8!!?=QN'[<9;
M["($347GO<3]1[M-;_?PHRD[1@[D^+?FX+;FW)I7=.EZ9SUP[)M2XA[6(]B/
MA*S]UCR9+"S!EH'PL3>(2VP=OLL>K':5XN$ND'V%WIX<8TG
M4DDDN(S9L^K^?O^.;-O:`N#;FFTDVIV!H`<:T2T0D8M/.K`MB@W;%?=T'W`4
MJ^(95BVQ->TOPNZPVJNN3F6XGL?%RG7PD:!+)P(>RK6WYHC!)&2V!O"V*EG$
M)(O,&;#(E&J88$]4HX'#IFE$&A)-U_6JD8QGG(%-,9\_`3$2!P$D14?%VH);
M=PN?`@`X##B)JME`,Y90L2%077J(O:[6;.)3QKVPWU@_854;L&,GVW;O[DA0
MIEE/")PA?X$;LAD?)?3`6;PT<(/X9A_.9`"_2-IP+#B3)[:*U?4G9H+[/KU9
ML.J\KC'98=:BEV@:5JW8"HXN)40H#`MW6%C\06H"]M^59B4:W\B'&<;_!_<^
MJ2FH`\6J;/X+%,6,^X_8I5!D)4X!&`AAG;%R!`Z;0T%3K!)B^494[BKA1;W"
MV+%M8Z7#'(X+$!/\[38;G=U.K4F2*%;EFP@`$,C#1%U$^X94_!7]$ZMB]=*E
M.E[WE1T[4"S"B&T)$EE\2*EWL659HEB-3)0PPE\S@$F12X#&W+@
M(2".L!7V?-"^`%JW[,@02'6JL>J`LTWHCA[X[I*:E8+;^*@-G8_Y0A:`K8<2
MUH*LL#HK:A'(\6B`A96])2@>DY0;8+-TA
M%:MGEKH,HZ.E'%E\?V1Z[G('"]4UJHO52(64SP-)2A.7U('#"AVNERO/5^4O
M8V6>%\)MN.G/=*_(SER8Q*Z<:]LP$&+">:A8YW0[1O$^?(BN'(XE/8FZ6-%8
MX)#>HHHO]`H;N0BMB<'P5N.R4,^2P+=
MNUHX!?B]U
M#UP?*`9HAXHDV+P`18$`=9<\!BO=UI8&6X(>68(;*)=2>)(EZD]Z)L?WXR&6
M.J1OP9+Y%C7[(`B^*3L0"!8D!.3(8ENA&%M0"*%@`+--3[4&@I@A(ZJYQ6O"]U4,T3?&B05&]*!MR9
M@)+2Y]+(7#!%SYI+CT6&1;`8\\.$1"'+M+&!S!,TMI(>#HG]_AWQ@,>/311<
M(4$?TC-JF`I18#A8\T$4Q^T\O9-9R+M]VP
MR]SE%*HB=ZO:;DDEJ@;=M&X"9M0:)2C)^*2,Z'%)ZP`MZZ"SJRP+Y::QA?L(
M6N)I<=@1?MQY(UU0.>G"%6AKS\1F3+^Y!]I59/?\F=X,'LG4>`OHH,<(0-XL
M`"=G.6D3!'`0'/A@>DQ6!DH-O%8%PK'/'4]5*`B]?7DI])1(GTMOB6!*6@>H
MESXG_Z^OX&@K2$U\^@27'X3`U72E(8
MX;+<5:D``-&8WK)A$,;T22BO""20/\(U9Q"Q)L\K7H0L9^;IWC/R-=1]&;WA
M#.'<(SW*6*X@JM`[;E?JG.2UQV6:%S*FKMB\I][F=<..,6"5PHL@()D!IN%V
M,ZAAPN2;DE%,XXEX\+FT&M7I-MI7K7YU)7-J=LI7V'Z4E0;N
M]`@NC'PON`(;\PC:]=&S,(Q)3R#S*$VI"/B\(M5L'F3(5-K9NG,OI&^,2O/!
M37@\X;N@`@S?C9*I$7&0F#Q&%7J8ITG&[=/58'.W<:"U92>7TC;U)FD.&88C
M5"+Q4@!81"?*/=6]2BN/;,Z@@HVC)`;(465>5"IH6/%D),IA>D-Q3`;N%YD^
M0VG[RD%F27TDLW>53Q2KT3[QO>=,:H*L/%_\VZ9RJN","].,BK.";#=UNO\$
MO1)6VG]#(62#Q2LU:(O"U%02L=U:HH98?FX=G[Y;U0R
M.6!"F@V\SZNOT_^&16,<^SOTKU@T(FBRT*TP6]$HD_!XJL(!5<:A1`HA66MD
M5F*``8L:8Z$[U#X@#P*I%412U=KM[![46C(2U)9A,L$3=
MD"5VTB*HH)202A?^NY(KV6D8!J)WOL*4+04::./2@KB4BN7`)BP$ATI5"51$
M4+8$1/^>]\9V%J@$]#!MXSB.[9GQO/%+?"6?54`=[U4K2@[UZ'\'\\7D%#-W
M*[Z*7J*4(9NYU$O)#[.WF'*6\=N2J@N@UHS_CY2+;I62+?]$RDRDN.`TST^D
MXI+NF1)[?,GY*)+*L.ONH,$2GPLJ05L[S17XC`&!/AO2)[X/AS]>+*6)#?Q%
M8W"CPA*BEY;:5@^`)-USQ>C;TRWNM,A9IMF(\SAG49HT[(D;OX6`[6U+_-UJ
M^]CDBG$>P=Q'@M4C5_#J`NJVY]DV1CJ^QXCS="Z:0/'*LN5CIE3>1=<*2YJU
MAFQB2`.@O3H*>T]39_?6=$3#'96W6%7]WJE2:O]$*7.YAQ^FC[\'!N*0XH+BTN1O_%#-]3\(N;(RYZPP+S1C
MB@6*18HEBF6*%:'?A(.:G+3;$/N[FXSB5+)KTA=V&=#J`1X=L[#3<*_$B%IH
M+(HH-$6;8HNB0]&EV':WH@+6J%NJ$#ZR22MDZ('0:D,A(N>]U)LHT^R,9B.:
MC6@VHMF(9B.ZXPBPG:X$?*VN]KJ;.%`;7CO]2JU_(5LI3QF.^`"SURC;3=0K
M:[<\\Y%,DL=1-4:C)IDC/AVZKWK'YJPVUX"R824/FO5U=1T,AZ0Q3@!\WL?C
MY',XQ-&7;!IH?&?R+6['5Z"#_7M-%=Z\%6$>W;F8FO&F)OLL05;*NTG7XPSF
0_IJ&DQ36]07W(1.9J$<`
`
end
---
Tomohiro KUBOTA <[EMAIL PROTECTED]>
http://www.debian.or.jp/~kubota/
"Introduction to I18N" http://www.debian.org/doc/manuals/intro-i18n/
___
I18n mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/i18n
[I18n][cvs] luit fix
Hi, Recently Juliusz's and my patches for luit have been adopted for CVS tree of XFree86. Thanks for XFree86 people. However, there seems to be a simple mistake. In Mon Jun 3 22:51:15 2002 UTC, luit.c and a few files were modified with the following comment: 167. A fix for luit's command line argument handling (#5173, Tomohiro Kubota). Though I don't have a copy of the patch nor ack from XFree86, I think the comment says about http://www.xfree86.org/pipermail/i18n/2002-February/002990.html http://www.xfree86.org/pipermail/i18n/2002-February/002993.html because it is the _only_ bug around command line argument handling as far as I know. However, the CVS version of luit still has the bug. Thus, I'd like to note that "luit's command line argument handling" bug is not fixed yet while the changelog says "fixed". I am afraid there is a simple mistake. Could you please check #5173 again? --- Tomohiro KUBOTA <[EMAIL PROTECTED]> http://www.debian.or.jp/~kubota/ ___ I18n mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/i18n
Re: [I18n]Hangul part of 12x13ja
Hi, At Tue, 05 Feb 2002 13:34:29 +, Markus Kuhn wrote: > > Tomohiro KUBOTA wrote on 2002-02-05 07:41 UTC: > > Markus, why don't you contribute your 12x13ja font to XFree86? > > I mean, your version of 12x13ja has much more glyphs (for example, > > Hangul) than corresponding font in XFree86. It will benefit > > Korean people who will use XTerm in UTF-8 mode (or with luit). > > It probabaly just hasn't been updated in quite some time by the > patch@xfree86 people as it comes in a separate package: > > http://www.cl.cam.ac.uk/~mgk25/ucs-fonts-asian.tar.gz > > Remind me again shortly before the next major XFree86 release to > resubmit everything. Since the CHANGELOG of XFree86 distribution says the version is 4.2.99.1 (which may mean that these changes are improvements for version 4.3), I think you can submit the improvements. --- Tomohiro KUBOTA <[EMAIL PROTECTED]> http://www.debian.or.jp/~kubota/ "Introduction to I18N" http://www.debian.org/doc/manuals/intro-i18n/ ___ I18n mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/i18n
[I18n]UTF-8 in XLC_LOCALE
Hi, At Tue, 30 Apr 2002 21:57:57 -0400 (EDT), Owen Taylor wrote: > And the locale.alias file aliases lots of of other locales > to the en_US.UTF-8 directory, so you can use those locales > with Xlib. My system has only en_US.UTF-8, ko_KR.UTF-8, and mk_MK.UTF-8 in /usr/X11R6/lib/X11/locale/locale.alias . However, since I think X locale is _only_ related to LC_CTYPE, we don't need en_US.UTF-8 but we need one universal UTF-8 locale for X, just like /usr/X11R6/lib/X11/locale/iso8859-1 defines all ISO-8859-1 locales. (Please correct me, since I feel I may be wrong.) --- Tomohiro KUBOTA <[EMAIL PROTECTED]> http://www.debian.or.jp/~kubota/ "Introduction to I18N" http://www.debian.org/doc/manuals/intro-i18n/ ___ I18n mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/i18n
[I18n]When patch will be adopted?
Hi, Juliusz and I wrote some bugfix patches for "luit" and I sent it as http://www.xfree86.org/pipermail/i18n/2002-February/002986.html (Juliusz) http://www.xfree86.org/pipermail/i18n/2002-February/002988.html (Juliusz) http://www.xfree86.org/pipermail/i18n/2002-February/002993.html (Juliusz) http://www.xfree86.org/pipermail/i18n/2002-February/003003.html (my #5177) http://www.xfree86.org/pipermail/i18n/2002-February/003007.html (Juliusz) http://www.xfree86.org/pipermail/i18n/2002-February/003066.html (my #5181) Though all of these patches are sent in February, they are not yet applied to XFree86 tree. Since these patches are needed to start development of xterm+luit (LC_CTYPE sensibility expansion of xterm) which I want to be realized in XFree86 4.3, I want these patches be adopted much earlier than the freeze of XFree86 4.3 or in early stage of development of XFree86 4.3 . Also, the patch includes some bugfixes which should be adopted as soon as possible (like 002993.html). I think Juliusz has already sent these patch to patch@xfree86, as I did for my patches. When will these patches be adopted? --- Tomohiro KUBOTA <[EMAIL PROTECTED]> http://www.debian.or.jp/~kubota/ "Introduction to I18N" http://www.debian.org/doc/manuals/intro-i18n/ ___ I18n mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/i18n
Re: [I18n]'xterm' terminfo definition conflicts with EUC encodings
Hi, At 20 Mar 2002 16:25:55 +, Juliusz Chroboczek wrote: > This is a known issue. Note that it is not peculiar to luit: the same > is true of kterm, which is why the kterm terminfo does not include ACS > capabilities. kterm supports ACS, just as I wrote (will write) below. > TK> The root of this problem is the definition of terminfo capabilites > TK> of enacs, smacs, and rmacs which conflicts with EUC encodings. > TK> How can we change the definition? > > Very simple. We need to change the definition of xterm to use VT 220-style > ACS. Namely > > :smacs=\E(0:rmacs=\E(B: > > (enacs is not needed). This will work for all locales that put ASCII > in G0 and point GL at G0 -- which includes all locales used on modern > Unices. I think this way is much better and works perfectly without confligting with all major encodings. Indeed, I found that "TERM=kterm" uses it! Thus kterm supports ACS. > Additionally, we need a new definition for ``xterm with no ACS'' for > encodings that do not satisfy the above condition (e.g. ISO-2022-JP). > This is quite simple to add: > > xterm-nacs|xterm without alternate characters:\ > smacs@:rmacs@:enacs@:tc=xterm: Sure. Strictly speaking, it is needed. However, very little people will need this, I think. (If it were needed by a certain amount of people or by some major encodings, we would need not only "xterm-nacs" but also "xterm-color-nacs", "xterm-r6-nacs", "xterm-xf86-v*-nacs", and so on so on. However, I think it is not realistic idea. We are happy because kterm-type enacs/smacs/rmacs can work well with all major encodings.) > I have been arguing for these changes to be made to ncurses for months > (since the first releases of luit), but Thomas is afraid of what they > might do to backwards compatibility. I would suggest that you take it > up with him. I checked term-type enacs/smacs/rmacs works well for many terminal emulators. $ xterm (or other terminal emulator) $ cat some-8bit-file (confirm that both of GL and GR characters are displayed properly) $ TERM=kterm dialog --msgbox foobar 8 20 (this uses enacs/smacs/rmacs to display line-drawing characters. Checks the line-drawing characters are displayed well.) $ cat some-8bit-file (confirm that usage of enacs/smacs/rmacs does not break GL or GR) I checked xterm, kterm, hanterm, rxvt, eterm, aterm and all of them works well (it can display line-drawings, and, more importantly, GL and GR are not destroyed by enacs/smacs/rmacs). gnome-terminal could not display line-drawing characters. Howevre, it is not as a severe bug as garbage characters for GL or GR. Anyway, I think gnome-terminal is responsible to fix this bug. I think ncurses should not hesitate to adopt kterm-type enacs/smacs/rmacs. On the other hand, mlterm http://mlterm.sourceforge.net implements proper ISO-2022 parser and this causes garbage characters. Thus, it is a present problem, not a future problem with future xterm+luit. Thus, I hope this situation will be fixed as soon as possible. And more, I think that leaving enacs/smacs/rmacs definition will mislead terminal-emulator-developers. Thomas, could you please change enacs/smacs/rmacs definition for "xterm" just as Juliusz has reported? --- Tomohiro KUBOTA <[EMAIL PROTECTED]> http://www.debian.or.jp/~kubota/ "Introduction to I18N" http://www.debian.org/doc/manuals/intro-i18n/ ___ I18n mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/i18n
Re: [I18n](no subject)
Hi, At Thu, 21 Mar 2002 07:16:29 -0800 (PST), yufufi wrote: > #localedef -ci tr_TR -f iso8859-9 tr_TR Please use "ISO-8859-9" instead of "iso8859-9". However, for Debian woody/sid, you will be asked which locale to be build when you installed "locales" package. The question (and auto building of chosen locales) will be available by typing "dpkg-reconfigure locales" by the root user. --- Tomohiro KUBOTA <[EMAIL PROTECTED]> http://www.debian.or.jp/~kubota/ "Introduction to I18N" http://www.debian.org/doc/manuals/intro-i18n/ ___ I18n mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/i18n
[I18n]'xterm' terminfo definition conflicts with EUC encodings
Hi, I found a severe problem in 'xterm' terminfo definition. It defines alternate character set-related capabilities like: enacs=\E)0 smacs=^N rmacs=^O which are indeed using G1 of ISO-2022. This works well for 8bit encodings which use G0 and G2. However, G1 is used in several encodings such as EUC-JP and EUC-KR. Thus, using these terminfo capabilities will overwrite the initial settings of G1 in these encodings and break proper displaying. This is a real problem in xterm+luit, though it doesn't matter for legacy xterm because it doesn't support EUC encodings. For example, $ xterm -u8 $ export LANG=ja_JP.eucJP $ luit $ dialog --msgbox foobar 8 10 $ cat Japanese_File_in_EUC will display the contents brokenly. The root of this problem is the definition of terminfo capabilites of enacs, smacs, and rmacs which conflicts with EUC encodings. How can we change the definition? --- Tomohiro KUBOTA <[EMAIL PROTECTED]> http://www.debian.or.jp/~kubota/ "Introduction to I18N" http://www.debian.org/doc/manuals/intro-i18n/ ___ I18n mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/i18n
Re: [I18n]So, will Bidi+Xterm happen ?
Hi, At 26 Feb 2002 10:15:35 +, Juliusz Chroboczek wrote: > - a number of people think that we should ``do BiDi in the terminal > emulator''. They were not willing (or not able?) to define what it > means to ``do BiDi in the terminal emulator'', instead pointing at the > Unicode BiDi algorithm (which is not designed for terminal emulators, > and may or may not be a sound basis for such applications). Nobody > produced an informed comment on ISO 6429 BiDi. Right. To tell the truth, I have not read. However, I will read some standards because we are agreeing on, at least, curses/slang level. Anyway, I think "everyday bidi-language speakers" should discuss on this point. > - everyone appeared to agree that there's a need for BiDi at the > curses/slang level. This means that the terminal emulator-level BiDi, > if any, must be switchable. For some reason, nobody seems interested > in implementing BiDi at the curses level (not sexy enough?). I think it is not enough, because I think Arab/Hebrew people want "cat arabfile" to work well. Of course "cat" doesn't and must not use curses/slang. > - some people produced analogies with luit, which to me seems to > imply a lack of understanding of what luit does (luit has *no* notion > of cursor position). Unless I'm missing something, BiDi really > needs access to internal terminal emulator data. I also think that "luit" approach doesn't work well. If we were use "luit"-like approach, we will have troubles around communication between terminal and "bidi-luit". The original "luit" already have one "communication" problem -- control code to specify doublewidth character. If "luit" approach were not taken and XTerm itself were have locale encodings support, such problems didn't appear. I don't like "GNU screen" analogy. This is because "GNU screen" implements various "fancy" functionarities which are not "must". On the other hand, for Arab/Hebrew speakers, bidi support is a "must". --- Tomohiro KUBOTA <[EMAIL PROTECTED]> http://www.debian.or.jp/~kubota/ "Introduction to I18N" http://www.debian.org/doc/manuals/intro-i18n/ ___ I18n mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/i18n
Re: [I18n]So, will Bidi+Xterm happen ?
Hi, At Sun, 24 Feb 2002 11:14:43 -0800 (PST), Nadim Shaikli wrote: > I think we're loosing focus again on this topic (note subject :-) I imagine that people who are discussing about copyright problem will naturally think Xterm should support Bidi in future. Imagine, is it likely that a person who thinks thet Xterm should not support Bidi will worry about FriBidi's license? I support the idea of supporting Bidi by Xterm, though we will have to research concrete definition of what "Bidi support" is. On the other hand, I want native Bidi people to use Brady's patch or Mlterm and give good feedbacks to Fribidi or Mlterm. Such experience of using Bidi terminal will be useful in discussing the above discussion, i.e., determining concrete definition of what "Bidi support" is. We will need some standard definition of what "Bidi support" is, because apprication softwares which want to run on Bidi-supported terminals will have to know what functionarities the terminals have. The contents should not be modified frequently. I want native Bidi people to take the initiative in such discussions. But, I am afraid whether people here will agree that Xterm will support Bidi, as Nadim is afraid... Without such consensus, any discussions will be futile. I remember that Markus and Juliusz have expressed an objection for Xterm to support Bidi. Is it true even now? PS. [offtopic] Juliusz, could you please release a new version of luit with all patches? --- Tomohiro KUBOTA <[EMAIL PROTECTED]> http://www.debian.or.jp/~kubota/ "Introduction to I18N" http://www.debian.org/doc/manuals/intro-i18n/ ___ I18n mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/i18n
Re: [I18n]i18n mechanism
Hi, At Tue, 19 Feb 2002 19:51:54 +0530 (IST), Aravind Menon wrote: > > Hi, > I do not exactly wish to do the entire handling of Indic script. We have > already modified a part of Xlib (the XDrawString and similar functions) to > handle input in a different manner when it is ISCII encoded (ISCII is an > 8-bit encoding for Indic scripts and is compatible with ascii). This > modification is, at best, ad hoc. I imagine your work is related to character -> glyph conversion. Is that right? > We wanted to introduce UTF-8 support for Indic scripts by > modifying lcUTF8.c and introducing appropriate converters in lcUniConv. These > converters convert UTF-8 encoded text into ISCII. The ISCII text is then > appropriately handled by the modified XDrawString. > I introduced a new locale 'DEVANAGARI', and wrote a UTF to ISCII > converter for it. When XmbDrawString is called with UTF encoded DEVANAGARI text, > the conversion is working fine, but the correct font is not getting loaded. In > fact, XCreateFontSet returns DEVANAGARI as a missing charset inspite of the fact > the required font is installed in the system. What font name you use? I imagine Devanagari will need more glyph codepoints than character codepoints. Since these X11 functions assume the character encoding to be *glyph* index, I think some radical redesign would be needed for X font mechanism to support Devanagari. It is because X's font mechanism including XFontStruct, XFontSet, and Xft all assume that character and glyph correspond one-to-one. I once have seen Indic ISCII fonts which, in reality, have more glyphs than ISCII codepoints. We need to have some orthodox codepoint for such expression forms. And, I remember these fonts have '-*-iso8859-1' names, which is a bad idea against the idea of FontSet. --- Tomohiro KUBOTA <[EMAIL PROTECTED]> http://www.debian.or.jp/~kubota/ "Introduction to I18N" http://www.debian.org/doc/manuals/intro-i18n/ ___ I18n mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/i18n
Re: [I18n]i18n mechanism
Hi, At Mon, 18 Feb 2002 13:54:56 +0530 (IST), Aravind Menon wrote: > I am working on a project that involves changing Xlib to support Indian > locales. I am quite new to i18n and would like to get technical information > about the existing i18n framework, specifically the internal mechanisms and > architecture. > Where can I find the above information. Sorry, people here seem not to be interested in supporting "complex" languages such as Arab/Hebrew and Indic in Xlib level or some other similarly basic level. Though I am interested in, I don't have enough skill (I am relatively a newcomer to this list). Though there are a few projects to support "complex" languages like Pango (http://www.pango.org/ it is not living now?), I think ST project (http://stsf.sourceforge.net/) is the one which you may like best. --- Tomohiro KUBOTA <[EMAIL PROTECTED]> http://www.debian.or.jp/~kubota/ "Introduction to I18N" http://www.debian.org/doc/manuals/intro-i18n/ ___ I18n mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/i18n
Re: [I18n][patch] XTerm to support various encodings according to locale
Hi, I got patch sequence number 5182 for this patch. At Sat, 16 Feb 2002 16:10:14 +0900, Tomohiro KUBOTA wrote: > Here is a patch for xterm to support various encodings by using > "luit". Discussion was done in the i18n@xfree86 mailing list. > http://www.xfree86.org/pipermail/i18n/2002-January/002947.html --- Tomohiro KUBOTA <[EMAIL PROTECTED]> http://www.debian.or.jp/~kubota/ "Introduction to I18N" http://www.debian.org/doc/manuals/intro-i18n/ ___ I18n mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/i18n
[I18n][patch] XTerm to support various encodings according to locale
Hi,
Here is a patch for xterm to support various encodings by using
"luit". Discussion was done in the i18n@xfree86 mailing list.
http://www.xfree86.org/pipermail/i18n/2002-January/002947.html
The patch I am sending now is a slightly modified version of
http://www.xfree86.org/pipermail/i18n/2002-February/003005.html
and the modifications are (1) a tiny bugfix in main.c, (2) manpage,
and (3) PROJECTROOT.
This patch needs "luit" with the following patches.
http://www.xfree86.org/pipermail/i18n/2002-February/002986.html
(Juliusz, overrides #5170)
http://www.xfree86.org/pipermail/i18n/2002-February/002988.html
(Juliusz, overrides #5170 yet again)
http://www.xfree86.org/pipermail/i18n/2002-February/002993.html
(Juliusz, a small bug in luit)
http://www.xfree86.org/pipermail/i18n/2002-February/003003.html
(Tomohiro, -encoding option, #5177)
http://www.xfree86.org/pipermail/i18n/2002-February/003066.html
(Tomohiro, manpage for 5177, #5181)
In the whole, this patch
- adds "locale" resource. When its value is:
"true": xterm will use locale's encoding everytime,
by turning on utf8 mode and calling luit in non-UTF-8 locales.
"false": xterm will use locale's encoding only in UTF-8 locales,
and otherwise xterm will be conventional 8bit mode,
by turning on utf8 mode only under UTF-8 locales and
never calling luit.
"medium": xterm will use locale's encoding in UTF-8, east Asian,
and Thai locales, and otherwise xterm will be conventional
8bit mode.
other values: the value is assumed to be an encoding name.
the default value is "medium".
- adds "localeFilter" resource to specify "
- adds -lc and +lc command line options, which correspond to
"locale: true" and "locale: false", respectively.
- adds -en command line option to specify encoding. "-en foobar"
is same as "locale: foobar".
- adds -lcc command line option
- doesn't touch "utf8" resource and -u8 and +u8 command options
for compatibility, though the default-determining algorithm is
moved from main.c to charproc.c .
- rewrites manpage.
The patch is gzipped and uuencoded.
begin 644 xterm-20020130-k3luit.diff.gz
M'XL("&4%;CP"`WAT97)M+3(P,#(P,3,P+6LS;'5I="YD:69F`+Q;>7,:2;+_
M&SY%#;MK@6@0AVX]SXX.9+,C"04@6S,C!VZ:0O13T\WK0[)FUM_]_3*K^D"`
M#L?&$K:`JLJLK+PSNQC9X[&H^-&%^!9*?UIIU&J-6KU9VVA/S3LYMAWY9*)R
MUW0B.TSG\Y5*925PKF>&HF.%HMX4M9W]+?S;%EA6SY?+Y9VU.Q?O
M_UZ<'RCE!5[G[=[QX*1UVKYH]<1[L;$.P,.SL\[GL\Z'#^V+#YFOI^VS5NNZ
M=2S6-QA47/]ZE`&]OAL>.[9TPQ.0[,H@7Q'ZE:ZIM*OB[\4,7`E?^ZWN^?'A
M96;DM'78O^JVLHMZQ]W.V=G187?0;7_XV*>AJ_[I[J!SV:>S$-;N*=:7\F7L
M>'G8_Y@AK7)RV>W\JW7<[W8Z?3`B\TVM_^^3B4]9(B&,O/B;/1[)L>CT&H>^
M-;%#:861+_,B?9T?MB]ZW6.0Z`6-J6F[52L_6J6WUL3T9[YG5:T5ZI4N6*:Y
MZ6RN%[GB7Z8+C1/UVO[6[O[FCM*^U:J;A<[H;F._4=]O[J:ZN[6]2;I+;WNL
MNV""`+<&G]LGK<'QQ\-N+R_^N@XOHG"\:XCK\/A*?^BVW=`0@?VG],9%VPU+
M!A3_.NR,QX'$W^(UT?79'MW*L"LMK+1\*=TJX1E,O9'$^@K6=WNA;[NWA@#K
MS<@)25S?C7PY.U5H%FBHY\L`:"\2PY/@L_CRU`ZNJ9@9!Z!NYPE2.
M[&A:*"U`GMH.:#-2\'@@@V.LAZ`?9YWCPS.HR1DTD`YYI)$]V"-Y##8'C.ES
M^BVGCTH+!I8:.ST\Z[4(NI>!/O*`JM(4GFFXW='6-;E/&^9]1K+':\CCS/D=`RRW,\?^#='4`9
MI`OUYEDZAU@/#O+E)1I"-ARY@7WKRI%>J=AXP%,\DLH&,OVC4?M"J#1^W@&^
M[W?I>\*+0A%.I(`KLWTI"HJ;!=`UG7DN1H4W%H4'5SX4Q`/KET'K73'RE*VN
MB[$MG5%E^%CA#\(,B+1I#!HCY,D`L#`0$SNY)E1&V"YA4XS::M:945O-'6.G
MP8Q:;B%XV:X=#E@W%L1?4FP`7+&HV``/`KJE>U\LG!T/X.$+I9)X_U[4Q+__
M'?..OJ_=U-9*0OO(E?#'_=\N6Z_!L!+'X<6'U\$+D0!?7)V=J8.-/5\4[?>U
M`V'_3WT/?\OEDOAKD>I8^/87@(=>-)M)O^C+_XMD$%9^?F+!6*4IRL0(,?2E
M>:=V_OP++XQ,D.*U9W+EZ_]K=6[_6+
M#Z_ZG=>OKNNE*7=A-`^D^Z$?25&M5L4X1+B^OQXF3^:8C`HH:6-6-\
M3I[L8)=P\EFIGIZ^$>*B\T:`VDJ)C4TZ$8G,\^U;VS4=<6\ZD")<5,H!.Q!R
M/$8F8M]GI/<2^XE/SW#UO6BF]"16\CK)OTI<"RKP/%1"]_=7"ON\==*^.E\E
MBI7"Z+7.VQF#6Y2)2AF44+0%:>9Z+JR*_!PS1ICN2!P&-J)E(I,D_B$7$H[I
MWAXL,[6,I3G2U>,E\;.H8S1SC%7R>)\8:V8Q_"OV`R/5\C]J7]8;6]ME_:W^
MA<'6_G>-1]?,M2<<4\!8<:=7>+0B'0[U\&0EX)_)BE)6L5XR_%?J4D8?WNZR
M7B:G]F/D_*?P9I9Q"L&IW9-86'JK@634Y0WV0;GW2MM0BD^FH3XQ^:_V2*_W
M\9E]/21BOGCP?&1IE*#Y\M;T1Y(2.F2'EC/;.!@
MZ;+YPQ&31W9@#L&3<>0SNX'#O67)KJQL1V9HKJQJU>2RBE;-Y/J3B*O9^JZH
MH93=WF^^V(B)(1$=J9(56Z)6VV_$D*J2W:M3(;M'"3OEZ:U[I/OG=%"9?()+
MZ'3/#Y&U+D_C*URH9`[EMAIL PROTECTED]:GAN$J;L/)IX?`LAJ1%;P
M1U-!H!2N?6MLF3*7`XN'CFG=B7OIAS84`9IDA>"Q@\G<^H;Q`I\GS_%DLI+/
MDQ_F\V21SXU,QZ#>:'"W"V^*TVD1MXREDG9RQ0)G4?Z)>.X%AF8*T=6\4MV8
M%>?2K9HEO%(SBQV6K?I+'988(5ZI-^+5^CKYJ-JWL7[!
M&P2A-$>4]'$]Q9E%$`T#LG\D$E%@WB*LR>IME2K38&8^N,42D#"N7NO#IVJ>
M;+42A":T2Q??ZZB5I\`T"+V!_":MM%I[S3)C<6;P8(>3`?O6&!7)>\2M1J%;
M^Z%=^C?8J9HF:.1/PA+HM"@7A%@RF^`J7%_"?LX
MEH)1'OL%*/*R&K#\)L!32OW3+0DTAE2MJ(*1@/?DC.%3<&*_AI7NJEU7@B6F
M1%QUU-;<\;DZ(Q_Y`N7>>)RP]^W`+L&JCGF3O$<9[]NZ9_Z7*%1"EZ-YP9C/
M5@JD7PCX][;OJ2[.O>G;'+1XN>!C+5,P2BC@.L(V$Z*@Z2.I"6\(T4.1.8BX2CIX\925$=<1I$F:#S>\%R*\C/'?.3BTAU)WR';1!K%
MTDLX2.WOCX>?6H.K_OFEDM1><]>`5RS7]S8WMX'92,5C:0/N)LEW4
M!.L!?52=*R2_%6CA4XBD9?9J&-TB6[*>4C*LSY3109J"EVB*",\&OQHE"6N-
MM0-]J.]XQW\MU`JXVI-A-#N7;A040V_F((=Q#/$.!>@4+GF&C["#B#Z6V!/G
M*$0!9[;K7A+7X2?S&'(*Y;GI(HZ,U$21)8M@QLX7P:II-)NZN4
M11/_HY)8CQ]B*-PEIH
Re: [I18n][patch] manpage for patch 5177
Hi, I got a patch sequence number of 5181 for this patch. At Sat, 16 Feb 2002 10:45:29 +0900, Tomohiro KUBOTA wrote: > Here is a patch for the manual page of luit, which should > accompany with the previous patch #5177. --- Tomohiro KUBOTA <[EMAIL PROTECTED]> http://www.debian.or.jp/~kubota/ "Introduction to I18N" http://www.debian.org/doc/manuals/intro-i18n/ ___ I18n mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/i18n
[I18n][patch] manpage for patch 5177
Hi, Here is a patch for the manual page of luit, which should accompany with the previous patch #5177. (for i18n@xfree86 people: patch #5177 is: http://www.xfree86.org/pipermail/i18n/2002-February/003003.html ) from here --- luit-cvs20020205j-k/luit.manMon Feb 11 23:06:54 2002 +++ luit-cvs20020205j-k2/luit.man Sat Feb 16 10:35:51 2002 @@ -34,7 +34,7 @@ Display some summary help and quit. .TP .B \-list -List the supported charsets and quit. +List the supported charsets and encodings, then quit. .TP .B \-v Be verbose. @@ -44,6 +44,13 @@ .TP .BI \-argv0 " name" Set the child's name (as passed in argv[0]). +.TP +.BI \-encoding " encoding" +Set up +.B luit +to use +.I encoding +rather than the current locale's encoding. .TP .B +oss Disable interpretation of single shifts in application output. ---- till here --- Tomohiro KUBOTA <[EMAIL PROTECTED]> http://www.debian.or.jp/~kubota/ "Introduction to I18N" http://www.debian.org/doc/manuals/intro-i18n/ ___ I18n mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/i18n
Re: [I18n]BiDi rant
Hi, At Thu, 14 Feb 2002 11:45:25 +0100, Pablo Saratxaga wrote: > > Kaixo! > > On Thu, Feb 14, 2002 at 02:37:46PM +0900, Tomohiro KUBOTA wrote: > > > Robert Brady's patch to be merged into the xterm. One is license > > problem; Robert's patch contains FriBidi code which is LGPL. > > So? > > There is no problem at all to link against a LGPL library. > In GNU/Linux *all* of XFree86 is linked with LGPL libraries. > THe libc and libm ones, namely. I mean, not *link*, but Robert's patch *contains* LGPL code. And, even if Robert's patch will be rewrited not to *contain* fribidi but to *link* fribidi, do you think it is a good idea for XFree86 distribution to need FriBidi to be compiled? --- Tomohiro KUBOTA <[EMAIL PROTECTED]> http://www.debian.or.jp/~kubota/ "Introduction to I18N" http://www.debian.org/doc/manuals/intro-i18n/ ___ I18n mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/i18n
Re: [I18n]BiDi rant
Hi, At Wed, 13 Feb 2002 19:44:56 -0500 (EST), Akber Choudhry wrote: > the question is, should we realistically expect bi-di support in xterm or > is it technically or otherwise unattainable in the near future? if not, > should app developers like us look at layers below or above to achieve the > desired result? Or, maybe the solution lies in those layers are not in > xterm. Yes. I'd like to talk about this. There are two usable implementations of bidi-supported X terminal emulators, as far as I know. One is Robert Brady's patch for xterm (Robert Brady's page seems not living now... please use my page http://www.debian.or.jp/~kubota/xterm and download xterm-152-27) and mlterm (http://mlterm.sourceforge.net). Besides aethetic problem whether bidi-support layer should be located in terminal emulator or other layers, there are a few problems for Robert Brady's patch to be merged into the xterm. One is license problem; Robert's patch contains FriBidi code which is LGPL. Another is that I have not heard from Robert for long time while I don't know well about the internal of the patch. On the other hand, mlterm is now actively under developement (mlterm cvs is updated almost everyday). It is a realistic solution for people who need a BiDi terminal today. The problem is ... it is not the famous popular Xterm. However, if BiDi people will use mlterm, it will be famous and popular. "luit" approach is one solution, but it may (or may not) have a problem; communication between terminal emulator and luit. Though I am now working with luit's improvement, we need a way to communicate East Asian Width information from luit to xterm. And, though "luit" would be virtually needless after 10 years or so when we will all use Unicode, there are no possibility that BiDi will be needless in future. And, usage of "luit" way will result in that the future xterm will need to call many filters like "luit", which is ugly. On the other hand, merits of "luit" approach are: it can be used from other terminal emulators and it can keep source code of xterm simple. Though the latter can be achieved by careful implementation, the former cannot be achieved by monolithic xterm with bidi support. Thus, I think one solution is to develop FriBidi-like library with non-problematic license and xterm will use it. --- Tomohiro KUBOTA <[EMAIL PROTECTED]> http://www.debian.or.jp/~kubota/ "Introduction to I18N" http://www.debian.org/doc/manuals/intro-i18n/ ___ I18n mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/i18n
Re: [I18n]BiDi rant
Hi, I think we must never talk about script reforms here, because we don't have political power to achieve them. Also, needed labor for i18n developers to supporting bidi or other complex scripts is *much* less than needed cost for such script reforms. Why people here who are interested in i18n cannot respect cultures in the world as such? I agree that BiDi support in terminal is a heavy work. However, it is possible. It is possible with much much less cost than script reform to have a certain level of BiDi support like Arab Windows/DOS and FriBidi, though I don't know how satisfying these implementations are for native speakers. Even if we don't have enough skill or time to implement BiDi support, we must not say "BiDi should not be supported". We should say "Sorry, I don't have enough skill/time to implement it". At Tue, 12 Feb 2002 14:12:00 -0700, Weldon Whipple wrote: > Prior to World War II, Japanese horizontal writing went from right to > left. After the war it changed to left-to-right. Yes. However, I don't know how many years they took. Anyway, we lost the War and the language reform was one of requests from The Occupation Forces. > (Of course, many [most?] Japanese books still go vertically, with the > front of a book at the back--from an English perspective.) The Japanese > don't have a real hangup with left-to-right versus right-to-left. I've > noticed that on buses and trucks, writing often goes from the front of > the vehicle to the back, so that on the left of the vehicle it is > L-to-R, and on the right of the vehicle it is R-to-L. Vertical writing is widely used. Go to Japanese bookstore and you will find more than half Japanese books are written vertically. (Generally speaking, most books, newspapers, and magazines whose topics are other than science, enginnering, and mathematics are written vertically. English textbook is horizonal. :-) > On my most recent trip to Japan, I noticed that signs for bathrooms were > invariably written "Toilet" (Romanized), rather than in katakana (and > rather than using O-te-arai [in kanji and hiragana], like they did 34 > years ago when I first went to Japan. Usage of such "Toilet" (Romanized) is only for design purpose. Though such usage is widely used, they are still not a normal Japanese language. > I doubt that if Japanese will ever completely abandon kanji, hiragana, > and katakana, but the language definitely uses more romanized words > today than it did 34 years ago ... I cannot imagine that, though there are few scholers who strongly insist abandoning kanji (using hiragana) or abandoning all of kanji, hiragana, and katakana (using Latin script). Such scholers are today completely ignored in major Japanese language. I read somewhere an interview of such scholers. The interviewer noted that even such scholers used kanji for interview purpose. It is apparent that such scholers are losing their places. --- Tomohiro KUBOTA <[EMAIL PROTECTED]> http://www.debian.or.jp/~kubota/ "Introduction to I18N" http://www.debian.org/doc/manuals/intro-i18n/ ___ I18n mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/i18n
Re: [I18n][patch] luit -encoding option
Hi, Thank you for checking my patch. At 11 Feb 2002 17:54:58 +, Juliusz Chroboczek wrote: > Unless I'm missing something, there's a bug: -encoding should set up > inputState in addition to outputState (keyboard input). I think it is OK because mergeIso2022() is called after parseOptions() where I added initIso2022(). I think mergeIso2022() is responsible for setting up inputState. Am I right? > You also forgot to update the manual page; I'm attaching my suggested > wording. I fully agree with your description of -encoding. I think we should also need the following patch for users to know valid encoding names for -encoding option (though I don't know it is a natural English expression; the first "and" connects "charsets" and "encodings" while the second "and" connects "List ... encodings" and "quit"). --- luit.man.oldSun Feb 10 23:18:15 2002 +++ luit.manTue Feb 12 09:38:07 2002 @@ -34,7 +34,7 @@ Display some summary help and quit. .TP .B \-list -List the supported charsets and quit. +List the supported charsets and encodings and quit. .TP .B \-v Be verbose. ___ I18n mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/i18n
Re: [I18n][patch] xterm to invoke luit
Hi, At 06 Feb 2002 15:40:42 +, Juliusz Chroboczek wrote: > TK>case 'e': > TK> if (argc <= 1) Syntax (*argv); > TK> command_to_exec = ++argv; > TK> break; > > I see. Well, I'd rather we didn't rely on such an accident of nature. > > TK> in main.c 1933. Anyway, I will change this part to use malloc() and > TK> copy argv into the buffer, to cope with "luit -- command" > > Good. Now, I think you are right, because my implementation of command_to_exec--; can be a cause of possible bugs in future when further modification would be done by someone. > TK> It is a good idea. I am now trying to implement it by modifying > TK> execvp() and exec_file() in spawn(). However, I have no idea what > TK> is exec_file() or what is AMOEBA system. > > I think you should feel free to remove all the Amoeba support. > Thomas, have you heard from any Amoeba user in the last 10 years or so? I see. Then, my patch will not touch AMOEBA code at all, because I don't think I can remove the code without knowing what it is or how it is popular. > TK> It is, addition of a command option to directly specify encoding. > > The nice thing with not having such a flag is that it forces people to > configure their locales correctly -- I'm fed up with bug reports from > people who set the locale to Latin-1, use Latin-2 fonts, then complain > that fontset-aware applications don't work. Well, you are right. I want users to know about locale, for two reasons: (1) developers come from users, and locale-innocent developes will write softwares which don't support locale or, even worse, softwares which don't work well under some locale configurations. (2) as you wrote, such locale-innocent users complain "i18n" softwares are useless for them. This is why "i18n" softwares are sometimes forced to implement non-locale behavior for such people. Otherwise, softwares will suffer from a huge amount of bugreports or lose users. Thus, multibyte people wish all users in the world to know about locale. However, we are accustomed to think that we have no rights to force 8bit-language people to study about locale. How do you think about this point? I think I will not implement "-encoding" in, at least, near future. (I also think "utf8" resource for Xterm is not a very good idea, also, from exactly the same reason. How do you think about this?) > TK> Another improvement is to accept UTF-8 locales. > Yep. I'm planning to do that when I implement generic support for > variable-width charsets (GB and stuff). I see. --- Tomohiro KUBOTA <[EMAIL PROTECTED]> http://www.debian.or.jp/~kubota/ "Introduction to I18N" http://www.debian.org/doc/manuals/intro-i18n/ ___ I18n mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/i18n
Re: [I18n][patch] xterm to invoke luit
Hi,
At 05 Feb 2002 11:26:15 +,
Juliusz Chroboczek wrote:
>
> Nice work. I fully agree in your change of terminology.
>
> A couple of questions.
>
> TK> + if (term->misc.locale) {
> TK> + if (command_to_exec) {
> TK> + command_to_exec --; /* This should be possible */
>
> Why should this be possible?
Because "command_to_exec" is set by
case 'e':
if (argc <= 1) Syntax (*argv);
command_to_exec = ++argv;
break;
in main.c 1933. Anyway, I will change this part to use malloc() and
copy argv into the buffer, to cope with "luit -- command" (and maybe
luit -e command").
> I'm also a wee bit worried by what happens if somebody removes luit
> from the system. XTerm should still accept to run if exec(luit)
> fails, just print a warning and continue with no locale support.
It is a good idea. I am now trying to implement it by modifying
execvp() and exec_file() in spawn(). However, I have no idea what
is exec_file() or what is AMOEBA system. (There are two versions
of spawn() for AMOEBA system and other systems.) I cannot test
the code.
BTW, I will make a few additional changes:
- remove getenv("LC_ALL") ... defaultUTF8[] codes from main.c
and add equivalent codes in charproc.c where I added
getenv("LC_ALL") and so on.
- remove defaultUTF8[] because of the above modification, without
modifying behavior of xterm.
- change setting string for "locale" resource: from "auto" to "medium"
because "auto" should be appropriate for "true" because encoding
is fully automatically set by locale in "true" mode while encoding
is partly automatically set by locale in "auto"/"medium" mode.
(In the mode, encoding is automatically set only for east Asian
and UTF-8 locales while encoding is 8bit [no encoding] for other
locales.) Candidates for names other than "medium" are welcome,
but not "auto".
- Resource of "locale: UTF-8" is equivalent to "utf8: true", which
is already implemented in the last patch. Similary, other encodings
will be available here, like "locale: ISO-8859-15". This needs
luit's improvement to specify encoding from command line option.
---
Tomohiro KUBOTA <[EMAIL PROTECTED]>
http://www.debian.or.jp/~kubota/
"Introduction to I18N" http://www.debian.org/doc/manuals/intro-i18n/
___
I18n mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/i18n
Re: [I18n]Luit fix for EUC charsets
Hi, At 05 Feb 2002 18:31:52 +, Juliusz Chroboczek wrote: > Actually, the previous patch was the corrected version. This one was > the version that I sent before I saw your patch[1]. (Reading your > patch is what made me realise my mistake and send the corrected > version; I hope I have adequately credited you in the submission.) I see. > In summary: please ignore the version ``Luit fix for EUC charsets''. > but use ``Luit fix for EUC charsets [overrides 5170]'' instead. > > I'm looking forward to the results of your testing; once you confirm > the ``overrides 5170'' version works, I'll put up a new standalone > version of luit. As I wrote, it works well. Further usage doesn't show any problem. Please release a new version. BTW, I have an idea to improve luit, which I imagine should be implemented easily. It is, addition of a command option to directly specify encoding. For example, "luit -en eucCN", though I don't know this is really a good idea to add it. (I intend to improve xterm's "locale" resource to use it, like "xterm*locale: utf-8" or "xterm*locale: eucJP".) Another improvement is to accept UTF-8 locales. In such case, luit will work as "doing-nothing-filter". This will simplify the needed work of caller of luit. (So far, the caller of luit has to check UTF-8 locale whether to call luit or not.) --- Tomohiro KUBOTA <[EMAIL PROTECTED]> http://www.debian.or.jp/~kubota/ "Introduction to I18N" http://www.debian.org/doc/manuals/intro-i18n/ ___ I18n mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/i18n
Re: [I18n]Luit fix for EUC charsets
Hi, At 04 Feb 2002 19:19:44 +0100, Juliusz Chroboczek wrote: > Please find attached an implementation of an obscure ISO 2022 feature. > According to Tomohiro Kubota, this is needed for proper support of the > EUC-JP character set, and probably other EUC thingies. This patch doesn't work well, though your previous patch (for which you added '}' later) works well. When I input "cat JISX0212.txt", xterm+luit displays wrong character. The test was done using the following file: od -t x1 JISX0212.txt 000 f1 d6 8f e9 d1 0a > It adds Yet Another Incomprehensible Flag to luit, which is good, as > this multitude of options makes it wonderfully clear why ISO 2022 is > not really a good idea. Sorry, I am not interested in such religious war any more. --- Tomohiro KUBOTA <[EMAIL PROTECTED]> http://www.debian.or.jp/~kubota/ "Introduction to I18N" http://www.debian.org/doc/manuals/intro-i18n/ ___ I18n mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/i18n
[I18n]A small bug in luit on invocation of child process
Hello, During I am trying to implement "luit -- " in xterm, I found that luit doesn't work with "luit " while it works well with "luit ". Here is a patch to fix this. Juliusz, please check my modification is right or not and send it to patch@xfree86. --from here diff -ruN luit-20020203-1/luit.c luit-20020203-2/luit.c --- luit-20020203-1/luit.c Sun Feb 3 10:51:02 2002 +++ luit-20020203-2/luit.c Wed Feb 6 01:35:15 2002 @@ -386,7 +386,7 @@ if(converter) return convert(0, 1); else -return condom(argc - i, argv + 1); +return condom(argc - i, argv + i); } static int --till here ___ I18n mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/i18n
[I18n]Hangul part of 12x13ja
Hello, Markus, why don't you contribute your 12x13ja font to XFree86? I mean, your version of 12x13ja has much more glyphs (for example, Hangul) than corresponding font in XFree86. It will benefit Korean people who will use XTerm in UTF-8 mode (or with luit). License problem? --- Tomohiro KUBOTA <[EMAIL PROTECTED]> http://www.debian.or.jp/~kubota/ "Introduction to I18N" http://www.debian.org/doc/manuals/intro-i18n/ ___ I18n mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/i18n
Re: [I18n][patch] luit SS2/SS3 (including all previous patches)
Hi, At 04 Feb 2002 18:16:36 +, Juliusz Chroboczek wrote: > Oops, sorry, I've just sent in mine; I hadn't checked the list yet. > > I don't think there's a need to make the use of SS/GR dependent on the > locale; in practice, single shifts will only happen in EUC locales. > So I've set it to true by default, and added a command-line flag. > > There's a minor problem with your patch: 7 bit keyboard mode should > disable use of GR. > > Other than that, it looks like there's a bug in my patch: it doesn't > properly set the high bit of the high byte in a double-byte encoding. > I'll send a revised patch ASAP. I see. I think your patch is almost always better than mine because luit is (at least, so far) your software and you have to know everything around luit. Please write a patch in the way which you think is best. PS. I would be glad if you also release corresponding luit-0.x series which can be compiled without XFree86 4.2, because it is easier to test by people who have not installed XFree86 4.2 yet. --- Tomohiro KUBOTA <[EMAIL PROTECTED]> http://www.debian.or.jp/~kubota/ "Introduction to I18N" http://www.debian.org/doc/manuals/intro-i18n/ ___ I18n mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/i18n
[I18n]current status of SCW proposal ?
Hi, How about the current status of Markus' SCW (Set Character Width) proposal? I think it is the time to start discussion. (Since the proposal says it is discussed on linux-utf8, I use the mailing list. However, since the discussion is strongly connected to xterm and luit, I Cc: to i18n@xfree86.) Markus' SCW proposal: http://www.cl.cam.ac.uk/~mgk25/ucs/scw-proposal.html Background: XFree86 4.2 has released and I am now working on Xterm improvement to invoke "luit" according to user's LC_CTYPE locale. The basic part of my work has done and patches are sent to i18n@xfree86 mailing list: xterm patch: http://www.xfree86.org/pipermail/i18n/2002-February/002965.html luit patch: http://www.xfree86.org/pipermail/i18n/2002-February/002977.html though I have some minor ideas to improve the patches. Of course (improved versions of) these patches are intended to be sent to patch@xfree86. I started to use xterm+luit in ja_JP.eucJP locale for my daily use for test purpose (previously I used rxvt). I felt again that JIS X 0208 characters have to be doublewidth in EUC-JP mode. Juliusz thinks this should be realized by submitting single shift codes from luit to xterm (thus the decision of width is done by luit side), and I think it is a reasonable idea. mail from Juliusz: http://mail.nl.linux.org/linux-utf8/2001-11/msg00093.html Though I don't know Juliusz will like it, I am planning to use a small subset of Markus' SCW proposal, i.e., only CSI 1 w I think this only one sequence is enough for my porpose. I hope Juliusz will agree because this sequence does not introduce any new "state". Of course I agree any other control sequence but I don't know any other control sequences. Thus, there are a few options which we can do: 1. fully agree with Markus' SCW proposal and luit will use a subset of it. 2. agree with a subset of the proposal and luit will use it. 3. modification of the proposal and luit will use it. 4. a new proposal which is entirely different from Markus' and luit will use it. 5. luit will use some xterm-local private undocumented control sequence. 6. xterm will have locale-dependent character width handling and we don't need any control sequence. Markus' page says "the proposal is at this stage EXPERIMENTAL and should not yet be fielded in widely distributed implementations without consulting the author first." I would also like to ask this point. When the proposal will be mature and usable? What is needed to reach such mature and usable state? If it takes a long time, I think we may implement private undocumented control sequence and use it until release of XFree86 4.3 because we will need debug period. --- Tomohiro KUBOTA <[EMAIL PROTECTED]> http://www.debian.or.jp/~kubota/ "Introduction to I18N" http://www.debian.org/doc/manuals/intro-i18n/ ___ I18n mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/i18n
[I18n][patch] luit SS2/SS3 (including all previous patches)
}
break;
case T_9494: case T_9696: case T_94192:
-if(i >= 0x2020)
+if(i >= 0x2020) {
+if(is->euc_ss2_ss3_r)
+i |= 0x8080;
WRITE_2_P(SS3, i);
+}
break;
default:
abort();
@@ -579,7 +594,12 @@
}
code = *s;
} else {
-charset = GR(is);
+switch(is->shiftState) {
+ case S_NORMAL: charset = GR(is); break;
+case S_SS2: charset = G2(is); break;
+case S_SS3: charset = G3(is); break;
+default: abort();
+}
code = *s - 0x80;
}
@@ -628,7 +648,12 @@
else
code = -1;
} else {
-charset = GR(is);
+switch(is->shiftState) {
+case S_NORMAL: charset = GR(is); break;
+case S_SS2: charset = G2(is); break;
+case S_SS3: charset = G3(is); break;
+default: abort();
+}
ku_code = is->buffered_ku - 0x80;
if(*s >= 0x80)
code = *s - 0x80;
diff -ruN luit-20020203/iso2022.h luit-20020203-new/iso2022.h
--- luit-20020203/iso2022.h Fri Nov 2 12:06:43 2001
+++ luit-20020203-new/iso2022.h Sun Feb 3 10:51:02 2002
@@ -68,6 +68,7 @@
int buffered_ku;
unsigned char *outbuf;
int outbuf_count;
+int euc_ss2_ss3_r;
} Iso2022Rec, *Iso2022Ptr;
#define GL(i) (*(i)->glp)
diff -ruN luit-20020203/luit.c luit-20020203-new/luit.c
--- luit-20020203/luit.cSun Jan 20 10:58:44 2002
+++ luit-20020203-new/luit.cSun Feb 3 10:51:02 2002
@@ -359,12 +359,15 @@
locale_name = setlocale(LC_CTYPE, NULL);
} else {
locale_name = getenv("LC_ALL");
-if(locale_name == NULL)
+if(locale_name == NULL) {
locale_name = getenv("LC_CTYPE");
+if(locale_name == NULL)
+locale_name = getenv("LANG");
+}
}
if(locale_name == NULL) {
-ErrorF("Couln't get locale name -- using C");
+ErrorF("Couldn't get locale name -- using C\n");
locale_name = "C";
}
--till here
---
Tomohiro KUBOTA <[EMAIL PROTECTED]>
http://www.debian.or.jp/~kubota/
"Introduction to I18N" http://www.debian.org/doc/manuals/intro-i18n/
___
I18n mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/i18n
[I18n][patch] luit to support more character sets and encodings
Hi,
Here is a patch for luit to add a few coded character sets and encodings:
ISO-8859-10
ISO-8859-11
ISO-8859-13
ISO-8859-14
ISO-8859-16
TIS-620
Note that TIS-620 and ISO-8859-11 are identical.
--from here
--- charset.c.orig Sat Feb 2 13:03:00 2002
+++ charset.c Sat Feb 2 13:03:03 2002
@@ -107,7 +107,13 @@
{"ISO 8859-7", T_96, 'F', "iso8859-7", 0x80, 0, 0},
{"ISO 8859-8", T_96, 'H', "iso8859-8", 0x80, 0, 0},
{"ISO 8859-9", T_96, 'M', "iso8859-9", 0x80, 0, 0},
+{"ISO 8859-10", T_96, 'V', "iso8859-10", 0x80, 0, 0},
+{"ISO 8859-11", T_96, 'T', "iso8859-11", 0x80, 0, 0},
+{"TIS 620", T_96, 'T', "iso8859-11", 0x80, 0, 0},
+{"ISO 8859-13", T_96, 'Y', "iso8859-13", 0x80, 0, 0},
+{"ISO 8859-14", T_96, '_', "iso8859-14", 0x80, 0, 0},
{"ISO 8859-15", T_96, 'b', "iso8859-15", 0x80, 0, 0},
+{"ISO 8859-16", T_96, 'f', "iso8859-16", 0x80, 0, 0},
{"KOI8-E", T_96, '@', "koi8-e", 0x80, 0, 0},
{"GB 2312", T_9494, 'A', "gb2312.1980-0", 0x, 0, 0},
@@ -325,7 +331,13 @@
{ "ISO8859-7", 0, 2, "ASCII", NULL, "ISO 8859-7", NULL},
{ "ISO8859-8", 0, 2, "ASCII", NULL, "ISO 8859-8", NULL},
{ "ISO8859-9", 0, 2, "ASCII", NULL, "ISO 8859-9", NULL},
+{ "ISO8859-10", 0, 2, "ASCII", NULL, "ISO 8859-10", NULL},
+{ "ISO8859-11", 0, 2, "ASCII", NULL, "ISO 8859-11", NULL},
+{ "TIS620", 0, 2, "ASCII", NULL, "ISO 8859-11", NULL},
+{ "ISO8859-13", 0, 2, "ASCII", NULL, "ISO 8859-13", NULL},
+{ "ISO8859-14", 0, 2, "ASCII", NULL, "ISO 8859-14", NULL},
{ "ISO8859-15", 0, 2, "ASCII", NULL, "ISO 8859-15", NULL},
+{ "ISO8859-16", 0, 2, "ASCII", NULL, "ISO 8859-16", NULL},
{ "KOI8-R", 0, 2, "ASCII", NULL, "KOI8-R", NULL},
{ "CP1251", 0, 2, "ASCII", NULL, "CP 1251", NULL},
{ "eucCN", 0, 1, "ASCII", "GB 2312", NULL, NULL},
--till here
---
Tomohiro KUBOTA <[EMAIL PROTECTED]>
http://www.debian.or.jp/~kubota/
"Introduction to I18N" http://www.debian.org/doc/manuals/intro-i18n/
___
I18n mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/i18n
[I18n][patch] xterm to invoke luit
Hi,
At Fri, 01 Feb 2002 13:21:00 +0900,
Tomohiro KUBOTA wrote:
> Thank you. I tried implementation last night and it is working
> almost well.
Here is the patch.
This patch adds following command line options:
-/+lc to turn on/off calling "luit"
--lcc to specify path for "luit"
This patch adds following resources:
"locale" (class "Locale") to turn on/off calling "luit"
"true"/"on"/"1" means always calls luit, "false"/"off"/"0"
means never calls luit. If "auto" (indeed, all other than
above), luit is called only ja/ko/th/zh locales (other than
UTF-8 locales). In "auto" and in other locales, UTF-8 mode
is automatically choosed (command line option -/+u8 and
resource utf8 are overrided).
"localeFilter" (class "LocaleFilter") to specify path for "luit".
The default is "/usr/X11R6/bin/luit". I'd like to change this
to be changable according to XFree86 installation process but
I don't know how to do this.
I think the roles of -/+lc and -/+u8 interferes each other.
Thus, I designed -/+u8 to be completely ignored in "locale: auto"
mode. (Instead, in "locale: auto" mode, -/+u8 is automatically
determined.) Since UTF-8 mode is forced to be enabled in
"locale: true" mode, -/+u8 is effective only in "locale: false"
mode.
--from here
diff -u xterm-20020130/charproc.c xterm-20020130-luit/charproc.c
--- xterm-20020130/charproc.c Sun Jan 20 10:58:47 2002
+++ xterm-20020130-luit/charproc.c Sat Feb 2 00:00:27 2002
@@ -565,6 +565,8 @@
{XtNutf8, XtCUtf8, XtRInt, sizeof(int),
XtOffsetOf(XtermWidgetRec, screen.utf8_mode),
XtRString, defaultUTF8},
+Sres(XtNlocale,XtCLocale, misc.locale_str,
+"False"),
+Sres(XtNlocaleFilter, XtCLocaleFilter,misc.localefilter,
+DEFLOCALEFILTER),
Bres(XtNwideChars, XtCWideChars, screen.wide_chars, FALSE),
Sres(XtNwideBoldFont, XtCWideBoldFont,misc.f_wb,
DEFWIDEBOLDFONT),
Sres(XtNwideFont, XtCWideFont,misc.f_w, DEFWIDEFONT),
@@ -4287,6 +4289,10 @@
Boolean color_ok;
#endif
char *s;
+#if OPT_WIDE_CHARS
+ unsigned char *locale;
+ char locale_string[20];
+#endif
/* Zero out the entire "screen" component of "wnew" widget, then do
* field-by-field assignment of "screen" fields that are named in the
@@ -4531,6 +4537,45 @@
#if OPT_WIDE_CHARS
init_Bres(screen.wide_chars);
+ if ((locale = getenv("LC_ALL")) == 0 || *locale == '\0')
+ if ((locale = getenv("LC_CTYPE")) == 0 || *locale == '\0')
+ if ((locale = getenv("LANG")) == 0 || *locale == '\0')
+locale = NULL;
+ for (i=0; i<19; i++) {
+ if ((locale_string[i] = toupper(request->misc.locale_str[i])) == 0)
+break;
+ }
+ locale_string[19] = 0;
+
+ if (strcmp(locale_string, "TRUE") == 0 ||
+ strcmp(locale_string, "ON") == 0 ||
+ strcmp(locale_string, "1") == 0) {
+ request->misc.locale = 1;
+ request->screen.utf8_mode = 2;
+ } else if (strcmp(locale_string, "FALSE") == 0 ||
+ strcmp(locale_string, "OFF") == 0 ||
+ strcmp(locale_string, "0") == 0) {
+ /* when false ... original value of utf8_mode is effective */
+ request->misc.locale = 0;
+ } else { /* auto mode ... override utf8_mode */
+ unsigned int lang;
+ if (locale !=NULL && strlen(locale) > 1 &&
+strstr(locale, "UTF-8") == NULL &&
+((lang = locale[0]*256+locale[1]) == 'j'*256+'a' ||
+ lang == 'k'*256+'o' || lang == 't'*256+'h' ||
+ lang == 'z'*256+'h')) {
+ request->misc.locale = 1;
+ request->screen.utf8_mode = 2;
+ } else if (locale != NULL && strstr(locale, "UTF-8") != NULL) {
+ request->misc.locale = 0;
+ request->screen.utf8_mode = 2;
+ } else {
+ request->misc.locale = 0;
+ request->screen.utf8_mode = 0;
+ }
+ }
+
+ init_Bres(misc.locale);
if (request->screen.utf8_mode) {
wnew->screen.wide_chars = True;
wnew->screen.utf8_mode = 2; /* disable further change */
diff -u xterm-20020130/main.c xterm-20020130-luit/main.c
--- xterm-20020130/main.c Sun Jan 20 10:58:51 2002
+++ xterm-20020130-luit/main.c Sat Feb 2 00:03:45 2002
@@ -891,6 +891,9 @@
#if OPT_WIDE_CHARS
{"-u8","*utf8",XrmoptionNoArg, (caddr_t) "2"
Re: [I18n]xterm to invoke luit
Hi, At 31 Jan 2002 13:28:22 +, Juliusz Chroboczek wrote: > Hi Tomohiro, > > I agree with the general idea. I would like to change a few details. Thank you. I tried implementation last night and it is working almost well. > I would suggest one new resource: > > XTerm*utf8Filter: /usr/X11R6/bin/luit I added it, with name "localeConverter". (I prefer to use "locale" in the keyword, than to use "utf8". Thus, "localeFilter" would be also OK.) > If utf8Filter is set, and XTerm is in UTF-8 mode, XTerm will spawn > >prog args > > instead of > > prog args Yes, but I am using "locale" now. > In addition, I suggest that the utf8 resource should be changed to a > tri-valued flag: it can be false, true, or auto, the latter meaning > that XTerm should run in UTF-8 mode if the locale is multi-byte, and > in eight-bit mode if it is not. A good idea. In "auto" mode, luit should be used not only in multibyte encodings but also in combining-character encodings such as Thai TIS-620 (ISO-8859-11). An another idea is that luit should be used in all non-ISO-8859-1 locales in "auto" mode, or to prepare two different "auto" modes. It depends on whether people from various countries tend to hope to use luit or to prefer manual font configuration (For example, Russian users have to write resource to use Russian font unless using luit). It is a tradeoff between convenience and performance. > The defaults for these resources should be > > XTerm*utf8Filter: /bin/luit > XTerm*utf8: auto (or perhaps true?) I prefer "true", but I am afraid that many people will complain because it breaks compatibility. Thus, "auto" is a good candidate. > TK> - emulate doublewidth de-facto standard for east Asian encodings > TK>(using http://www.cl.cam.ac.uk/~mgk25/ucs/scw-proposal.html ?) > > With all due respect, I refuse to implement Markus' proposal. I know you don't like to introduce "state". I think we can use a subset of Markus' proporsal without state. Indeed, all what we have to use is "CSI 1 w" sequence. Inserting the sequence before each EastAsianAmbiguous character (and a few more characters written in "Width problems" in http://www.debian.or.jp/~kubota/unicode-symbols.html) is enough. > TK> - whether xterm or luit will support BiDi or not. Usage of fribidi > TK>may have license problem (like Robert Brady's patch). > > My personal opionion is that BIDI belongs above the terminal emulator. Though I don't have enough motivation to discuss on this point because I am not a native speaker of RTL/BIDI languages, all people who speak Arab/Hebrew who I know wanted terminal emulators to support BIDI (though only a few people). If these people really want it, it would be these people's labor to persuade you (and others with same opinion). > And the number 1 item: include your fix for SS in EUC-JP (actually a > slightly improved version). Yes. However, I don't know how to improve my patch. Do you have any idea? --- Tomohiro KUBOTA <[EMAIL PROTECTED]> http://www.debian.or.jp/~kubota/ "Introduction to I18N" http://www.debian.org/doc/manuals/intro-i18n/ ___ I18n mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/i18n
Re: [I18n]xterm to invoke luit
Hi, At Thu, 31 Jan 2002 13:58:11 +0800, James Su wrote: > Does luit support the encodings that do not compatible with iso-2022? > For example GB18030? It supports a few non-ISO-2022-compliant encodings such as Big5. It doesn't support GB18030 so far, though Juliusz is willing to support it. See his message at http://mail.nl.linux.org/linux-utf8/2001-11/msg00093.html for detail. --- Tomohiro KUBOTA <[EMAIL PROTECTED]> http://www.debian.or.jp/~kubota/ "Introduction to I18N" http://www.debian.org/doc/manuals/intro-i18n/ ___ I18n mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/i18n
[I18n]xterm to invoke luit
Hi, XFree86 4.2 has been released. Thus, I'd like to start an improvement of xterm to invoke luit, so that xterm will obey the current LC_CTYPE locale not only when it is one of UTF-8 locales but also when it is one of various major locales (which luit supports). My idea is: - adding "-lc" command line option and "locale" resource (boolean) to specify whether luit will be invoked or not. - luit will be invoked only when locale is other than "C", "POSIX", or UTF-8. - when luit will be invoked, xterm will be need to be UTF-8 mode. This will be done automatically. - "xterm -e ..." has to work well even with luit. - A new sample resource file "XTerm-locale.ad" will be supplied. - manual page will need explanation of this new feature. If nobody is working on this so far, I'd like to develop this and to send a patch to XFree86 finally. Items which need further discussion: - emulate doublewidth de-facto standard for east Asian encodings (using http://www.cl.cam.ac.uk/~mgk25/ucs/scw-proposal.html ?) - luit to support more encodings (http://mail.nl.linux.org/linux-utf8/2001-11/msg00093.html) - whether xterm or luit will support BiDi or not. Usage of fribidi may have license problem (like Robert Brady's patch). However, my work above will be able to be started without waiting for conclusions of these discussions. Any comments? --- Tomohiro KUBOTA <[EMAIL PROTECTED]> http://www.debian.or.jp/~kubota/ "Introduction to I18N" http://www.debian.org/doc/manuals/intro-i18n/ ___ I18n mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/i18n
Re: [I18n]non-ASCII characters in locale.alias file
Hi, At Mon, 21 Jan 2002 11:24:05 +0900, Tomohiro KUBOTA wrote: > I propose to remove these alias names. For people who really need > compatibility to HPUX system (though I don't think there are any > such people, because these locale names are aliases), some instructions > how to add ISO-8859-1 locale names may be written in some documents. Any comments? --- Tomohiro KUBOTA <[EMAIL PROTECTED]> http://www.debian.or.jp/~kubota/ "Introduction to I18N" http://www.debian.org/doc/manuals/intro-i18n/ ___ I18n mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/i18n
Re: [I18n]Li18nux Locale Name Guideline Public Review
Hi, At Mon, 21 Jan 2002 19:18:09 +0900, Tomohiro KUBOTA wrote: > I found the 2nd public review of Li18nux Locale Name Guideline > has started. > > http://www.hauN.org/ml/b-l-j/a/800/840.html > http://www.li18nux.org/subgroups/sa/locnameguide/index.html One important note. I am not a member of Li18nux. Thus, people who have opinions should write it to Li18nux. The above web page writes how to comment. --- Tomohiro KUBOTA <[EMAIL PROTECTED]> http://www.debian.or.jp/~kubota/ "Introduction to I18N" http://www.debian.org/doc/manuals/intro-i18n/ ___ I18n mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/i18n
Re: [I18n]i18n of Xt
Hi, At Thu, 17 Jan 2002 12:19:52 +0900, Tomohiro KUBOTA wrote: > I found that xc/lib/Xt/Converters.c calls XCreateFontSet() > few times and the parameter for it is not appropriate. I submitted a patch. (#5152) --- Tomohiro KUBOTA <[EMAIL PROTECTED]> http://www.debian.or.jp/~kubota/ "Introduction to I18N" http://www.debian.org/doc/manuals/intro-i18n/ ___ I18n mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/i18n
[I18n]Li18nux Locale Name Guideline Public Review
Hi, I found the 2nd public review of Li18nux Locale Name Guideline has started. http://www.hauN.org/ml/b-l-j/a/800/840.html http://www.li18nux.org/subgroups/sa/locnameguide/index.html The page says that comments are welcome until 14 Feb 2002. Any additions from Li18nux insiders? --- Tomohiro KUBOTA <[EMAIL PROTECTED]> http://www.debian.or.jp/~kubota/ "Introduction to I18N" http://www.debian.org/doc/manuals/intro-i18n/ ___ I18n mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/i18n
[I18n]non-ASCII characters in locale.alias file
Hi, I found two non-ASCII characters, which may be intended to be ISO-8859-1. (xc/nls/locale.alias 666) bokm?l: nb_NO.ISO8859-1 (xc/nls/locale.alias 685) fran?ais: fr_FR.ISO8859-1 I think usage of non-ASCII characters here is invalid. (In future, we may or may not use UTF-8). I imagine these locale names are left unremoved because of compatibility for HPUX system. (because xc/nls/locale.alias file has the following line) (xc/nls/locale.alias 662) XCOMM The following locale names are used in HPUX 9.x I propose to remove these alias names. For people who really need compatibility to HPUX system (though I don't think there are any such people, because these locale names are aliases), some instructions how to add ISO-8859-1 locale names may be written in some documents. Reasons: 1. Usage of ISO-8859-1 encoding is legal only under ISO-8859-1 locales. Since all system files are locale-independent, only ASCII characters (i.e., valid characters in "C" locale) can be used. (In future it may or may not be UTF-8, if "C" locale would mean UTF-8). 2. Imagine when people want to use locale names. It is when people want to configure their locale environments. When people want to configure their locale environment, it is natural that their locale environment is not yet configured. Thus, there are nobody who want to use ISO-8859-1 locale names legally. 3. Even if we were really need to use non-ASCII characters in locale.alias, usage of ISO-8859-1 encoding should be avoided because it is local encoding for 15 European languages, just like TIS-620 is Thai local and KOI8-R is Russian local. Usage of local encoding here means "biased" to specific languages. (Of course, usage of multiple encodings in one file is illegal.) UTF-8 should be the only candidate for this purpose. Thus, commenting out these two locale alias names would be insufficient. 4. Especially, locale.alias should be a good example or copybook for other i18n-learning people. Usage of illegal characters should be thus strongly discouraged. 5. If such bad locale names are written in locale.alias, new users (not only people who _really_ need it for compatibility purpose and who know what they are doing) will use these names. It should not occur because it helps more and more people will have wrong idea on i18n. (The reason why this should be avoided is that this may help appearance of more and more i18n-novice developers.) 6. People can do without such ISO-8859-1 locale names because these locale names are aliases. Use the original names or other aliases and people will be happy. I am planning to propose similar thing for GNU libc's locale.alias file. --- Tomohiro KUBOTA <[EMAIL PROTECTED]> http://www.debian.or.jp/~kubota/ "Introduction to I18N" http://www.debian.org/doc/manuals/intro-i18n/ ___ I18n mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/i18n
[I18n]i18n of Xt
Hi, Recently I found many basic X softwares output the message of "Missing charsets in String to FontSet conversion" when invoked in Japanese locale. I found that xc/lib/Xt/Converters.c calls XCreateFontSet() few times and the parameter for it is not appropriate. In xc/lib/Xt/Converters.c 1037 /* Should really do XListFonts, but most servers support this */ f = XCreateFontSet(display, "-*-*-*-R-*-*-*-120-*-*-*-*", &missing_charset_list, &missing_charset_count, &def_string); However, the "-*-*-*-R-*-*-*-120-*-*-*-*" is too restructive and the XCreateFontSet() cannot find fonts for some charsets even when appropriate fonts are available in XFree86 distribution (or in other popular font distributions) and are installed. Thus, I'd like to send a patch to modify the font pattern to "-*-*-*-R-*-*-*-120-*-*-*-*,*" in order to use any fonts if available. I think it is a mess to prepare a long long list of patterns in order to get slightly better proportion. I am now using a modified version of Xt for a few days and it seems to work well without any side effects. Any comments? --- Tomohiro KUBOTA <[EMAIL PROTECTED]> http://www.debian.or.jp/~kubota/ "Introduction to I18N" http://www.debian.org/doc/manuals/intro-i18n/ ___ I18n mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/i18n
Re: [I18n]luit and JIS X 0212 in EUC-JP
Hi, At Tue, 15 Jan 2002 08:33:13 +0900, Tomohiro KUBOTA wrote: > Sorry, I found my patch causes luit to abort silently when I try to > display JIS X 0201 Kana (G2) in EUC-JP. I don't know why. Thus, > I'd like you to check my patch carefully (please don't simply submit > my patch). I found this bug is because of my foolish (un)modification of my local luit source. Please forget about this bug because the patch I sent doesn't have the bug. (I forgot to remove "charset = GR(is);" in the original source.) I tested JIS X 0201 Kana with mlterm with GNU Unifont which has HALFWIDTH KANA. --- Tomohiro KUBOTA <[EMAIL PROTECTED]> http://www.debian.or.jp/~kubota/ "Introduction to I18N" http://www.debian.org/doc/manuals/intro-i18n/ ___ I18n mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/i18n
Re: [I18n]luit and JIS X 0212 in EUC-JP
Hi, At 14 Jan 2002 17:05:47 +, Juliusz Chroboczek wrote: > Thanks, that makes sense. I'll check your patch when I have time > (Thursday at earliest) and submit it. Sorry, I found my patch causes luit to abort silently when I try to display JIS X 0201 Kana (G2) in EUC-JP. I don't know why. Thus, I'd like you to check my patch carefully (please don't simply submit my patch). --- Tomohiro KUBOTA <[EMAIL PROTECTED]> http://www.debian.or.jp/~kubota/ "Introduction to I18N" http://www.debian.org/doc/manuals/intro-i18n/ ___ I18n mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/i18n
Re: [I18n]luit and JIS X 0212 in EUC-JP
Hi,
At Sun, 13 Jan 2002 03:12:44 +0900,
Tomohiro KUBOTA wrote:
> I think luit uses JIS X 0212 (i.e., G3 character set) via GL.
> This is not true. EUC-JP uses JIS X 0212 via GR.
I think I found the reason. In luit, SS2 and SS3 are implemented
to invoke G2 and G3 to GL. However, I have read a textbook that
SS2 and SS3 are re-defined by ISO 2022 to invoke G2 and G3 to
_both of GL and GR_. I imagine this modification is for EUC
encoding scheme to be compliant to ISO 2022.
Here is a patch to enable _displaying_ JIS X 0212 in EUC-JP, by
following the re-definition I wrote above, by modifying copyOut()
in iso2022.c . However, I don't know my patch is complete because
I don't know the internal of luit very well.
Note that luit with my patch yet has a problem around G3 in EUC-JP.
Though I think this can be done within copyIn() in iso2022.c ,
a new flag whether G2/G3 is mapped into GL or GR (with SS2/SS3)
may be needed because usage of GR is an exception in EUC encoding
scheme. The problem can be shown like this:
$ xterm -u8
$ LANG=ja_JP.eucJP luit
$ echo -e '\361\326\217\351\321'
<><> (two Kanji characters, the 2nd one is from JIS X 0212)
$ echo <><> | od -t x1
000 f1 d6 8f 69 51 0a
=
"69 51" should be "e9 d1" here.
I have not tested G2 in EUC-JP, i.e., JIS X 0201 Kana (halfwidth
kana). It seems that xterm+luit does not work with JIS X 0201 at
all
--- patch from here
--- iso2022.c Sun Dec 23 20:07:24 2001
+++ iso2022.c.new Sun Jan 13 11:04:46 2002
@@ -628,7 +628,12 @@
else
code = -1;
} else {
-charset = GR(is);
+switch(is->shiftState) {
+case S_NORMAL: charset = GR(is); break;
+case S_SS2: charset = G2(is); break;
+case S_SS3: charset = G3(is); break;
+default: abort();
+}
ku_code = is->buffered_ku - 0x80;
if(*s >= 0x80)
code = *s - 0x80;
--- patch until here
---
Tomohiro KUBOTA <[EMAIL PROTECTED]>
http://www.debian.or.jp/~kubota/
"Introduction to I18N" http://www.debian.org/doc/manuals/intro-i18n/
___
I18n mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/i18n
[I18n]luit and JIS X 0212 in EUC-JP
Hello, I tested luit and found a problem on JIS X 0212, like following: First I invoke xterm in UTF-8 mode. $ xterm -u8 Then, push Ctrl + Mouse3 and choose "Large" to use 9x18 and 18x18ja. Next, I prepared a Japanese text file which contain JIS X 0212 character written in EUC-JP. $ echo -e '\361\326\217\351\321' > JISX0212testfile Next, the contents was displayed using "iconv" (I use Debian Sid with GNU libc 2.2.4.) $ iconv -f EUC-JP -t UTF-8 <> (two Kanjis where the 2nd one is from JIS X 0212 character set) Next, invoke luit in Japanese locale. $ LANG=ja_JP.eucJP luit Then, the contents was displayed again. Now the terminal must be EUC-JP mode and I can use 'cat' simply. $ cat JISX0212testfile <><> (two Kanjis where the 2nd one is not same as the upper one) However, the result is different! Thus, I tried to understand what occurs. $ echo <><> (broken one, copy-paste from the above) | od -t o1 361 326 351 321 012 Here, the two characters were inputed into shell by using copy-paste of the above (broken) string. Now, check the contents of the octadecimal dump. I found that \217 (0x8F, SS3) is disappeared... I think luit uses JIS X 0212 (i.e., G3 character set) via GL. This is not true. EUC-JP uses JIS X 0212 via GR. The Japanese string I used for this test is just same as the string which (I remember) is shown in luit's web page as a JIS X 0212 demo. http://www.pps.jussieu.fr/~jch/software/luit/ though this page is not available now... --- Tomohiro KUBOTA <[EMAIL PROTECTED]> http://www.debian.or.jp/~kubota/ "Introduction to I18N" http://www.debian.org/doc/manuals/intro-i18n/ ___ I18n mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/i18n
Re: [I18n]U+3000 limit
Hi, At Wed, 09 Jan 2002 18:07:03 +, Markus Kuhn wrote: > .. unless an explicit subrange specification is present, such that > people have to write > > *-iso10646-1[0_0x] > > if they are sure that they want to have the full font. > > In other words, allow the specification of a default subrange for > sparsely populated ISO10646-1 fonts (e.g., those with more than 90% of > their characters below 0x3000). How such range limitation will be used? By knowledged end-users who knows (s)he doesn't need >U+3000 characters? Or, automatically set based on locale? Or, as a hard-coded default font by foolish software developers who assume computers are used only by http://www.debian.or.jp/~kubota/ "Introduction to I18N" http://www.debian.org/doc/manuals/intro-i18n/ ___ I18n mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/i18n
Re: [I18n]U+3000 limit
Hi, At 08 Jan 2002 19:01:49 +, Juliusz Chroboczek wrote: > MK> Any opinions? > > I don't think it is a good idea. Most UTF-8 clients don't make use of > this feature. New UTF-8 clients should use Xft instead. I also think so, from a different point of view. Such a limitation of glyph range can confuse CJK people, if developers of softwares use it without consideration for people abroad. Human being (including software developers) do tend to forget about foreign people. This is proved by the existance of many softwares which hard-code "*-iso8859-1" font as a default. CJK people don't want to suffer from such foolish developers (and the foolishness is common, not a rare case). The limitation of glyph range can offer a new method to annoy CJK people, if no mechanism to avoid the limitation on needed cases are supplied. --- Tomohiro KUBOTA <[EMAIL PROTECTED]> http://www.debian.or.jp/~kubota/ "Introduction to I18N" http://www.debian.org/doc/manuals/intro-i18n/ ___ I18n mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/i18n
Re: [I18n][Q] Latin-0 compose w/o locale
Hi, At Mon, 7 Jan 2002 18:05:25 +0100 (CET), Bruno Haible wrote: > It doesn't make sense. On Linux and most other Unix systems, the > character set supported by the C locale is US-ASCII. No french > characters, no U+20AC either. > > Remember that the C locale exists only to make portable behaviour of > command line programs possible, It is not meant to be used by humans. Right! Thus, it had been an illegal usage to use ISO-8859-1 in C locale. (I wonder why many softwares were designed to enable such illegal usage.) When I internationalized softwares (i.e., locale- enabling), I got "bug" reports from such people like "i18n is only for asian people and please stop doing i18n in the upstream level" and I was forced to write a code to manage locale-ignorant people. --- Tomohiro KUBOTA <[EMAIL PROTECTED]> http://www.debian.or.jp/~kubota/ "Introduction to I18N" http://www.debian.org/doc/manuals/intro-i18n/ ___ I18n mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/i18n
Re: [I18n][Q] Latin-0 compose w/o locale
Hi, At Wed, 02 Jan 2002 12:20:06 +0100, Didier Verna wrote: > I've now switched my application to latin-0 fonts, I experimented with an > fr_FR@euro locale on my debian system and it works correctly (I can input > french characters plus the euro sign). However, what I want is having this > input ability without messing up the locale. I still want a C locale. It is illegal. If you really want to do that, replace ISO-8859-1 fonts with ISO-8859-15 fonts. You can get an illegal but working system. --- Tomohiro KUBOTA <[EMAIL PROTECTED]> http://www.debian.or.jp/~kubota/ "Introduction to I18N" http://www.debian.org/doc/manuals/intro-i18n/ ___ I18n mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/i18n
Re: [I18n]Re: mlterm with BiDi support
Hi, At Thu, 27 Dec 2001 10:59:48 +0200 (IST), Tzafrir Cohen wrote: > I believe that we all agree that a bidi terminal will solve the problems > of command-line programs. However full-screen programs may do more > complicated manipulations of the text. > > Consider the following: > >ONE RTL SENTENCEAND ANOTHER RTL SENTENCE >IN A "TEXT BOX" IN A SEPERATE BOX > > A simple bidi terminal would get this thing wrong (if you stuff in some > LTR chars, at least) because it will mix the texts of the two boxes. > > The progrm that draws this has to know about the existance of the > separate boxes. > > As I said before, a simple bidi terminal is on many times still a good > approximation of the behaviour that the user wants even in such complex > cases. This problem can be solved with a control code to disable (and then re-enable) BiDi support of the terminal, as Behdad said. Are there any such control codes standardized? (Sorry, I am not a main developer of mlterm and I don't know whether mlterm supports the codes even if there are any.) Shaul Karl wrote: >> Otherwise, since a little part of people in the world need BiDi > > As far as I know there are at least 500,000,000 people whose native > language uses BiDi. And by that I assume that most Muslims native > language use BiDi. I am aware to the fact that there are many Muslims > in places were the native language is LTR (probably east-southern Europe > and Turkey) who only use a BiDi language (Arabic) when they are > discussing the Islam in its original language. There are at least 1,000,000,000 people whose native language uses Han Ideogram. I am one of them. Indic language spekers are also a large group. However, in the Open Source Software world, most of developers don't think about supporting such languages. Even with such huge popularity of BiDi + CJK + Indic + ... , we are still a minority in Open Source World. Thus we have to improve our situation by ourselves. --- Tomohiro KUBOTA <[EMAIL PROTECTED]> http://www.debian.or.jp/~kubota/ "Introduction to I18N" http://www.debian.org/doc/manuals/intro-i18n/ ___ I18n mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/i18n
Re: [I18n]Re: mlterm with BiDi support
Hi, At Thu, 27 Dec 2001 05:28:34 +0200, Shaul Karl wrote: > > I'm a native persian speaker, have wrote many parts of fribidi > > library, and also working on console bidi, as all of you agree, > > almost all command line tools (like cat, tr, grep, ...), should do > > nothing about bidi, and on the other side, their output on terminal > > should be readable, then bidi is necessery on terminal, this also > > happens for all applications that are subject to gnu translation > > project, I mean that when I put my persian message files there, I > > should be able to get right messages in persian. Thank you very much, Behdad, for your comment as a native Persian speaker. Yes, I agree with you and Shaul that terminal should be able to handle BiDi so that developers of application softwares can be free from studying about BiDi. Otherwise, since a little part of people in the world need BiDi and most of non-BiDi-needing developers would not study about BiDi, most part of softwares in the world would be able to handle BiDi. This is what we (native Japanese speaker) have explienced for long years. Japanese need multibyte encoding. However, most of people in the world don't need multibyte encoding and most of developers in the world didn't study about multibyte encoding. Thus, we have to modify them to enable multibyte encoding. East Asian people (including Japanese) need not only multibyte encodings but also doublewidth character, input method support, and so on. Thus, I eager a situation that developers who don't know about i18n nor foreign languages cannot develop softwares which don't support East Asian, BiDi, combining characters, and so on. > > What we have found is to enable the bidi on terminal, ask applications > > that support bidi, to send a bidi-off escape code to terminal, and do > > the stuff themselves, for example, libncurses, should support bidi and > > turn the terminal bidi off on initscr()... > > Can you explain what do you mean by `libncurses, should support bidi'? > Why not having the BiDi stuff centralized at one point (the terminal) > instead of having it spread across many (ncurses, slang, libraries for > text only processing)? I think Behdad says that they sometimes need to use non-BiDi-supported terminals such as Linux console. For such cases, libraries such as curses may supply BiDi support, though I don't know this works well or not. For my case, Linux console doesn't support Japanese. Thus, I have lines like: if [ "$TERM" = "linux" ] ; then LANG=C else LANG=ja_JP.eucJP fi in my ~/.bashrc file. --- Tomohiro KUBOTA <[EMAIL PROTECTED]> http://www.debian.or.jp/~kubota/ "Introduction to I18N" http://www.debian.org/doc/manuals/intro-i18n/ ___ I18n mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/i18n
[I18n]Re: mlterm with BiDi support
Hello, At Mon, 24 Dec 2001 18:50:19 +0200, Shaul Karl wrote: > I believe a terminal emulator is the natural place for BiDi handling. > Isn't one of the terminal emulator main tasks to free the application > from the > tedious details of input/output and present a common interface? After > all, it is the terminal emulator and not the application who has more > knowledge about the terminal and the most convenient methods of dealing > with various aspects of the terminal. A terminal emulator that does not > handle its BiDi applications force these applications to deal with BiDi > by themselves. > This is bad because: > (1) It complicates the application with aspects that the application > should not be concerned of (input/output methods). > (2) It also complicates the application because the application has > more limited ways to handle the terminal then the terminal emulator. > (3) It does not help in creating a common application-terminal > interface for BiDi applications. Actually, not only that it does not > help but it also makes it more difficult. Even if the application > programmer is looking for BiDi support it is hard for him to verify the > correctness of his work since this is not natural for him. Thank you for your clear opinion. Though I fully agree the logic of your opinion, I thought it was not sufficient. I wanted to know how _native_ speakers of Hebrew and Arab think. (Sometimes logically perfect opinion annoys native speakers because native speakers have their own way to do and tradition, which may be somewhat irrational but should be respected.) > > The point is, Shaul, do you think the BiDi support should be enabled > > by default or should be disabled by default? > > What are the implications of enabling it by default? > Will it be transparent to applications that are not BiDi aware? Will it > makes them totally unusable? Perhaps it would makes them show some > gibberish here and there but the overall result would be acceptable? Enabling BiDi never make mlterm unusable for non-BiDi people. I cannot feel even speed down because of BiDi. I think there are no reasons to disable BiDi. FYI, there are some people who thinks BiDi should be supported not by terminal emulators but by applications. http://www.pps.jussieu.fr/~jch/software/luit/ http://www.cl.cam.ac.uk/~mgk25/unicode.html#xterm However, they are not native speakers of RTL languages and I think native speakers' opinion should be respected. --- Tomohiro KUBOTA <[EMAIL PROTECTED]> http://www.debian.or.jp/~kubota/ "Introduction to I18N" http://www.debian.org/doc/manuals/intro-i18n/ ___ I18n mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/i18n
Re: [I18n]mlterm with BiDi support
Hi, At Mon, 24 Dec 2001 08:30:20 +0200 (IST), Tzafrir Cohen wrote: > So for me bidi support should be added, as long as there is an easy way to > disable it on *runtime* (not just on the command-line). Thank you for your comment. Mlterm satisfies this point, like Robert Brady's XTerm patch. Note that BiDi support is available only in UTF-8 mode. This is partly because we don't know any BiDi-needed encodings other than UTF-8. > What is the overhead of bidi support? Any reason someone might not want it > because of that overhead? I am using mlterm with Celeron 300MHz and I don't feel any overhead. > Other than that, it will only matter for people who run into RTL text. And > those people will probably want it on by-default. Thank you. I was afraid that native Hebrew/Arab speakers are starting to use BiDi application softwares which are assumed to be run on non-BiDi-supporting terminals or they use display-order text file. I'd like also to ask native Arab speakers on this point. Note that mlterm supports Arab shaping also. Any comments? --- Tomohiro KUBOTA <[EMAIL PROTECTED]> http://www.debian.or.jp/~kubota/ "Introduction to I18N" http://www.debian.org/doc/manuals/intro-i18n/ ___ I18n mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/i18n
[I18n]mlterm with BiDi support
Hello Shaul, At Wed, 28 Nov 2001 01:33:51 +0200, Shaul Karl wrote: > I hope that mlterm also takes into considerations the RTL (Right To > Left) languages. As far as I know these are Hebrew and Arabic. > Actually, BiDi (Bi Directional) might be more suitable then RTL in this > context since users of these languages do expect to be able to combine > the other direction too. And by that I mean have Hebrew/Arabic text > combined with other languages text. mlterm version 2.1.0 with BiDi support using FriBidi will be released soon. However, some people insist that terminal emulators are not responsible for BiDi and application softwares are responsible (and thus terminal emulators should _not_ support BiDi). I think mlterm can satisfy such people by disabling BiDi support by using command option or configuration file. The point is, Shaul, do you think the BiDi support should be enabled by default or should be disabled by default? mlterm: http://mlterm.sourceforge.net/ --- Tomohiro KUBOTA <[EMAIL PROTECTED]> http://www.debian.or.jp/~kubota/ "Introduction to I18N" http://www.debian.org/doc/manuals/intro-i18n/ ___ I18n mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/i18n
[I18n]mlterm mailing list is now opened
Hi, everyone. mlterm (MultiLingual TERMinal emulator), which I introduced a few days ago in i18n@xfree86 and debian-i18n lists, has got a SourceForge hosting. http://www.sourceforge.net/projects/mlterm/ http://mlterm.sourceforge.net/ mlterm is a terminal emulator with following unique features: - various encodings are supported (multilingual) - combining characters (TIS-620, TCVN5712, JIS X 0213, and UTF-8) - anti-aliased fonts with Xft and True Type fonts. - multiple windows in one process - XIM is changeable dynamically in run-time and you can input multiple complex languages such as Japanese and Chinese. - scroll by wheel mouse - background image (in other words, wallpaper) - transparent background - scrollbar plugin API (unstable) Two mailing lists are now available, one for discussion in English, the another for discussion in Japanese language. I imagine some of you will be interested in joining the English mailing list. --- Tomohiro KUBOTA <[EMAIL PROTECTED]> http://www.debian.or.jp/~kubota/ "Introduction to I18N" http://www.debian.org/doc/manuals/intro-i18n/ ___ I18n mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/i18n
Re: [I18n]Problems displaying Japanese fonts clearly
Hi, At Wed, 28 Nov 2001 17:39:57 -0800, Scott Jonathan wrote: > I believe someone had talked about this on the list before, but I cant find > the messages. My Japanese fonts display properly on most apps. However, > there are several where the anti-aliasing seems to be turned off and kanji > often come out as blobs, barely distinguishable. You mean, the same font appears differently according to the application softwares? Do these softwares really support anti-aliasing? I heard that the current version of Xft cannot handle built-in bitmap fonts in Unicode True-Type fonts. I observed that nothing is displayed when I try to display True-Type fonts using Xft in the size that the font has built-in bitmaps for. --- Tomohiro KUBOTA <[EMAIL PROTECTED]> http://www.debian.or.jp/~kubota/ "Introduction to I18N" http://www.debian.org/doc/manuals/intro-i18n/ ___ I18n mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/i18n
Re: [I18n]Re: Thai XIM
Hi, At Thu, 29 Nov 2001 12:08:02 +0700, Theppitak Karoonboonyanan wrote: > In fact, they should have been said to be restricted to "UCS" support. > The special treatment for combining characters can be considered as > "implementation level 2" in ISO/IEC 10646-1. Sorry, I don't understand your opinion well. You said that "-m-" and "-c-" fonts should be exactly fixed-width, without negative expand nor offset. Then, what fonts should terminal emulators (and other column- based softwares) use? "-m-*-tis620-0" or "-c-*-tis620-0" fonts which are exactly fixed-width? Or, "-p-*-tis620-0" with negative expand but virtually fixed-width? I read your web page that advocate usage of "tis620-0" fonts instead of "tis620.-x" fonts. However, the page doesn't mention detailed technical design of such fonts. (The page http://linux.thai.net/~thep/th-xwindow/ seems not accessable now. Could you please check the page?) Anyway, I think that native Thai people should have a political voice for the detailed technical design of tis620.0 fonts, because other people (including I) don't know how deeply Thai people depend on the de-facto standard of fonts. Of course, if Thai people think the modification of the fonts doesn't cost very much, we (people from all over the world) can attend the discussion on the detailed technical design of Thai fonts. --- Tomohiro KUBOTA <[EMAIL PROTECTED]> http://www.debian.or.jp/~kubota/ "Introduction to I18N" http://www.debian.org/doc/manuals/intro-i18n/ ___ I18n mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/i18n
RTL and MLTERM (Re: [I18n]Re: Thai XIM)
Hi, At Wed, 28 Nov 2001 01:33:51 +0200, Shaul Karl wrote: > I hope that mlterm also takes into considerations the RTL (Right To > Left) languages. As far as I know these are Hebrew and Arabic. > Actually, BiDi (Bi Directional) might be more suitable then RTL in this > context since users of these languages do expect to be able to combine > the other direction too. And by that I mean have Hebrew/Arabic text > combined with other languages text. Thank you for your comment. BiDi is one of major challenging issues and which I am interested in. However, I don't know well about this. I'd like to start to study BiDi soon. (Since I don't know very well about the internal of mlterm, I am not sure BiDi can be implemented into mlterm. I'll ask the main developer about this.) To study about BiDi, is the following document enough, or do you have some recommendation? (though I have not read the document yet). Unicode Standard Annex #9 The Bidirectional Algorithm http://www.unicode.org/unicode/reports/tr9/ --- Tomohiro KUBOTA <[EMAIL PROTECTED]> http://www.debian.or.jp/~kubota/ "Introduction to I18N" http://www.debian.org/doc/manuals/intro-i18n/ ___ I18n mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/i18n
Re: [I18n]Re: Thai XIM
Hi, At Wed, 28 Nov 2001 10:01:26 +1100, Chanop Silpa-Anan wrote: > tis620-0 is the offical one. please patch the code I'll try the mlterm > soon. I think it is the same as tis620.2533-1, just the naming that is > different. Thank you very much for your effort. However, I found that tis620-0 font is slightly different from tis620.-x fonts. Combining characters in tis620-0 fonts have negative expand (i.e., glyphs are written leftward from the specified location) while all characters in tis620.-x fonts are exactly fixed-width. Can we rely on the structures of fonts? --- Tomohiro KUBOTA <[EMAIL PROTECTED]> http://www.debian.or.jp/~kubota/ "Introduction to I18N" http://www.debian.org/doc/manuals/intro-i18n/ ___ I18n mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/i18n
Re: [I18n]Re: Thai XIM
Hi, At Mon, 26 Nov 2001 11:04:55 +1100, Chanop Silpa-Anan wrote: > If you launch an application with LANG=th_TH providing that you have > th_TH locales support from the locales package, you could then use xkb > to input thai character. Since I use only Thai keybord, I have my xkb > set up in XF86Config. You can use "setxkbmap th" to set up the keyboard > too. Use recent XFree86 (since 4.1), of course. KDE also has a panel for > setting up keyboard map. > > The default key map change between thai and english is alt-lshift for > english (first iso group), and alt-rshift for thai (last iso group). Thanks! I wanted to know this sort of information. I am now participating in development of "mlterm" (multi-lingual terminal) which supports various encodings including TIS-620 and UTF-8. The latest version of mlterm can use "tis620.2533-1", "tis620.2529-1", or "iso10646-1" fonts and supports combining characters. I hope the software is useful for Thai people. I tested Thai input using "setxkbmap th" and it worked for both of TIS-620 and UTF-8. However, since I am not a native Thai speaker nor can I speak Thai at all, I cannot judge the software is really useful for native Thai people. Thus, I'd like some Thai people to test "mlterm" and read reports from them. Debian package of mlterm version 1.9.47 will available in a few days (I uploaded it yesterday). The upstream web page of mlterm is: http://mlterm.dnsalias.net/ken/mlterm/mlterm.shtml Note that "tis620-0" fonts are not supported yet. Of course I'd like to read reports from people from other countries. --- Tomohiro KUBOTA <[EMAIL PROTECTED]> http://www.debian.or.jp/~kubota/ "Introduction to I18N" http://www.debian.org/doc/manuals/intro-i18n/ ___ I18n mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/i18n
[I18n]Thai XIM
Hi, I found a description that XFree86 contains Thai XIM. http://linux.thai.net/~thep/th-xwindow/ Thus, I tried it using my Debian Sid. $ LANG=th_TH XMODIFIERS=@im=BasicCheck xterm -fn -nectec-fixed-medium-r-normal--18-180-72-72-c-90-tis620-0 $ LANG=th_TH XMODIFIERS=@im=BasicCheck xterm -fn -misc-fixed-medium-r-normal--14-140-72-72-m-70-tis620.2529-1 However, I have no idea how to input Thai characters. On the other hand, I can input Thai using Debian xiterm+thai package. $ txiterm and type F1 and 'd' inputs the first Thai character (though I don't know the name of the character). I'd like to know how to type keyboard to input Thai characters using Thai XIM. (txiterm is 'LANG=th_TH /usr/bin/xiterm -fn nectec18 -cursorColor yellow \ -cursorColorThai red'.) Debian Package information: xlibs 4.1.0-9 xiterm+thai1.04.cvs20010801 xfonts-intl-asian 1.2-2 xfonts-thai-nectec 2526-2 --- Tomohiro KUBOTA <[EMAIL PROTECTED]> http://www.debian.or.jp/~kubota/ "Introduction to I18N" http://www.debian.org/doc/manuals/intro-i18n/ ___ I18n mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/i18n
Re: [I18n]Xft undocumented behavior
Hi, At Fri, 16 Nov 2001 23:22:36 -0800, Keith Packard wrote: > Yes, the behaviour is intended -- it's designed for terminal applications > that want to use several faces on the screen but need them to all have the > same width. The intended use (and what X term does) is to open the "main" > font and then specify the width of that font when opening subsequent fonts. Thank you for your answer. > I'm curious as to whether you're interested in using this behaviour or > just mystified as to its existance. I am now interested in a terminal emulator which uses Xft. Thus, my interest is usage of fixed-width fonts. I am now planning to open a font (without XFT_WIDTH), checks the width, and then close and reopen the font with XFT_WIDTH of the value. Since there are some (and will be many) fonts which contain doublewidth (or quasi-doublewidth) glyphs and people may want to use these fonts for singlewidth glyphs, I am planning to use XftTextExtent() to check the width of "W", instead of using max_advance_width. Though there may be many "singlewidth" glyphs which are wider than "W", I think this is a not so bad way to determine the width of singlewidth glyphs. Anyway, Using proportional fonts for fixed-width purpose is a makeshift and the best way would be preparing fixed-width fonts. BTW, I am testing the software using "Kochi Gothic" and "Kochi Mincho" Unicode truetype Japanese fonts. I found that XftDrawString*() cannot display characters if these fonts are used in XFT_PIXEL_SIZEs of 10, 11, 12, 13, 14, 15, 16, 17, 20, and 21. Curiously enough, the Kochi fonts include built-in bitmap fonts for these sizes. I imagine either of FreeType, Xft, or Kochi fonts is responsible for this problem. Since I don't know at all about TrueType font format, I cannot check it. Kochi Gothic and Kochi Mincho fonts: http://www.on.cs.keio.ac.jp/~yasu/jp_fonts.html Though this page is written in Japanese, I think you can easily find .tar.bz2 files for kochi-gothic and kochi-mincho. I am using Debian Sid (XFree86 4.1.0 and FreeType 2.0.2). --- Tomohiro KUBOTA <[EMAIL PROTECTED]> http://www.debian.or.jp/~kubota/ "Introduction to I18N" http://www.debian.org/doc/manuals/intro-i18n/ ___ I18n mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/i18n
[I18n]Xft undocumented behavior
Hi, I am now testing Xft. I tested XftFontOpen() with and without specifying XFT_WIDTH. When I didn't specify XFT_WIDTH, XftDrawString*() displayed variable-width glyphs (when I use a proportional truetype font). However, I specify XFT_WIDTH, XftDrawString*() displayed fixed-width glyphs whose widths are exactly equal to the specified XFT_WIDTH. This behavior is not documented. Is it an intended behavior? In other words, can I rely on this behavior when I write a softwares which use Xft? --- Tomohiro KUBOTA <[EMAIL PROTECTED]> http://www.debian.or.jp/~kubota/ "Introduction to I18N" http://www.debian.org/doc/manuals/intro-i18n/ ___ I18n mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/i18n
[I18n]Xft manual pages
Hi, I am now interested in a project which is trying to use Xft. However, I cannot find how to use Xft. The Xft(3) manual describes not many features and, furthermore, the manual says that Xft will be changed radically. Does it mean that we should not use Xft yet? Otherwise, are there any manuals or documents on specification of Xft API? --- Tomohiro KUBOTA <[EMAIL PROTECTED]> http://www.debian.or.jp/~kubota/ "Introduction to I18N" http://www.debian.org/doc/manuals/intro-i18n/ ___ I18n mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/i18n
Re: [I18n]Call for testers: luit in XFree86 CVS
Hi, At 12 Nov 2001 18:56:10 +, Juliusz Chroboczek wrote: > I don't want to extend luit for 4.2.0; bug fixes only in this version. > Much of what you're proposing will go into future releases of luit. > More precisely, I see. Let's discuss these points after the release of 4.2.0. BTW, I have now trouble compiling luit. charset.c includes and I could not find it. I found it in xc/lib/font/include/fontenc.h . Is it the right file? When I proceed compilation, I met compilation errors of: charset.o: In function `FontencCharsetRecode': charset.o(.text+0x146): undefined reference to `FontEncRecode' charset.o: In function `getFontencCharset': charset.o(.text+0x2f0): undefined reference to `FontEncMapFind' charset.o(.text+0x302): undefined reference to `FontMapReverse' I think I need some libraries in XFree86 CVS tree... > TK> How about Johab? > > Don't know. We'll see. Johab is a Korean encoding which covers full hanguls and symbols and ideographs in KS X 1001. However, the codepoints are not compatible with EUC-KR. > As I've already mentioned, I strongly dislike the complexity of > Markus' proposal. I want to use single shifts only. Thus I said CSI 1 w for each character. > TK> but I am afraid this solution can be too heavy, because luit will > TK> have to issue CSI 1 w for each doublewidth character and XTerm > TK> will have to parse it. > > I don't think that will be much of a problem. If it is, we'll see > what can be done. Sure. If we will single shifts only, we can have more simple sequence. --- Tomohiro KUBOTA <[EMAIL PROTECTED]> http://www.debian.or.jp/~kubota/ "Introduction to I18N" http://www.debian.org/doc/manuals/intro-i18n/ ___ I18n mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/i18n
