This is Info file pspp.info, produced by Makeinfo version 1.68 from the
input file pspp.texi.

START-INFO-DIR-ENTRY
* PSPP: (pspp).             Statistical analysis package.
END-INFO-DIR-ENTRY

   PSPP, for statistical analysis of sampled data, by Ben Pfaff.

   This file documents PSPP, a statistical package for analysis of
sampled data that uses a command language compatible with SPSS.

   Copyright (C) 1996, 1997, 1998 Free Software Foundation, Inc.

   This version of the PSPP documentation is consistent with version 2
of "texinfo.tex".

   Permission is granted to make and distribute verbatim copies of this
manual provided the copyright notice and this permission notice are
preserved on all copies.

   Permission is granted to copy and distribute modified versions of
this manual under the conditions for verbatim copying, provided that the
entire resulting derived work is distributed under the terms of a
permission notice identical to this one.

   Permission is granted to copy and distribute translations of this
manual into another language, under the above condition for modified
versions, except that this permission notice may be stated in a
translation approved by the Free Software Foundation.


File: pspp.info,  Node: Top,  Next: Introduction,  Prev: (dir),  Up: (dir)

PSPP
****

   This file documents the PSPP package for statistical analysis of
sampled data.  This is edition 0.2, for PSPP version 0.2, last modified
at Time-stamp: <1999-03-09 12:00:42 blp>.

* Menu:

* Introduction::                Description of the package.
* License::                     Your rights and obligations.
* Credits::                     Acknowledgement of authors.

* Installation::                How to compile and install PSPP.
* Configuration::               Configuring PSPP.
* Invocation::                  Starting and running PSPP.

* Language::                    Basics of the PSPP command language.
* Expressions::                 Numeric and string expression syntax.

* Data Input and Output::       Reading data from user files.
* System and Portable Files::   Dealing with system & portable files.
* Variable Attributes::         Adjusting and examining variables.
* Data Manipulation::           Simple operations on data.
* Data Selection::              Select certain cases for analysis.
* Conditionals and Looping::    Doing things many times or not at all.
* Statistics::                  Basic statistical procedures.
* Utilities::                   Other commands.
* Not Implemented::             What's not here yet

* Data File Format::            Format of PSPP system files.
* Portable File Format::        Format of PSPP portable files.
* q2c Input Format::            Format of syntax accepted by q2c.

* Bugs::                        Known problems; submitting bug reports.

* Function Index::              Index of PSPP functions for expressions.
* Concept Index::               Index of concepts.
* Command Index::               Index of PSPP procedures.


File: pspp.info,  Node: Introduction,  Next: License,  Prev: Top,  Up: Top

Introduction
************

   PSPP is a tool for statistical analysis of sampled data.  It reads a
syntax file and a data file, analyzes the data, and writes the results
to a listing file or to standard output.

   The language accepted by PSPP is similar to those accepted by SPSS
statistical products.  The details of PSPP's language are given later
in this manual.

   PSPP produces output in two forms: tables and charts.  Both of these
can be written in several formats; currently, ASCII, PostScript, and
HTML are supported.  In the future, more drivers, such as PCL, MS
Windows, X Windows, perhaps even HTML, may be developed.  For now,
Ghostscript, available from the Free Software Foundation, may be used
to convert PostScript chart output to other formats.

   The current version of PSPP, 0.2, is woefully incomplete in terms of
its statistical procedure support.  PSPP is a work in progress.  The
author hopes to support fully support all features in the products that
PSPP replaces, eventually.  The author welcomes questions, comments,
donations, and code submissions.  *Note Submitting Bug Reports: Bugs,
for instructions on contacting the author.


File: pspp.info,  Node: License,  Next: Credits,  Prev: Introduction,  Up: Top

Your rights and obligations
***************************

   Most of PSPP is distributed under the GNU General Public License.
The General Public License says, in effect, that you may modify and
distribute PSPP as you like, as long as you grant the same rights to
others.  It also states that you must provide source code when you
distribute PSPP, or, if you obtained PSPP source code from an anonymous
ftp site, give out the name of that site.

   The General Public License is given in full in the source
distribution as file `COPYING'.  In Debian GNU/Linux, this file is also
available as file `/usr/doc/copyright/GPL'.

   To quote the GPL itself:

     This program is free software; you can redistribute it and/or
     modify it under the terms of the GNU General Public License as
     published by the Free Software Foundation; either version 2 of the
     License, or (at your option) any later version.

     This program is distributed in the hope that it will be useful, but
     WITHOUT ANY WARRANTY; without even the implied warranty of
     MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
     General Public License for more details.

     You should have received a copy of the GNU General Public License
     along with this program; if not, write to the Free Software
     Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.


File: pspp.info,  Node: Credits,  Next: Installation,  Prev: License,  Up: Top

Credits
*******

     I'm always embarrassed when I see an index an author has made of
     his own work.  It's a shameless exhibition--to the trained eye.
     Never index your own book.

     --Claire Minton, `Cat's Cradle', Kurt Vonnegut, Jr.

   Most of PSPP, as well as this manual (including the indices), was
written by Ben Pfaff.  *Note Contacting the Author::, for instructions
on contacting the author.

   The PSPP source code incorporates `julcal10' originally written by
Michael A. Covington and translated into C by Jim Van Zandt.  The
original package can be found in directory
`ftp://ftp.cdrom.com/pub/algorithms/c/julcal10'.  The entire contents
of that directory constitute the package.  The files actually used in
PSPP are `julcal.c' and `julcal.h'.


File: pspp.info,  Node: Installation,  Next: Configuration,  Prev: Credits,  Up: Top

Installing PSPP
***************

   PSPP conforms to the GNU Coding Standards.  PSPP is written in, and
requires for proper operation, ANSI/ISO C.  You might want to
additionally note the following points:

   * The compiler and linker must allow for significance of several
     characters in external identifiers.  The exact number is unknown
     but at least 31 is recommended.

   * The `int' type must be 32 bits or wider.

   * The recommended compiler is gcc 2.7.2.1 or later, but any ANSI
     compiler will do if it fits the above criteria.

   Many UNIX variants should work out-of-the-box, as PSPP uses GNU
autoconf to detect differences between environments.  Please report any
problems with compilation of PSPP under UNIX and UNIX-like operating
systems--portability is a major concern of the author.

   The pages below give specific instructions for installing PSPP on
each type of system mentioned above.

* Menu:

* UNIX installation::           Installing on UNIX-like environments.
* MS-DOS installation::         Installing on MS-DOS with DJGPP 2.0.
* Cygnus Windows installation:: Installing on Windows 95/NT with Cygnus tools.
* Borland C++ installation::    Installing on Windows 95/NT with Borland tools.
* Windows porting notes::       Using Windows compilers.


File: pspp.info,  Node: UNIX installation,  Next: MS-DOS installation,  Prev: Installation,  Up: Installation

UNIX installation
=================

To install PSPP under a UNIX-like operating system, follow the steps
below in order.  Some of the text below was taken directly from various
Free Software Foundation sources.

  1. `cd' to the directory containing the PSPP source.

  2. Type `./configure' to configure for your particular operating
     system and compiler.  Running `configure' takes a while.  While
     running, it displays some messages telling which features it is
     checking for.

     You can optionally supply some options to `configure' in order to
     give it hints about how to do its job.  Type `./configure --help'
     to see a list of options.  One of the most useful options is
     `--with-checker', which enables the use of the Checker memory
     debugger under supported operating systems.  Checker must already
     be installed to use this option.  Do not use `--with-checker' if
     you are not debugging PSPP itself.

  3. (optional) Edit `Makefile', `config.h', and `pref.h'.  These files
     are produced by `configure'.  Note that most PSPP settings can be
     changed at runtime.

     `pref.h' is only generated by `configure' if it does not already
     exist.  (It's copied from `prefh.orig'.)

  4. Type `make' to compile the package.  If there are any errors during
     compilation, try to fix them.  If modifications are necessary to
     compile correctly under your configuration, contact the author.
     *Note Submitting Bug Reports: Bugs, for details.

  5. Type `make check' to run self-tests on the compiled PSPP package.

  6. Become the superuser and type `make install' to install the PSPP
     binaries, by default in `/usr/local/bin/'.  The directory
     `/usr/local/share/pspp/' is created and populated with files
     needed by PSPP at runtime.  This step will also cause the PSPP
     documentation to be installed in `/usr/local/info/', but only if
     that directory already exists.

  7. (optional) Type `make clean' to delete the PSPP binaries from the
     source tree.


File: pspp.info,  Node: MS-DOS installation,  Next: Cygnus Windows installation,  Prev: UNIX installation,  Up: Installation

MS-DOS installation
===================

*Please note:* The instructions below were written for an earlier
version of PSPP.  They are known not to work with the current version.
However, these instructions and the accompanying files in the
distribution are supplied anyway, in order to provide an outline for
anyone who would care to work on porting, which should not be
complicated.

   PSPP is most often supplied for MS-DOS as a precompiled (binary)
distribution.  If for some reason you wish to compile it yourself,
follow the instructions given below:

  1. Change the working drive and/or `cd' to the directory containing
     the PSPP source.

  2. Execute batch file `makedj2.bat'.  This batch file performs the
     following actions:

        * Copies `configh.dj2' to `config.h'.

        * Copies `confh.dj2' to `conf.h'.

        * Copies `prefh.ori' to `pref.h', if `pref.h' does not already
          exist.  You can customize the settings in `pref.h'.

        * Copies `makefile.dj2' to `makefile'.

        * Runs `make'.  This must be GNU `make', not GNU `make' or
          Microsoft `nmake'.

     *Please note:* The DJGPP makefile is not as general as the UNIX
     makefile.  It does not keep track of dependencies.  This is due to
     limitations in the DOS batch language.  If someone would like to
     improve the DJGPP makefile, contributions are welcome.


File: pspp.info,  Node: Cygnus Windows installation,  Next: Borland C++ installation,  Prev: MS-DOS installation,  Up: Installation

Windows 95/NT installation with Cygnus tools
============================================

   PSPP is most often supplied compiled for Windows in precompiled
(binary) form.  If for some reason you wish to compile it yourself,
follow the instructions for compiling under UNIX.  You must supply a
configuration name on the `configure' command line.

   The latest version of Cygnus tools for Windows can be obtained from
Cygnus's FTP site at `ftp://ftp.cygnus.com/'.


File: pspp.info,  Node: Borland C++ installation,  Next: Windows porting notes,  Prev: Cygnus Windows installation,  Up: Installation

Windows 95/NT installation with Borland C++
===========================================

   PSPP is most often supplied for Windows in precompiled (binary) form.
If you want to compile yourself, you still need a real operating system
(read: UNIX) in order to produce the correct source code distribution.
Follow these instructions under that OS:

   From the root of the configured source distribution, execute
`sysdeps/borlandc5.0/mk-bc5-dist PSPP-DIR BCC-DIR', where PSPP-DIR is
the DOS drive and directory where you will put the PSPP source
distribution, and BCC-DIR is the DOS drive and directory where Borland
C++ lives.  Under my setup, these are `e:\pspp' and `e:\bc5',
respectively, but on yours, they probably aren't.

   This produces a directory `pspp-VERSION-bc5'.  Copy this to the
previously indicated directory on your Windows partition.  Then open
the supplied `pspp.ide' project file in Borland C++ 5.0 and tell it to
Make All.  After compilation finishes, run InstallShield Express on the
supplied `pspp.iwz' to produce a installation program.  Afterwards, you
can run the whole thing through Zip from InfoZip and prepend the ZipSfx
program in order to get a self-extracting executable.

   Note that the Borland C++ `alloca()' implementation is bogus.  Don't
use it--either turn it off by not defining HAVE_ALLOCA in config.h, or
use the alloca implementation in `alloca.c' included with the
distribution.  The included configuration takes the former approach.


File: pspp.info,  Node: Windows porting notes,  Prev: Borland C++ installation,  Up: Installation

Windows compilers other than Borland C++
========================================

   PSPP is currently a console-mode application.  This is no big deal
under Windows 95 and Windows NT.  However, Windows 3.1 has no console,
so PSPP includes a console emulation library named `con32s'.  This
emulation library is active only under Windows 3.1.

   `con32s' is mostly compiler-independent.  However, its interface to
the runtime library is necessarily compiler-dependent.  Under Borland
C++ 5.0, the compiler-specific portion is isolated in files `_read.c'
and `_write.c', which replace three functions from Borland's runtime
library.

   Ports to other Windows compilers will have to take these facts into
account.  Probably very little code will have to be added.  The
Borland-specific code can be examined as a model.  Any port will
probably require runtime library source code to write, perhaps even to
compile.


File: pspp.info,  Node: Configuration,  Next: Invocation,  Prev: Installation,  Up: Top

Configuring PSPP
****************

   PSPP has dozens of configuration possibilities and hundreds of
settings.  This is both a bane and a blessing.  On one hand, it's
possible to easily accommodate diverse ranges of setups.  But, on the
other, the multitude of possibilities can overwhelm the casual user.
Fortunately, the configuration mechanisms are profusely described in the
sections below....

* Menu:

* File locations::              How PSPP finds config files.
* Configuration techniques::    Many different methods of configuration....
* Configuration files::         How configuration files are read.
* Environment variables::       All about environment variables.
* Output devices::              Describing your terminal(s) and printer(s).
* PostScript driver class::     Configuration of PostScript devices.
* ASCII driver class::          Configuration of character-code devices.
* HTML driver class::           Configuration for HTML output.
* Miscellaneous configuring::   Even more configuration variables.
* Improving output quality::    Hints for producing ever-more-lovely output.


File: pspp.info,  Node: File locations,  Next: Configuration techniques,  Prev: Configuration,  Up: Configuration

Locating configuration files
============================

   PSPP uses the same method to find most of its configuration files:

  1. The "base name" of the file being sought is determined.

  2. The path to search is determined.

  3. Each directory in the search path, from left to right, is searched
     for a file with the name of the base name.  The first occurrence
     is read as the configuration file.

   The first two steps are elaborated below for the sake of our pedantic
friends.

  1. A "base name" is a file name lacking an absolute directory
     reference.  Some examples of base names are: `ps-encodings',
     `devices', `devps/DESC' (under UNIX), `devps\DESC' (under M$
     environments).

     Determining the base name is a two-step process:

       a. If the appropriate environment variable is defined, the value
          of that variable is used (*note Environment variables::.).
          For instance, when searching for the output driver
          initialization file, the variable examined is
          `STAT_OUTPUT_INIT_FILE'.

       b. Otherwise, the compiled-in default is used.  For example,
          when searching for the output driver initialization file, the
          default base name is `devices'.

     *Please note:* If a user-specified base name does contain an
     absolute directory reference, as in a file name like
     `/home/pfaff/fonts/TR', no path is searched--the file name is used
     exactly as given--and the algorithm terminates.

  2. The path is the first of the following that is defined:

        * A variable definition for the path given in the user
          environment.  This is a PSPP-specific environment variable
          name; for instance, `STAT_OUTPUT_INIT_PATH'.

        * In some cases, another, less-specific environment variable is
          checked.  For instance, when searching for font files, the
          PostScript driver first checks for a variable with name
          `STAT_GROFF_FONT_PATH', then for one with name
          `GROFF_FONT_PATH'.  (However, font searching has its own list
          of esoteric search rules.)

        * The configuration file path, which is itself determined by the
          following rules:

            a. If the command line contains an option of the form `-B
               PATH' or `--config-dir=PATH', then the value given on the
               rightmost occurrence of such an option is used.

            b. Otherwise, if the environment variable
               `STAT_CONFIG_PATH' is defined, the value of that
               variable is used.

            c. Otherwise, the compiled-in fallback default is used.  On
               UNIX machines, the default fallback path is

                 1. `~/.pspp'

                 2. `/usr/local/lib/pspp'

                 3. `/usr/lib/pspp'

               On DOS machines, the default fallback path is:

                 1. All the paths from the DOS search path in the
                    `PATH' environment variable, in left-to-right order.

                 2. `C:\PSPP', as a last resort.

               Note that the installer of PSPP can easily change this
               default fallback path; thus the above should not be
               taken as gospel.

   As a final note: Under DOS, directories given in paths are delimited
by semicolons (`;'); under UNIX, directories are delimited by colons
(`:').  This corresponds with the standard path delimiter under these
OSes.


File: pspp.info,  Node: Configuration techniques,  Next: Configuration files,  Prev: File locations,  Up: Configuration

Configuration techniques
========================

   There are many ways that PSPP can be configured.  These are
described in the list below.  Values given by earlier items take
precedence over those given by later items.

  1. Syntax commands that modify settings, such as `SET'.

  2. Command-line options.  *Note Invocation::.

  3. PSPP-specific environment variable contents.  *Note Environment
     variables::.

  4. General environment variable contents.  *Note Environment
     variables::.

  5. Configuration file contents.  *Note Configuration files::.

  6. Fallback defaults.

   Some of the above may not apply to a particular setting.  For
instance, the current pager (such as `more', `most', or `less') cannot
be determined by configuration file contents because there is no
appropriate configuration file.


File: pspp.info,  Node: Configuration files,  Next: Environment variables,  Prev: Configuration techniques,  Up: Configuration

Configuration files
===================

   Most configuration files have a common form:

   * Each line forms a separate command or directive.  This means that
     lines cannot be broken up, unless they are spliced together with a
     trailing backslash, as described below.

   * Before anything else is done, trailing whitespace is removed.

   * When a line ends in a backslash (`\'), the backslash is removed,
     and the next line is read and appended to the current line.

        - Whitespace preceding the backslash is retained.

        - This rule continues to be applied until the line read does
          not end in a backslash.

        - It is an error if the last line in the file ends in a
          backslash.

   * Comments are introduced by an octothorpe (#), and continue until
     the end of the line.

        - An octothorpe inside balanced pairs of double quotation marks
          (`"') or single quotation marks (`'') does not introduce a
          comment.

        - The backslash character can be used inside balanced quotes of
          either type to escape the following character as a literal
          character.

          (This is distinct from the use of a backslash as a
          line-splicing character.)

        - Line splicing takes place before comment removal.

   * Blank lines, and lines that contain only whitespace, are ignored.


File: pspp.info,  Node: Environment variables,  Next: Output devices,  Prev: Configuration files,  Up: Configuration

Environment variables
=====================

   You may think the concept of environment variables is a fairly simple
one.  However, the author of PSPP has found a way to complicate even
something so simple.  Environment variables are further described in
the sections below:

* Menu:

* Variable values::             Values of variables are determined this way.
* Environment substitutions::   How environment substitutions are made.
* Predefined variables::        A few variables are automatically defined.


File: pspp.info,  Node: Variable values,  Next: Environment substitutions,  Prev: Environment variables,  Up: Environment variables

Values of environment variables
-------------------------------

   Values for environment variables are obtained by the following means,
which are arranged in order of decreasing precedence:

  1. Command-line options.  *Note Invocation::.

  2. The `environment' configuration file--more on this below.

  3. Actual environment variables (defined in the shell or other parent
     process).

   The `environment' configuration file is located through application
of the usual algorithm for configuration files (*note File
locations::.), except that its contents do not affect the search path
used to find `environment' itself.  Use of `environment' is discouraged
on systems that allow an arbitrarily large environment; it is supported
for use on systems like MS-DOS that limit environment size.

   `environment' is composed of lines having the form `KEY=VALUE',
where KEY and the equals sign (`=') are required, and VALUE is
optional.  If VALUE is given, variable KEY is given that value; if
VALUE is absent, variable KEY is undefined (deleted).  Variables may
not be defined with a null value.

   Environment substitutions are performed on each line in the file
(*note Environment substitutions::.).

   See *Note Configuration files::, for more details on formatting of
the environment configuration file.

     *Please note:* Support for `environment' is not yet implemented.


File: pspp.info,  Node: Environment substitutions,  Next: Predefined variables,  Prev: Variable values,  Up: Environment variables

Environment substitutions
-------------------------

   Much of the power of environment variables lies in the way that they
may be substituted into configuration files.  Variable substitutions are
described below.

   The line is scanned from left to right.  In this scan, all characters
other than dollar signs (`$') are retained unmolested.  Dollar signs,
however, introduce an environment variable reference.  References take
three forms:

`$VAR'
     Replaced by the value of environment variable VAR, determined as
     specified in *Note Variable values::.  VAR must be one of the
     following:

        * One or more letters.

        * Exactly one nonalphabetic character.  This may not be a left
          brace (`{').

`${VAR}'
     Same as above, but VAR may contain any character (except `}').

`$$'
     Replaced by a single dollar sign.

   Undefined variables expand to a empty value.


File: pspp.info,  Node: Predefined variables,  Prev: Environment substitutions,  Up: Environment variables

Predefined environment variables
--------------------------------

   There are two environment variables predefined for use in environment
substitutions:

`VER'
     Defined as the version number of PSPP, as a string, in a format
     something like `0.9.4'.

`ARCH'
     Defined as the host architecture of PSPP, as a string, in standard
     cpu-manufacturer-OS format.  For instance, Debian GNU/Linux 1.1 on
     an Intel machine defines this as `i586-unknown-linux'.  This is
     somewhat dependent on the system used to compile PSPP.

   Nothing prevents these values from being overridden, although it's a
good idea not to do so.


File: pspp.info,  Node: Output devices,  Next: PostScript driver class,  Prev: Environment variables,  Up: Configuration

Output devices
==============

   Configuring output devices is the most complicated aspect of
configuring PSPP.  The output device configuration file is named
`devices'.  It is searched for using the usual algorithm for finding
configuration files (*note File locations::.).  Each line in the file
is read in the usual manner for configuration files (*note
Configuration files::.).

   Lines in `devices' are divided into three categories, described
briefly in the table below:

driver category definitions
     Define a driver in terms of other drivers.

macro definitions
     Define environment variables local to the the output driver
     configuration file.

device definitions
     Describe the configuration of an output device.

   The following sections further elaborate the contents of the
`devices' file.

* Menu:

* Driver categories::           How to organize the driver namespace.
* Macro definitions::           Environment variables local to `devices'.
* Device definitions::          Output device descriptions.
* Dimensions::                  Lengths, widths, sizes, ....
* papersize::                   Letter, legal, A4, envelope, ....
* Distinguishing line types::   Details on `devices' parsing.
* Tokenizing lines::            Dividing `devices' lines into tokens.


File: pspp.info,  Node: Driver categories,  Next: Macro definitions,  Prev: Output devices,  Up: Output devices

Driver categories
-----------------

   Drivers can be divided into categories.  Drivers are specified by
their names, or by the names of the categories that they are contained
in.  Only certain drivers are enabled each time PSPP is run; by
default, these are the drivers in the category `default'.  To enable a
different set of drivers, use the `-o DEVICE' command-line option
(*note Invocation::.).

   Categories are specified with a line of the form `CATEGORY=DRIVER1
DRIVER2 DRIVER3 ...  DRIVERN'.  This line specifies that the category
CATEGORY is composed of drivers named DRIVER1, DRIVER2, and so on.
There may be any number of drivers in the category, from zero on up.

   Categories may also be specified on the command line (*note
Invocation::.).

   This is all you need to know about categories.  If you're still
curious, read on.

   First of all, the term `categories' is a bit of a misnomer.  In fact,
the internal representation is nothing like the hierarchy that the term
seems to imply: a linear list is used to keep track of the enabled
drivers.

   When PSPP first begins reading `devices', this list contains the
name of any drivers or categories specified on the command line, or the
single item `default' if none were specified.

   Each time a category definition is specified, the list is searched
for an item with the value of CATEGORY.  If a matching item is found,
it is deleted.  If there was a match, the list of drivers (DRIVER1
through DRIVERN) is then appended to the list.

   Each time a driver definition line is encountered, the list is
searched.  If the list contains an item with that driver's name, the
driver is enabled and the item is deleted from the list.  Otherwise,
the driver is not enabled.

   It is an error if the list is not empty when the end of `devices' is
reached.


File: pspp.info,  Node: Macro definitions,  Next: Device definitions,  Prev: Driver categories,  Up: Output devices

Macro definitions
-----------------

   Macro definitions take the form `define MACRONAME DEFINITION'.  In
such a macro definition, the environment variable MACRONAME is defined
to expand to the value DEFINITION.  Before the definition is made,
however, any macros used in DEFINITION are expanded.

   Please note the following nuances of macro usage:

   * For the purposes of this section, "macro" and "environment
     variable" are synonyms.

   * Macros may not take arguments.

   * Macros may not recurse.

   * Macros are just environment variable definitions like other
     environment variable definitions, with the exception that they are
     limited in scope to the `devices' configuration file.

   * Macros override other all environment variables of the same name
     (within the scope of `devices').

   * Earlier macro definitions for a particular KEY override later
     ones.  In particular, macro definitions on the command line
     override those in the device definition file.  *Note Non-option
     Arguments::.

   * There are two predefined macros, whose values are determined at
     runtime:

    `viewwidth'
          Defined as the width of the console screen, in columns of
          text.

    `viewlength'
          Defined as the length of the console screen, in lines of text.


File: pspp.info,  Node: Device definitions,  Next: Dimensions,  Prev: Macro definitions,  Up: Output devices

Driver definitions
------------------

   Driver definitions are the ultimate purpose of the `devices'
configuration file.  These are where the real action is.  Driver
definitions tell PSPP where it should send its output.

   Each driver definition line is divided into four fields.  These
fields are delimited by colons (`:').  Each line is subjected to
environment variable interpolation before it is processed further
(*note Environment substitutions::.).  From left to right, the four
fields are, in brief:

driver name
     A unique identifier, used to determine whether to enable the
     driver.

class name
     One of the predefined driver classes supported by PSPP.  The
     currently supported driver classes include `postscript' and
     `ascii'.

device type(s)
     Zero or more of the following keywords, delimited by spaces:

    `screen'
          Indicates that the device is a screen display.  This may
          reduce the amount of buffering done by the driver, to make
          interactive use more convenient.

    `printer'
          Indicates that the device is a printer.

    `listing'
          Indicates that the device is a listing file.

     These options are just hints to PSPP and do not cause the output
     to be directed to the screen, or to the printer, or to a listing
     file--those must be set elsewhere in the options.  They are used
     primarily to decide which devices should be enabled at any given
     time.  *Note SET::, for more information.

options
     An optional set of options to pass to the driver itself.  The exact
     format for the options varies among drivers.

   The driver is enabled if:

  1. Its driver name is specified on the command line, or

  2. It's in a category specified on the command line, or

  3. If no categories or driver names are specified on the command
     line, it is in category `default'.

   For more information on driver names, see *Note Driver categories::.

   The class name must be one of those supported by PSPP.  The classes
supported depend on the options with which PSPP was compiled.  See
later sections in this chapter for descriptions of the available driver
classes.

   Options are dependent on the driver.  See the driver descriptions for
details.


File: pspp.info,  Node: Dimensions,  Next: papersize,  Prev: Device definitions,  Up: Output devices

Dimensions
----------

   Quite often in configuration it is necessary to specify a length or a
size.  PSPP uses a common syntax for all such, calling them
collectively by the name "dimensions".

   * You can specify dimensions in decimal form (`12.5') or as
     fractions, either as mixed numbers (`12-1/2') or raw fractions
     (`25/2').

   * A number of different units are available.  These are suffixed to
     the numeric part of the dimension.  There must be no spaces
     between the number and the unit.  The available units are
     identical to those offered by the popular typesetting system TeX:

    `in'
          inch (1 `in' = 2.54 `cm')

    `"'
          inch (1 `in' = 2.54 `cm')

    `pt'
          printer's point (1 `in' = 72.27 `pt')

    `pc'
          pica (12 `pt' = 1 `pc')

    `bp'
          PostScript point (1 `in' = 72 `bp')

    `cm'
          centimeter

    `mm'
          millimeter (10 `mm' = 1 `cm')

    `dd'
          didot point (1157 `dd' = 1238 `pt')

    `cc'
          cicero (1 `cc' = 12 `dd')

    `sp'
          scaled point (65536 `sp' = 1 `pt')

   * If no explicit unit is given, a DWIM(1) "feature" attempts to
     guess the best unit:

        - Numbers less than 50 are assumed to be in inches.

        - Numbers 50 or greater are assumed to be in millimeters.

   ---------- Footnotes ----------

   (1) Do What I Mean


File: pspp.info,  Node: papersize,  Next: Distinguishing line types,  Prev: Dimensions,  Up: Output devices

Paper sizes
-----------

   Output drivers usually deal with some sort of hardcopy media.  This
media is called "paper" by the drivers, though in reality it could be a
transparency or film or thinly veiled sarcasm.  To make it easier for
you to deal with paper, PSPP allows you to have (of course!) a
configuration file that gives symbolic names, like "letter" or "legal"
or "a4", to paper sizes, rather than forcing you to use cryptic numbers
like "8-1/2 x 11" or "210 by 297".  Surprisingly enough, this
configuration file is named `papersize'.  *Note Configuration files::.

   When PSPP tries to connect a symbolic paper name to a paper size, it
reads and parses each non-comment line in the file, in order.  The first
field on each line must be a symbolic paper name in double quotes.
Paper names may not contain double quotes.  Paper names are not
case-sensitive: `legal' and `Legal' are equivalent.

   If a match is found for the paper name, the rest of the line is
parsed.  If it is found to be a pair of dimensions (*note
Dimensions::.) separated by either `x' or `by', then those are taken to
be the paper size, in order of width followed by length.  There *must*
be at least one space on each side of `x' or `by'.

   Otherwise the line must be of the form `"PAPER-1"="PAPER-2"'.  In
this case the target of the search becomes paper name PAPER-2 and the
search through the file continues.


File: pspp.info,  Node: Distinguishing line types,  Next: Tokenizing lines,  Prev: papersize,  Up: Output devices

How lines are divided into types
--------------------------------

   The lines in `devices' are distinguished in the following manner:

  1. Leading whitespace is removed.

  2. If the resulting line begins with the exact string `define',
     followed by one or more whitespace characters, the line is
     processed as a macro definition.

  3. Otherwise, the line is scanned for the first instance of a colon
     (`:') or an equals sign (`=').

  4. If a colon is encountered first, the line is processed as a driver
     definition.

  5. Otherwise, if an equals sign is encountered, the line is processed
     as a macro definition.

  6. Otherwise, the line is ill-formed.


File: pspp.info,  Node: Tokenizing lines,  Prev: Distinguishing line types,  Up: Output devices

How lines are divided into tokens
---------------------------------

   Each driver definition line is run through a simple tokenizer.  This
tokenizer recognizes two basic types of tokens.

   The first type is an equals sign (`=').  Equals signs are both
delimiters between tokens and tokens in themselves.

   The second type is an identifier or string token.  Identifiers and
strings are equivalent after tokenization, though they are written
differently.  An identifier is any string of characters other than
whitespace or equals sign.

   A string is introduced by a single- or double-quote character (`''
or `"') and, in general, continues until the next occurrence of that
same character.  The following standard C escapes can also be embedded
within strings:

`\''
     A single-quote (`'').

`\"'
     A double-quote (`"').

`\?'
     A question mark (`?').  Included for hysterical raisins.

`\\'
     A backslash (`\').

`\a'
     Audio bell (ASCII 7).

`\b'
     Backspace (ASCII 8).

`\f'
     Formfeed (ASCII 12).

`\n'
     Newline (ASCII 10)

`\r'
     Carriage return (ASCII 13).

`\t'
     Tab (ASCII 9).

`\v'
     Vertical tab (ASCII 11).

`\OOO'
     Each `o' must be an octal digit.  The character is the one having
     the octal value specified.  Any number of octal digits is read and
     interpreted; only the lower 8 bits are used.

`\xHH'
     Each `h' must be a hex digit.  The character is the one having the
     hexadecimal value specified.  Any number of hex digits is read and
     interpreted; only the lower 8 bits are used.

   Tokens, outside of quoted strings, are delimited by whitespace or
equals signs.


File: pspp.info,  Node: PostScript driver class,  Next: ASCII driver class,  Prev: Output devices,  Up: Configuration

The PostScript driver class
===========================

   The `postscript' driver class is used to produce output that is
acceptable to PostScript printers and to PC-based PostScript
interpreters such as Ghostscript.  Continuing a long tradition, PSPP's
PostScript driver is configurable to the point of absurdity.

   There are actually two PostScript drivers.  The first one,
`postscript', produces ordinary DSC-compliant PostScript output.  The
second one `epsf', produces an Encapsulated PostScript file.  The two
drivers are otherwise identical in configuration and in operation.

   The PostScript driver is described in further detail below.

* Menu:

* PS output options::           Output file options.
* PS page options::             Paper, margins, scaling & rotation, more!
* PS file options::             Configuration files.
* PS font options::             Default fonts, font options.
* PS line options::             Line widths, options.
* Prologue::                    Details on the PostScript prologue.
* Encodings::                   Details on PostScript font encodings.


File: pspp.info,  Node: PS output options,  Next: PS page options,  Prev: PostScript driver class,  Up: PostScript driver class

PostScript output options
-------------------------

   These options deal with the form of the output and the output file
itself:

`output-file=FILENAME'
     File to which output should be sent.  This can be an ordinary
     filename (i.e., `"pspp.ps"'), a pipe filename (i.e., `"|lpr"'), or
     stdout (`"-"').  Default: `"pspp.ps"'.

`color=BOOLEAN'
     Most of the time black-and-white PostScript devices are smart
     enough to map colors to shades themselves.  However, you can cause
     the PSPP output driver to do an ugly simulation of this in its own
     driver by turning `color' off.  Default: `on'.

     This is a boolean setting, as are many settings in the PostScript
     driver.  Valid positive boolean values are `on', `true', `yes',
     and nonzero integers.  Negative boolean values are `off', `false',
     `no', and zero.

`data=DATA-TYPE'
     One of `clean7bit', `clean8bit', or `binary'.  This controls what
     characters will be written to the output file.  PostScript
     produced with `clean7bit' can be transmitted over 7-bit
     transmission channels that use ASCII control characters for line
     control.  `clean8bit' is similar but allows characters above 127 to
     be written to the output file.  `binary' allows any character in
     the output file.  Default: `clean7bit'.

`line-ends=LINE-END-TYPE'
     One of `cr', `lf', or `crlf'.  This controls what is used for
     newline in the output file.  Default: `cr'.

`optimize-line-size=LEVEL'
     Either `0' or `1'.  If LEVEL is `1', then short line segments will
     be collected and merged into longer ones.  This reduces output
     file size but requires more time and memory.  A LEVEL of `0' has
     the advantage of being better for interactive environments.  `1'
     is the default unless the `screen' flag is set; in that case, the
     default is `0'.

`optimize-text-size=LEVEL'
     One of `0', `1', or `2', each higher level representing
     correspondingly more aggressive space savings for text in the
     output file and requiring correspondingly more time and memory.
     Unfortunately the levels presently are all the same.  `1' is the
     default unless the `screen' flag is set; in that case, the default
     is `0'.


File: pspp.info,  Node: PS page options,  Next: PS file options,  Prev: PS output options,  Up: PostScript driver class

PostScript page options
-----------------------

   These options affect page setup:

`headers=BOOLEAN'
     Controls whether the standard headers showing the time and date and
     title and subtitle are printed at the top of each page.  Default:
     `on'.

`paper-size=PAPER-SIZE'
     Paper size, either as a symbolic name (i.e., `letter' or `a4') or
     specific measurements (i.e., `8-1/2x11' or `"210 x 297"'.  *Note
     Paper sizes: papersize.  Default: `letter'.

`orientation=ORIENTATION'
     Either `portrait' or `landscape'.  Default: `portrait'.

`left-margin=DIMENSION'
`right-margin=DIMENSION'
`top-margin=DIMENSION'
`bottom-margin=DIMENSION'
     Sets the margins around the page.  The headers, if enabled, are not
     included in the margins; they are in addition to the margins.  For
     a description of dimensions, see *Note Dimensions::.  Default:
     `0.5in'.


File: pspp.info,  Node: PS file options,  Next: PS font options,  Prev: PS page options,  Up: PostScript driver class

PostScript file options
-----------------------

   Oh, my.  You don't really want to know about the way that the
PostScript driver deals with files, do you?  Well I suppose you're
entitled, but I warn you right now: it's not pretty.  Here goes....

   First let's look at the options that are available:

`font-dir=FONT-DIRECTORY'
     Sets the font directory.  Default: `devps'.

`prologue-file=PROLOGUE-FILE-NAME'
     Sets the name of the PostScript prologue file.  You can write your
     own prologue, though I have no idea why you'd want to: see *Note
     Prologue::.  Default: `ps-prologue'.

`device-file=DEVICE-FILE-NAME'
     Sets the name of the Groff-format device description file.  The
     PostScript driver reads this in order to know about the scaling of
     fonts and so on.  The format of such files is described in
     groff_font(5), included with Groff.  Default: `DESC'.

`encoding-file=ENCODING-FILE-NAME'
     Sets the name of the encoding file.  This file contains a list of
     all font encodings that will be needed so that the driver can put
     all of them at the top of the prologue.  *Note Encodings::.
     Default: `ps-encodings'.

     If the specified encoding file cannot be found, this error will be
     silently ignored, since most people do not need any encodings
     besides the ones that can be found using `auto-encodings',
     described below.

`auto-encode=BOOLEAN'
     When enabled, the font encodings needed by the default
     proportional- and fixed-pitch fonts will automatically be dumped
     to the PostScript output.  Otherwise, it is assumed that the user
     has an encoding file and knows how to use it (*note Encodings::.).
     There is probably no good reason to turn off this convenient
     feature.  Default: `on'.

   Next I suppose it's time to describe the search algorithm.  When the
PostScript driver needs a file, whether that file be a font, a
PostScript prologue, or what you will, it searches in this manner:

  1. Constructs a path by taking the first of the following that is
     defined:

       a. Environment variable `STAT_GROFF_FONT_PATH'.  *Note
          Environment variables::.

       b. Environment variable `GROFF_FONT_PATH'.

       c. The compiled-in fallback default.

  2. Constructs a base name from concatenating, in order, the font
     directory, a path separator (`/' or `\'), and the file to be
     found.  A typical base name would be something like
     `devps/ps-encodings'.

  3. Searches for the base name in the path constructed above.  If the
     file is found, the algorithm terminates.

  4. Searches for the base name in the standard configuration path.  See
     *Note File locations::, for more details.  If the file is found,
     the algorithm terminates.

  5. At this point we remove the font directory and path separator from
     the base name.  Now the base name is simply the file to be found,
     i.e., `ps-encodings'.

  6. Searches for the base name in the path constructed in the first
     step.  If the file is found, the algorithm terminates.

  7. Searches for the base name in the standard configuration path.  If
     the file is found, the algorithm terminates.

  8. The algorithm terminates unsuccessfully.

   So, as you see, there are several ways to configure the PostScript
drivers.  Careful selection of techniques can make the configuration
very flexible indeed.


File: pspp.info,  Node: PS font options,  Next: PS line options,  Prev: PS file options,  Up: PostScript driver class

PostScript font options
-----------------------

   The list of available font options is short and sweet:

`prop-font=FONT-NAME'
     Sets the default proportional font.  The name should be that of a
     PostScript font.  Default: `"Helvetica"'.

`fixed-font=FONT-NAME'
     Sets the default fixed-pitch font.  The name should be that of a
     PostScript font.  Default: `"Courier"'.

`font-size=FONT-SIZE'
     Sets the size of the default fonts, in thousandths of a point.
     Default: `10000'.


File: pspp.info,  Node: PS line options,  Next: Prologue,  Prev: PS font options,  Up: PostScript driver class

PostScript line options
-----------------------

   Most tables contain lines, or rules, between cells.  Some features of
the way that lines are drawn in PostScript tables are user-definable:

`line-style=STYLE'
     Sets the style used for lines used to divide tables into sections.
     STYLE must be either `thick', in which case thick lines are used,
     or DOUBLE, in which case double lines are used.  Default: `thick'.

`line-gutter=DIMENSION'
     Sets the line gutter, which is the amount of whitespace on either
     side of lines that border text or graphics objects.  *Note
     Dimensions::.  Default: `0.5pt'.

`line-spacing=DIMENSION'
     Sets the line spacing, which is the amount of whitespace that
     separates lines that are side by side, as in a double line.
     Default: `0.5pt'.

`line-width=DIMENSION'
     Sets the width of a typical line used in tables.  Default: `0.5pt'.

`line-width-thick=DIMENSION'
     Sets the width of a thick line used in tables.  Not used if
     `line-style' is set to `thick'.  Default: `1.5pt'.

