Encoding instances provide some standard encoding resources for PostScript. When a PostScript file is parsed, the characters in a string are really indices into an array of glyph names, which are in turn the keys to entries in a glyph dictionary. Input to a PostScript interpreter is not really characters, but rather character indexes. (The two might be the same, especially for ASCII characters).
So the PostScript interpreter uses a two-step process, as follows: 1. It conceptually maps character codes (integer values) to name objects like /A or /Uacute. This map is known as an "encoding". There are several standard encoding schemes defined in the PostScript standard that each interpreter must know how to handle. Those are provided as Encoding subclasses. 2. The name objects created in step 1 are then used as the key into a dictionary (contained in the Font dictionary) whose values contain the PostScript instructions needed to actually paint the glyph.
Nowhere in the above scheme is Unicode encoding contemplated or supported. Applications that create PostScript output from Unicode input need a way to convert from that Unicode input to the indexes that are expected for by the selected encoding. The closest resource that we have for this purpose is the standard glyph lists supplied by Adobe.
The canonical method for mapping a Unicode code point to a PostScript encoding index would be:
However, for efficiency, an Encoding combines the above two steps and provides a direct mapping from a Unicode code point to the encoded index. Two parallel arrays are used to make this process efficient. The first is a an array of all Unicode code points supported in the Encoding. This array is sorted for fast searching. The second array provides the encoded index for the Unicode code point in the first array. Methods are provided to encode and decode characters.
| |