Go to the previous, next chapter.

AdobeStandardEncoding under OS/2

OS/2 operates within a set of supported code pages; two system- wide code pages are specified in the config.sys file and an application is allowed to switch the active code page to any supported code page (not just these two). DeScribe, for example, currently operates in code page (CP) 850, which includes most letters needed for western European Latin alphabet writing. CP 850 does not contain typographic quotes, en- and em-dashes, and other useful characters. It does contain the IBM "pseudographics," which are useful for drawing boxes and lines with monospaced fonts.

When the user inputs a value (through the regular keyboard or the numeric keypad), the application checks the active CP, looks up in an internal table the name of the character that lives in that cell within that CP, and translates it into a unique number that corresponds to one of the 383 glyphs supported by OS/2 (the union of all supported code pages). This number is passed to PM-ATM (the OS/2 ATM implementation), which translate the glyph number into the glyph name that PostScript fonts expect and searches the font for that name. The system never looks at where a glyph is assigned under the AdobeStandardEncoding array; rather, it scans the font looking for the character by name and gives it an assignment derived from the active code page. This is the remapping that OS/2 performs on AdobeStandardEncoding type fonts.

As a result, a situation arises where, for example, is mapped to cell 246 under Windows ANSI but to cell 148 under CP 850. Using the identical PFB file, this glyph is accessed differently in the two operating environments.