COMPOUND_TEXT versus UTF8_STRING

[Owen Taylor]

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.

Regards,
						Owen

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.freedesktop.org/archives/xdg/attachments/20040922/143c9288/attachment.pgp