[Top][All Lists]

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

Re: [mew-int 01596] Re: windows 1252

From: Kenichi Handa
Subject: Re: [mew-int 01596] Re: windows 1252
Date: Fri, 14 Nov 2003 11:57:01 +0900 (JST)
User-agent: SEMI/1.14.3 (Ushinoya) FLIM/1.14.2 (Yagi-Nishiguchi) APEL/10.2 Emacs/21.3 (sparc-sun-solaris2.6) MULE/5.0 (SAKAKI)

In article <address@hidden>, "Stephen J. Turnbull" <address@hidden> writes:
> I certainly agree that UTF-8 should be used for encoding.  The
> question is should the DOCS UTF-8 (XFree86 only, I fear) sequence be
> used to invoke it, or should the DOCS private final byte UTF-8 (X11
> standard extended segment) be used.

I don't understand what "DOCS private final byte UTF-8"
means.  Do you mean using the following for UTF-8?

6.  Non-Standard Character Set Encodings
     01/11 02/05 02/15 03/00 M L   variable number of octets per character

Do you know if there exist an application that send/receive
such an encoding?  If so, now we have three methods for
transfering UTF-8 in inter-client communication (the above,
XFree86's only UTF-8 encoding using ESC % G ..., use
UTF8_STRING instead of CTEXT), and there's no way to know
which receiver accept which encoding.  Sigh...

Kenichi>  Emacs decodes extended segment for ISO-8859-15 correctly,
Kenichi>  but doesn't use it for encoding.  According to Dave,
Kenichi>  Latin-9 (ISO-8859-15) users don't want it.  See this code
Kenichi>  in mule.el.

> I know it violates the CTEXT standard but many Linux apps give it to
> you anyway.

> It's interesting that they happily take the standard codes.  That's
> useful to know.

I've just confirmed that, in iso-8859-15 locale, XFree86
client (gnome-terminal) sends iso-8859-15 chars in extended
segment, not in the standard encoding (i.e. ESC - b ...),
but accepts iso-8859-15 in the standard encoding.

Ken'ichi HANDA

reply via email to

[Prev in Thread] Current Thread [Next in Thread]