/*

*
*/

Atari Ghostscript 3.33, Release 0, 8/95

>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>

NOTE:
Ghostscript installation will almost always require the user
to set an environment variable called GS_LIB. If you don't
set this variable, GS will most likely abort on start-up.
GS_LIB should be equated to a comma separated list of
directories that contain the PostScript startup files,
the Ghostscript fonts, and (optionally) the Ghostscript
help files. See below for more details.

GHOSTSCRIPT OVERVIEW:
PostScript is a programming language whose executable statements draw
an image on a page. It is not an image format like GIF or JPG, which
contain (compressed) information about the pixels of a bitmapped image
at some specific resolution. PostScript programs may give
resolution-independent descriptions of an image, and they may also
contain resolution-dependent bitmaps.
Aladdin Ghostscript 3.33 is a PostScript language interpreter which is
free to non-commercial users (the kernel is written and maintained by
Peter Deutsch -- ghost@aladdin.com). It can be used to convert
PostScript files into bitmapped formats suitable for non-PostScript
printers, or to display PostScript files on the screen. It is also
quite nice for PostScript code development. Beginning with version
3.33, Ghostscript can also display files formatted in Adobe's Portable
Document Format, or PDF.
If you are used to using GIF and JPG viewers, the behavior of
Ghostscript may seem a little strange. For example, the pages of
multiple page documents can generally be viewed only in sequential
order. Moving back to a previous page would amount to jumping
backwards in the program. There are ways around this limitation, but
they are awkward. Ghostscript does not behave like other file viewers
because it is NOT a file viewer. It is a program language interpreter
(like a BASIC interpreter).
The binary distribution of the Atari release contains an executable,
the PostScript support files, the help files, and the default font
(Courier). GS searches for the support files in all directories
contained in the comma-separated list assigned to the GS_LIB
environment variable. The default value for GS_LIB is
".,f:\gs\help,f:\gs\ps,f:\gs,f:\gs\fonts". To avoid potential filename
conflicts, the path to the help files may be specified separately by
the GS_HELPDIR environment variable.
The Atari port of GS consists of the standard Unix source code, plus a
few files that handle Atari-specific functions. The Atari source code
is available for ftp from
ftp://lifshitz.ph.utexas.edu/pub/atari/ghostscript/3.33/gs333s.zoo. The
standard source code and the remainder of the fonts for 3.33 (you can
use the old fonts if you want) are available from ftp.cs.wisc.edu.
This site can be accessed from the Atari Ghostscript WWW page at
http://godel.ph.utexas.edu/Members/timg/gs.html. You should be aware
that most of the Ghostscript font set is not very good. If you need
high-quality text output, you may want to buy a commercial font set,
or restrict yourself to the few GS fonts which are of high quality.

Later in this file is a brief description of some features which are

specific to the Atari platform. You may want to review it after
getting GS installed.
SYSTEM REQUIREMENTS:
To run GS 3.33, you probably need a minimum of 4M ram and 1M of free
disk space (as long as you write no files to disk). How much you can
get by with really depends on the PostScript files you want to
process, since ALOT of memory is allocated dynamically. If you get
all of the GS fonts, you will need another 3M of disk space. I run GS
on a 4M 520ST with an 85M hard drive and a monochrome monitor. You can
always try with less.
GS rasterizes PostScript images in a buffer in RAM. A 300dpi image
requires a little over 1M, so high resolution printing requires either
lots of memory or band printing (see use.doc). Color is a real memory
hog, so you may have to decrease the resolution for color images
(screen images cannot be printed in bands). Documents which load lots
of fonts can also hog lots of ram. (Try using the -dNOCACHE option if
you think fonts are using too much memory.)
You can probably get by without a hard drive if you are willing to use
only the Ghostscript default font. The font files take up about 3 Meg
of disk space. For graphics, the default font is fine, but text
output won't be great.
INSTALLATION:
The use of Ghostscript requires a set of PostScript support files (in
the ps directory), some fonts (at least the default font -- in the
fonts directory), and a file called fontmap. On-line help files (in
the help directory) are optional. When GS is executed, it reads a
number of the PostScript files to initialize itself. If it cannot
find these initialization files, Ghostscript will ABORT! The fontmap
file contains a list of which fonts reside in which disk files.
Ghostscript must be able to locate all of these files in order to
execute successfully.
>>>>>>>>>> This will almost always require the user to set an
>>>>>>>>>> environment variable called GS_LIB. If you don't set this
>>>>>>>>>> variable, GS will most likely abort on start-up.
When Ghostscript needs a file, it searches a list of directories until
it finds what it needs. Which directories it searches is determined as
follows:
1.) The current directory is searched first.
2.) Directories to be searched can be specified from the GS command
line with the -I option.
3.) Directories specified by the GS_LIB environment variable are
checked next. Gem users may be unfamiliar with environment
variables. Basically, this is just a global variable stored
by the computer in a location which is accessible by all
programs running on the machine. Most shells have commands

that allow you to set environment variables. If you are

running from the desktop, you may need an auto-folder program
(I believe GEMENV is the name of one such program) which will
set environment variables for you. Environment variables can
also be set from the Atari Ghostscript startup file stgs.rc,
but at the moment, these environment variable entries will not
be saved when the "Save Config" menu is selected. Look in the
stgs.rc file for the proper syntax.
Ghostscript will look for a global environment variable named
GS_LIB. If the environment variable GS_LIB is set to
"c:\gs,d:\gs,e:\gs" GS will search the directories c:\gs,
d:\gs, and e:\gs in sequence for the files that it needs.
This comma-separated list of directories is called a "path".
4.) If the GS_LIB variable is not set, GS searches a default path of
".,f:\gs\help,f:\gs\ps,f:\gs,f:\gs\fonts". This corresponds to
my setup. When GS needs a file, it first looks in the current
directory (.), then in f:\gs\help, then in f:\gs\ps,
f:\gs\fonts, and finally in f:\gs.
Optionally, the path to the help files may be specified
separately in the environment variable GS_HELPDIR.
I have Ghostscript installed as follows:
f:\gs
f:\gs\ps
f:\gs\fonts
f:\gs\help

GS source and executable,

GS PostScript support files and
other PostScript source (pictures),
GS fonts and the fontmap file,
GS ASCII and PostScript help files.

If your installation corresponds to the default path, you need

not worry about any environment variables. If the directories
used in your installation do not correspond to the default
path, you will want to set up your computer to automatically
define GS_LIB to be a COMMA separated path (corresponding to
your setup) for Ghostscript to search.
To install:
1) Copy gs333b.zoo (probably truncated to gs333.zoo) to the desired
directory (f:\gs to use the default search path).
2) Unpack the archive with 'zoo e// gs333b.zoo'
This will produce a directory structure as follows:
. (current directory) GS executable,
.\ps
GS PostScript support files and examples,
.\fonts
Default font and fontmap,
.\help
PostScript and ASCII help files.
If you want the root gs directory to be somewhere besides
f:\gs, define the environment variable GS_LIB to be a comma
separated search path which contains the files in the
'ps', help, and 'fonts' directories. You will probably want to
set up your system so that this environment variable is
defined automatically at boot time. If your system does not
support the ".gtp" extension, rename the executable to
"gs.ttp" or "gs.prg", depending on whether you wish to
be prompted for input when GS is executed.

USAGE:
To use Ghostscript:
1) To display a file on the screen, either:
a.) Type 'gs file1.ps file2.ps ...' on the command line. The
default device is the screen at 80 dpi. You can specify (with
the -r option) as much resolution as you have memory for, but
it may take forever to construct your image. Filenames can be
omitted and opened later from within the program.
b.) Double-click on gs.gtp, and provide any parameters you like
in the dialog box.
GS will open a console window, and will write some initialization
messages to it. The mouse will turn to a busy bee while GS is
creating a bitmap of the image. If you are using the screen
(stvdi) device, an image window will eventually open and the
image will be displayed (this can take a long while for complicated
files or high resolutions). You can then scroll around the image
using the scroll bars or the cursor keys.
Further files can be viewed by clicking on the "Open" menu
item and choosing the desired file with the file selector.
Usually the last postscript command on a PS page will be
"showpage". The showpage command causes the page to be displayed
and then waits for the user to enter a <return> before proceeding
to the next page. When all pages have been displayed, GS displays
a GS> prompt in the console window. Postscript commands typed in
the console window will then be executed by the PS interpreter. For
example, typing "(file.ps) run" after the prompt will cause
file.ps to be displayed.
PostScript files need not be specified on the GS
You can double-click on gs.gtp, or install gs to
executed by double-clicking on PostScript files.
inside GS, you can use the menu items to perform
like selecting the page size, the output device,
image resolution.

command line.
be automatically
Once
operations
and the

On-line help about any menu item can be invoked by holding

down any meta key (control, alt, or shift) while selecting
the menu item.
The use of windows may be disabled by setting the environment
variable GS_WIN to "off". In this case, you can move around
the image with the cursor keys, and type "q" when you have
finished viewing the image. Press the help key for further
information.
2) To use a printer device:
A printing device can be selected from the "Options" menu,
or can be specified from the command line. Type "gs
-sDEVICE=djet500 file.ps" on the command line for a deskjet
500, "gs -sDEVICE=epson file.ps", etc. Type "gs -h" for a
list of available printer devices. If you like, you can
define a shell alias for "gs -sDEVICE=djet500". The printer

output will be written by default in a file called

"gs_pr.XXX", where XXX is a unique number. Selecting the
"Print ..." menu item will allow output to be sent to a named
file or directly to the printer.
From the command line, output can be redirected to a file of
your choosing, or to the printer with the
"-sOutputFile=filename" option. OutputFile=PRN: or CEN:
will send output to the printer port (CEN: prints faster,
but is less compatible). If the CEN: output file has not
worked for you in the past, please try it again. I think
this bug may now be fixed. The output file name can also
be selected from the dialog opened by the "Print ..." menu.
ATARI FEATURES:
Most of the Atari-specific features are documented in the on-line
help, so I won't go into much detail here. Here is a brief overview
of the Atari-specific features:
1.) When GS is started, a console window is opened and stdin, stdout,
and stderr are directed to it. Use of windows may be disabled
by setting the GS_WIN environment variable to "off". Menus
are provided to change things like resolution, output device,
and page size without exiting and restarting GS. This can
save a good deal of time, since GS takes alot of time to
initialize.
The windows contain the standard gadgets, but they do not all
In addition to their normal function, the arrow buttons can be
used to move to the top, bottom, left edge, or right edge of
the window. This is accomplished by holding down a meta key
(cntl, alt, or shift) while clicking on the arrow. The fuller
button can be used to iconify windows in the same way (meta
key, click). In newer versions of TOS, windows are iconified
with the smaller button instead of the meta-fuller button.
The x coordinate of text windows will always snap to the
nearest word, so it may not end up exactly where you put it
when you move the window. This is an attempt to keep the text
word aligned, which is supposed to improve text output speed.
Text output speed is improved if the console window is topped.
In this case, text output is accelerated by avoiding both
clipping and walking the usual rectangle list.
2.) The stvdi screen device supports 1-, 2-, 4-, 8-, 16- and hopefully
24-bit color. The 24-bit color has not been thoroughly
tested, so it may not work properly, if at all.
Vdi routines are used to determine the screen parameters and
to copy to the screen, so graphics should work with lots of
different screen devices. The price of compatibility,
however, is alot of image transformation. Some
transformations are written in assembler in an attempt to
speed things up a bit.
The screen driver allocates colors dynamically as the GS
kernel requests them. For 2 and 4 bit color, GS spaces colors
equally throughout the color cube, and then approximates the

needed colors by dithering the two closest colors in the

palette. Because of the dynamic color allocation, you may see
colors changing on your screen while GS is running. GS
attempts to avoid changing the color of the desktop and of
window gadgets, but if your image needs lots of colors, this
may not be possible. Of course, the original palette is
restored when GS exits. Thanks to Markus Wenzel for the
routines to set and save the color palette.
3.) There are two ways to send output directly to the printer.
Including '-sOutputFile=PRN:' on the command line will send
output to the centronics port via Gemdos. The option
'-sOutputFile=CEN:' will write output directly to the
centronics port. These options can also be selected from
menus after GS is running.
The routines for direct centronics output were contributed by
Chris Strunk (CS-TeX)--THANKS! Direct centronics output is
generally much faster (about a factor of 4 for heavy
graphics). A subtle bug that caused centronics printing not
to work on some machines may now be fixed (thanks to Andrew
Paterson), so give it a try if it failed to work in the past.
For those with an Atari SLM laser printer, this driver sends
output directly to the printer (running the Diablo emulator),
so there is no need to specify the OutputFile. Some problems
have been reported with using the old Diablo emulator, so the
newest one is recommended. Also, the SLM driver is a major
memory hog, and users may encounter memory problems when
printing certain documents (like those with lots of fonts).
4.) The number of available drivers has increased to the point that it
is not feasible to include all that an ST owner might
reasonably use. The current choice of 21 drivers was decided
mostly by a vote of GS users on the internet (a couple were
included at my whim). Type 'gs -h' for a list of the
available drivers.
stvdi
slm
gemimg

- The screen device. Supports 1, 2, 4, 8, 16, & 24(?) bit color,

- Atari SLM laser printer (thanks to Robert Stabl),
- GEM bitmap format (thanks to Marcus Haebler),

deskjet
djet500
cdj500
cdj550

Generic HP DeskJet,
HP DeskJet 500,
H-P DeskJet 500C (same as cdjcolor)
HP DeskJet 550C/560C,

laserjet
ljetplus
ljet2p
ljet3
ljet4

Generic HP LaserJet,
HP LaserJet Plus,
HP LaserJet 2P,
HP LaserJet 3P,
HP LaserJet 4P,

bj10e
bj200

- Canon BubbleJet BJ10e

- Canon BubbleJet BJ200

epson
eps9high
epsonc
ap3250

Epson 9 and 24 pin printers (limited resolutions),

High resolution Epson 9-pin device (makes multiple passes),
Color epson printers,
Epson ESC/P 2,

st800
necp6

- Epson Stylus 800,

- NEC 360 dpi printer,

pbm
pbmraw
pgm
pgmraw
ppm
ppmraw

Portable
Portable
Portable
Portable
Portable
Portable

Bitmap (plain format)

Bitmap (raw format)
Graymap (plain format)
Graymap (raw format)
Pixmap (plain format) (RGB)
Pixmap (raw format) (RGB)

5.) The following environment variables are specific to the Atari port
of GS. See use.doc for standard environment variables (like
GS_LIB).
GS_WIN: Set this to "off" to disable windows. Otherwise the value of
this variable is ignored.
GS_HELPDIR: This is a comma-separated path to search for the Atari
Ghostscript help files.
GS_DISPLAY: Set this to "chunky8" to tell GS that your screen hardware
uses chunky pixel format. I don't think any graphics boards
actually use this format, but if they do, this will allow GS
to skip two image format transformations and save some time.
Otherwise GS will transform GS's native chunky format to standard
GEM color planes, and then transform back to chunky format for
display.
GS_DEBUG: This is used by me during debugging. I doubt it is of interest
to anyone else. Setting it to "gdebug" will cause some debugging
output to be printed to the console.
KNOWN BUGS, LIMITATIONS and POSSIBLE PROBLEMS:
See the doc files for some known bugs and problems.
1.) 24-bit color has not been tested; it may not work properly.
2.) Control-C to abort printing is not handled very gracefully.
3.) Fatal errors are still not handled gracefully. An alert is used to
keep the console window from closing before the error message
can be read, but the alert itself may cover some of the error
message.
4.) The CEN: output option may not work properly on some STEs and TTs.
I think this bug is now fixed, but am not sure.
5.) Programs which take control of the printer port can interfere with
Ghostscript's Atari SLM laser printer device. Also, you
should have the latest Diablo emulator to avoid output
problems under MultiTOS.
TIPS:
Here are a few miscellaneous tips.

1) Read the supplied documentation! It is a bit sparse for beginners,

but it is helpful and is quicker than sending me questions.
Use.doc is the most important file for casual users. GS is an
excellent tool for learning PostScript programming, but it is
not the intention of the docs to teach PS to you. If you want
to learn PostScript programming, you will probably need to buy
a PS programming book.
2) Try to arrange things so that you don't have to restart GS very
often. This startup takes a good deal of time. I have tried
to make this easier by providing menus to perform some common
operations. If you MUST restart GS often, putting the
initialization files in a ram disk significantly decreases
initialization time (at least on my system).
3) An archive named ps_picts.zoo contains some files on which to test
Ghostscript. These are some of the files that where used to
test the port.
4) GS can be used to view or print the output of dvips (TeX dvi to PS
translator). The combination of TeX (a typesetting program),
dvips, and GS can be used to preview TeX documents which
contain graphics at high resolution (if you need this sort of
thing and have the memory). I have gone up to 300dpi and it
seems to work OK. Dvips allows PS graphics to be easily
included in TeX documents. Note that 300dpi TeX documents
will not look very good when viewed on the screen at 80dpi,
since TeX fonts are not resolution independent.
5) You can change the Ghostscript prompt by editing the gs_init.ps
file. Search the file for GS or >, and then change this to
whatever you want the prompt to be. Many other changes can be
made in this file to alter the behavior of GS. For example,
you can redefine the 'showpage' command so that it doesn't
wait around for a CR to be typed after every page (this can
also be done from the command line or a menu). European users
can also set the default page size to A4 in this file.
6) You may find interesting things in the following Usenet newsgroups:
gnu.ghostscript.bug
comp.lang.postscript
comp.sources.postscript
ACKNOWLEDGMENTS:
Many kind people have contributed to the Atari version of Ghostscript.
Some of the more direct contributions are:
Hauke Hess:
Robert Stabl:
Marcus Haebler:
Chris Strunk:
Steve Eker:
Steven Ourada:
Markus Wenzel:
Andrew Paterson:
Thorsten Otto:
J. Bammi:

Original screen driver upon which stvdi was based,

The Atari SLM laser printer driver,
360 dpi NEC P6 and GEM image drivers,
Contributed code for direct centronics printing,
Contributed assembly image transformation algorithms,
Contributed assembly image transformation algorithms,
Color palette save and restore routines,
Possible fix to the centronics bug,
Code fixes and enhancements; the ORCS resource editor.
For gcc and numerous library bug fixes,

Please forgive me if I forgot to mention an important contribution,

and gently remind me of my omission.
FOR MORE INFO:
The original source files, docs, and fonts can be obtained from
ftp.cs.wisc.edu.
There is an Atari Ghostscript WWW page at
http://godel.ph.utexas.edu/Members/timg/gs.html, which contains a
Ghostscript Frequently Asked Questions list, in addition to some screen
shots and other information. This WWW page and the email address
have an uncertain future. They will, however, most likely be valid
through December 1995.
Send bug reports to:
Tim Gallivan
gallivan@ufpsprod.attmail.com