nanogui: Thread: Fonts and keyboard support

I'm currently working on a text area widget for NanoWidgets (we'll have to put 
a new release together fairly soon... There's several new widgets, and lots of 
bugfixes), and the font and keyboard handling issue popped up again. 
 
I'd like to know the status of any ongoing work on keyboard events and font 
handling before I start hacking on something myself. 
 
There's quite a few things to consider: 
 
- 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. 
 
- 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). 
 
- 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. 
 
- 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'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...) 
 
Any comments welcomed... 
 
Regards, 
Vidar Hokstad 
VP of R&D, 
Screen Media AS 
 

Vidar,

Vidar Hokstad wrote:

> I'm currently working on a text area widget for NanoWidgets (we'll have to put
> a new release together fairly soon... There's several new widgets, and lots of
> bugfixes), and the font and keyboard handling issue popped up again.
>
> I'd like to know the status of any ongoing work on keyboard events and font
> handling before I start hacking on something myself.
>

Kool. We need internationalization too for our project. And we also need rotating
fonts (looks like we'll need vectorial fonts ... )

>
> - 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 also considered Freetype (http://www.freetype.org) for truetype fonts and I am
concerned about the patent issue. Freetype is surely too big to be incuded in nanox
but could be supported through a wrapper as an external support library for those
who want. Also, I was wondering how easy it would be to strip it down to a mininum.

I considered T1lib
(http://www.neuroinformatik.ruhr-uni-bochum.de/ini/PEOPLE/rmz/t1lib/t1lib.html) for
adobe type 1 fonts (postscript fonts), it is somewhat smaller and don't seem to
have patent issue. Needs more study ...

>
> - 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.
>

Agree.

We could join forces on the font issue, I'll see what I can do on my side

Martin Jolicoeur
GVT project
####@####.####

> -----Original Message-----
> - 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.

I've changed mine to "¬" to quit, something nice and rare.  I've got a
patch which, amid other things, does this.  I've also done some makefile
bits which allow you to define this.... How have you done it?  I'll be
adding my bits into the main nanox tree shortly....

	-Darran

--
 Darran D. Rimron            European Research & Development Manager
Real Data Services, 117-119 Marlborough Road, Romford, Essex, RM7 8AR
 ####@####.####                      http://www.getreal.co.uk/
 Phone:44-1708-70-44-33 Fax:44-1708-74-88-59 Mobile:44-7931-37-59-39

On Tue, 04 Jan 2000 10:05:54 -0500 Martin Jolicoeur ####@####.#### 
wrote: 
>Vidar,  
>Kool. We need internationalization too for our project. And we also need 
>rotating  fonts (looks like we'll need vectorial fonts ... )  
 
That should work fine with Freetype... But it needs consideration when for 
API changes etc. 
 
>>  
>> - 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 also considered Freetype (http://www.freetype.org) for truetype fonts and I 
>am  concerned about the patent issue. 
 
Yes.. I'm pretty confident that will be resolved though, from the explanations 
on the website. But we won't risc our business on it :-) 
 
>Freetype is surely too big to be incuded in nanox but could be supported 
>through a wrapper as an external support library for those  
>who want. 
 
I agree. Font rendering is so important, that it would be extremely nice to 
be able to pick the one best suited, without having to rewrite client 
applications. 
 
>Also, I was wondering how easy it would be to strip it down to a >mininum.  
 
I haven't looked at that yet, but from a fairly standard build, I ended up 
with a 270kb shared library, and that isn't too bad for our use.. Of course 
it may be unacceptable for other people, which is why I'd like it to be easy 
to switch to something simpler. 
  
>I considered T1lib  
>(http://www.neuroinformatik.ruhr-uni-bochum.de/ini/PEOPLE/rmz/t1lib/t1lib.html) 
>for  adobe type 1 fonts (postscript fonts), it is somewhat smaller and don't 
>seem to have patent issue. Needs more study ...  
 
Thanks for the pointer. 
 
>We could join forces on the font issue, I'll see what I can do on my side  
 
That would be great. 
 
Thanks for your comments. 
 
Regards, 
Vidar Hokstad 
Screen Media AS 

On Tue, 4 Jan 2000 15:10:42 -0000 "Darran D. Rimron" ####@####.#### 
wrote: 
>> -----Original Message-----  
>> - 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.  
>  
>I've changed mine to "¬" to quit, something nice and rare.  I've got a  
>patch which, amid other things, does this.  I've also done some makefile  
>bits which allow you to define this.... How have you done it?  I'll be  
>adding my bits into the main nanox tree shortly....  
 
I just commented it out in our internal tree :-) 
 
Regards, 
Vidar 

: - 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

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 

: 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

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 

> That leaves UCS-2, which can't encode all unicode characters, or UTF-8 which 
> can... 

The internet is heavily UTF8 based.

> >we agree that kbd data should be sent to the app as UNICODE, so  
> >we're going to have to convert UNICODE anyway...  
>  
> Yes. 

Convert the unicode before you compile, then your binaries will be more compact. A flash
disk full of alternate letters and zeros isnt my idea of perfection