Go to the previous, next chapter.

Advice to the user

OS/2's code page orientation provides some advantages, in that it separates the character set (code page) mapping from the encoded font mapping. The main inconvenience isn't a loss of function, but a disorientation as users become accustomed to the new paradigm.

If you need a glyph that you know is in your PFB file but that isn't in the active code page (and if you can't change code pages within your application), you can't get at it in OS/2 without tampering with the font files. To tamper, you can use font manipulation tools to redesignate the PFB file as FontSpecific ("Symbol" character set to Fontographer). If you then map the glyphs you need into one of the lower 256 cells (with some limitations), they will be accessible in all environments. The Fontographer manual does not explain what the "Symbol" character encoding label really does, it just tells you not to use it except for real symbol fonts. In fact you should use it for any font that will not correspond in inventory to the code page supported by your application, which means any non-Latin fonts.

You do not have to recode all your fonts, and you wouldn't normally want to do so, since Fontographer hinting is not nearly as good as Adobe's own hand-tuning and regenerating a font regenerates the hints. All you have to do is make sure you have one FontSpecific type font installed that includes your typographic quotes, etc. for each typeface you need. Within DeScribe, you can then write a macro that will let you switch fonts, fetch a character, and switch back, thereby allowing you to augment any group of fonts with a single, shared set of typographic quotes (or whatever) that you put in a single FontSpecific font. Alternatively, OS/2 also supports CP 1004, which does contain typographic quotes and other characters used for high-quality typography, but the user may not be able to convince an application to invoke this code page if it was not designed to do so.

You can have any number of FontSpecific fonts installed, which means that there is a mechanism for dealing with unsupported character sets (code pages).

You can also tinker with the font files to try to trick the operating system. For example, using Fontographer or other utilities, you can change the name assigned to a glyph description within the PFB file. If you want to use AdobeStandardEncoding and you want to see a specific glyph at a specific cell when DeScribe thinks it's using CP 850, you have to make sure that the name assigned to the description of that glyph is what DeScribe expects to find. OS/2 doesn't care whether, say, really looks like with two dots over it, as long as it bears the right name.

This second approach is obviously far more complex and provides much more opportunity for error. Its advantage is that OS/2 does not support case conversion and sorting (other than in machine order) for unsupported code pages, since these operations depend on character names. Keeping supported names from supported code pages while changing the artwork is one way to maintain order and case correspondences while increasing the range of glyphs actually supported. I have not experimented with this approach, since the use I would get out of the adding functionality (over the FontSpecific encoding approach) is not worth the amount of effort required.