Chapter Contents


The GKEYMAP Procedure


About Key Maps and Device Maps

The characters A through Z (upper- and lowercase), 0 through 9, and many symbols and national characters are represented by a set of hexadecimal codes. However, a character may be represented by one code for the keyboard, another code for the operating environment, and yet another for the output device. To resolve these differences, SAS/GRAPH software stores all characters using its own internal encoding scheme, which is a set of hexadecimal values that are associated with all supported characters. SAS/GRAPH Internal Character Encoding shows these internal character encoding (ICE) codes.

To accommodate differences in the encoding of characters, you must be able to translate the hexadecimal codes generated by your keyboard or operating environment into the corresponding SAS/GRAPH internal encoding. A key map gives you this ability.

You also must be able to convert the internal encoding that is used by SAS/GRAPHsoftware to the codes required to produce the corresponding hardware characters on your output device. A device map gives you this ability.

Key maps and device maps are SAS catalog entries. Institute-supplied key maps and device maps are stored in the catalog SASHELP.FONTS. User-generated key maps and device maps are stored in the catalog GFONT0.FONTS. Key maps are stored with the extension KEYMAP (for example, GERMAN.KEYMAP), and device maps are stored with the extension DEVMAP (for example, DEFAULT.DEVMAP).

SAS/GRAPH Internal Character Encoding


What Key Maps Do

A key map changes the code generated by a keyboard key to the value corresponding to the SAS/GRAPH internal character encoding. Otherwise, a different character (or no character) may be drawn when the character is requested in a SAS/GRAPH software font.

Key maps are required when the code that is sent to the operating environment does not match the SAS/GRAPH internal encoding for the character corresponding to the key that is pressed. They are useful for generating a character in a software font that is not available on your keyboard or when the same key on different keyboards sends a different character to the operating environment. They are also useful for creating new characters by combining existing characters with accent characters (called diacritics).

Note:   In SAS/GRAPH Internal Character Encoding, the diacritic characters specified by the codes D2 through DB are backspaced before being drawn and can be used to create new characters (characters resulting from codes B0 through B7, B9, and BA are not backspaced before being drawn). See Modifying a Key Map for an example of using a diacritic character as an accent. Two commonly used characters have already been created for you: the character located in position F0 of the ICE table could be created by combining DA with an uppercase C, and the character located in position BC could be created by combining DB with an uppercase G.  [cautionend]

What Device Maps Do

A device map maps the code stored in the SAS/GRAPH internal encoding to the code required to reproduce the character on the output device when a particular hardware character is requested in a SAS/GRAPH program.

You usually use device maps in these two situations:

Using Key Maps and Device Maps

You use key maps and device maps by specifying them with the KEYMAP= or DEVMAP= options in a GOPTIONS statement. You also can specify a device map by filling in the DEVMAP field in the Detail window of the device entry for the device driver that you are using.

For example, if you use the GKEYMAP procedure to generate a key map called MYKEYMAP, you can specify it with a statement like this:

goptions keymap=mykeymap;

Once you specify MYKEYMAP as your current key map, you can press a key and the code it generates is translated by MYKEYMAP into the ICE code that is specified by the key map.

When you specify a device map with the DEVMAP= graphics option and you use a hardware character set, mapped characters are converted from their SAS/GRAPH internal encoding to the codes required to display the corresponding characters on your device. See Graphics Options and Device Parameters Dictionary for more information on the KEYMAP= and DEVMAP= graphics options.

Asymmetrical Maps

It is possible, and sometimes necessary, to define a key map or device map that is not symmetrical (that is, two or more input character codes map to the same output character code). For example, if you define a key map to map the keyed character A to the internal encoding for B, the keyed characters A and B both map to the internal encoding for B, but no code maps to A. This situation may make it impossible for you to display certain characters defined in software fonts.

Seeing What Characters in a Font are Available

To see what characters in a font can be displayed if a particular key map is used, do the following:

  1. Use the KEYMAP= option in a GOPTIONS statement to specify the key map that you are interested in.

  2. Then, use the GFONT procedure with the ROMHEX option to display the font that you want to use.

The hexadecimal values and corresponding font characters that are displayed are the ones available under the specified map. If the map is not symmetrical, a warning is issued. See The GFONT Procedure for more information on using hexadecimal values to display special characters.

About the GKEYMAP Data Set

To generate a key map or device map, you must create a data set that contains the mapping information and use that data set as input for the GKEYMAP procedure. The mapping information is specified as values for the variables in the data set, which should contain one observation for each character or key to be mapped. Any characters not specified in the data set are passed through the map unchanged.

GKEYMAP Data Set Variables

To provide information on the character mapping that is to be performed for a key map or a device map, you must use a variable named FROM to specify the character that you are mapping from, and a variable named TO to specify the character to map to. For key maps, these are the only variables in the data set. For device maps, you may also need variables named CHARTYPE and TOLEN.

Here are definitions for these variables:

specifies which hardware character set to use when a device requires that you select an alternate character set in order to display certain characters. CHARTYPE is a numeric variable.

All of the characters in the TO string for a particular FROM value must use the same character set. The CHARTYPE variable is required if you use the MULTFONT option in the PROC GKEYMAP statement; otherwise, it is ignored. (The CHARTYPE variable is always ignored when you are creating a key map.) The CHARTYPE value must match a value listed in the Chartype field in the Chartype window of the device entry for the device to which the map is applied. However, you can set the CHARTYPE variable to a missing value to specify that the character can be drawn in any hardware character set.

specifies the character you are mapping from. FROM is a character variable. For each observation, the FROM variable should contain a single character value. Any characters after the first are ignored. The data set must be sorted by the FROM variable.
Featured in: Modifying a Key Map

specifies the string that the character in the FROM variable is mapped to. TO is a character variable.

For device maps, if the TO variable contains more than one character, you must also specify TYPE=MAP1N in the PROC GKEYMAP statement to indicate that a single FROM character is being mapped to multiple TO characters. In addition, you must include the TOLEN variable in the data set to specify the length of each TO string. If you specify TYPE=MAP11 in the PROC GKEYMAP statement or if you do not use the TYPE= option, only the first byte of the TO string is recognized.
Featured in: Modifying a Key Map

specifies the length of the string in the TO variable. TOLEN is a numeric variable. The TOLEN variable is used only with device maps and is required if you specify TYPE=MAP1N in the PROC GKEYMAP statement; otherwise, it is ignored.

Chapter Contents



Top of Page

Copyright 1999 by SAS Institute Inc., Cary, NC, USA. All rights reserved.