nanogui: Fonts and keyboard support
Subject:
RE: Fonts and keyboard support
From:
Greg Haerr ####@####.####
Date:
4 Jan 2000 23:42:33 -0000
Message-Id: <C1962B36D9BBD311B0F80060083DFEFBF0FE@NBA-SLAM.CenSoft.COM>
: The reason I suggested UTF-8 encoding over UCS-2 (16 bit unicode),
: is that there's already work being done on UCS-4 (32 bit unicode). UTF-8
: supports both. So I'd prefer that over UCS-2... The other alternative
: is UTF-16, in which most characters are 16 bit, but some values are
: indicate the usage of a second 16 bit extension value - almost the
: same as UTF-8. In other words, with UTF-16 we'd get mostly 16 bit
characters,
: but still have to decode them, since some characters will be 32 bit.
Well, I don't think we should consider UTF-16 or UCS-4.
:
: Also, UTF-8 is very common for storage of unicode text, both on the web,
: and from misc. applications. Libraries such as xmlpat for instance use
: UTF-8, since UTF-8 can reliably be handled by anything that accepts
: 8-bit null terminated character strings, while UCS-16 and UTF-16 AFAIK
: can't.
Saving all text as 8-bit null terminated strings is appealing, since
the text output api's don't have to be duplicated.
I'm not that adamant about using 16-bit UNICODE, since UTF-8
can be encoded without extending the APIs. A few other concerns
though: if UTF-8 is used, then Europeans can't just type kbd characters
from the machines and have them pass thru unmodifed to get umlaut
characters like now. We would _require_ translation tables. Also,
there are UNICODE applications out there, especially on the Windows
side (all of WinCE, for instance). These applications might want to be
ported,
and we'd be better off having UNICODE support directly. Finally,
we agree that kbd data should be sent to the app as UNICODE, so
we're going to have to convert UNICODE anyway...
Greg
