For other information, see the Ghostscript overview and the documents on how to build Ghostscript from source, Ghostscript C coding guidelines, drivers, the Ghostscript library and how to install Ghostscript.
The Ghostscript source code is divided conceptually as follows:
PostScript interpreter: PostScript operators
Other interpreter code
PDF interpreter: PostScript code
Graphics library: Main library code
gs.c is the main program for the interactive language
gserver.c is an alternative main program that
is a rudimentary server. If you configure Ghostscript as a server rather
than an interactive program, you will use
.c are Ghostscript operator
files. The names of the files generally follow the section headings of the
operator summary in section 6.2 (Second Edition) or 8.2 (Third Edition) of
the PostScript Language Reference Manual. Each operator XXX is implemented
by a procedure named
zXXX, for example,
.c, and *
.h, are the rest of the
interpreter. See the makefile for a little more information on how the
files are divided functionally.
The main loop of the PostScript interpreter is the
interp.c. When the interpreter is reading
from an input file, it calls the token scanner in
idebug.c contains a lot of debugger-callable routines
useful for printing PostScript objects when debugging.
The PDF interpreter is written entirely in PostScript. Its main loop is
.pdfrun procedure in
the PDF interpreter is configured into the build, it redefines the
run" operator to test whether the file is a PDF file.
This redefinition is near the beginning of
Files beginning with
gserver.c, are the
Ghostscript library. Files beginning with
gdev are device
drivers or related code, also part of the library. Other files beginning
g are library files that don't fall neatly into either
the kernel or the driver category.
.h are a flexible stream package,
including the Level 2 PostScript "filters" supported by Ghostscript. See
strimpl.h for all the details.
The interface between the graphics library and device drivers is the only really well documented one in all of Ghostscript: see the documentation on drivers.
In addition to many real device and file format drivers listed in
contrib.mak, a number of
drivers are used for internal purposes. You can search
lib.mak for files named
.c to find almost all of them.
Drivers are divided into "printer" drivers, which support banding, and
non-printer drivers, which don't. The decision whether banding is
required is made (by default on the basis of how much memory is available)
in the procedure
gdevprn.c: it implements this decision by filling the
virtual procedure table for the printer device in one of two different
A good simple "printer" (bandable) driver to read is
gdevmiff.c: it's less than 100 lines, of which much is
boilerplate. There are no simple non-printer drivers that actually drive
devices: probably the simplest non-printer driver for reading is
gdevm8.c, which implements 8-bit-deep devices that only
store the bits in memory.
There are very few platform dependencies in Ghostscript. Ghostscript deals with them in three ways:
_.hsubstitute for the corresponding
.h>file by adding conditionals that provide a uniform set of system interfaces on all platforms.
arch.hcontains a set of mechanically-discovered platform properties like byte order, size of
int, etc. These properties, not the names of specific platforms, are used to select between different algorithms or parameters at compile time.
.hdefine interfaces that are intended to be implemented differently on each platform, but whose specification is common to all platforms.
The platform-specific implementations of the
.h interfaces have names of the form
(this list may be out of date):
DOS and MS Windows
DOS, Borland compilers
DOS, Watcom or Microsoft compiler
DOS and MS Windows
MS Windows NT
Unix, OS-9, and QNX
Unix and QNX
System V Unix
MS Windows NT
If you are going to extend Ghostscript to new machines or operating
systems, check the *
_.h files for
things other than
DEBUG. You should probably plan to make
a new makefile and a new
This section is only for advanced developers who need to integrate Ghostscript into a larger program at build time.
NOTE: THIS SECTION IS INCOMPLETE. IT WILL BE IMPROVED IN A LATER REVISION.
The Ghostscript makefiles are meant to be organized according to the following two principles:
Thus, for example:
lib.mak. In principle this could be merged with
gs.mak, but we wanted to leave open the possibility that
gs.makmight be useful with hypothetical interpreter-only products.
unix.makfile, but because
makesometimes cares about the order of definitions, and because some of it is shared with DV/X, it got split between
For MS-DOS and MS Windows builds, there should be:
and so on.
Copyright © 2000-2018 Artifex Software, Inc. All rights reserved.
This software is provided AS-IS with no warranty, either express or implied. This software is distributed under license and may not be copied, modified or distributed except as expressly authorized under the terms of that license. Refer to licensing information at http://www.artifex.com/ or contact Artifex Software, Inc., 1305 Grant Avenue - Suite 200, Novato, CA 94945, U.S.A., +1(415)492-9861, for further information.
Ghostscript version 9.22, 4 October 2017