[mew-int 01618] Re: windows 1252
Stephen J. Turnbull
stephen at example.com
Fri Nov 14 01:32:06 JST 2003
>>>>> "Kenichi" == Kenichi Handa <handa at example.com> writes:
Kenichi> In article <87ekwdilwx.fsf at example.com>,
Kenichi> "Stephen J. Turnbull" <stephen at example.com> writes:
>>>>>>> "Kenichi" == Kenichi Handa <handa at example.com> writes:
>>>> 7. The UTF-8 encoding
Kenichi> [...]
>>>> How about using this to encode mule-unicode-0100-24ff?
Kenichi> That's a good idea. I'll work on it.
>> AFAIK this is an XFree86-only extension. As of X11R6.4 such
>> extensions were forbidden in X.org Compound Text Encoding. Is
>> it really a good idea?
Kenichi> I think so. Currently we encode mule-unicode-0100-24ff
Kenichi> by ESC $ - 1 ... which is also an invalid code, and only
Kenichi> Emacs can decode it. If we use UTF-8 encoding, more
Kenichi> clients can decode it.
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.
XEmacs will follow what GNU does on this; there's no point in having
yet another unneeded incompatibility. But I prefer to follow the
general standard, not XFree86, especially where the XFree86 practice
has always been forbidden by the general X11 standard.
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.
--
Institute of Policy and Planning Sciences http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
Ask not how you can "do" free software business;
ask what your business can "do for" free software.
More information about the Mew-int
mailing list