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

[Kenichi Handa]

In article <address@hidden>, "Stephen J. Turnbull" <address@hidden> writes:
>>>>>>  "Kenichi" == Kenichi Handa <address@hidden> 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?

I think so.  Currently we encode mule-unicode-0100-24ff by
ESC $ - 1 ...  which is also an invalid code, and only Emacs
can decode it.  If we use UTF-8 encoding, more clients can
decode it.

> On the other hand, even if extended segments are ugly, we must support
> extended segments to handle ISO-8859-15 selections on XFree86.  At
> least it is a standard mechanism on all versions of X, going back to
> at least X11R5.

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

;; If you add charsets here, be sure to modify the regexp used by
;; ctext-pre-write-conversion to look up non-standard charsets.
(defvar ctext-non-standard-designations-alist
  '(("$(0" . (big5 "big5-0" 2))
    ("$(1" . (big5 "big5-0" 2))
    ;; The following are actually standard; generating extended
    ;; segments for them is wrong and screws e.g. Latin-9 users.
    ;; 8859-{10,13,16} aren't Emacs charsets anyhow.  -- fx
;;     ("-V"  . (t "iso8859-10" 1))
;;     ("-Y"  . (t "iso8859-13" 1))
;;     ("-_"  . (t "iso8859-14" 1))
;;     ("-b"  . (t "iso8859-15" 1))
;;     ("-f"  . (t "iso8859-16" 1))

I think Dave is correct because CTEXT spec has this
paragraph.

        Extended segments are not to be used for any character set
        encoding that can be constructed from a GL/GR pair of
        approved standard encodings. For example, it is incorrect to
        use an extended segment for any of the ISO 8859 family of
        encodings.

---
Ken'ichi HANDA
address@hidden