Re: X11 Compound Text vs ISO 2022

[James Cloos <cloos@jhcloos.com>]

>>>>> "SJT" == Stephen J Turnbull <stephen@xemacs.org> writes:

SJT> But that goes against the spec, which AFAIK still provides that in
SJT> COMPOUND_TEXT the escape to non-ISO-2022 should only be used for
SJT> characters not in the repertoires of the registered charsets:

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

SJT> I would argue that you have two choices here: consider the whole
SJT> string to be Unicode, and used an extended segment for the whole
SJT> thing; or consider the string to be pieced together from segments in
SJT> approved standard encodings, in which case a character that can be
SJT> represented in those encodings should be.

AFAICT, gtk and qt doe the former, and that is really what I was
suggesting, except when there is reason for Emacs to beleive that the
user may perfer the CJK set.

SJT> BTW, for the case of MIDDLE DOT using JIS X 0213, the most recent spec
SJT> I could find on the web doesn't admit JIS X 0213 (or JIS X 0212 for
SJT> that matter).

Exactly the complaint.  And even compound-text-with-extensions makes
that choice.  I'm testing the latter now in xfns.c, but the ctext
charsets still need to avoid JIS X 0213.

Yes, that seems to fix everything except the usage of 0213.

>> The question, then, is how best to do that?

SJT> Wouldn't it be better to avoid use of COMPOUND_TEXT targets?  How many
SJT> apps prefer it to UTF8_STRING?  So, for example, when asked for
SJT> supported targets Emacs could list UTF8_STRING first.

Things are getting better, but ctext is still required for some
properties and for interactions with some other clients.  I'd prefer
UTF8_STRING everywhere, but not to the extent of breaking compatability
with the other clients I (and others) use.  

-JimC
-- 
James Cloos <cloos@jhcloos.com>         OpenPGP: 1024D/ED7DAEA6