Markus Kuhn <[EMAIL PROTECTED]> writes:
> 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.
This reminds me to point out (as I've been planning to do for some
time) that there are a couple of problems with the UTF8_STRING spec -
- the suggestion to return UTF8_STRING in response to a request
for TEXT is a Bad Idea, since that breaks legacy apps.
- I disagree with the recommendations in the section of
C0 and C1 control centers. (In particular the handling
of \t, and treating a single LF as a soft linebreak.)
Remember, most clients, when cutting and pasting, are cutting
and pasting text provided by the user. The user expects
C0/C1 characters to be passed across in the same way.
So, this spec doesn't really need to describe handling
in this much detail. In most circumstances, text provded
by the user should be tranferred verbatim.
If more detail is needed, then this spec should simply refer
to the Unicode guidelines on newline handling.
Regards,
Owen
-
Linux-UTF8: i18n of Linux on all levels
Archive: http://mail.nl.linux.org/lists/
