X11 Compound Text vs ISO 2022

[James Cloos]

While testing my recently applied patch, I've discovered that Emacs will
product ISO-2022 output for COMPOUND_TEXT which other libs and apps --
notably including libX11 -- cannot decode.

As an example, (encode-coding-string "•" 'compound-text) ; U+2022 BULLET
produces "^[$(address@hidden(B".  '$(O' is ISO-IR 228¹, JIS X 2013:2000.  But
libX11 only knows about the $( charsets:  0, 1, A-D and G-M.

A number of characters are output in '^[$-1'; such as:

(encode-coding-string "ℜ" 'compound-text) ; U+211C BLACK-LETTER CAPITAL R
"^[$-1\365\334^[-A"
(encode-coding-string "ʻ" 'compound-text) ; U+02BB MODIFIER LETTER TURNED COMMA
"^[$-1\244\333^[-A"

That is encoded in mule-unicode-0100-24ff, essentially unknown outside
Emacs.

Other libs/apps prefer to use utf-8³ in compound_text for such chars.

I understand *why* this happens, given that Emacs used to use 2022
internally, but it confuses other X11 apps.

I am not fully fluent in Emacs' internal charset conversion routines;
is there an easy way to tell it to limit which 2022 charsets it will
use when converting a string into a 2022 encoding?  A better way?

I will be adding at least some of the charsets to libX11, provided I can
find the relevant mappings with X11-compatable licensing, but that will
not help current installations, nor those who, like Emacs, rolled their
own compund_text decoders.

-JimC

P.S.  The libX11 src, in libX11/src/xlibi18n/lcCT.c, is the best
      resource to know which 2022 charsets libX11 supports.

1] http://www.itscj.ipsj.or.jp/ISO-IR/228.pdf
2] http://www.itscj.ipsj.or.jp/ISO-IR/143.pdf
3] http://www.itscj.ipsj.or.jp/ISO-IR/196.pdf

-- 
James Cloos <address@hidden>         OpenPGP: 1024D/ED7DAEA6