[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re[2]: cut and paste for chinese in x window system



Hello,

Saturday, January 22, 2000, 6:00:25 AM, you wrote:
AW> |
AW> |you mean you can do it? how? i just cant figure it out, please.
AW> |i can cut-n-paste in netscape, but after a paste, the chinese characters
AW> |are not shown in chinese fonts. _this_ is just my big headache.

AW> I use cut-n-paste too... (e.g. from cxterm to licq).
AW> You can't read it, but it doesn't matter. what you see is garbage but
AW> the text is there. (btw, unfortunately mozilla M12 still doesn't
AW> support pasting...)

Okey, I finally get around to do some testing.

For netscape, version 4.7 I guess, its form and javascript
definitely have problem support Chinese. I cannot display
any chinese Char in a form or javascript button. This
have nothing to do with cut-n-paste using String type.

I can copy-n-paste from netscape to crxvt (GB). This is
basically like the above but crxvt can handle Chinese
string in its window.

For xemacs, the thing is trickier. As we know emacs-mule
use iso-2022 (7bits) as its internal encode. Although it
do accept paste from the cut-n-paste butter, it assume
things in the buffer are 7bit iso-2022. So any GB or Big5
euc encoded (8bit) string means garbage to emacs. You can
only see garbage when you paste-n-cut euc GB code from
crxvt(gb) to emacs-mule. However, you can do cut-n-paste
inside emacs with no problem. If you cut-n-paste from
emacs to a crxvt(gb), you will find that what you got is
just some ascii characters, maybe with some escape sequence
which you cannot see.

For licq, I guess that licq's input field does not support
Chinese either. So although you can paste with no problem,
you cannot see what you pasted. Maybe ax+cv can solve it
with no problem.

For this icccm scheme we are on, basically you can just use cut-n-paste
buffer0 with no problem. However, the underline client has
to support displaying Chinese properly. The condition is of course
as I pointed out before that the client do not make special
treatment to the encoding scheme. otherwise, you have to do
special treatement like in xemacs, convert your euc encoded
char to iso-2022 before do the paste into xemacs. Mozilla uses
unicode as its internal representation, I don't know what's the
real implication here. :(

I hope this information is somewho useful. :)

Best regards,
 hashao                            mailto:hashao@telebot.com



Reply to: