[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: X11 Compound Text vs ISO 2022
From: |
James Cloos |
Subject: |
Re: X11 Compound Text vs ISO 2022 |
Date: |
Wed, 07 Jul 2010 01:19:39 -0400 |
User-agent: |
Gnus/5.110011 (No Gnus v0.11) Emacs/24.0.50 (gnu/linux) |
>>>>> "SJT" == Stephen J Turnbull <address@hidden> 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 <address@hidden> OpenPGP: 1024D/ED7DAEA6
Re: X11 Compound Text vs ISO 2022, David De La Harpe Golden, 2010/07/06
Re: X11 Compound Text vs ISO 2022, Kenichi Handa, 2010/07/29