Subject:
RE: Fonts and keyboard support
From:
"Vidar Hokstad" ####@####.####
Date:
4 Jan 2000 23:18:17 -0000
Message-Id: <20000104231706.10839.qmail@mail.relight.com>
On Tue, 4 Jan 2000 14:17:13 -0700 Greg Haerr ####@####.#### wrote:
>I propose keeping it simple, initially. There are two main areas
>requiring unicode, kbd input and text output. I propose that
>text output be available in 8 and 16 bit versions, and kbd
>input as 16 bit always. For instance,
>the Nano-X GrText function would remain and an additional GrText16
>function added, that takes a unicode string.
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.
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.
>For keyboard input, we could support two different
>driver methods, one to read 8 bit data, an additional one for 16 bit data.
>The driver could indicate which ones it supports, and a mid level
>conversion routine could be added, if really needed.
>
>Since kbd data is delivered to applications always character-by-
>character, rather than as a string, then that character data could
>always be unicode, which, of course, remains the same for codes 1-127.
>
>In regards to MSB encoding, I think this makes things harder than
>just using straight UNICODE-2, for which many tables are available,
>and conversion routines are simple, and no packing/unpacking
>is required.
Converting from UTF-8 to and from UCS-2/4 is simple - there are several
functions available that handles it (it's 20-30 lines of code tops).
See my comments above with regards to UCS-4 for why UTF-8 is good..
>These three entry points are GetFontInfo, GetTextSize, and GetTextBits.
>If the new font renderer implements these three functions, then everything
>is extremely easy. If the renderer can't return a character bitmap,
>but needs to draw it, then things will be messy. Not recommended.
I've looked at both FreeType and T1lib (briefly today ;) , and in both
cases it's easier to get bitmaps than have the renderer draw it directly,
so that should be acceptable... Both supports antialiasing, though,
and it might be nice to support that too. It's not the most important
feature, though :)
I'll take a look at it.
>I want to add termcap-style function key parsing, but this really can
>be done in the low level kbd driver. The ESC quit has got to go. Any
>suggestions for quitting? The kbd handling is stable, but it certainly
>isn't
>finished. Like I said above, I think we ought to return 16 bits
>rather than 8 for each character, with an addition 16 bits for other
>data, like meta keys, ctrl, etc.
Ok. This sounds good.
[on on-screen keyboard support:]
>That would be great! Do it yes yes yes!
I'll see what I can find... :-)
Regards,
Vidar
