Robert Brady wrote on 2000-09-04 16:46 UTC: > > It is not untyped, it is always STRING (i.e. Latin1). Furthermore it > > is not deprecated; it is just "much simpler but much less powerful > > than the selection mechanism". See ICCCM spec section 3. > > Ok, in that case the question is "how to make cutbuffers use UTF-8 in an > interoperable way?" I think the answer here must be that applications interested in UTF-8 transfer of text should always first try to use selections and check whether UTF8_STRING is available there. Only if this fails, they should try selection with STRING and cut-buffer with STRING, and in that case, every non-Latin-1 character will have to appear as a "?" or so. UTF8_STRING is unfortunately so far just a proposal. [EMAIL PROTECTED] told me some time ago: > FYI: What X-i18n WG planned to support Unicode string right before X > Consortium was tapering out is to define CompoundText2, which directly > transfer UTF-16. That spec never made it before the X Consortium stopped to exist, and I am trying to find out whether we can reactivate such a project to standardize Unicode selections within X.Org. Markus -- Markus G. Kuhn, Computer Laboratory, University of Cambridge, UK Email: mkuhn at acm.org, WWW: <http://www.cl.cam.ac.uk/~mgk25/> - Linux-UTF8: i18n of Linux on all levels Archive: http://mail.nl.linux.org/lists/
