COMPOUND_TEXT versus UTF8_STRING
otaylor at redhat.com
Wed Sep 22 23:38:31 EEST 2004
On Wed, 2004-09-22 at 11:57 -0700, Keith Packard wrote:
> Around 19 o'clock on Sep 22, Roland Mainz wrote:
> > ... or "enhanche" the ISO2022/COMPUND_TEXT spec (see my other email in
> > this thread) to include an escape-sequence which says: "UTF-8 starts
> > here..." :)
> > That may be a less aggressive approach to the problem...
> Adding UTF-8 support to COMPOUND-TEXT would be a relatively large job for
> applications as they could no longer count on mapping text segments to
> unique core fonts, something they can count on with today's set of
> encodings. We'd have to perform magic inside Xlib to get those glyphs up
> on the screen, and I'm not sure that's possible using the existing Xlib
> APIs for dealing with COMPOUND-TEXT.
As I recall, I think if you check in Xlib, you'll find that UTF-8 in
COMPOUND_TEXT is already supported. It just isn't used for languages
that have legacy encodings, since you don't want to break
interoperability with apps (well, Emacs) that actually parse
COMPOUND_TEXT themselves and expect COMPOUND_TEXT as it used to be.
> In addition, applications and window managers will have to continue
> supporting EWMH for the forseeable future, just as they support existing
> ICCCM properties today; changing the core ICCCM properties will only
> require more work today, and never less work in the future.
> Switching to a world where the STRING/COMPOUND_TEXT properties are
> deprecated and the EWMH UTF-8 properties are standardized would mean that
> applications could put some kludge in the STRING property so that legacy
> window managers wouldn't crash, but otherwise interact with the user
> strictly through the EMWH hints, which virtually all modern window managers
> already support.
You'll find such code in toolkits currently...
> I'd rather just allow UTF-8 text in the existing ICCCM properties, but I
> think that doesn't provide a reasonable transition strategy. One strategy
> which might work is to have the window manager place a property on the
> root window indicating support for UTF-8 encoded strings in window
> properties, but even that seems problematic for other applications using
> those strings.
Since we have the new properties already in common use in both
applications/toolkits and window managers, I don't think bringing in a
different mechanism is worth it. And remember, reading WM_NAME isn't
just a function of the window manager ... tools such as tasks lists,
may read these properties as well.
If people think that preserving the ability to write shortish Xlib-only
programs is supported, a new function, XSetWMNames or something could
be added to replace XSetWMName; my personal preference is that additions
to Xlib taking it away from protocol-wrapper should be avoided.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.freedesktop.org/archives/xdg/attachments/20040922/143c9288/attachment.pgp
More information about the xdg