One of the most prolific piece of software I have ever written was a 2-3 month project that was done in 1994. The resultant product sold for over 10 years, supported over 8 Indian languages, worked with the Desktop Publishing software of the time; Word, Wordperfect, Adobe Pagemaker and a whole lot of others. It won quite a few awards…not necessarily for me.
The most important caveat for this is…I only knows 2-3 spoken/written Indian languages. And I like to think I am sufficiently lazy, someone who does not want to go back and look at an implementation again once it is done. Done means done.
The Problem
This was a time way before unicode. Windows 3.1 was fairly new. The ascii codeset was 256 characters, and any language supported, like hindi, malayalam, tamil, kannada and so on used “creative” font design/layout to fit all the character combination (and accents) into those 256 characters. This client wanted 8 Indian languages supported.
The biggest issue was the keyboard. Standard language keyboards did not exist, so repurposing the QWERTY keyboard was the only path available. With the accent’ requirements in most Indian languages, it usually required a combination of keystrokes more than just control/shift etc to type in the Indian language.
There were two schools of thought on the keyboard layouts.
- Provide a keyboard layout that was designed for the QWERTY keyboard
- Allow the user to use english-phonetic input to enter language text (more on this later)
Multilingual support was NOT a part of word/wordperfect/DTP software at that time. My task was to extend those applications so that they could be used to support input in these Indian languages.
And in my four years experienced “gung-ho” I said…no sweat, two months should do this!
The approach
Windows 3.1 was a large improvement over Windows 3.0. It included multi-tasking and some funky methods by which you could insert your application into another applications message queue; and stuff messages into that applications queue yourself. Which meant that you could trap keystrokes and mouse events before they got to the target application, and change them, and stuff more events if you wanted to.
I’m never going to learn 8 languages in two months (heck it’s 24 years since I wrote this application and I haven’t learned any more languages). So it was about how can I create a tool that will help me.
I had just started working with C++ and I thought streamable objects were cool (I still think they are…another story).
The solution
I wrote a simple message trap application, that would connect to a running application that the user selected (remember Ctrl-ESC would bring up a list of running programs). Now my application would get all the keystrokes (including alt, control, shift etc) that were meant for Word/Pagemaker. By default the language processing was not enabled but if you pressed Ctrl-Alt-K the magic would begin.
The message trap feature would intercept a keystroke, see if there was a replacement key for it in the selected keyboard template, and send that key instead. If a second key was pressed and there was another combination for that set of keys it would send a backspace key remove the previous one and output the new key (or keys). It would go on and on till it found that there wasn’t any more key in the combination set, and then would flush its memory and start waiting for the next keystroke.
One nice feature I added was extending the menu of the application that I was controlling. This allowed me to add menu items (like listing all the language keyboards supported) in the main application menu. When a user selected a language keyboard (there were up to 3-4 keyboard types) the message queue handler would start processing all the keystrokes. I left it to the main application (Word/Wordpress) to handle the font selection.
In my “everything object oriented” frame of mind…my application could connect to multiple target applications at the same time. And in each application you could select a different language. Severe overdesign… Nobody ever used more than one language and one target application at a time…
The tool
To solve my lack of Indian language abilities, I wrote a tool. This was a single screen application that had a matrix of the 256 characters available in the selected font. At the bottom there were two edit controls. One in english, and another in the font selected. This was essentially a finite state machine. For example…
Haan is a hindi word which is writen: हां (isn’t unicode cool…this entire combination is now one character!!!!)
It has a combination of one consonant, one matra (accent) and a second half matra.
- When the user pressed “H” it mapped to one character ह
- when the user pressed “a” it said eh…still means the same character
- when the user pressed the second “a” it put out हा
- when the user pressed the “n” it deleted what ever was put and put the character combination that gave हां
So this tool allowed the creation of chains of characters and their related output. The output of this tool was a Keyboard Layout file (.KRL) that would be used by my application based on the language and keyboard selected.
For every keystroke, the application would evaluate if there was space pressed or a keystroke that went a different path it would flush the buffer. If at any time the user pressed backspace; it would backspace the number of characters that had been output so far. If there was no further keys in the combination, it would flush its memory and say to itself that ok the output the user wanted is done and it can start processing the next keystroke.
Writing this…realizing that brevity is hard. If you are still reading this (Thanks!)…you should email me. I could give you the long version of this.
I gave the customer the tool. I never had to understand a font, or a keyboard type. He happily put his team that knew language processing to work in generating keyboards.
Learnings
If you build a tool, likely the work you need to do will effectively be less. Avoiding biting the bullet and building the tool would have gone a really long path of frustration. Ok I didn’t finish in two months, but without the tool this would have been a long struggle.
C++, Multiple inheritance, operator overloading and streamable classes. Very cool for a good C++ programmer, not easy for somebody else to understand. Well maybe the structure of all this was hard to understand for other developers that my customer put on extending my application.
This damn application sold for over 10 years. This customer is a good friend, and he always said how the application just continued to work…through versions of windows, NT, XP, 2000…the application won a lot of awards for him.
The big learning (not sure if I have learned this yet)…don’t underestimate the value of what you are working on. If somebody thinks it is worth doing it likely is.
Samyeer Metrani 