Juliusz wrote in http://www.pps.jussieu.fr/~jch/software/UTF8_STRING/UTF8_STRING.text
> In the interest of interoperability, the semantics of the selection > target TEXT are *not* changed; in particular, replying with a > selection type of type UTF8_STRING to a request specifying TEXT is > explicitly *not* allowed. Question: That was mostly in the context of how to handle xterm-style cut&paste selections. What about the window manager property types WM_CLIENT_MACHINE WM_ICON_NAME WM_NAME which are all specified in the ICCCM as type TEXT. If we exclude UTF8_STRING from being used where a type TEXT is specified, we will have no portable way of using Unicode in windows titles and icon names. Why can't we just jump into the cold water by adding UTF8_STRING to the list of encodings allowed to be used when then polymorphic type TEXT is used, with the simple restriction that STRING must be used whenever all the character of the string are contained in Latin-1? I understand that it may break temporarily a few things if the originator of a property uses UTF8_STRING and the recipient does not yet understand it. But in practice, isn't that just the same situation as we had when COMPOUND_TEXT was added in 1991 and C_STRING was added in 1993, two types that even today are still not supported by most applications. The only alternatives I could think of are all a bit ugly, such as adding WM_CLIENT_MACHINE_UTF8 WM_ICON_NAME_UTF8 WM_NAME_UTF8 all of type UTF8_STRING. Opinions? Markus -- Markus Kuhn, Computer Lab, Univ of Cambridge, GB http://www.cl.cam.ac.uk/~mgk25/ | __oo_O..O_oo__ _______________________________________________ I18n mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/i18n
