[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

X11 Compound Text vs ISO 2022

From: James Cloos
Subject: X11 Compound Text vs ISO 2022
Date: Tue, 06 Jul 2010 12:21:11 -0400
User-agent: Gnus/5.110011 (No Gnus v0.11) Emacs/24.0.50 (gnu/linux)

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
(encode-coding-string "ʻ" 'compound-text) ; U+02BB MODIFIER LETTER TURNED COMMA

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

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.


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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]