emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: MML charset tag regression


From: Jan D.
Subject: Re: MML charset tag regression
Date: Tue, 20 May 2003 21:42:14 +0200

In article <address@hidden>, Richard Stallman <address@hidden> writes:

    Recently, many gtk clients start supporting UTF8_STRING
    without making COMPOUND_TEXT support better.  It may cause
    no problem between gtk clients because they will request
    only the type UTF8_STING.  But, it's a too shortsighted
    manner.  :-(

Is this an issue I should raise with the GTK developers?  Could they,
should they, do something to encourage app developers to handle
COMPOUND_TEXT properly?

Perhaps, app developers are just using some GTK function for
X selection handing (I don't know if such a function surely
exists).  In that case, improving that function solve the
problem.

There is a function that converts selection data to an UTF8 string,
if the format is a known text format.  But mostly widgets take care
of selection handling by themselves (i.e. transparent to an application
that uses GTK). To get better COMPOUND_STRING handling, I suspect GTK as a library must change.

The reason you are seeing more UTF8_STRING is probably not a choice
made by GTK client developers, it is just an effect of porting to
GTK version 2.  UTF8_STRING is not present in GTK 1.x, but the
preferred format in GTK 2.x.  The reason for this is the standards
work being done by the free desktop people
(see http://www.freedesktop.org/standards/) to improve interoperability
between desktop environments, for example KDE and GNOME.  It seems
UTF8_STRING is the preferred coding.

I am not sure, but I suspect that better COMPOUND_STRING handling
is low on the priority, as the web page above kind of implies that
UTF8_STRING is to replace COMPOUND_STRING in the future.  Qt (KDE)
also uses UTF8_STRING as a first choice.

        Jan D.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]