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
Attachment:
pgpivCorFKZkR.pgp
Description: PGP signature