Rendering engines and what do they do?

The rendering engine has a difficult job. It is tasked with properly displaying complex script text in Windows and any running applications, which is a job made much more difficult by the wide variety of scripts and languages supported on Windows. On versions of Windows prior to Windows 2000, many clues about the language/script came from the HKL ("handle to a keyboard layout", now known as an input locale), since the LOWORD of the HKL is a language ID. This usage has largely been deprecated on the newer versions of Windows, which use the infinitely more sophisticated Uniscribe (Microsoft's shaping engine technology) and its various engines that render text based on the writing system of the appropriate language. On downlevel platforms, however, you can still see a great deal of information being obtained by this value.

Figure : The relationship between a keyboard, the rendering engine and display in a complex script (Kannada, an Indic Script Language)

Fonts

What has diminished the importance of the HKL of a keyboard has been the increased selection of fonts available, as well as font linking (the borrowing of information from multiple fonts to obtain glyphs not in the current font), which was introduced in Windows 2000 and improved for Windows XP. Obviously for a keyboard to work well, it assumed that there will be at least one font somewhere on the machine to assist in displaying the inputted text, lest every character be replaced by a null glyph7.

IMEs -- when are they preferred?

An Input Method Editor (IME) is a program that allows computer users to enter complex characters and symbols, such as Japanese Kanji characters, by using a standard keyboard. It is a solution to the issue of ideographic languages having tens of thousands of characters, or more. IMEs allow different, alternate means of input for such cases. Attached to each IME is a keyboard layout. On Windows the convention has always been to attach it to the US English keyboard layout, although some third party IMEs might be attached to other keyboards. The reason that the US English keyboard is usually preferred is that non-Unicode applications using CJK languages would be relying on default system code pages that would not include the text for other languages. Using a US English keyboard simplifies matters. For more information on IMEs, see the Platform SDK

Dealing with code pages

Although Windows keyboards are exclusively Unicode, it is important to note that if a keyboard is used with a non-Unicode application, some effort should be made to support this application when possible by choosing characters that fit with the appropriate Windows code page (ACP). Obviously this is not always feasible, since some languages are only supported by Unicode on Windows (e.g., Armenian, Georgian, Hindi, etc.), and thus do not have a system code page.

Sorting out collation issues

For the most part, collation and keyboards do not have to interact. There is one major area where they can have an impact, and that is the fact that many keyboards (both ones from Microsoft and those provided by third parties) fail to have a consistent story in their use of composite versus pre-composed characters. This can require an extra normalization step if the input is going to be used in XML and other technologies that expect normalized data. Collation itself is handled well on Windows, with the proper equivalences between the composite and pre-composed forms being an important part of the sorting data kept by the OS9.