InScript keyboard

Lore & Background

The first InScript keyboard was standardised in 1986 under the auspices of the DOE (Department of Electronics at the Ministry of Communications & Information Technology). It was subsequently revised in 1988 by a DOE committee and modifications were made to accommodate nuqta extended keys as well as to add certain matras. The last revision to the BIS document was made in 1992, after which the document has not undergone any revision. This was partly because very few new characters were added to the ISCII code-set and these if at all were handled by extending and generating the character by the use of the nuqta. The BIS document specifically mentions such characters. Hence the InScript keyboards were felt to be self-sufficient.

With the advent of Unicode, a few new characters were added to each code-page; characters for which the BIS document had not made any provision. In addition Unicode introduced the concept of ZWJ and ZWNJ, as well as that of normalisation. These new features had marked repercussions on storage as well as inputting and an urgent need was felt for a revision whereby each new character introduced in Unicode would be accommodated on the keyboard and a uniform manner of entering data as well as storing data would be devised. With this urgent requirement in mind, CDAC GIST involved in the initiative all major players: IBM, Microsoft and Red Hat Linux and hence in 2008, a joint meeting was organised between CDAC GIST and senior representatives of these multi-nationals to devise a common and uniform strategy for inputting and equally important for storage. This would enable the creation of one single keyboard and more importantly one single storage, essential for all high-end NLP. A task-force was created with two major briefs: evolve a design policy which would retain the major features of the existing Inscript keyboard, and accommodate on the keyboard every character proposed in Unicode 5.1 and also ensure that the design could accommodate all future additions. This resulted in a document by the joint deliberations of all these companies described as proposal for 'Enhanced InScript keyboard layout 5.1'.

Reader's Guide

The InScript keyboard layout is notable as the decreed standard for inputting text in Indian scripts, covering 12 scripts including Devanagari, Bengali, Gujarati, Gurmukhi, Kannada, Malayalam, Odia, Tamil and Telugu, as well as the Santali language in Ol Chiki script. Its significance lies in its widespread built-in support across major operating systems—Windows (2000 and later), most Linux, and Mac OS—and its availability on mobile platforms such as Android 4.0 and higher, iOS 5 and higher (for Tamil and Hindi), and Windows Mobile 5.x and 6.x from third parties. The layout is designed with a common phonetic character order, allowing a person who knows InScript typing in one script to type in any other Indic script using dictation even without knowledge of that script. Its legacy includes the 2008 joint meeting between CDAC GIST and IBM, Microsoft, and Red Hat Linux to address Unicode additions, resulting in the 'Enhanced InScript keyboard layout 5.1' proposal. However, it was removed from the latest Google Keyboard application (Gboard) and Google Indic Keyboard, though it remains available in Android 4.0 and higher.

Did You Know?

• InScript is the decreed standard keyboard layout for Indian scripts using a standard 104- or 105-key layout.
• The layout supports the Santali language written in the non-Brahmic Ol Chiki script.

The Three Dimensions of a Keyboard Layout

A keyboard layout is not a single fixed thing but rather a layered system that can be understood through three distinct lenses. The physical dimension concerns where each key switch sits on the chassis—the tangible geometry a typist's fingers encounter. The visual dimension refers to the legends printed or engraved on keycaps, the symbols and letters that guide the eye. The functional dimension is the most abstract: it is the software or firmware mapping that dictates what action fires when a particular key is pressed, independent of what is printed above it. These three layers can be decoupled. A single physical board can serve multiple languages simply by swapping the mapping table, while the keycaps remain unchanged. Standard arrangements differ across writing systems and use cases, and hobbyist designers have long proposed alternative configurations to better match individual ergonomics or to unlock additional functionality beyond what a stock layout provides.

The Scancode Bridge Between Hardware and Character

When a key is depressed on a modern computer keyboard, the device does not report the letter or symbol printed on its cap. Instead, it transmits a scancode that identifies only the row and column position of the switch within the matrix. The operating system receives this positional signal and consults a keyboard mapping table—a lookup structure that translates the scancode into a specific binary character code. This indirection is what makes dynamic remapping possible: a user can reassign every key's output through system settings or third-party software without ever replacing a single physical component. Most contemporary USB and wireless keyboards are plug-and-play, automatically advertising their default visual layout to the host upon connection. Some boards also carry onboard firmware capable of storing custom layout configurations, adjusting backlighting, and handling other peripheral functions entirely independent of the host machine. The engraved glyph on a keycap is therefore merely a suggestion; the true output is governed by software interpretation.

Modifier Keys and the Architecture of Combinations

Beyond the core alphanumeric block, keyboards incorporate a family of modifier keys that produce no output on their own but reshape the behavior of other keys when held simultaneously. The Shift key toggles between lowercase and uppercase letters and selects the upper of two engraved symbols on a key. Control, Alt, and AltGr keys trigger special operations when combined with other inputs. Because a modifier must be held while another key is struck, they are typically provided in mirrored pairs—one for each hand—so that one hand can anchor the modifier while the other strikes the target key. On non-English Latin-alphabet keyboards, the AltGr key (positioned to the right of the space bar) unlocks a third-level symbol, and pairing it with Shift can reveal a fourth. Apple keyboards replace the traditional Ctrl/Alt/AltGr trio with Command and Option keys, while retaining a Ctrl key for legacy compatibility and adding an Fn key to switch F-key behavior between standard function actions and media or system shortcuts.

Experimental and Alternative Configurations

The standard QWERTY-descended arrangement is far from the only configuration ever attempted. Unix workstations and home machines such as the Amiga relocated the Ctrl key to the left of the letter A and moved Caps Lock to the bottom-left corner, while also shifting the Esc key to sit left of the number 1. The XO laptop adopted this same Ctrl placement but eliminated Caps Lock entirely. At the other extreme, the so-called space-cadet keyboard used on MIT LISP machines pushed the modifier concept to its logical limit, featuring no fewer than seven dedicated modifier keys—a design that multiplied the number of possible key combinations exponentially. More recently, the Fn key has appeared on smaller Windows and Linux laptops and tablets, serving a role analogous to its Mac counterpart by toggling between F-key functions and media or system controls. These variations illustrate that the keyboard's physical and functional architecture remains an active area of experimentation, shaped by the needs of specific computing environments and the preferences of individual users.

Gallery