[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: X11 Compound Text vs ISO 2022
From: |
Kenichi Handa |
Subject: |
Re: X11 Compound Text vs ISO 2022 |
Date: |
Fri, 30 Jul 2010 10:27:20 +0900 |
In article <address@hidden>, James Cloos <address@hidden> writes:
KH> And, anyway ctext is not used for selection,
> I has to be used for X selection, yes?
No.
> How else could X selection of
> text work than using data tagged with X's STRING, COMPOUND_TEXT or
> UTF8_STRING atoms?
iso-8859-1, ctext-with-extensions, utf-8 respectively in
this order.
KH> I'd rather just document that ctext is not fully compatible X's
KH> COMPOUND_TEXT spec, but is the extended vesion.
KH> For WM_NAME, etc, yes, we should use ctext-with-extensions,
KH> and as ctext-with-extensions is not intended to be used
KH> directly by users, I think it won't cause actual problems
KH> even if we change it so that more characters are encoded
KH> using UTF8-extended-segment. So, I'll work on it soon.
> ctext-with-extesnions already supports the UTF8 extended segment; the
> bug is that it uses JISX 0213 for some characters. The earlier JISX
> versions (0201, 0208 and 0212) are OK, but 0213 is not.
Yes, I understand that. My intention is to modify (or fix)
ctext-with-extesnions to use UTF8-extended-segment for
characters that doesn't belong to any of few legacy
character sets listed in the spec of COMPOUND_TEXT.
KH> The only problem with ctext-with-extensions is that it is
KH> now implemented by Elisp, and thus it may cause GC. I'm not
KH> sure it is safe to call Lisp at the place we convert WM_NAME
KH> etc. If it is not safe, I'll implement
KH> ctext-with-extensions in C.
> the WM_NAME code already has to gc protect to do the conversion to utf8
> for the gtk call (when compiled for gtk) and the new code to set the
> UTF8_STRING _NET_WM_NAME and _NET_WM_ICON_NAME properties; I presume it
> could do a conversion to ctext-with-extensions within that same protect?
Ah, then, perhaps so.
By the way, the spec of COMPOUND_TEXT (included in
xorg-docs-1.5) lists these registered charsets.
ISO8859-1
ISO8859-2
ISO8859-3
ISO8859-4
ISO8859-5
ISO8859-6
ISO8859-7
ISO8859-8
ISO8859-9
JISX0201.1976-0
GB2312.1980-0
JISX0208.1983-0
KSC5601.1987-0
but libX11-1.3.2/src/xlibi18n/lcCT.c lists many more
charsets (e.g. more 8859 series and all CNS11643 series). I
think it is better to follow the above spec than lcCT.c.
What do you think?
---
Kenichi Handa
address@hidden
- Re: X11 Compound Text vs ISO 2022, (continued)
- Re: X11 Compound Text vs ISO 2022, Stephen J. Turnbull, 2010/07/06
- Re: X11 Compound Text vs ISO 2022, James Cloos, 2010/07/07
- Re: X11 Compound Text vs ISO 2022, James Cloos, 2010/07/07
- Re: X11 Compound Text vs ISO 2022, David De La Harpe Golden, 2010/07/07
- Re: X11 Compound Text vs ISO 2022, James Cloos, 2010/07/14
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