Subject:
RE: Fonts and keyboard support
From:
Greg Haerr ####@####.####
Date:
4 Jan 2000 21:19:47 -0000
Message-Id: <C1962B36D9BBD311B0F80060083DFEFBF085@NBA-SLAM.CenSoft.COM>
: - Support for international characters.
: It would be good to support unicode internally. I would suggest
: support for using UTF-8 text rendering. The advantage of using
: UTF-8 is that the 128 ASCII letters stay the same, while any
characters
: with MSB set are part of multibyte sequences mapping to UCS-4 (32 bit
: unicode characters). It is easy and compact to encode, and for any
fonts
: that only support ASCII, characters with MSB set can just be ignored.
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.
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.
:
: - Support for font formats.
: For very small devices, compiled in fonts like it is currently would
: probably be enough. However for larger devices, support for many fonts
: and maybe even scalable fonts, may be requirement. I suggest making it
: easy to replace the font rendering at compile time. (We're considering
: adding support for Freetype, but realize that Freetype is *way* to big
: to just add to Nano-X without an option to turn it off).
I agree. It already is easy to replace the font rendering however.
mwin/src/drivers/genfont.c for instance contains the three driver
functions that are required for compiled in fonts.
mwin/src/drivers/romfont.c
contains the routines for pc rom-based font display.
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 fully support additional methods for fonts, and I think Freetype-like
font support, as well as support for loadable fonts (Martin, I thought
you were going to write that...) would be great.
:
: - Support for querying for fonts.
: We need a mechanism to obtain a list of fonts, their ID, and their
most
: important attributes (at the very least size - including a value to
signal
: "any" for freetype etc. -, and slant). Internally this could be
handled
: by whatever font renderer is compiled in, for instance a Freetype
wrapper,
: or a simple function that copies a compiled in structure when using
compiled
: in fonts.
I agree completely. I think another SCREENDEVICE entry point
should be created for this. There's quite a bit of discussion required to
keep this simple, though. I started too simple and #defined a number
of "font types" that hopefully match the description. We probably
want to fill out a structure, pass it to the driver, and then have the
driver
enumerate what it knows about, and pass this back to the app.
:
: - Keyboard events:
: 0.87 broke my escape code handling, and anyway I've always needed a
small
: patch to disable the ESC = quit thingie... I'd like to know if the
keyboard
: handling is now stable, or if things will change again. Again, I'd
love
: adding unicode support, but I'm thinking that for the keyboard this
might
: belong on the client side, since some applications may want raw
keyboard
: events anyway. Any comments?
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.
:
: I'm also thinking about looking into my archives and digging out the
: preliminary support for an on screen keyboard I wrote last summer...
: Basically a function to insert fake keyboard events into the event
stream.
: (should also be useful for automated testing...)
That would be great! Do it yes yes yes!
Regards,
Greg
