[mew-int 01620] Re: windows 1252

Kenichi Handa handa at example.com
Fri Nov 14 11:57:01 JST 2003


In article <87he18grg9.fsf at example.com>, "Stephen J. Turnbull" <stephen at example.com> 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
handa at example.com



More information about the Mew-int mailing list