COMPOUND_TEXT versus UTF8_STRING

[Keith Packard]

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.

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.

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.

-keith


-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
URL: <http://lists.x.org/archives/xorg/attachments/20040922/356c875c/attachment.pgp>