One of the biggest challenges in enabling the operating system for international character sets is the ability to select and display the right character or glyph. When editing a multilingual document, the user should not be expected to select a different font for each one of the scripts he or she wants to view because:
- The average user might not know which font is the most suitable choice.
- Simple applications such as Notepad.exe only allow one font for the whole document.
- This type of font selection would impose a big productivity overhead.
Therefore, in addition to the font substitution (also known as "font association") technique used since the early versions of Windows, new features–OpenType fonts, font fallback, and font linking–were introduced in Windows 2000 to solve these types of font–selection problems.
The Unicode–based OpenType font format has been developed jointly by Microsoft and Adobe; it extends the TrueType font file format originally designed by Apple. OpenType fonts allow rich mapping between characters and glyphs, thus enabling support for ligatures, positional forms, alternates, and other substitutions. OpenType fonts can also include information that supports two–dimensional glyph positioning and glyph attachment, and can contain either TrueType or PostScript outlines. Layout features within OpenType fonts are organized by scripts and languages, allowing a single font to support multiple writing systems, even within the same script.
The Windows core fonts (Times New Roman, Courier New, Arial, Microsoft Sans Serif, and Tahoma) contain Latin, Hebrew, Arabic, Greek, and Cyrillic scripts but do not contain East Asian script characters. They link to fonts that do. The main reason behind the exclusion of these scripts is related to the massive performance overhead that East Asian glyphs would introduce in terms of font loading and mapping in GDI. In addition, these scripts would make the font size several times bigger. Instead of having instructions on how to create glyphs for several hundred characters, you would have instructions on how to create them for some 6,000 or 7,000 characters, approximately.
One benefit of Unicode is the ability to represent many languages and scripts in a single string. This is also a problem, since very few fonts support more than a couple of scripts. Indeed, it's very difficult to do a good job of making fonts with glyphs for different scripts such that all conform to one set of vertical metrics. To overcome this limitation, and in order to accommodate complex scripts, Uniscribe can detect if the currently selected font doesn't support a particular script and can automatically switch–or fall back–to a predefined font that has appropriate glyphs for the desired script. All these operations are transparent to the user.
Here is an example to better understand this mechanism. A user running Windows XP selects the Tahoma font to enter some text first in English, next in Hebrew, and then in Telugu. Since Tahoma is an OpenType font, it provides support for Latin and Hebrew scripts, but does not contain any Telugu glyphs. Uniscribe detects this lack of font support and automatically renders the Telugu script by using its fallback font, which is Gautami.
Although font fallback can accommodate Indic scripts such as Telugu in Windows XP or later Windows versions, no such mechanism existed in Windows 2000. For most of the scripts, the fallback font is set to Microsoft Sans Serif (an OpenType font). For the Indic family of languages, the fallback is set to another appropriate font. Font fallback is internal to Uniscribe, and applications cannot add new fallback fonts or modify existing ones.
Unlike font fallback, in which the selected font is internally replaced by a predefined font, in font linking it is possible to link one or more fonts (called "linked fonts") to another font (called the "base font"). Once you link fonts, you can use the base font to display code points that do not exist in the base font, but that do exist in one of the linked fonts. For example, linking a hangul font and a Japanese font to a Tahoma font allows you to display both Korean and Japanese characters in Tahoma font.
Note: Font linking can only add glyphs to a base font; you cannot override or replace glyphs in the base font.
If font linking is enabled on your device, you can examine the registry by enumerating the subkeys of the registry key at HKEY_LOCAL_MACHINE–\SOFTWARE\Microsoft\Windows NT\CurrentVersion\FontLink\SystemLink to determine the mappings of linked fonts to base fonts. You can add links by using Regedit to create additional subkeys. Once you have located the registry key that has just been mentioned, from the Edit menu, Highlight the font face name of the font you want to link to and then from the Edit menu, click Modify. On a new line in the dialog field "Value data" of the Edit Multi-String dialog box, enter the path and file name to link to, and face name of the font. Use coma to separate the font file name and font face name. Figure 1 below demonstrates how to enter the value for font linking.
Figure 1: RegEdit's "Edit Multi-String" dialog box
Caution: Editing/modifying the font link entries in the Registry can be done, but is NOT supported by Microsoft. The wrong font link entry can leave the system unstable and impacts machine performance.
Note: After using Regedit to add the font linking, you have to log off Windows and log back on in order to have the new added font linking taking the effect.
Important: Font linking is a mechanism enabled within GDI and takes priority over font fallback.
With font fallback and font linking, the font size of the newly selected font will be the same as that of the original font. For example, if an 8–point Tahoma font was selected to type English and now the user enters some Japanese text, an 8–point MS UI Gothic font will be automatically selected. The 8–point font size might not be the best choice for some scripts, since it can make them hard to read.
Both font fallback and font linking contain logic to estimate an appropriate font size, but both mechanisms have to use metrics exposed by the font that might or might not actually match the way the font appears. Consider the difference in the height of English letters among 8–point Microsoft Sans Serif, 8–point Traditional Arabic, and 8–point Angsana New:
Even though all of these are supposedly 8–point fonts, the actual size of the English letters varies widely. Font fallback and font linking are no substitutes for choosing the right font in the first place. Rather, these mechanisms are simply a means of preventing the user from manually selecting a font; additionally, they prevent UI text from being displayed as a default glyph.
Even so, when font linking occurs, GDI will attempt scale the linked font with the aim of making the glyphs from the linked font appear to match in size the glyphs from the base font. In Windows XP, an algorithm was used that operates in terms of various font metrics. In Vista, this algorithm was found not to give satisfactory results in all scenarios; in particular, it did not give good results when linking to new East Asian fonts that have no embedded bitmaps. To resolve this problem, an alternate scaling mechanism was introduced: explicit scaling factors for particular linked fonts could be specified in font linking registry entries. Scaling factors are specified as a pair of positive integers. For instance, the value
indicates that the scaling algorithm should apply the scaling factors 128 and 85 whenever the given base font is linked to the Meiryo font.
Note that GDI+ is not able to parse these scaling factors. Thus, references to fonts with scaling factors are repeated without these scaling factors. In GDI+, the first reference, with the scaling factors, will appear to be to an unrecognized font and will be ignored. In GDI, the second reference will be treated as redundant and ignored.
Font substitution is used by GDI to translate a request for one face name into a request for another face name. Substitutions are also sensitive to charsets, so that a request for Arial with Western charset (0) can be translated into a request for Arial with Greek charset (161), for instance.
Font substitution is set with the registry entries under the key HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\FontSubstitutes. The registry entry of “Helvetica” with the value of “Arial”, for instance, indicates to substitute Helvetica font with Arial font; and the registry entry of “Arial,0” with the value of “Arial,161” will substitute Arial with ANSI_CHAERSET to Arial with GREEK_CHARSET.