FORW: Re: X11 UTF-8 and Unicode support
Found this <slrn7nh5pj.h4b.vanhala@tuuri.ling.helsinki.fi> in comp.windows.x:
== BEGIN forwarded message ==
From: vanhala@ling.helsinki.fi (Tomas Vanhala)
Newsgroups: comp.windows.x,comp.std.internat,comp.software.international
Subject: Re: X11 UTF-8 and Unicode support
Date: 29 Jun 1999 09:51:52 GMT
In article <7kmcva$t18$1@pegasus.csx.cam.ac.uk>, Markus Kuhn wrote:
>Are here any engineers from X.Org companies such as Sun, HP, SCO, IBM, etc.
>who have a strong interest in seeing proper Unicode/UTF-8 support in the
>X11 protocol specification and in the Xlib sample implementation?
>
>I think it is time to set up a working group that takes care of filling
>in the (very few but still crucial) missing bits in the X protocol and
>Xlib to enable excellent interoperability between the many upcoming X11
>clients with Unicode support.
>
>There are a number of urgent issues that have to be arranged with the
>X.Org group, and I am rather clueless about how to orderly proceed with
>this. For example, as part of the xterm UTF-8 extension, Julius
>Chroboczek and I have defined a few conventions that really should in
>some form find their way into the next revision of the X protocol
>standard:
>
Are you familiar with the information available at www.x.org? It
seems that the logical way to proceed would be for your employer
to join X.Org as an associate (or premier or executive) member.
I quote http://www.x.org/members_assoc.htm:
Associate Members receive fundamental involvement in X.Org, an
effectual voice and the opportunity for leadership in stewardship.
Some X.Org members, e.g. Sun and Compaq, already have developed
Unicode-based X11 technology. As a representative for a fellow
X.Org member you could persuade Sun or Compaq to contribute the
technology, or persuade X.Org to purchase the technology from
them.
Solaris 7 includes Unicode/UTF-8 support in the X11 environment
in the form of:
- X11 locales. See the locale database file
/usr/openwin/lib/locale/en_US.UTF-8/XLC_LOCALE
- X input and output methods for Unicode. (These are provided
by the dynamically loadable object files in the directory
/usr/openwin/lib/locale/common)
- With font aliases and (Xlib) FontSets, "virtual" Unicode
fonts are constructed from "real" fonts originally created
for other encodings. There are also some Unicode-specific
fonts in /usr/openwin/lib/locale/en_US.UTF-8/X11/fonts/misc
Digital UNIX 4.0E (and presumably Compaq Tru64 UNIX 4.0F) also
has support for Unicode in the form of:
- Unicode locales. See files /usr/lib/X11/locale/XLC_LOCALE/UTF-8
and /usr/lib/X11/locale/locale.dir
- Support libraries in /usr/i18n/shlib and /usr/i18n/shlib/X11
- Fonts under /usr/i18n/X11/fonts/FGC:
The font support under Digital UNIX seems to be done without
X output methods or FontSets. A new font type is introduced
instead:
$ cat /usr/i18n/lib/X11/fonts/FGC/100dpi/timR12.fgc
FONT -dec-times-medium-r-normal--17-120-100-100-p-84-ISO10646-1
SIZE 12
COMPONENTS 2
ISO8859-1 /usr/lib/X11/fonts/100dpi/timR12.pcf.Z
ISO8859-15 /usr/i18n/lib/X11/fonts/decwin/100dpi/timR12_lat9.pcf.Z
Why has Compaq chosen to introduce a new font type? I have not
studied the Xlib source code, but I presume that XCreateOC() and
XCreateFontSet() immediately resolve to a series of calls to
XLoadFont(), whereas Compaq's solution might allow for the
underlying "real" fonts to be loaded on demand.
Regards,
Tomas V.
== END forwarded message ==
Reply to: