These represent standard computer keyboard layouts in the respective languages. They are meant to function as such using either your mouse or your keyboard.
There are a couple of obvious uses of these keyboards. The first is to type a small amount of text in a foreign language, to paste in some other program. The second is as a typing tutor for a standard keyboard in chosen language.
You should be able to click on the keys with the mouse, or type on the keyboard with the same effect.
To produce uppercase letters with the mouse, click on the Caps Lock key. Holding down on the keyboard Shift key while clicking a key with the mouse doesn’t work. The keyboard Shift key only works while typing on the keyboard.
In some browsers, the Backspace key activates the browser’s “previous page” button. In such cases, use the Delete key.
In most browsers, the left-arrow and right-arrow keys should move the text insertion point. (Opera has a buggy right arrow). Also, the Home and End keys should put the insertion point at the beginning or end of the text, respectively.
The Ctrl, Alt, win, and menu keys have no effect.
The keyboards are fully scalable, so if you find them too small (or too big), use your browser’s text size function (zoom) to alter the size.
The typed text is in Unicode, or UTF-8, encoding. So you will be able to paste the text only into an application that supports Unicode encodings.
In Windows XP, you can paste into Notepad or or jext.
In Linux, you can paste into KWrite, Gedit or the mail client Balsa or text fields in Firefox or Opera. To paste into xterms, they must be set up for Unicode.
Certain capacities are required of your browser to support the keyboards. On most modern systems, these are already available, but on older systems you may have to do some work.
You will need a font that supports Unicode encodings, and which contains glyphs (characters) for the alphabet in question.
Such a font has been provided by Microsoft: “Arial Unicode”. There are now several free alternatives, including the DejaVu and FreeFont families.
If a font with a new range is added to your system, your web browser should make use of it to display characters in that range.
JavaScript is what makes the keyboard function. This varies greatly between browsers, and is endless, fiddly trouble.
I have specifically modified the keyboards to work around the peculiarities of MS Explorer v. 6, but small omissions or bugs in other browsers may cause them to fail.
I used the W3C’s Document Object Model (DOM) to address the keyboard keys individually.
Only the most recent of browsers are sufficiently compliant with the DOM to allow the keyboards to function.
Browsers that function are Firefox, Opera 7+, Netscape 7, Mozilla 1+, MS IE 6, whereas Netscape 4.x and MSIE 4 will not suffice.
An encoding is a numbering of the characters in a written language. There are lots of encodings. For example, ASCII (American Standard Code for Information Interchange) is an adequate encoding for most English text. The International Standards Organization has standardized encodings for many languages: ISO-8859-15 covers most Western European languages, and ISO-8859-5 covers languages written in Cyrillic (such as Russian), and allows for both Cyrillic and Latin characters. Some languages are supported by several different encodings: English is supported by both ASCII and ISO-8859-15, Russian is supported by ISO-8859-5 and KOI-8.
Over the past decade, there has been a thrust to encode all the world’s living languages with a single encoding, called Unicode. It’s not as efficient as a special encoding for a particular language, and there are a lot of technical hurdles to be overcome. It is the future of character encodings, though.
For this project, the easy thing to do was to adopt the Unicode standard UTF-8. What this means to you is, you have to use Unicode- compliant software to use the keyboards, and to paste the text you make with the keyboards.
Even if you have a font that supports Unicode, it may not contain glyphs for all the characters of all languages. For instance, many current Unicode fonts don’t contain glyphs for Sinhalese (I don’t know why.) Also, Unicode fonts are pretty new, and most have lots of bugs, such as missing or wrong characters.
I have tried to support both left-to-right (English) and right-to-left (Hebrew) writing systems.
A keyboard layout specifies which characters are on what keyboard key. This has nothing to do with character encodings.
Some languages only have one standard keyboard layout, others have several. The most common English layout is the QWERTY layout (named for the first six letters on the keyboard), but there is also the much less well known (but more logical) Dvorak layout. Tamil seems to have at least six layouts.
Many written languages have too many characters to fit on any reasonable keyboard—Chinese is the most extreme example. For such languages, there are input methods that permit a user to type a letter by means of multiple keystrokes.
Such input methods are beyond my current level of interest in this project, so I’m not supporting languages that require them. Could be done, though.
In written English, one letter essentially follows another in left-to-right fashion. In some languages, a sound may be written as a modification of another character, and how letter is written may depend on where it appears in a word or on adjacent letters.
These are hard issues, and I intend to deal with them only if there’s an easy solution (that is, if the operating system or browser takes care of it).
However, I may have to make a distinction between what is displayed on the key, and what character is actually typed.
I used several technologies here: HTML, CSS, JavaScript (ECMAScript), and XML/XSLT.
They keyboard itself is just a big HTML table, with the table cells being the keys.
CSS is used to specify the colors and sizes of things.
JavaScript provides the functionality.
The HTML documents are generated using XSLT from relatively simple XML documents that just specify which characters are on what keys.
There are several ways to deploy XSLT-generated pages such as these keyboards.
Ideally, one would rely on the user’s browser having an XSLT processor. Then the deployment is very tidy, consisting of the XML data files, one XSLT stylesheet, and ancillary files such as JavaScript, CSS, etc. Moreover, the user’s machine does the bulk of the processing.
Only a few modern browsers have an XSLT processor, however. MSIE 6 was the first, and now Firefox and Opera have them. For my purposes, it's still a lot to ask.
Another approach is to have the web server run the XML data through its own XSLT pre-processor when a page is requested. This puts the processing burden on the server, but has tidiness advantages.
However, most ISP’s are disinclined to offer such capabilities to their members. Besides the computing overhead and additional maintenance, they are rightly concerned about security.
I have used a rather crude approach here which works on my ISP’s server, and requires little of users’ browsers. I produce HTML documents by running the XML data documents through an XSLT stylesheet by hand, using a stand-alone XSLT processor (xsltproc). It’s a little less tidy, inasmuch as I have to store the separate HTML output as well as the XML data.
The Opera browser has a feature that misbehaves with this application, whereby the browser takes ownership of many keystrokes that ought to be going to the keyboard’s text area.
Here is my work-around:
Tools → Preferences → Advanced → Shortcuts Keyboard setup Opera Standard → Edit Application → Platform Windows-Unix-MCE, Backspace *delete this entry* *delete the other entries that use plain keystrokes*
The keyboards are described by XML files, whose syntax is defined by the Document Type Description file keyboard.dtd. These XML files can be viewed by clicking on any of the XSLT versions from the main page, then from your browser menus, choosing View Source. These XML files are transformed into HTML by the XSLT transformation file keyboard.xsl.
As explained above, XSLT transformation may be done either on loading, by the browser, or beforehand, by me. For the files I transform by hand, I use this Makefile on my Linux system.
Once the HTML is generated, colors, fonts, and sizes are specified by a Cascading Style Sheet keyboard.css, and finally, the typing and mouse behavior is specified by a JavaScript file keyboard.js.