With the rapid introduction of UCS (ISO 10646) / Unicode as the primary character set in many programming environments (Win32, WWW, Java, XML, Perl, Python, TCL, Ada95, etc.) the lack of proper support for ISO 10646 in X11 has become the single most significant shortcoming of the X11 platform and sample implementation today. Unicode support needs to be addressed with highest priority in forthcoming X11 sample implementation releases.
XFree86 has worked over the past two years in order to find solutions for at least the most urgent ISO 10646 related shortcomings of X11.
Three very simple aspects of this work are now stable, widely-reviewed, uncontroversial and ready for immediate integration into X11R6:
-Adobe-* and -B&H-* 75dpi and 100 dpi fonts:
Asian double-width supplement for -misc-fixed-*-iso10646-1 fonts:
Applicable to troff source of ICCCM spec (PostScript version):
Suggested replacement for xc/doc/specs/XProtocol/X11.keysyms:
Formatted PDF of the proposed new keysym appendix:
Formatted Postscript of the original specification:
Suggested replacement for <X11/keysymdef.h>:
Other aspects of X11 and UCS that should be addressed in X11R6.6.1 as well, but for which we do not submit patches at this time:
XmbDrawImageString, XmbDrawString, XmbDrawText, XmbLookupString, XmbResetIC, XmbSetWMProperties, XmbTextEscapement, XmbTextExtents, XmbTextListToTextProperty, XmbTextPerCharExtents, and XmbTextPropertyToTextList
into locale-independent UTF-8 equivalents Xutf8DrawImageString, Xutf8DrawText, Xutf8LookupString, etc. Many modern programming environments (Perl, Python, TCL/Tk, many web browsers and widget sets) now handle all their text data internally in UTF-8, independent of the currently selected locale, while they use at the same time locale-dependent C functions. As a result, calls to the Xlib multi-byte functions have to be encapsulated by application developpers with potentially highly inefficient and multi-threading unsafe setlocale calls plus additional measures to preserve multi-threading safety. This clumsy and inefficient programming style could be easily avoided if Xlib provided a UTF-8 API. The amount of code added to Xlib is negligible (a few kilobytes), but the practicality gain is significant.]
More information ...
created 2001-03-27 -- last modified 2001-05-05 -- http://www.cl.cam.ac.uk/~mgk25/ucs/xorg.html