[Xcb] about XTextProperty

Keith Packard keithp at keithp.com
Sat May 14 21:23:21 PDT 2005

On Sat, 2005-05-14 at 20:09 -0700, Jamey Sharp wrote:

> For the mb and wc variants, I think the iconv-related functions should
> be all you need; they're shipped in glibc and should be readily
> available on non-glibc platforms as well.

This is, sadly, not quite true.  X uses a custom encoding called
COMPOUND_TEXT which is based on ISO 2022 to merge multiple other
encodings together in the same property.

These legacy encodings are not necessary to interoperate with Mozilla,
Qt or Gtk+ based applications; those all happily use the new UTF-8
property encodings.  So, if you're cavalier about legacy non-US
application support, you could bail on COMPOUND_TEXT and stick with ISO
8859-1 and ISO 10646.

> Ideally, ecore and other libraries in the client stack would operate
> only on UTF-8. In dealing with X properties, conversion to and from
> UTF-8 may sometimes be needed to correctly inter-operate with other X
> clients -- but I believe neither wc nor mb APIs will help with that.

Yes, there are newer Xlib APIs not in your paper manual which can
transcode between COMPOUND_TEXT and UTF-8.  These can be reconstructed
as wrapper functions around iconv functionality for use with XCB though;
COMPOUND_TEXT is just a way to wrap multiple legacy encodings into a
single string.

> You might be able to convince me that shared code to convert between
> iconv character set names and X atoms would be useful, though. 


> > I agree that their code is really not nice at all. I really don't like the
> > way Xlib is written.
> Heh. No argument here. :-)

Yes, the Xlib internationalization code is a total horror show.  It was
written in the middle of ANSI-C's first foray into non-ASCII encodings
but before Unicode had gained enough traction to be a viable universal
encoding (i.e. before Unicode moved from 16 to 21 bits)

None of this code should ever have been put into Xlib in the first
place.  I'd say it is not the worst part of Xlib; that surely has to go
to the input method support.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.freedesktop.org/archives/xcb/attachments/20050514/b5af1db4/attachment.pgp

More information about the xcb mailing list