COMPOUND_TEXT versus UTF8_STRING

[Ienup Sung]

Hello,

I was reading the threads on the COMPOUND_TEXT versus UTF8_STRING and
would like to make some comments on the issue.

First of all, I also think using UTF8_STRING would be the way to go.
And to make sure that the UTF8_STRING will be even more popular,
it seem there is a need for API and also converters at XLC module but I'm
not sure or aware of on if there are already such convenience conversion API
similar to that of STRING and COMPOUND_TEXT for UTF8_STRING at libX11.
Similarly, it would be needed to have converters and data structures for
XLC module's converters among MB, WC, CS, and CT so that such convenience
conversion API at libX11 can be done correctly. If anyone knows whether
there is a spec for such, please let me know. (About a few years ago,
I proposed back to Juliusz's UTF8_STRING proposal to X.Org that we could
work together to define the API spec but couldn't follow up at that time.)

Secondly, if there are majority of people who wish to keep using
COMPOUND_TEXT, I personally think that the support of UTF-8 or any other
Unicode representation forms can be included in the COMPOUND_TEXT spec
as a non-standard character set encoding. There is no need to change
ISO 2022 extension mechanism but the only thing that would be needed would
be agreeing on the encoding name that will be used and minor wording
changes at the COMPOUND_TEXT spec. Existing implementations will work
fine as long as XLC module's converters are going to handle it. (Some
libX11 may need to do a bug fix since last time I checked, some libX11
implementations didn't do very well on the CT for non-standard character
set encoding and were looking for NULL at the end of the CT.)

Thirdly, is there any possibility of EWMH spec included in the ICCCM spec
so that we will have a single standard?

With regards,

Ienup