To explore this, Japan provides the perfect confluence of the most complex written script in the world, in the form of Chinese characters (Kanji), combined with one of the most technologically advanced societies in the world. The sad truth, however, is that Japanese and Chinese text on modern computers is in many ways an order of magnitude worse than English on the 8-bit computers of the 1970s. To start with, let’s look at some of the more complex characters in current use in Japanese. The first five are common characters taught in high school, the last two I picked randomly from the Japanese encoding standards for their complexity. (Rendered at 72-pixel x 72-pixel resolution).

Now, let’s jump right in and see how the same characters look in Windows Explorer when used as part of a filename (Japanese Windows XP under default settings, blown up 6x for comparison).

Clearly, the 12×12 pixel character cell size of the default font is nowhere near sufficient. It makes the fonts on 1970’s 8-bit computers look positively futuristic. If you’re wondering about other operating systems, just remember that Mac and Unix monitors have the same dot pitches as PC monitors. Before we can really understand what this means, let’s take a look at the how Japanese handle their own script when freed of the limitations imposed by western-based design decisions.

Native Choice

First, we need to establish a foundation for comparing Japanese and Latin characters. The following shows a side-by-side comparison of the on-paper printed text in the novels Onmorakinokizu (陰摩羅鬼の瑕) by Kyogoku Natsuhiko and The Diamond Age by Neal Stephenson. These are both long, well-written, intricately plotted novels aimed at adult audiences. (As an extra data point, I have a couple of Chinese novels that use pretty much the same font sizes as Japanese novels).

It is interesting to note that the font sizes are almost identical vertically, and roughly 2:1 horizontally. That is, most of the extra detail needed for Japanese characters is realized by creating finer detail within the characters, not by extending the characters outwards. An interesting example of how this affected technological development comes from the dot matrix printers that were popular in the late 70s and throughout the 80s.

9-Pin Versus 24-Pin

Anyone who owned a computer during the 1980s would know that there were basically 2 types of printers: 9-pin dot matrix and 24-pin dot matrix. In the west, 9-pin dot matrix printers were sold as the basic model while 24-pin printers were sold as offering more readable near-letter quality (NLQ) printing. It’s easy to see the reason for 9 pins; it’s the minimum that can produce readable English text:

What you might not know is that 24-pin dot matrix printers were not developed to print clearer English text, but were developed in Japan to print Kanji. The 72-dpi resolution of a 9-pin printer simply cannot print readable Japanese text. As the following blow-up of 24-pixel text shows, this resolution is just high enough to render these complex characters – making it the Japanese equivalent of the 8-bit days. (Because I’ve used a Windows font to capture the image, the characters are not as well defined as they would be from a Japanese printer or mobile phone of the same resolution).

Compared to 72-pixel font:

Japanese Standards from the 1980s

A second data point for what the Japanese considered to be the minimum resolution comes from the Japanese industrial standards from the 1980s. These define character bitmaps for 16×16 and 24×24 dot resolutions. These bitmap fonts needed to be defined as a standard so that complex kanji could be simplified in a standard way on lower resolution devices. While the 16-dot font is clearly incapable of handling the complex characters above, it is perfectly usable for more common characters, making it suitable for applications that do not necessarily need to recreate every character. Interestingly, Japanese computers from the 1980s used 24×24 dot fonts that put modern operating systems to shame.

A More Modern Example: Mobile Phones

One area of technology where the Japanese are still on the cutting edge is in mobile phones (English specs of one of this year’s models). While most foreign manufacturers have caught up with the 32-bit processors Japan introduced in the 1990s to handle Kanji text input, the west is still lagging behind in terms of screen resolution. As an example, it is actually difficult to find phones in Japan that have screen resolutions under 300dpi. My current phone (the Sharp 910SH), which was released in 2006, has a 2.4-inch full VGA (640×480) screen at 330dpi. For comparison, this year’s Apple iPhone (3.5-inch screen), Google Android (3.2-inch screen), and most other western smart phones offer the lower half-VGA (480×320) resolution, putting them in the 160-180 dpi range. When contrasted with 96dpi computer monitors, the difference is even more dramatic. Just to make the point, here is the default email list font size of the mobile phone (40×40 pixels) compared to the default in Thunderbird (12×12 pixels), which is also the same as Outlook.

*Disclaimer: The screen shot is actually of the menu, which uses the same font size, because I didn’t want to show my person emails.

As a professional translator who has spent 8+ hours everyday reading Japanese text on a computer monitor for many years, I can tell you that reading text on a Japanese phone is a pleasure by comparison. The fiddliness of a small screen that can only display a small amount of text at a time is more than outweighed by the clarity of the text. It’s like stepping from the stone age into the 21st century.

Computer Monitors

As I mentioned earlier, the majority of computer monitors have DPIs at around the 100 mark. So why haven’t the Japanese created high DPI monitors to make Japanese easier to read on computer screens? One explanation could be the tradeoff between the expense of a higher DPI monitor versus the benefit obtained from the clearer text. However, this cost factor was never a stumbling block for 24-pin printers, nor for Japanese computers offering VGA resolutions as standard five years earlier than in the west, nor for the high resolution mobile phone screens used today, nor for the myriad of other products in Japan that are more expensive because they are made to handle Japanese text more cleanly. In fact, NEC did begin producing a 15” laptop with a resolution of 2048×1536 (i.e. 170 dpi) in 2002, which at $4500 was more than double the $2040 price tag of an equivalent model with a regular 1024×768 screen. This price dropped to $3500 in 2005, with the models subsequently replaced by widescreen models at the much lower 135dpi mark (the current model has a 16” screen with a 1920×1080 resolution starting at $1350).

Although this large price difference is certainly a factor, I don’t think it is the main reason. Because LCD monitor prices are tightly linked to production volumes, the prices of high DPI monitors would come down if there were enough demand (again, this is exactly the same situation as 24-pin printers, etc.). However, if a problem aside from price were to act as a deterrent to buying higher resolutions panels, then the panels would never become popular and the prices would never drop. And the main deterrent in this case comes from the operating system and the programs running under it.

If we simply replace a 1024×768 monitor with a 2048×1536 monitor of the same size, everything on the screen is suddenly twice as small, not twice as highly detailed. Instead of gaining a more readable display, high DPI monitors actually deliver harder-to-read displays. Theoretically, in Windows at least, you should be able to change the DPI setting of your graphics card in Control Panel from the 96dpi standard to 192dpi to get the same physical size display but with much more clearly rendered fonts. Unfortunately, this does not work properly in Windows. Even worse, the problem is not in Windows itself (in which case it would be easily fixable), but in poorly written third party drivers and other programs. The problem arises when the outer containing window size does not scale with the DPI setting, while the content of the window does, making it impossible to access the all-important OK and Cancel buttons in the bottom right of the Window.

This is not just a problem for the Japanese. My dear old parents have worsening eyesight, and in an attempt to increase the size of the text on their 19” LCD monitor, they changed the resolution setting from the native 1280×1024 down to 1024×768 (and yes, it was extremely ugly, but it achieved the desired effect of making the text on the screen bigger). Of course, I couldn’t stand the ugliness of the resolution mismatch and went and changed the DPI setting to large fonts (120 dpi) and returned the monitor to its native resolution. But sure enough, the next time they tried printing, the print settings screen (provided by the printer driver) appeared with half the content expanded outside of the window, with no scroll bars and no resizable border.

I suspect that this is a common experience among people who have tried changing their DPI setting, and is undoubtedly one of the reasons why the DPI setting is buried so deeply within the computer settings. The reason this problem is so common is that Windows uses a mixture of units for creating windows and controls. Windows must be created by specifying the size in pixels, which do not scale. The programmer therefore has to perform a manual calculation by fetching the system DPI setting in order to determine the scaled window size in pixels. The controls within a window, however, are typically specified in twips or other inch-based units, and therefore automatically scale. (Even if the tool the programmer uses shows dimensions in pixels, these are often converted into twips internally to get the automatic scaling effect.)

In any event, the net result is that creating high DPI monitors for computers that can deliver high quality Japanese text is not really a technical problem that the Japanese can solve. Even at the operating system level, it is difficult to see how the problem can be solved when third-party application developers still tend to think of control/window sizes and positions in terms of fixed pixels instead of scalable units. So the Japanese are stuck with jagged text reminiscent of 8-bit computers, at least for the time being.

With the rise of China, which also requires high DPI for the Chinese language, it will be interesting to see if the western operating system makers can come up with a solution before someone in China embarks on creating a new operating system to deal with the problem. I guess that one solution would be to treat high DPI monitors as having a logical resolution a sub-multiple of the native resolution, and then offering access to the physical pixels only to the OS font-rendering routines and to applications that declare themselves aware of this ploy. That is, a 2048×1536 screen would appear to applications as having a resolution of 1024×768, with the font rendering treating the 2×2 pixel blocks that make up each logical pixel as sub-pixels in a similar way to current sub-pixel rendering technology. Unfortunately, it is difficult to imagine a hardware manufacturer producing such a high resolution display again given that Microsoft made no moves to implement such technology during the 6 years while NEC was manufacturing high DPI laptops (or perhaps this another casualty of the Vista train wreck). However, I still hold out hope that the computer monitors in the future will again become easier to read than my tiny little 2.4-inch mobile phone screen.

How it works

To understand how the typewriter works, let’s take a look at a more recent model (from Wikipedia – Click for a hi-res image):

The actual strikers that produce the type are all separate metal pieces, somewhat like movable type, arranged in a grid in the tray (1) beneath the typewriter.

A handle (2) on the typewriter is used select the character to type from the list (3) of characters shown at the front of the typewriter. This handle is directly connected to the tray, and moves the tray relative to the fixed striking mechanism within the typewriter.

On this particular model, there are two separate handles (4 and 5) for printing the character. One handle operates the mechanism that pulls the striker out of the tray and attaches it to the hammer, and the other handle is struck to propel the striker onto the ink ribbon, paper and platen. (I’m not sure which handle is which.)

The actual typing mechanism

The following diagrams from the patent of the original 1915 model show the original mechanism. This uses a single handle to pickup the striker and then type the character in one action. (Click to enlarge)

The part labeled number 13 on the right side is the striker handle, and connects all the way through to the roller (number 19) on the left side. As 13 is pushed down, 19 lifts up, pivoting the long bar (20) under the typewriter and pushing the striker (32) out into the hammer.

As 13 is pushed further, 19 continues rising, pushing into part 24, which locks the striker into the hammer, and then strikes the hammer onto the platen.

One of the things that made the typewriter difficult to use was getting the strike lever force correct. If struck with even just regular force, characters such as decimal points or punctuation would pierce the ribbon and paper, becoming stuck in the rubber platen. On the other hand, very complex characters (such as 曇 or 驚) required striking with additional force to compensate for the large surface area of the typeface. This combined with the huge number of characters (which makes hunt and peck typing on a QWERTY keyboard seem trivial) meant that only experienced operators could use these typewriters.

Various advancements

In this 1928 model, a tractor-like mechanism is used in the character selection method. The dial at the front-left scrolled through the characters much like the caterpillar tread on a bulldozer. The price of this model was 190 yen, equivalent to approx. $US6000 in modern currency. (Note: Remaining photos reproduced with permission from 和文タイプライター　日本語タイプライター (Japanese only)).

Here, we can see how it was used.

The following 1942 model uses a felt roller to apply ink instead of an ink ribbon. The compact striking mechanism still retains much of the original 1915 design.

Another advance was the drum selection mechanism, as can be seen in this 1955 model by Toshiba.

The advertising boasts that it can handle both Japanese and English.

And finally, a Toshiba model from 1981. Here the strikers are attached to the selection strips by springs. Once a particular strip has been selected out of the drum, the hammer swings around from behind to force the striker into the ink ribbon and paper.

Eventually, models were developed that used electrical striking mechanisms. This required a return to the tray of strikers design. The following models are from the 1980s.

The beginning of the end for Kanji typewriters was heralded by the arrival of affordable digital word processors in 1984. By the mid 90s, personal computers also began to become popular in Japanese homes, and the age of kanji typewriters came to an end. Although most have been discarded or lie idle gathering dust in storage, you can still find second-hand models for sale. (Yahoo Auction Japan has some electric models.)

Although Japanese typewriters are no longer manufactured, the company founded by Kyoka Sugimoto to manufacture his invention, the Nippon Typewriter Company (日本タイプライター株式会社), continues to exist in the form of Canon Semiconductor Equipment.

I couldn’t find any English language books on the subject, but technophiles may be interested in this poster of a Japanese typewriter in action that I found on Amazon:

Related Posts

• Using an IME: Japanese text entry in modern computers
• Why Japan Didn’t Create the iPod: How the complexities of the Japanese language affected the Japanese digital culture




]]> http://blog.gatunka.com/2009/09/30/japanese-typewriters/feed/ 0 http://blog.gatunka.com/2009/09/30/japanese-typewriters/ http://feedproxy.google.com/~r/gatunka/HLcx/~3/IUfdDFJaS5c/ http://blog.gatunka.com/2009/09/20/ime-basics-for-developers/#comments Sun, 20 Sep 2009 10:39:04 +0000 Gatunka http://blog.gatunka.com/?p=20 The advent of Unicode has been a huge boon for developers, enabling applications to run on computers throughout the world with little or no effort on the part of the developer. However, there are several quirks in East Asian operating systems that can make applications developed in the west frustrating or difficult to use when installed on an East Asian computer. This post looks at the most basic issues that every application developer should know. Although I focus on Japanese and Windows in this post, many of the issues are equally applicable to Chinese and Korean, as well as other operating systems.

Input Method Editor (IME)

Because of the complex character sets of the East Asian languages, text needs to be entered through a multi-stage interactive process, which is handled by an OS component called the IME. (I’ve written an article detailing how the Japanese IME works as a bit of a background for people who are interested). Although the OS does it’s best to conceal the operation of the IME from the running applications, the fact that the IME needs to intercept keystrokes and display it’s own UI to the user can create problems for some applications (including web applications) in some situations. Beginning with Windows 98/2000, a system module called the Input Method Manager (imm32.dll) was introduced that offers a common interface that can be used to resolve many IME-related problems.

Disabling the Entire IME

For many games and other applications that do not use text input, the IME is a liability. First, let’s take a look at a screenshot from my favorite third-person shooter, Dead Space (click the image to enlarge):



The text across the top of the screen is the intermediate composition string that appears because the IME is performing romaji-kana conversion on the keyboard input that is controlling the player character. What the screenshot fails to capture is the annoying flickering as the IME and game continually compete to redraw the same section of the screen. It’s a bit like one of those gyrating banner ads that claim that you’re the winning millionth visitor.

Why does this happen? This is the result of an IME feature called the floating conversion window. Although the IME normally performs conversion in-place in the textbox or other control that has the keyboard focus, if the control that has the focus does not have a text input area (or there are no controls), the IME instead displays the floating conversion window temporarily to handle character conversion. A great example of how this feature is intended to work can be seen in Windows Explorer, where you can jump directly to the first file or folder starting with a particular letter by pressing that key. The floating conversion window offers similar functionality to East Asian users.

In applications that are not IME aware, IME activation is fully controlled by the user. In a game, this means that the IME activates if the user bumps any of the IME keys on the keyboard. In something like a first person shooter, it’s very easy to bump one of these when the action suddenly steps up a notch, which is exactly the worst moment to have the screen suddenly filling up with garbage. The problem is also exacerbated by the layout of the Japanese keyboard:



The keys highlighted in red are IME related, and turn on the IME if pressed. The key highlighted in green is actually the space bar, although ever since Microsoft managed to con manufacturers into adding the two Windows logo keys to the standard 109 key Japanese keyboard, it has become more like a space key. As a curiosity, this particular keyboard still employs a wire under the space bar despite the space bar actually being narrower than the shift key:



Solution

The solution to this problem is quite simple. Disable all IME functionality in your application. On Windows 98/2000 and later, this is handled through the appropriately named ImmDisableIME function, which has to be called before your application creates any windows. Because this function is only available if East Asian support is installed, we end up with something like this:

typedef BOOL (WINAPI *pfnImmDisableIME)(DWORD);
void DisableIME() {
    HMODULE hImm32;
    pfnImmDisableIME pImmDisableIME;

    hImm32 = LoadLibrary(“imm32.dll”);
    if (NULL == hImm32) return; // No East Asian support
    pImmDisableIME = (pfnImmDisableIME) GetProcAddress(hImm32, “ImmDisableIME”);
    if (NULL == pImmDisableIME)
    {
        FreeLibrary(hImm32);
        return;
    }
    pImmDisableIME(-1); // -1 means disable IME in all threads of current process
    FreeLibrary(hImm32);
}

I tested for this bug in my entire game collection, with the result that Morrowind, Fallout 3, Assassin’s Creed, and Dead Space all failed. Only Half-Life 2 correctly disables the IME. It is important to note that this measure is not limited to games. Any app that can only handle 7-bit ASCII input should disable the IME. An example of an app that handles this correctly is the calculator app that comes with Windows.

IME Contexts

One of the key things to note about the above example is that disabling the IME in your own process does not disable the IME in other processes. The reason for this is that Windows creates something called an IME Context for each new process that is created, and it is the IME Context that maintains the IME settings that are used when the corresponding app is active. As an example, imagine a Japanese developer who is running Visual Studio and Thunderbird. They turn the IME off in Visual Studio because code is written in 7-bit ASCII, but they turn the IME on in Thunderbird so that they can write their email in Japanese. Because separate IME Contexts were allocated to both Visual Studio and Thunderbird when they were launched, the IME is able to automatically turn Japanese input on or off as the user switches between the two applications.

Most developers do not need to handle IME Contexts explicitly because a default IME Context is automatically allocated to each process by Windows. However, the exception occurs when a single process opens multiple windows that operate as separate entities. Probably the best example of this is the web browser, where individual windows or tabs can be running completely independent tasks. Windows users are used to the IME Context paradigm (even if they are not consciously aware of it), so you really need to respect this system if you are developing for Windows. The latest versions of Firefox (3.5.3), Chrome (3.0.195.21), and Opera (10.00) all get this wrong. IE6, 7, and 8 all work correctly. This is one of the reasons why Firefox, Chrome and Opera have such poor adoption rates in Asia. (I found this interesting article about browser share in China)

Solution

The main API calls are:

HIMC ImmCreateContext(void); Create a new HIMC for each new window.
HIMC ImmAssociateContext(HWND hWnd, HIMC hIMC); Call this on every control you create in each new window.
BOOL ImmDestroyContext(HIMC hIMC); - Destroy the context when you are done

Implementation is simple. For each window or tab, define an HIMC variable to store the context handle. Upon creating each window or tab, call ImmCreateContext to allocate a new context. Every time you create a new control, call ImmAssociateContext to associate the control with the context for that window or tab. Finally, after you have closed the window or tab, call ImmDestroyContext to delete the context again. It is important, however, that all of the controls associated with the context are destroyed before the context is destroyed.

One of the important things to note about the IME Context concept is that it is a Windows-only thing. Unix and Macintosh treat the IME state as a system-wide property, kind of like part of the keyboard. However, the simple fact that there is a difference creates problems for OS-agnostic web apps, as we will see below.

Disabling the IME in Individual Controls

Even in Unicode-aware applications that have been designed to accept any kind of text input, there are still situations where the IME should be disabled for certain controls. The most obvious example of this is the password field. Since the IME operates interactively and relies on prompting the user to select from candidate lists, it would be impossible to conceal the input characters. Of course, password fields are a well-known case, and so the OS or web browser automatically disables the IME for password controls.

However, there are many more subtle examples, such as alphanumeric text fields or custom controls that accept the focus but do not accept text. Let’s take a numeric field as an example to see how things work when the IME is enabled. Suppose a Japanese user tabs from a “name” input field where they have just entered their name (and so the IME is in Kanji mode) to an “age” input field asking for their age. Typing in 34 gives them the following candidate list:



Now there are several problems. In this example, the first candidate is the number in full-width digits (U+FF10 to U+FF19). This is what the user will most probably select, in which case you have to perform full-width to half-width conversion on the input text. (This also applies to general alphanumeric input since there are full-width characters for the entire ASCII 7-bit range). The second problem arises if you are trying to use keydown/keypress events to filter out non-numeric key presses. When the IME is active, keydown/keypress/keyup events follow a different model than normal (which I will go into later), which makes most attempts to filter keyboard input disastrous. (Google really sucked at this when they first attempted to enter the Japanese market). The final problem is one of usability. If a field only accepts numbers, you should save your users the hassle of having to go through the conversion process. (For completeness, the last four candidates in the above list are a bit like writing out “thirty four” in English, so you don’t generally need to worry about them).

Solution

In HTML, Microsoft introduced the “ime-mode” style for text input fields in IE5 to allow web apps some control over the IME mode. However, the other browser makers have opposed introducing this into the standard (I suspect this is largely because it is really a Windows-only concept). Firefox introduced the style in Firefox 3, but because of the problems it has on the Mac, you really want to specify different values for Mac and Windows users. IE8 added an alias “-ms-ime-mode”. (Personally, I think the best case would be for the other browser makers to adopt “-ms-ime-mode” as something that only has an effect on Windows platform browsers.) The key values of ime-mode are:

disabled This style disables the IME only for this control. When the user clicks on or navigates to another control, the IME returns to the same state as it was in before entering the control. This is the best mode to use for number-only or alphanumeric-only fields. Some notes: 1) Because the user cannot override this setting, make sure you only use it on fields that will never allow CJK characters. 2) Users can still cut/paste exotic characters into the field. 3) This setting doesn’t work properly on Mac or Linux systems because there is no OS support for this kind of functionality.

inactive This setting turns the IME off, but allows the user to turn it on again if they wish. Although you should avoid using this setting on Windows (unless you really know what you are doing), on the Mac you should use “inactive” as a replacement for the buggy “disabled” style, particularly because this is more inline with the Mac way of handling Japanese input.

For native Windows applications, the easiest way to control the IME is to use the .NET or similar framework that offers an IMEMode property on controls. (Just set IMEMode=disabled on controls that required only 7-bit ASCII input). Alternatively, you can disable the IME for a single control using the following Win32 API function:

HIMC ImmAssociateContext(HWND hWnd, HIMC hIMC);

Simply specify the HWND to the control in the first parameter, and NULL in the second parameter (NULL disables the IME for that control). As with the ImmDisableIME function, you need to make sure that the imm32.dll module exists before calling the function, or you may run into problems on systems without East Asian support.

Windows Events

Because the IME context is maintained separately within each individual process, the system-wide language bar that displays the IME status needs to communicate with the IME part of your application to keep the language bar icons up to date. This is achieved through the named Windows messages. Named messages are messages in the range 0xC000 through to 0xFFFF. It is essential that you correctly call DispatchMessage on these messages as you receive them in your message loop, or the language bar will stop working.

For those who are interested, the Chinese, Japanese, and Taiwanese language bars are shown below:



Keydown/Keypress/Keyup

Since the IME is intercepting keystrokes to hold a conversation with the user, the keydown/keypress/keyup events take on a slightly new meaning. However, the processing that takes place depends on the particular control that you are using. The most important point to note is that you must not attempt to perform validation on text that is in the middle of conversion. Doing so leads to a terrible end user experience.

Win32 Edit Control

When the IME is actively intercepting keystrokes, it replaces the key value in the WM_KEYDOWN message with the value VK_PROCESSKEY (229) to indicate that a key was pressed, but has been processed by the IME. There is also no corresponding WM_CHAR message (which corresponds to the KeyPress event). However, the WM_KEYUP message is sent with the key code of the correct key. This process is repeated as the user interacts with the IME to select the text that they want to input. When they finally accept the text, your application receives a WM_CHAR message for each character in the selected text. You can look for WM_KEYUP messages where the keycode is 13 (the enter key) to indicate that the user has finished conversion.

RichTextbox

The Win32 Edit control and the NET Framework TextBox control actually don’t interoperate with the IME very nicely, so if you can you should use the RickTextbox control instead. Although the KeyUp and KeyDown events operate the same as in the Edit box, there is no WM_CHAR (KeyPress) message upon the user accepting the input. Instead, the TextChanged event is called when candidate text is accepted.

HTML INPUT TEXT

Internet Explorer and Chrome send 229 for KeyDown and the actual keycode for KeyUp on each key press. There are no KeyPress events. You can therefore trigger on-the-fly validation code on receiving any KeyPress event (non-IME input), and for KeyUp events where the key code is 13 (IME input).

Firefox sends a single 229 key code on KeyDown, and a KeyPress with value 0 when the user first starts interacting with the IME. A final KeyUp event is then sent once the user has finished interacting with the IME. This means that you can use the KeyUp event as a trigger to validate user input regardless of the IME state.

Opera does not send any KeyDown/KeyPress/KeyUp events at all for any text entered via an IME.

CAPS LOCK

The final issue, which is primarily related to games, is the caps lock key. Caps lock on the Japanese keyboard is toggled by holding down shift while tapping the caps lock key. Simply tapping the caps lock key does not toggle the caps lock state. This is an issue in both Morrowind and Fallout 3, which use the caps lock key to toggle running on and off. Unfortunately, both of these games seem to use a mixed bag of methods to test for caps lock, and it’s always a lucky dip to see what key combination will toggle running on or off. Since this is tied to the Japanese keyboard, and not the IME itself, you need to call GetKeyboardLayout and check for a Japanese keyboard, and then maintain your toggle state based on KeyDown events if you want to use caps lock in a game.

Summary

Hopefully this collection of tips will give you some insight into the difficulties of internationalization. If anyone with Mac experience has anything to add, I would love to hear about it in the comments.




]]> http://blog.gatunka.com/2009/09/20/ime-basics-for-developers/feed/ 3 http://blog.gatunka.com/2009/09/20/ime-basics-for-developers/ http://feedproxy.google.com/~r/gatunka/HLcx/~3/uI0N6u8uqSw/ http://blog.gatunka.com/2009/09/12/using-a-japanese-ime/#comments Sat, 12 Sep 2009 12:24:54 +0000 Gatunka http://blog.gatunka.com/2009/09/12/using-a-japanese-ime/ One of the questions that I see come up a lot is about how Japanese text can be written using a computer, mobile phone, or other electronic device. Since it is a fairly important process for understanding the development of technology in Japan, I thought I would detail the process here.

Basics – Types of Japanese Characters

Japanese consists of 3 separate writing systems: Katakana and hiragana, which are phonetic alphabets (collectively referred to as kana) that each consist of roughly 50 base characters (and which are phonetically equivalent); and Kanji, which is a pictographic writing system originating from China of which approximately 6,355 characters are defined in the Japanese Industrial Standards (JIS X 0208).

Traditionally, all Japanese characters are written in a square grid of non-proportional, 1:1 aspect ratio characters (school notebooks for practicing writing use a square grid). By comparison, 7-bit ASCII characters (i.e. English letters and numbers) are generally rectangular with a roughly 1:2 aspect ratio. In fixed-width computer systems, it is therefore convenient to render Japanese characters in the same area as two consecutive English characters. From a Japanese perspective, the square Japanese characters are the normal characters and are therefore called full-width characters, while English characters that only take up half of that width are called half-width characters. However, due to all kinds of technical limitations, early computer systems actually used a half-width version of the katakana writing system that was developed specifically for computers, with the earliest Japanese encoding standard JIS X 0201 consisting only of half-width alphanumerics (i.e. 7-bit ASCII) and half-width katakana characters. Full-width katakana characters were only added later, along with full-width hiragana and kanji, as multi-byte encodings were developed. The JIS standards also define various Greek, Cyrillic and symbol characters in the standard Japanese encodings, which are displayed as full-width characters in Japanese fonts. These character sets are summarized by the following screen shot (taken from the Windows XP command prompt).



Character Conversion

Because of the large number of characters in languages such as Japanese and Chinese (Japanese education standards define around 2000 characters for high school students and JIS standards define more than 6000 characters), characters cannot be entered directly, but instead need to be entered via some kind of conversion process. Modern computers and electronic equipment therefore employ a system whereby words are entered phonetically, and then converted into kanji through an interactive conversion process. I’m going to describe this process by using the Japanese IME included in Microsoft Windows XP.

Japanese Input Method Editor (IME)

In Windows, input method editor is a general term used by Microsoft for their abstraction of multi-stage text entry systems (specifically for Japanese, Chinese and Korean). When the IME is disabled, the keyboard functions exactly the same as a regular US English keyboard (except for the slightly different key layout), with keydown, keypress, and keyup events sent directly to the control that has the focus, as per usual. When the IME is activate, however, key events are intercepted by the IME, which then interacts with the user in a seamless way to provide character conversion according to the conversion mode selected by the user. In the Japanese IME, the most common conversion mode is a multi-stage conversion process employing romaji-kana conversion in the first stage and kana-kanji conversion in the second stage.

In the following sections, I’m going to take 特急電車 (which means “express train”) as an example to examine the multi-stage conversion from “tokkyuudennsha” to “とっきゅうでんしゃ”, and then to “特急電車”.

Romaji-kana Conversion

Romaji-kana conversion is the process of converting Roman alphabetic key presses into Japanese phonetic characters. This is a relatively straightforward process in which the IME looks up Romaji character sequences in a simple table, and replaces sequences with the corresponding kana as soon as they are matched. There are individual conversion codes for each character, such as “si” -> “し”, “xya” -> “ゃ”, sequences that convert into multiple characters, such as “sya” -> “しゃ”, and alternate sequences such as “sha” -> “しゃ”. The default conversion table contains around 300 sequences. For our example, typing “tokkyuudennsha” produces:

t	ｔ
to	と
tok	とｋ
tokk	とｋｋ
tokky	とｋｋｙ
tokkyu	とっきゅ
tokkyuu	とっきゅう
tokkyuud	とっきゅうｄ
tokkyuude	とっきゅうで
tokkyuuden	とっきゅうでｎ
tokkyuudenn	とっきゅうでん
tokkyuudenns	とっきゅうでんｓ
tokkyuudennsh	とっきゅうでんｓh
tokkyuudennsha	とっきゅうでんしゃ

Note that the underline shown above actually appears on the screen during input, and serves to highlight the text that is currently undergoing conversion. For example, if we were typing this in the middle of a sentence, it would look something like this:



This underlined section is known as the composition string. This is an important concept when dealing with the IME, and warrants a more detailed explanation.

The composition string is the only part of the text in a control to which the IME has access. Once conversion begins, the cursor is trapped within the composition string until the conversion is complete (when the current string is accepted by the user hitting enter or the control losing focus) or is cancelled (by the user deleting all of the characters in the conversion string or hitting escape). An important aspect of the composition string is that the user is able to cursor around inside the string to correct typos or make other changes before proceeding to the second part of the conversion, kana-kanji conversion.

Kana-Kanji Conversion

Now that the target word is spelled out phonetically in the composition string, the next step is to enter the kana-kanji stage of the process. This is achieved by simply hitting the space bar. What actually goes on inside the IME at this point is actually quite sophisticated and largely beyond the scope of this article. However, the basics are that the IME analyzes the grammar of our text, attempts to identify the separate words in the text (a process known as segmentation that is necessary because there are no spaces in Japanese), and then perform a context-sensitive look up of each of those words in its built-in dictionaries. The IME then picks the best matches for each segment, and displays them like so:



In this case, we’ve used such a common phrase that the IME has no trouble identifying the segmentation and the best candidates for each word. At this point, the IME has still not accepted our input, but is waiting for our approval of the suggested candidate characters. At this point we can either hit enter to accept, escape to return to the kana composition string, look through the other candidates that the IME has dug out of its dictionary and choose alternatives if necessary, or even adjust the location of the break between the two words.

An important point to note is that the selection of the best candidate is influenced by the context, which we can demonstrate by looking at the other candidates. The heavier underline under the first segment indicates that it is selected, and so hitting the space bar (or the up/down arrows or 変換 key) will open up a list showing the other candidates for tokkyuu, like so:



Topping the list is 特急 (express), followed by 特級 (premium) and 特休 (special holiday), and then the two different phonetic alphabet versions. However, the IME knew that 特急 (express) was a better match for 電車 (train) than the other options. Grammar and past selections are also taken into account, which gives the IME the complexity of a grammar checker, contextual dictionary, and adaptive predictive text engine all rolled into one.

Consequences

The process as described above may sound straightforward from the perspective of the user, but there are actually a great number of subtleties that arise during real-world processing.

1) Correcting typing errors is a costly operation. For example, mistakenly typing “tio” instead of “to” during romaji-kanji conversion results in “ちお” instead of “と”, and the corrective operation of deleting “i” has grown into deleting everything and starting again. Automatic romaji-kanji conversion thereby acts to amplify the labor required to correct typing errors. The labor of typing a few extra keystrokes, however, is almost insignificant compared to the cognitive load that errors create, which arises because of dealing with three different representations of the same text.

In our example, the target text 特急電車 (which relates to the actual thing we are thinking about) contains 4 characters, our intermediate text とっきゅうでんしゃ (which is tied to the pronunciation that we are forced to think about while typing) contains 9 characters, and the text we actually enter on the keyboard tokkyuudennsha (which is tied to our actual motor function) contains 14 characters. So, when a single character typo produces a result like this: と kk ッ 雄電社, it can be difficult to mentally process what went wrong.

2) One consequence of the IME operating totally seamlessly without cooperation from applications is that the IME can only maintain the state of a single composition string at a time. This means that if a control loses focus while conversion is in progress, the semi-converted string is accepted as-is into the control, and all relevant state information is lost. Unfortunately, this also means that windows that steal focus, even for a split second, create a headache for any text that is in mid-conversion at the moment when the focus is stolen. (And it’s amazing how many apps actually do steal focus for just a split second.)

3) The ability to type a word relies on that word being in the IME’s dictionary. This becomes a minor problem for scientific and field-specific terminology, and a major problem for people’s names. The general solution is to try and think of other more common words that use each of the same kanji, and then delete any excess kanji.

Direct Kana Input

One immediate question that arises when we consider the complexities of text entry described above is why not simply use a kana keyboard containing the native Japanese phonetic characters to simplify the process? In fact, the JIS standard keyboard (Wikipedia has a nice picture) does define the key layout for direct kana entry, and the Japanese IME fully supports this keyboard layout. However, as a poll cited on the Japanese Wikipedia states, around 84% of Japanese people use Romaji input compared to only around 8% for direct kana input. Why is this?

The first thing to note is that back in the early 80s when computers were starting to become widespread, the complexity of the writing system led to a boom in dedicated word processing devices that could handle text entry far better than the personal computers of the time, and these dedicated word processors were almost 100% focused on direct kana entry. PCs, on the other hand, were almost exclusively used by enthusiasts who were interested in things like programming, or in businesses that used alphanumeric-oriented programs such as spreadsheets.

The other thing to note is that the Japanese phonetic alphabet consists of 82 separate kana (when accented characters are included). In order to allow touch-typing, the Japanese word-processors employed systems such as OASYS (親指シフト in Japanese, which literally means “thumb shift”, referring to the two additional thumb-actuated shift keys) which utilized complex shifting systems so that all of the kana could be squeezed into a more touch-typing friendly layout.

While these kinds of systems were very popular at the time – with OASYS keyboards still available today – when PCs finally caught up to dedicated word processors in the mid 90s the computer keyboard layout had already been standardized around the JIS layout. The JIS layout is able to fit the large number (82) of kana onto a regular US-like keyboard without additional shift keys by separating out the two accent marks into modifier characters, giving 56 kana plus 2 accent keys, which are scattered around the keyboard in one of the most touch-typing unfriendly layouts imaginable (11 regular kana keys assigned to the right pinky, including the highly-frequently used accent characters). This scheme also offers better compatibility with the JIS X 0201 encoding where accent marks are encoded as separate characters.

In short, users of modern computers need to learn the QWERTY layout anyway due to the prevalence of ASCII-only characters in things like usernames, passwords, programming languages, spreadsheets, etc., and there is no real incentive to learn the touch-typing unfriendly direct kana layout, regardless of the burden of romaji-kana conversion. The touch-typing friendly OASYS layout is also rarely used, somewhat like the Japanese version of the Dvorak keyboard.

Mobile Phones

In mobile phones, however, the scales tip the other way. Japanese kana are taught from elementary school as a 5 x 10 grid as follows:

あ (A)	か (KA)	さ (SA)	た (TA)	な (NA)	は (HA)	ま (MA)	や (YA)	ら (RA)	わ (WA)
い (I)	き (KI)	し (SI)	ち (TI)	に (NI)	ひ (HI)	み (MI)		り (RI)
う (U)	く (KU)	す (SU)	つ (TU)	ぬ (NU)	ふ (HU)	む (MU)	ゆ (YU)	る (RU)
え (E)	け (KE)	せ (SE)	て (TE)	ね (NE)	へ (HE)	め (ME)		れ (RE)
お (O)	こ (KO)	そ (SO)	と (TO)	の (NO)	ほ (HO)	も (MO)	よ (YO)	ろ (RO)	を (WO)

This makes direct kana input by assigning the numbers 1 through to 0 to each of the above columns a very intuitive system for Japanese speakers. When this is combined with the adaptive predictive kana-kanji conversion systems employed by Japanese mobile phone manufacturers (which offer a lot of features that are not available in the Windows IME), text entry on a mobile phone is almost comparable in speed to using a computer and full keyboard.

Comments Below…




]]> http://blog.gatunka.com/2009/09/12/using-a-japanese-ime/feed/ 2 http://blog.gatunka.com/2009/09/12/using-a-japanese-ime/ http://feedproxy.google.com/~r/gatunka/HLcx/~3/4mc47M4hSzs/ http://blog.gatunka.com/2008/05/05/why-japan-didnt-create-the-ipod/#comments Mon, 05 May 2008 02:47:46 +0000 Gatunka http://blog.localhost/2008/05/05/why-japan-didnt-create-the-ipod/ At the end of last year, there were a couple of articles about Japan’s failure to be a giant in the new digital age (Newsweek on Why Apple Isn’t Japanese, and there were some interesting comments in a blog response Japan is no longer a leader in Electronics). Unfortunately, the Newsweek article completely ignores the technical background which forms the basis for Japan’s current position in the digital age. In this post, I want to explore this technical background and show why business-types such as CEO’s and Newsweek readers really do need to understand the underlying technical issues of a problem.

8-bit Computers

The real start of the digital gulf between Japan and the western world started back in the late 1970s and early 1980s when the first 8-bit home computers began to be released. One of the most important factors at this time was the complexity of the Japanese language. Put simply, an 8-bit computer with only 64k of memory simply does not have the capacity to edit Japanese. As an example, the first Japanese word processor to use the modern kana-kanji text entry system was the Toshiba JW-10. The JW-10 was a dedicated word processor with no other functionality. Released in February 1979, the JW-10 weighed 220kg and had a price tag of 6,300,000 yen (around $30,000). Here in the west, we could get similar capabilities with a $300 Commodore Vic-20 connected to a cheap 8-pin dot matrix printer. (In fact, you could argue that the Vic-20 offered better functionality). Before we continue with the history, let’s look at the technical details. (Skip this section if you don’t care).

Technical Details

There are two separate technical barriers for the Japanese language. The first is displaying the characters. For anyone who hasn’t used an Apple II, Commodore-64 or other 8-bit system, here is a screen-shot showing the cutting-edge 8×8 pixel fonts of 1982. For comparison, let’s look at a few common Japanese characters (these are ranked as the 35th, 64th, and 104th most commonly used characters, respectively):

議　選　調

It should be pretty clear that the Japanese are not getting away with 8×8 pixel characters on a 320×200 pixel screen. The NEC PC-9801 was one of the leading Japanese personal computers of the time, and offered a 640×400 display with 16×20 pixel characters. For all 6802 characters defined in the 1978 Japanese Industrial Standards (JIS C 6226-1978), we get 6802×20x16 bits = 265 kBytes of font data. (Compared to a mere 2 kBytes for 256 8×8 ASCII characters).

The second problem is the text entry process – whereby the 100 or so keys on the keyboard are used to select from the 6000 or so characters. In the days of telegraph, this was done using a 94×94 cell table written on a sheet of paper with all of the characters listed on it. The “kuten” codes were the coordinates of the characters in this table. The modern kana-kanji conversion approach involves entering characters phonetically, and converting based on dictionaries. The size of the dictionaries is directly related to how easy it is to enter text. For comparison, the conversion dictionaries on Windows XP are 36 MB. An 8-bit system is pretty much limited to the size of a disk.

Japan 1983

Back to 1983, and we can see the choices available to the Japanese consumer.

1) The Nintendo Entertainment System released 1983. 14400 yen (around $70). No keyboard. Japanese text is displayed as graphics stored in the game (only the font data for displayed characters need be included).

2) 8-bit computer with “katakana” Japanese characters. (Examples include the NEC PC-8001 series. The Mark II was released in 1983 was 123,000 yen (around $600)). Katakana is a Japanese phonetic alphabet only requiring 50 characters. Before the advent of computers, katakana was never used to write entire sentences. Computers that only offered katakana had no practical value to home users over the NES, except for computer enthusiasts. Although these computers are similar to the Commodore 64/Apple II in terms of technical capabilities, they are crippled in terms of functionality from the viewpoint of home consumers.

3) 16-bit computers with special hardware for displaying kanji. The NEC PC-9801 was released in 1982 and became the number one selling home computer in Japan. The first model retailed for around 300,000 yen ($1500). The ROM chips containing the kanji font data were extra (50,000 yen – $250), and only support Level 1 characters (around half of the number in the Japanese standards). Kanji input was by kuten code (i.e. you had to type in the hexadecimal number of the characters you wanted to display). The PC-9801 featured a standard resolution of 640×400, which would not be surpassed as a standard in the west until the release of VGA and Macintosh II in 1987.

4) Specialist word processing systems (i.e. the Japanese equivalent of an electronic typewriter). The JW-1 (grandchild of the JW-10 discussed in the intro) was released in 1983 for 500,000 yen (around $2,500).

So, 6 years after the Apple II first brought computers into homes in America, the Japanese still had no reason to buy a home computer unless they wanted to type by entering hexadecimal codes. Whereas computer manufacturers in the west could advertise under the premise of Why Buy Just a Video Game?, Japanese households were faced with a choice between $1500 for a world of hexadecimal nightmare compared to $70 for the world of Mario Bros.

Appliances vs General Computers

Throughout the 1980s, western countries saw explosive growth in general-purpose computing platforms, with even games manufacturer Atari switching from a console to a general-purpose computer (Atari ST). Japan, on the other hand, was deeply immersed in an appliance mentality of computers. Companies like Nintendo, Sega, and Sony dominated the games console market. And while American developers worked on desktop operating systems such as Windows and MacOS for general purpose computers, Japanese engineers were working on embedded operating systems such as TRON and T-Kernel for running embedded devices such as fax machines and car engine control systems. (As an aside, although the name TRON is not well-known among consumers, the number of devices running TRON is on par with the install-base of Windows).

The iPod

By the time the iPod was released in 2001, Japanese mobile phones were already e-mail and internet capable. Although personal computer numbers had grown, more Japanese were accessing the Internet through their mobile phone than through a computer, and Japanese manufacturers were locked into the appliance mindset. As an example, consider the Sharp J-SH51 mobile phone released in 2002 which also offered a built-in MP3 player and digital camera. Despite being one of the most advanced mobile phones in the world at the time, the J-SH51 could not be connected to a computer. So how did you get music onto your phone? Well, you took an analog audio cable and plugged it into the aux. out plug on your CD player.

In the west, the home computer was already being viewed as the central hub of the digital age. It was obvious that devices such as digital cameras and MP3 players would need connectivity with the home computer, and that people would transfer pictures from the digital camera to their computer, or would use their computer as the central storage for music files to upload to their iPod or other music player as needed. The iPod, for example, requires a home computer. Without one, there is no way to get music on or off the device.

In Japan, however, things were different. Perhaps the easiest way to understand the Japanese market at the time is to imagine that home computers did not exist. From this perspective, the direction that the Japanese electronics industry took makes perfect sense. Everything needed to be designed as stand-alone appliance. The basis for much of this was the digital memory card, particularly the SD card. Digital cameras and camera-phones stored everything on a memory stick, and offered DPOF configuration options for configuring printing options. Color printers went on sale offering SD card slots so that these photos could be printed without a computer in the middle. MP3 players took a similar turn, offering either analog cable connectivity or SD card slots for music transfers. New stereo systems also offered an additional SD card slot. The SD card was like the new cassette. Record stores even began offering machines that sold digital music directly stored on your SD card. 3G phone handsets were released in 2001, and Japanese telecoms envisioned a world where consumers would buy and download music directly onto their mobile phones. It all makes sense if nobody owns a home computer, and when the mobile phone is the dominant form of Internet connectivity.

The flip-side of all this support for stand-alone appliances that do not require a home computer is that the Japanese electronics manufacturers offered virtually no support at all for home computers. Many devices simply could not be connected to a PC. For those that could be connected, the support software was unfriendly and extremely primitive. Let’s take the SD card as an example. SD cards offered a ‘feature’ called SD Audio whereby music was stored protected by a DRM system. However, only one manufacturer ever produced USB card readers that actually supported this scheme. Even if you did manage to track down the lone card reader that supported SD Audio, you still can’t transfer music to your SD card. In fact, you now had to purchase a special version of RealPlayer (that’s right, you had to pay for free software).

Of course, this kind of situation wasn’t going to fly in the west, where everyone had a home computer. Even in the Japanese market, this wasn’t going to fly. By the year 2000, most of the technical difficulties facing computers in Japan in the 80s and 90s had been resolved, and home computers were becoming mainstream. Japanese consumers wanted PC connectivity from their appliances, and the iPod offered a well-designed, highly functional package. So Apple created the iPod, and Japanese electronics manufacturers were left to re-evaluate a new world where the home computer is the hub for digital media.

The Future

Japanese manufacturers are finally catching on and have started to offer PC connectivity. Most mobile phones now come with USB cables and software for transferring photos and music to and from a PC. While the latest music-capable phones still come with an SD card, support has been added for Apple’s MP4 format, and files can be transferred using a generic card reader. It’s difficult to say whether the misjudgment of the Japanese electronics companies was a one-off falter, or if it is the start of a trend. The Nintendo Wii is certainly a strong indicator that all is not lost, even if it is back on the Japanese strong ground of an appliance-oriented device.

Related Posts

• Japanese Typewriters: Mechanical typewriters capable of typing thousands of different characters
• Using an IME: Japanese text entry in modern computers




]]> http://blog.gatunka.com/2008/05/05/why-japan-didnt-create-the-ipod/feed/ 45 http://blog.gatunka.com/2008/05/05/why-japan-didnt-create-the-ipod/ http://feedproxy.google.com/~r/gatunka/HLcx/~3/hXakvhVW930/ http://blog.gatunka.com/2007/12/05/intelligent-lighting-a-definitive-way-to-resolve-the-issue-of-creation-vs-evolution/#comments Wed, 05 Dec 2007 07:33:29 +0000 Gatunka http://blog.gatunka.com/2007/12/05/intelligent-lighting-a-definitive-way-to-resolve-the-issue-of-creation-vs-evolution/ They say that God Intelligent Designer (Who Is Possibly An Alien) (IDWIPAA) works in mysterious ways. So it should come as no surprise that the key to answering the intelligent design vs. evolution debate appeared in a message board post on reddit (a website whose logo, incidentally, is an alien. Coincidence? I think not). At this point, I must give the user “psyne” (possibly his/her real name) credit for the ground-breaking idea of Intelligent Lighting (IL). Let me explain.

Introduction

Proponents of intelligent design argue that everything on Earth was created by an IDWIPAA. Yet, the complexity of biological organisms and the number of unanswered questions in the field of biology make it virtually impossible to prove that biological organisms were designed by IDWIPAA. In Science, whenever we come up against difficult problems of this nature, one approach is to look for simpler examples that are analogous to the original question, and Intelligent Lighting is the perfect parallel for this.

Theory

Consider the Sun and the Moon. The Sun: a big bright light that lights up your work environment while you are working, and the Moon: a small mood light for the more intimate night. The evidence is clear. Our Intelligent Designer (Who Is Possibly An Alien) is, in fact, an Interior Designer (Who Is Possibly An Alien). What other possible explanation could there be for the perfect correlation between interior work lighting and the Sun, and between night-time mood lighting and the Moon.

Discussion

I can hear the naysayers now. “Why would an IDWIPAA create a mood light that is sometimes left on during the day? If your IDWIPAA is so intelligent, surely the Moon would only appear at night.” The answer to this question also provides an opportunity for definitively proving the existence of IDWIPPA. You see, surely an IDWIPAA capable of creating the Sun/Moon lighting system would be advanced enough to create a remote control to turn them on and off. The obvious answer, therefore, is that IDWIPAA has misplaced the remote control, and we are now stuck with the system set in “timer” mode.

Proving IL – The Search for the Holy Remote Control

At this point, I need your help. Somewhere out there is a remote control for the Sun and Moon. This is a holy relic that will prove, once and for all, the existence of an Intelligent Designer. I therefore humbly ask you to assist me in the search for this relic. I am hereby offering the sum of $1million for anyone who can produce a remote controller capable of turning the Sun on/off, or of dimming the Moon (we all know that mood lights use a dimmer, that’s just interior design 101). I realize that anyone finding this relic may be tempted to sell it on eBay. It would probably fetch a good price. Please resist this temptation! Put the good of Science above your own greed.

Clues on the Location of the Holy Remote Control

My own personal research suggests that most remote controllers that have been misplaced often appear: (1) Under the cushions in the couch (65%); (2) Being chewed on by the dog (30%); or (3) Under the magazines on the lounge table (5%). Let’s examine these one by one. The location will therefore depend on the nature of IDWIPAA. If the IDWIPAA is the Flying Spaghetti Monster, for example, we could expect the remote control to turn up underneath the tomato-based sauce in pasta dishes. As another example, I expect that IDWIPAA wouldn’t keep such a trivial pet as a dog. However, creationism tells us that Tyrannosaurus Rex would have been an ideal pet, who may have confused the remote control for a coconut. Therefore, I would also like everyone to be on the lookout for Tyrannosaurus Rex feces. I know what a terrible job it is to sift through coconut-husk filled feces. But be strong. Remember, this is for science! Finally, under magazines on the lounge table. However, seeing as how our IDWIPAA is already intelligent, we wouldn’t expect IDWIPAA to read anything too heavy. Perhaps the remote control is under a stack of PlayAlien somewhere. Keep your eyes peeled.

Significance of the Holy Remote Control

One of the most significant aspects of the holy remote control is that it will reveal information about the IDWIPAA. For example, if the remote control is covered in sticky pasta sauce, we may be able to conclude that the Flying Spaghetti Monster is our intelligent designer. Similarly, if the controller is covered in short orange hair, the intelligent designer may be of the species ALF. On the other hand, if the controls for the Moon dimmer include up/down arrows, we may conclude that the reddit alien is the intelligent designer.

Conclusions

To summarize the theory of Intelligent Lighting: Any self-respecting IDWIPAA would require a strong primary light source for doing work, and a softer mood light for setting the mood during “down-time”. The Sun and the Moon are these light sources. The remote control for the Sun and Moon were lost sometime in the last 8000 years since IDWIPAA created them. The discovery of the remote control will prove, once and for all, the theory of Intelligent Lighting, and thereby the theory of Intelligent Design (and as a corollary, the theory of Interior Design). Furthermore, the state of the remote control may give us clues as to the nature of the IDWIPAA.

Wrap-up

As mentioned, I am offering $1million for proof of the remote control. If you are submitting evidence in the form of images, please note that any images containing pixels will be immediately disqualified as having been Photoshopped. Video evidence may be submitted to YouTube with links posted here.

dynh9w3cbk




]]> http://blog.gatunka.com/2007/12/05/intelligent-lighting-a-definitive-way-to-resolve-the-issue-of-creation-vs-evolution/feed/ 0 http://blog.gatunka.com/2007/12/05/intelligent-lighting-a-definitive-way-to-resolve-the-issue-of-creation-vs-evolution/