nanogui: Fonts and keyboard support
Subject:
RE: Fonts and keyboard support
From:
"Vidar Hokstad" ####@####.####
Date:
5 Jan 2000 08:52:36 -0000
Message-Id: <20000105085130.30596.qmail@mail.relight.com>
On Tue, 4 Jan 2000 16:40:01 -0700 Greg Haerr ####@####.#### wrote:
>Well, I don't think we should consider UTF-16 or UCS-4.
That leaves UCS-2, which can't encode all unicode characters, or UTF-8 which
can...
>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.
They can't do that for any Unicode encoding that I know of, so that's
an issue that would crop up anyway. UCS-2 is probably the simplest,
since it only requires adding a null most significant byte. UTF-8
requires doing that, and also passing the UCS-2 value through a (small)
conversion routine. Remember: UTF-8 is only a way of encoding UCS-2 and
UCS-4 in 8 bit characters while keeping zero termination and ASCII text
intact.
I can dig up some UTF8 <-> UCS-2/4 conversion functions. It's fairly
straightforward.
>We would _require_ translation tables.
For ISO Latin 1 no tables are required.
>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...
Yes.
Regards,
Vidar
