[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 15:51:06 -0400 |
User-agent: |
Gnus/5.110011 (No Gnus v0.11) Emacs/24.0.50 (gnu/linux) |
>>>>> "SJT" == Stephen J Turnbull <address@hidden> writes:
>>>>> "JC" == James Cloos <address@hidden> writes:
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.
JC> AFAICT, gtk and qt doe the former, and that is really what I was
JC> suggesting, except when there is reason for Emacs to beleive that the
JC> user may perfer the CJK set.
I misstated that. Ctext should still use the 8859 sets where possible,
and the GB_2312-80, JIS_X0208-1983, JIS_X0208-1990, KS_C_5601-1987 and
CNS11643-1992 sets (but not JIS_X0213) for characters covered by Emacs'
'han script name symbol (as used by, eg, (set-fontset-font)) and utf8
for everything else.
Other apps which understand utf8 will (one hopes) prefer UTF8_STRING;
those which actually need ctext would then get maximum benefit.
As I wrote, ctext-with-extensions is almost there; elimitating 0213
from it should just about do it.
-JimC
P.S. Stephen: mail to your @xemacs address alwasy bounces,
and has for some time.
--
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