Browse Prior Art Database

Function-Independent Approach to Driving Soft Keyboards

IP.com Disclosure Number: IPCOM000101842D
Original Publication Date: 1990-Sep-01
Included in the Prior Art Database: 2005-Mar-17
Document File: 3 page(s) / 112K

Publishing Venue

IBM

Related People

Bird, CL: AUTHOR [+2]

Abstract

Soft keyboards permit an application program to control the function the keyboard presents to a user. Such keyboards may be implemented with a transparent overlay on a flat display. Matrix-addressed liquid crystal displays are well-suited to this role.

This text was extracted from an ASCII text file.
This is the abbreviated version, containing approximately 52% of the total text.

Function-Independent Approach to Driving Soft Keyboards

       Soft keyboards permit an application program to control
the function the keyboard presents to a user.  Such keyboards may be
implemented with a transparent overlay on a flat display.
Matrix-addressed liquid crystal displays are well-suited to this
role.

      The method described here manages changes in the keyboard
images without any reference to the application function, thus
providing a driver nucleus which can be used with any application.
In effect, it also allows the changes of view to be demonstrated in
the absence of any function, relying solely on definitions of the
various keyboard views. When a soft key is touched, a code is
returned to the control software.  This code then becomes the cue for
deciding whether any change is necessary and, if so, which key boxes
are to be changed.  No reference need be made to the application
function.

      The embodiment of the approach described in this article
employs an LCD pane, such as Hitachi LM236XB, interfaced to an IBM PC
through its color graphics adapter. The overlay creates a 5-row by
10-column array of key boxes. Software divides the 640x200 monochrome
graphics screen into 50 boxes, 64 pels across by 40 pels down to
provide the keyboard images beneath the overlay.  It should be noted
that the software can flexibly accommodate other key-box arrays and
has in particular been demonstrated with an overlay which has a 6 x 9
array of keyboxes.
      DATA AND DISPLAY STRUCTURE
      The following terms are defined:
      KEY-BOX:  The image of a single (soft) key.
        In the prototype implementation this is an array of
        pels, 64 across by 40 down.
      WINDOW:   A rectangular array of key-boxes.
        Each window is identified by an integer index number.
        (The entire keyboard view may itself be a window)
      VIEW:     The complete array of key-boxes comprising
        one view of the keyboard.
        Each view is identified an integer index number.

      For each window there is a table which identifies the source of
the image of the key-boxes, together with sufficient other
information to enable it to be displayed. Although the window image
can be stored in memory as a direct bit-map, as in the prototype
embodiment, it may be more memory-efficient to pre-define a set of
key-boxes. Some of these key-boxes may be dependent upon the
application being used, while others may be reserved for
commonly-used images, such as alphanumeric characters. Thus, the
window table could comprise a short sequence of one-byte codes, with
each code corresponding to a predefined key-box image.  The window
size, in terms of the numbers of rows and columns of key-boxes, could
be defined by two bytes.

  ...