PostScript fonts often contain many more than 256 characters, in order to accommodate foreign language characters and special symbols. PostScript uses encodings to map these onto single-byte symbol sets. Each font can have many different encodings applied to it.
PSPP's PostScript driver needs to know which encoding to apply to each font. It can determine this from the information encapsulated in the Groff font description that it reads. However, there is an additional problem—for efficiency, the PostScript driver needs to have a complete list of all encodings that will be used in the entire session when it opens the output file. For this reason, it can't use the information built into the fonts because it doesn't know which fonts will be used.
As a stopgap solution, there are two mechanisms for specifying which encodings will be used. The first mechanism is automatic and it is the only one that most PSPP users will ever need. The second mechanism is manual, but it is more flexible. Either mechanism or both may be used at one time.
The first mechanism is activated by the auto-encode driver option (see PS file options). When enabled, auto-encode causes the PostScript driver to include the encodings used by the default proportional and fixed-pitch fonts (see PS font options). Many PSPP output files will only need these encodings.
The second mechanism is the file specified by the encoding-file option (see PS file options). If it exists, this file must consist of lines in PSPP configuration-file format (see Configuration files). Each line that is not a comment should name a PostScript encoding to include in the output.
It is not an error if an encoding is included more than once, by either mechanism. It will appear only once in the output. It is also not an error if an encoding is included in the output but never used. It is an error if an encoding is used but not included by one of these mechanisms. In this case, the built-in PostScript encoding ISOLatin1Encoding is substituted.