Information for Ghostscript developers

Introduction
Architecture

Design goals
Design principles
Large-scale structure
Object-oriented constructs

File roadmap

Substrate
Graphics library

Support, Paths, Text, Images, Paint, Clipping, Other graphics, Driver support, Font API support Visual Trace

Device drivers

Internal devices, PostScript and PDF writers, Other high-level devices, Other maintained drivers, Contributed drivers

PostScript interpreter

Main program, Data structures, Stacks, Interpreter loop, Scanning/parsing, Standard operators, Non-standard operators, Interpreter support, PostScript code

PDF interpreter
Build process

Makefile structure, .dev files, Generators, Support

Utilities

Utilities in PostScript
Utility scripts

Memory management

Memory manager architecture

Objects vs strings, Structure descriptors, Garbage collection, Movability, Parent hierarchy, Allocator API

Freeing storage

Explicit freeing, Reference counting, (Real) garbage collection

Special implementations

malloc, Locking, Retrying

Standard implementation
PostScript interpreter extensions

Refs (PostScript "objects"), save/.forgetsave/restore, Stable allocators, Garbage collection

Portability

Structural

CPU and compiler, Library headers, Cross-platform APIs, Makefiles

Coding

Explicit dependencies, Implicit dependencies

Platform-specific code

Adding features and options
Troubleshooting

For other information, see the Ghostscript overview and the documentation related to maintaining Ghostscript.

Introduction

This document provides a wealth of information about Ghostscript's internals, primarily for developers actively working on Ghostscript. It is primarily descriptive, documenting the way things are; the companion C style guide is primarily prescriptive, documenting what developers should do when writing new code.

THIS FILE IS A WORK IN PROGRESS. MANY SECTIONS ARE PLACE-HOLDERS.

Architecture

Design goals

Ghostscript has the following high-level design goals (not listed in order of importance):

Functionality
- Ability to interpret the current PostScript and PDF languages, as defined (and occasionally, in the case of conflict, as implemented) by Adobe.
- Ability to convert PostScript to and from PDF, comparable to Adobe products.
- Ability to produce output for a wide range of resolutions (from TV-resolution displays to imagesetters) and color models (black and white, multilevel gray, bilevel or multi-level RGB and CMYK, 6- or 8-color inkjet printers, spot color).
Performance
- Ability to render PostScript and PDF with commercial-quality performance (memory usage, speed, and output quality) on all platforms.
- Specifically, ability to render PostScript effectively in embedded environments with constrained RAM, including the ability to put the code and supporting data in ROM.
Licensing
- Licensing that supports both the Open Source / Free software communities and a commercial licensing business.
- Freedom from licensing restrictions or fees imposed by third parties.
Other
- Easy source portability to any platform (CPU, operating system, and development tools) that has an ANSI C compiler.
- Support for writing new interpreters and new drivers with no change to any existing code; specifically, ability to support PCL 5e, PCL 5c, and PCL XL interpreters, and the ever-changing roster of inkjet printers.

These goals often conflict: part of Ghostscript's claim to quality is that the conflicts have been resolved well.

Design principles

Part of what has kept Ghostscript healthy through many years of major code revisions and functional expansion is consistent and conscientious adherence to a set of design principles. We hope the following list captures the most important ones.

Non-preemption

Ghostscript is designed to be used as a component. As such, it must share its environment with other components. Therefore, it must not require ownership of, or make decisions about, inherently shared resources. Specifically, it must not assume that it can "own" either the locus of control or the management of the address space.

Not owning control means that whenever Ghostscript passes control to its caller, it must do so in a way that doesn't constrain what the caller can do next. The caller must be able to call any other piece of software, wait for an external event, execute another task, etc., without having to worry about Ghostscript being in an unknown state. While this is easy to arrange in a multi-threaded environment (by running Ghostscript in a separate thread), multi-threading APIs are not well standardized at this time (December 2000), and may not be implemented efficiently, or at all, on some platforms. Therefore, Ghostscript must choose between only two options for interacting with its caller: to return, preserving its own state in data structures, or to call back through a caller-supplied procedure. Calling back constrains the client program unacceptably: the callback procedure only has the options of either returning, or aborting Ghostscript. In particular, if it wants (for whatever reason) to multi-task Ghostscript with another program, it cannot do so in general, especially if the other program also uses callback rather than suspension. Therefore, Ghostscript tries extremely hard to return, rather than calling back, for all caller interaction. In particular:

For callers that want to pass input to Ghostscript piece by piece, Ghostscript returns with an e_NeedInput code rather than using a callback. This allows the caller complete flexibility in its control structure for managing the source of input. (It might, for example, be generating the input dynamically.)
In the future, the same arrangement should be used for input from stdin and output to stdout and stderr.
Likewise, scheduling of Ghostscript's own threads (contexts), currently done with a callback, should be done with suspension. The Display Ghostscript project (GNU DGS) is working on this.

The one area where suspension is not feasible with Ghostscript's current architecture is device output. Device drivers are called from deep within the graphics library. (If Ghostscript were being redesigned from scratch, we might try to do this with suspension as well, or at least optional suspension.)

Not owning management of the address space means that even though Ghostscript supports garbage collection for its own data, it must not do any of the things that garbage collection schemes for C often require: it must not replace 'malloc' and 'free', must not require its clients to use its own allocator, must not rely on manipulating the read/write status of memory pages, must not require special compiler or run-time support (e.g., APIs for scanning the C stack), must not depend on the availability of multi-threading, and must not take possession of one of a limited number of timer interrupts. However, in order not to constrain its own code unduly, it must also not require using special macros or calls to enter or leave procedures or assign pointers, and must not constrain the variety of C data structures any more than absolutely necessary. It achieves all of these goals, at the expense of some complexity, some performance cost (mostly for garbage collection), and some extra manual work required for each structure type allocated by its allocator. The details appear in the Memory management section below.

Multi-instantiability

From many years of experience with the benefits of object-oriented design, we have learned that when the word "the" appears in a software design -- "the" process scheduler, "the" memory manager, "the" output device, "the" interpreter, "the" stack -- it often flags an area in which the software will have difficulty adapting to future needs. For this reason, Ghostscript attempts to make every internal structure capable of existing in multiple instances. For example, Ghostscript's memory manager is not a one-of-a-kind entity with global state and procedures: it is (or rather they are, since Ghostscript has multiple memory managers, some of which have multiple instances) objects with their own state and (virtual) procedures. Ghostscript's PostScript interpreter has no writable non-local data (necessary, but not sufficient, to allow multiple instances), and in the future will be extended to be completely reentrant and instantiable. The device driver API is designed to make this easy for drivers as well. The graphics library is currently not completely reentrant or instantiable: we hope this will occur in the future.

Late configuration binding

Ghostscript is designed to make configuration choices as late as possible, subject to simplicity and performance considerations. The major binding times for such choices are compilation, linking, startup, and dynamic.

Compilation binds only CPU and compiler characteristics (including data type size, presence of floating point hardware, and data alignment), and whether the code will be used for production, debugging, or profiling.
Linking binds the choice of what features and device drivers will be included in the executable. (Work is underway to make the choice of drivers dynamic.)
Startup binds essentially nothing. Almost every option and parameter that can appear on the command line can also be changed dynamically.
The selection of output device, all parameters associated with the device, the selection of debugging printout and self-checking (in debugging configurations), the macro-allocation of memory, and almost all other operational parameters are dynamic.

In addition, a number of major implementation decisions are made dynamically depending on the availability of resources. For example, Ghostscript chooses between banded and non-banded rendering depending on memory availability.

Large-scale structure

At the largest design scale, Ghostscript consists of 4 layers. Layer N is allowed to use the facilities of all layers M <= N.

The bottom layer is called the substrate. It includes facilities like memory management, streams, fixed-point arithmetic, and low-level interfaces to the operating system. The substrate is written in C, with a little C++ and/or assembler code for some platforms.
The layer above the substrate is the graphics layer. It consists of two separate sub-parts. The graphics layer is written in C.
- The graphics library manages graphics state information for, and decomposes and renders 2-D images described using, a graphics model that is approximately the union of those of PostScript, PDF, and PCL 5e/5c/XL.
- The device drivers are called by the graphics library to produce actual output. The graphics library, and all higher layers, call device driver procedures only through virtual functions.
The principal clients of the graphics layer are language interpreters. Ghostscript as distributed includes the PostScript interpreter; there are also interpreters for PCL 5e, PCL 5c, and PCL XL, which are not currently freely redistributable and are not included in the standard Ghostscript package. The PostScript interpreter is written partly in C and partly in PostScript.
The PDF interpreter is actually a client of the PostScript interpreter: it is written entirely in PostScript.

The most important interface in Ghostscript is the API between the graphics library and the device drivers: new printers (and, to a lesser extent, window systems, displays, plotters, film recorders, and graphics file formats) come on the scene frequently, and it must be possible to produce output for them with a minimum of effort and distruption. This API is the only one that is extensively documented (see Drivers.htm) and kept stringently backward-compatible through successive releases.

Object-oriented constructs

Ghostscript makes heavy use of object-oriented constructs, including analogues of classes, instances, subclassing, and class-associated procedures. Since Ghostscript is written in C, not C++, implementing these constructs requires following coding conventions. The "Objects" section of the C style guide explains these.

The memory manager API provides run-time type information about each class, but this information does not include anything about subclassing. See under Structure descriptors below.

File roadmap

This section of the document provides a roadmap to all of the Ghostscript source files.

Substrate

Memory manager

See below.

Streams

Framework, file and string streams:

src/gsdsrc.c, src/gsdsrc.h, src/scommon.h, src/sfxboth.c, src/sfxfd.c, src/sfxstdio.c, src/stream.h, src/stream.c, src/strimpl.h.

Standard filters:

CCITTFax:: src/scf.h, src/scfd.c, src/scfdgen.c, src/scfdtab.c, src/scfe.c, src/scfetab.c, src/scfparam.c, src/scfx.h.
DCT (JPEG):: src/gsjconf.h, src/gsjmorec.h, src/sdcparam.c, src/sdcparam.h, src/sdct.h, src/sdctc.c, src/sdctd.c, src/sdcte.c, src/sddparam.c, src/sdeparam.c, src/sjpeg.h, src/sjpegc.c, src/sjpegd.c, src/sjpege.c.
JBIG2: src/sjbig2.h, src/sjbig2.c.
Other compression/decompression:: src/slzwc.c, src/slzwce.c, src/slzwd.c, src/slzwx.h, src/srld.c, src/srle.c, src/srlx.h.
Other:: src/sa85d.c, src/sa85d.h, src/sa85x.h, src/sfilter1.c, src/sfilter2.c, src/sstring.c, src/sstring.h.

Non-standard filters used to implement standard filters:

src/seexec.c, src/sfilter.h, src/shc.c, src/shc.h, src/shcgen.c, src/shcgen.h, src/spdiff.c, src/spdiffx.h, src/spngp.c, src/spngpx.h, src/szlibc.c, src/szlibd.c, src/szlibe.c, src/szlibx.h, src/szlibxx.h.

Non-standard filters:

src/sbcp.c, src/sbcp.h, src/sbhc.c, src/sbhc.h, src/sbtx.h, src/sbwbs.c, src/sbwbs.h, src/smd5.c, src/smd5.h, src/sarc4.c, src/sarc4.h, src/smtf.c, src/smtf.h.

Internal filters:

asrc/siinterp.c, src/siinterp.h, src/siscale.c, src/siscale.h, src/sisparam.h.

Higher-level stream support:

src/spprint.c, src/spprint.h, src/spsdf.c, src/spsdf.h, src/srdline.h.

Platform-specific code

See below.

Miscellaneous

Library top level:: src/gsinit.c, src/gslib.h.
Configuration-related:: src/gconf.c, src/gconf.h, src/gscdef.c, src/gscdefs.h.
Arithmetic:: src/gsfemu.c, src/gxarith.h, src/gxdda.h, src/gxfarith.h, src/gxfixed.h, src/gxfrac.h.
Operating system interface:: src/gserror.h, src/gsexit.h, src/gxstdio.h, src/gxsync.c, src/gxsync.h.
Other:: src/gsargs.c, src/gsargs.h, src/gserrors.h, src/gsnotify.c, src/gsnotify.h, src/gsrect.h, src/gstypes.h, src/gsuid.h, src/gsutil.h, src/gsutil.c, src/gx.h, src/md5.c, src/md5.h, src/md5main.c.

Graphics library

Images

Buffered API (mostly for PostScript interpreter):

src/gsimage.c, src/gsimage.h.

Generic support:

src/gsiparam.h, src/gxiclass.h, src/gximage.c, src/gximage.h, src/gxiparam.h.

Type 1 and 4 images:

Setup:: src/gsiparm4.h, src/gximage1.c, src/gximage4.c.
Rendering:: src/gxi12bit.c, src/gxicolor.c, src/gxidata.c, src/gxifast.c, src/gximono.c, src/gxino12b.c, src/gxipixel.c, src/gxiscale.c.

Type 2 images (Display PostScript):

src/gsiparm2.h, src/gximage2.c.

Type 3 images:

src/gsipar3x.h, src/gsiparm3.h, src/gximag3x.c, src/gximag3x.h, src/gximage3.c, src/gximage3.h.

Other:

src/gsimpath.c.

Paint

Ghostscript uses 4 internal representations of color. We list them here in the order in which they occur in the rendering pipeline.

Clients of the graphics library normally specify colors using the client color structure (gs_client_color, defined in src/gsccolor.h), consisting of one or more numeric values and/or a pointer to a Pattern instance. This corresponds directly to the values that would be passed to the PostScript setcolor operator: one or more (floating-point) numeric components and/or a Pattern. Client colors are interpreted relative to a color space (gs_color_space, defined in src/gscspace.h and src/gxcspace.h, with specific color spaces defined in other files). Client colors do not explicitly reference the color space in which they are are interpreted: setcolor uses the color space in the graphics state, while images and shadings explicitly specify the color space to be used.
For ordinary non-Pattern colors, the first step in color rendering reduces a client color to a concrete color -- a set of values in a color space that corresponds to the device's color model (except for possible conversions between DeviceGray, DeviceRGB, and DeviceCMYK), together with an identification of the associated color space. (The confusion here between color spaces and color models will have to be cleaned up when we implement native Separation/DeviceN colors.) Concrete colors are like the numeric values in a client color, except that they are represented by arrays of frac values (defined in src/gxfrac.h) rather than floats. The procedure for this step is the virtual concretize_color and concrete_space procedures in the (original) color space. This step reduces Indexed colors, CIEBased colors, and Separation and DeviceN colors that use the alternate space.
The final step requires mapping a concrete color to the device's color model, done by procedures in src/gxcmap.c. These procedures combine the following three conceptual sub-steps:
- A possible mapping between Device color spaces, possibly involving black generation and undercolor removal. The non-trivial cases are implemented in src/gxdcconv.c.
- Application of the transfer function(s) (done in-line).
- Halftoning if necessary: see below.
The result is called (inappropriately) a device color (gx_device_color, defined in src/gsdcolor.h and src/gxdcolor.h). For ordinary non-Pattern colors, a device color is either a pure color, or a halftone. The device and color model associated with a device color are implicit. The procedure for this step is the virtual remap_concrete_color procedure in the color space.
The pure colors that underlie a device color are opaque pixel values defined by the device (misnamed gx_color_index, defined in src/gscindex.h). The device with which they are associated is implicit. Although the format and interpretation of a pixel value are known only to the device, the device's color model and color representation capabilities are public, defined by a gx_color_info structure stored in the device (defined in src/gxdevcli.h). Virtual procedures of the device driver map between pixel values and RGB or CMYK. (This area is untidy and will need to be cleaned up when we implement native Separation/DeviceN colors.)

Steps 2 and 3 are normally combined into a single step for efficiency, as the remap_color virtual procedure in a color space.

Using a device color to actually paint pixels requires a further step called color loading, implemented by the load virtual procedure in the device color. This does nothing for pure colors, but loads the caches for halftones and Patterns.

All of the above steps -- concretizing, mapping to a device color, and color loading -- are done as late as possible, normally not until the color is actually needed for painting.

All painting operations (fill, stroke, imagemask/show) eventually call a virtual procedure in the device color, either fill_rectangle or fill_mask to actually paint pixels. For rectangle fills, pure colors call the device's fill_rectangle procedure; halftones and tiled Patterns call the device's tile_rectangle; shaded Patterns, and painting operations that involve a RasterOp, do something more complicated.

Color specification:: src/gsccolor.h, src/gscolor.c, src/gscolor.h, src/gscolor1.c, src/gscolor1.h, src/gscolor2.c, src/gscolor2.h, src/gscolor3.c, src/gscolor3.h, src/gshsb.c, src/gshsb.h, src/gxcolor2.h, src/gxcvalue.h.
Color spaces:: src/gscdevn.c, src/gscdevn.h, src/gscie.c, src/gscie.h, src/gscpixel.c, src/gscpixel.h, src/gscscie.c, src/gscsepnm.h, src/gscsepr.c, src/gscsepr.h, src/gscspace.c, src/gscspace.h, src/gscssub.c, src/gscssub.h, src/gxcdevn.h, src/gxcie.h, src/gxcspace.h.
Color mapping:: src/gsciemap.c, src/gscindex.h, src/gscrd.c, src/gscrd.h, src/gscrdp.c, src/gscrdp.h, src/gscsel.h, src/gsdcolor.h, src/gxcindex.h, src/gxcmap.c, src/gxcmap.h, src/gxctable.c, src/gxctable.h, src/gxdcconv.c, src/gxdcconv.h, src/gxdcolor.c, src/gxdcolor.h, src/gevndi.c, src/gxdevndi.h, src/gxdither.h, src/gxfmap.h, src/gxlum.h, src/gxtmap.h.
ICC profiles are in some ways a special case of color mapping, but are not standard in PostScript.
Color mapping:: src/gsicc.c, src/gsicc.h,

Ghostscript represents halftones internally by "whitening orders" -- essentially, arrays of arrays of bit coordinates within a halftone cell, specifying which bits are inverted to get from halftone level K to level K+1. The code does support all of the PostScript halftone types, but they are all ultimately reduced to whitening orders.

Threshold arrays, the more conventional representation of halftones, can be mapped to whitening orders straightforwardly; however, whitening orders can represent non-monotonic halftones (halftones where the bits turned on for level K+1 don't necessarily include all the bits turned on for level K), while threshold arrays cannot. On the other hand, threshold arrays allow rapid conversion of images (using a threshold comparison for each pixel) with no additional space, while whitening orders do not: they require storing the rendered halftone cell for each possible level as a bitmap.

Ghostscript uses two distinct types of rendered halftones -- that is, the bitmap(s) that represent a particular level.

Binary halftones. The rendered halftone is a single bit plane; each bit selects one of two pure colors. These are fast but limited: they are used for monochrome output devices, or for color devices in those cases where only two distinct colors are involved in a halftone (e.g., a pure cyan shade on a CMYK device). The device color for a binary halftone stores a pointer to the halftone bitmap, and the two pure colors.
Multi-plane halftones. Internally, each plane is rendered individually. Since there isn't enough room to store all 2^N pure colors, multi-plane halftones only store the scaled values for the individual components; the halftone renderer maps these to the pure colors on the fly, then combines the planes to assemble an N-bit index into the list of colors for each pixel, and stores the color into the fully rendered halftone.

The halftone level for rendering a color is computed in src/gxdevndi.c; the actual halftone mask or tile is computed either in src/gxcht.c (for multi-plane halftones), or in src/gxht.c and src/gxhtbit.c (for binary halftones).

Halftoning:: src/gsht.c, src/gsht.h, src/gsht1.c, src/gsht1.h, src/gshtscr.c, src/gshtx.c, src/gshtx.h, src/gxcht.c, src/gxdht.h, src/gxdhtres.h, src/gxht.c, src/gxht.h, src/gxhtbit.c, src/gxhttile.h, src/gxhttype.h, src/gzht.h.
Well tempered screening:: src/gswts.h, src/gswts.c, src/gxwts.h, src/gxwts.c.

Pattern colors (tiled patterns and shadings) each use a slightly different approach from solid colors.

The device color for a tiled (PatternType 1) pattern contains a pointer to a pattern instance, plus (for uncolored patterns) the device color to be masked. The pattern instance includes a procedure that actually paints the pattern if the pattern is not in the cache. For the PostScript interpreter, this procedure returns an e_RemapColor exception code: this eventually causes the interpreter to run the pattern's PaintProc, loading the rendering into the cache, and then re-execute the original drawing operator.

Patterns:: src/gspcolor.c, src/gspcolor.h, src/gsptype1.c, src/gsptype1.h, src/gxp1fill.c, src/gxp1impl.h, src/gxpcache.h, src/gxpcmap.c, src/gxpcolor.h.

The device color for a shading (PatternType 2) pattern also contains a pointer to a pattern instance. Shadings are not cached: painting with a shading runs the shading algorithm every time.

Shading:: src/gsptype2.c, src/gsptype2.h, src/gsshade.c, src/gsshade.h, src/gxshade.c, src/gxshade.h, src/gxshade1.c, src/gxshade4.c, src/gxshade4.h, src/gxshade6.c.

In addition to the PostScript graphics model, Ghostscript supports RasterOp, a weak form of alpha channel, and eventually the full PDF 1.4 transparency model. The implemention of these facilities is quite slipshod and scattered: only RasterOp is really implemented fully. There is a general compositing architecture, but it is hardly used at all, and in particular is not used for RasterOp. It is used for implementation of the general support for overprint and overprint mode.

Compositing architecture:: src/gscompt.h, src/gxcomp.h.
RasterOp:: src/gdevdrop.c, src/gdevrops.c, src/gsnorop.c, src/gsrop.c, src/gsrop.h, src/gsropc.c, src/gsropc.h, src/gsropt.h, src/gsroptab.c, src/gxdevrop.h, src/gxropc.h.
Alpha channel and compositing:: src/gsalpha.c, src/gsalpha.h, src/gsalphac.c, src/gsalphac.h, src/gsdpnext.h, src/gxalpha.h.
Advanced transparency:: src/gstparam.h, src/gstrans.c, src/gstrans.h, src/gxblend.c, src/gxblend.h, src/gdevp14.c, src/gdevp14.h, src/gdevpnga.c.
Overprint and Overprint mode:: src/gsovrc.c, src/gsovrc.h, src/gxoprect.c, src/gxoprect.h. There is support for both overprint and overprint mode. There is a general compositor based implementation of these features for all devices. In addition, the memory devices implement a higher speed set of special fill routines to improve performance for printer based devices.

Clipping

The Ghostscript graphics library implements clipping by inserting a clipping device in the device pipeline. The clipping device modifies all drawing operations to confine them to the clipping region.

The library supports three different kinds of clipping:

Region/path clipping: This corresponds to the PostScript concept of a clipping path. The clipping region is specified either by a list of rectangles (subject to the constraints documented in src/gxcpath.h), or by a path that is converted to such a list of rectangles.
Stationary mask clipping: This corresponds to the mask operand of a PostScript ImageType 3 image. The clipping region is specified by a bitmap and an (X,Y) offset in the coordinate space.
Tiled mask clipping: This corresponds to the region painted by a PostScript Pattern, for the case where the Pattern does not completely cover its bounding box but the combined transformation matrix has no skew or non-orthogonal rotation (i.e., XStep and YStep map respectively to (X,0) and (0,Y) or vice versa). The clipping region is specified by a bitmap and an (X,Y) offset in the coordinate space, and is replicated indefinitely in both X and Y.

Note that simply scan-converting a clipping path in the usual way does not produce a succession of rectangles that can simply be stored as the list for region-based clipping: in general, the rectangles do not satisfy the constraint for rectangle lists specified in src/gxcpath.h, since they may overlap in X, Y, or both. A non-trivial "clipping list accumulator" device is needed to produce a rectangle list that does satisfy the constraint.

Clipping support:: src/gxclip.c, src/gxclip.h.
Region/path clipping:: src/gxcpath.c, src/gxcpath.h, src/gzcpath.h.
Clipping list accumulator:: src/gxacpath.c, src/gzacpath.h.
Mask clipping support:: src/gxmclip.c, src/gxmclip.h.
Stationary mask clipping:: src/gxclipm.c, src/gxclipm.h.
Tiled mask clipping:: src/gxclip2.c, src/gxclip2.h.

Other graphics

Miscellaneous graphics state:: src/gsclipsr.c, src/gsclipsr.h, src/gsdps.c, src/gsdps.h, src/gsdps1.c, src/gsistate.c, src/gsline.c, src/gsline.h, src/gslparam.h, src/gsstate.c, src/gsstate.h, src/gstrap.c, src/gstrap.h, src/gxclipsr.h, src/gxistate.h, src/gxline.h, src/gxstate.h, src/gzline.h, src/gzstate.h.

Font API support

UFST bridge:: src/gxfapi.c, src/gxfapi.h.

Driver support

Generic driver support:: src/gdevdcrd.c, src/gdevdcrd.h, src/gdevemap.c, src/gsdevice.c, src/gsdevice.h, src/gsdparam.c, src/gsxfont.h, src/gxdevbuf.h, src/gxdevcli.h, src/gxdevice.h, src/gxrplane.h, src/gxxfont.h.
Accessing rendered bits:: src/gdevdbit.c, src/gdevdgbr.c, src/gxbitfmt.h, src/gxgetbit.h.
"Printer" driver support:: src/gdevmeds.c, src/gdevmeds.h, src/gdevppla.c, src/gdevppla.h, src/gdevprn.c, src/gdevprn.h, src/gdevprna.c, src/gdevprna.h, src/gxband.h, src/gxpageq.c, src/gxpageq.h.
High-level device support:: src/gdevvec.c, src/gdevvec.h, src/gxhldevc.c, src/gxhldevc.h.
Banding:: src/gxclbits.c, src/gxcldev.h, src/gxclfile.c, src/gxclimag.c, src/gxclio.h, src/gxclist.c, src/gxclist.h, src/gxcllzw.c, src/gxclmem.c, src/gxclmem.h, src/gxclpage.c, src/gxclpage.h, src/gxclpath.c, src/gxclpath.h, src/gxclrast.c, src/gxclread.c, src/gxclrect.c, src/gxclutil.c, src/gxclzlib.c, src/gxdhtserial.c, src/gxdhtserial.h, src/gsserial.c, src/gsserial.h.

Visual Trace

Visual Trace support :: src/vdtrace.h, src/vdtrace.c.

See doc/Lib.htm for extensive documentation on Visual Trace instructions.

Device drivers

See doc/Drivers.htm for extensive documentation on the interface between the core code and drivers.

The driver API includes high-level (path / image / text), mid-level (polygon), and low-level (rectangle / raster) operations. Most devices implement only the low-level operations, and let generic code break down the high-level operations. However, some devices produce high-level output, and therefore must implement the high-level operations.

Internal devices

There are a number of "devices" that serve internal purposes. Some of these are meant to be real rendering targets; others are intended for use in device pipelines. The rendering targets are:

Memory devices, depth-independent:: src/gdevmem.c, src/gdevmem.h, src/gdevmpla.c, src/gdevmpla.h, src/gdevmrop.h, src/gsdevmem.c, src/gxdevmem.h.
Memory devices, specific depths:: src/gdevm1.c, src/gdevm2.c, src/gdevm4.c, src/gdevm8.c, src/gdevm16.c, src/gdevm24.c, src/gdevm32.c, src/gdevm40.c, src/gdevm48.c, src/gdevm56.c, src/gdevm64.c, src/gdevmr1.c, src/gdevmr2n.c, src/gdevmr8n.c.
Alpha-related devices:: src/gdevabuf.c.
Other devices:: src/gdevdflt.c, src/gdevhit.c, src/gdevmrun.c, src/gdevmrun.h, src/gdevplnx.c, src/gdevplnx.h.

The forwarding devices meant for use in pipelines are:

The bounding box device:: src/gdevbbox.h, src/gdevbbox.c.
Clipping devices:: See under Clipping above.
Device filter stack:: src/gsdfilt.c, src/gsdfilt.h.
Other devices:: src/gdevcmap.c, src/gdevcmap.h, src/gdevnfwd.c.

PostScript and PDF writers

Because PostScript and PDF have the same graphics model, lexical syntax, and stack-based execution model, the drivers that produce PostScript and PDF output share a significant amount of support code. In the future, the PostScript output driver should be replaced with a slightly modified version of the PDF driver, since the latter is far more sophisticated (in particular, it has extensive facilities for image compression and for handling text and fonts).

The PDF code for handling text and fonts is complex and fragile. A major rewrite in June 2002 was intended to make it more robust and somewhat easier to understand, but also increased its size by about 40%, contrary to the expectation that it would shrink. Currently both sets of code are in the code base, with compatible APIs, selected by a line in src/devs.mak.

Shared support:

src/gdevpsf.h, src/gdevpsf1.c, src/gdevpsf2.c, src/gdevpsfm.c, src/gdevpsft.c, src/gdevpsfu.c, src/gdevpsfx.c, src/gscedata.c, src/gscedata.h, src/gscencs.c, src/gscencs.h.
Other:: src/gdevpsdf.h, src/gdevpsdi.c, src/gdevpsdp.c, src/gdevpsds.c, src/gdevpsds.h, src/gdevpsdu.c.

PostScript output driver ([e]pswrite):

src/gdevps.c, src/gdevpsu.c, src/gdevpsu.h.

PDF output driver (pdfwrite):

Substrate:: src/gdevpdfo.c, src/gdevpdfo.h, src/gdevpdfr.c, src/gdevpdfu.c.
Old text and fonts:: src/gdevpdfe.c, src/gdevpdff.c, src/gdevpdff.h, src/gdevpdfs.c, src/gdevpdft.c, src/gdevpdft.h, src/gdevpdfw.c.
New text and fonts:: src/gdevpdt.c, src/gdevpdt.h, src/gdevpdtb.c, src/gdevpdtb.h, src/gdevpdtc.c, src/gdevpdtd.c, src/gdevpdtd.h, src/gdevpdte.c, src/gdevpdtf.c, src/gdevpdtf.h, src/gdevpdti.c, src/gdevpdti.h, src/gdevpdts.c, src/gdevpdts.h, src/gdevpdtt.c, src/gdevpdtt.h, src/gdevpdtv.c, src/gdevpdtv.h, src/gdevpdtw.c, src/gdevpdtw.h, src/gdevpdtx.h.
Graphics:: src/gdevpdfc.c, src/gdevpdfc.h, src/gdevpdfd.c, src/gdevpdfg.c, src/gdevpdfg.h, src/gdevpdfk.c, src/gdevpdfv.c.
Images:: src/gdevpdfb.c, src/gdevpdfi.c, src/gdevpdfj.c.
Other:: src/gdevpdf.c, src/gdevpdfm.c, src/gdevpdfp.c, src/gdevpdfx.h.

Other high-level devices

Currently, the CGM driver is raster-only. If anyone cares seriously about CGM in the future, this driver should be upgraded to a higher level.

PCL XL output device (pxlmono, pxlcolor):: src/gdevpx.c, src/gdevpxat.h, src/gdevpxen.h, src/gdevpxop.h, src/gdevpxut.c, src/gdevpxut.h.
Other high-level devices:: src/gdevtrac.c.

Other maintained drivers

The standard Ghostscript distribution includes a collection of drivers, mostly written by Aladdin Enterprises, that are "maintained" in the same sense as the Ghostscript core code.

Display drivers:

src/gdev8bcm.c, src/gdev8bcm.h, src/gdevegaa.asm, src/gdevevga.c, src/gdevl256.c, src/gdevpccm.c, src/gdevpccm.h, src/gdevpcfb.c, src/gdevpcfb.h, src/gdevs3ga.c, src/gdevsco.c, src/gdevsvga.c, src/gdevsvga.h, src/gdevvglb.c.

Window system drivers:

X Windows:: src/gdevx.c, src/gdevx.h, src/gdevxalt.c, src/gdevxcmp.c, src/gdevxcmp.h, src/gdevxini.c, src/gdevxres.c, src/gdevxxf.c.
Microsoft Windows:: src/gdevmswn.c, src/gdevmswn.h, src/gdevmsxf.c, src/gdevwddb.c, src/gdevwdib.c.
OS/2 Presentation Manager:: src/gdevpm.c, src/gdevpm.h, src/gspmdrv.c, src/gspmdrv.h.

Raster file output drivers:

Fax and TIFF:: src/gdevfax.c, src/gdevfax.h, src/gdevtfax.c, src/gdevtfax.h, src/gdevtifs.c, src/gdevtifs.h, src/gdevtfnx.c.
(Low-level) CGM:: src/gdevcgm.c, src/gdevcgml.c, src/gdevcgml.h, src/gdevcgmx.h.
Example DeviceN devices:: src/gdevdevn.c, src/gdevdevn.h, src/gdevxcf.c, src/gdevpsd.c, src/gdevperm.c.
Other raster file formats:: src/gdevbit.c, src/gdevbmp.c, src/gdevbmp.h, src/gdevbmpa.c, src/gdevbmpc.c, src/gdevjpeg.c, src/gdevmiff.c, src/gdevp2up.c, src/gdevpcx.c, src/gdevpbm.c, src/gdevpng.c, src/gdevpsim.c.

Printer drivers:

Operating system printer services:: src/gdevos2p.c, src/gdevwpr2.c, src/gdevwprn.c.
H-P monochrome printers:: src/gdevdljm.c, src/gdevdljm.h, src/gdevdjet.c, src/gdevlj56.c.
Other printers:: src/gdevatx.c.

Contributed drivers

This list is likely to be incomplete and inaccurate: see src/contrib.mak for the real one.

Display and window system drivers:: src/gdev3b1.c, src/gdevherc.c, src/gdevpe.c, src/gdevsnfb.c, src/gdevsun.c.
Raster file output drivers:: src/gdevcfax.c, src/gdevcif.c, src/gdevdfax.c, src/gdevifno.c, src/gdevmgr.c, src/gdevmgr.h, src/gdevsgi.c, src/gdevsgi.h, src/gdevsunr.c.
Printer drivers:: lib/bj8.rpd, lib/cbjc600.ppd, lib/cbjc800.ppd, src/gdev3852.c, src/gdev4081.c, src/gdev4693.c, src/gdev8510.c, src/gdevadmp.c, src/gdevbj10.c, src/gdevbjc.h, src/gdevbjcl.c, src/gdevbjcl.h, src/gdevccr.c, src/gdevcdj.c, src/gdevclj.c, src/gdevcljc.c, src/gdevcp50.c, src/gdevcslw.c, src/gdevdjtc.c, src/gdevdm24.c, src/gdevepsc.c, src/gdevepsn.c, src/gdevescp.c, src/gdevhl7x.c, src/gdevijs.c, src/gdevimgn.c, src/gdevl31s.c, src/gdevlbp8.c, src/gdevlp8k.c, src/gdevlxm.c, src/gdevn533.c, src/gdevo182.c, src/gdevokii.c, src/gdevpcl.c, src/gdevpcl.h, src/gdevphex.c, src/gdevpjet.c, src/gdevsj48.c, src/gdevsppr.c, src/gdevstc.c, src/gdevstc.h, src/gdevstc1.c, src/gdevstc2.c, src/gdevstc3.c, src/gdevstc4.c, src/gdevtknk.c, src/gdevupd.c.

PostScript interpreter

The PostScript interpreter is conceptually simple: in fact, an interpreter that could execute "3 4 add =" and print "7" was running 3 weeks after the first line of Ghostscript code was written. However, a number of considerations make the code large and complex.

The interpreter is designed to run in environments with very limited memory. The main consequence of this is that it cannot allocate its stacks (dictionary, execution, operand) as ordinary arrays, since the user-specified stack size limit may be very large. Instead, it allocates them as a linked list of blocks. See below for more details.

The interpreter must never cause a C runtime error that it cannot trap. Unfortunately, C implementations almost never provide the ability to trap stack overflow. In order to put a fixed bound on the C stack size, the interpreter never implements PostScript recursion by C recursion. This means that any C code that logically needs to call the interpreter must instead push a continuation (including all necessary state information) on the PostScript execution stack, followed by the PostScript object to be executed, and then return to the interpreter. (See src/estack.h for more details about continuations.) Unfortunately, since PostScript Level 2 introduces streams whose data source can be a PostScript procedure, any code that reads or writes stream data must be prepared to suspend itself, storing all necessary state in a continuation. There are some places where this is extremely awkward, such as the scanner/parser.

The use of continuations affects many places in the interpreter, and even some places in the graphics library. For example, when processing an image, one may need to call a PostScript procedure as part of mapping a CIE color to a device color. Ghostscript uses a variety of dodges to handle this: for example, in the case of CIE color mapping, all of the PostScript procedures are pre-sampled and the results cached. The Adobe implementation limits this kind of recursion to a fixed number of levels (5?): this would be another acceptable approach, but at this point it would require far more code restructuring than it would be worth.

A significant amount of the PostScript language implementation is in fact written in PostScript. Writing in PostScript leverages the C code for multi-threading, garbage collection, error handling, continuations for streams, etc., etc.; also, we have found PostScript in general more concise and easier to debug than C, mostly because of memory management issues. So given the choice, we tended to implement a feature in PostScript if it worked primarily with PostScript data structures, wasn't heavily used (example: font loading), or if it interacted with the stream or other callback machinery (examples: ReusableFileDecode streams, resourceforall). Often we would add non-standard PostScript operators for functions that had to run faster or that did more C-like things, such as the media matching algorithm for setpagedevice.

Main program

The main program of the interpreter is normally invoked from the command line, but it has an API as well. In fact, it has two APIs: one that recognizes the existence of multiple "interpreter instances" (although it currently provides a default instance, which almost all clients use), and a completely different one designed for Windows DLLs. These should be unified as soon as possible, since there are two steadily growing incompatible bodies of client code.

Files:: src/gs.c, src/gserver.c, src/iccinit0.c, src/iinit.c, src/iinit.h, src/imain.c, src/imain.h, src/imainarg.c, src/imainarg.h, src/iminst.h, src/main.h.

Data structures

The main data structures visible to the PostScript programmers are arrays, contexts, dictionaries, names, and stacks.

Arrays have no unusual properties. See under Refs below for more information about how array elements are stored.

Contexts are used to hold the interpreter state even in configurations that don't include the Display PostScript multiple context extension. Context switching is implemented by a complex cooperation of C and PostScript code.

Dictionaries have two special properties worth noting:

They use an optimized storage representation if all the keys are names, which is almost always the case.
They interact with a caching scheme used to accelerate name lookup in the interpreter.

Names are allocated in blocks. The characters and hash chains are stored separately from the lookup cache information, so that in the future, most of the former can be compiled into the executable and shared or put in ROM. (This is not actually done yet.)

Contexts:: src/icontext.c, src/icontext.h, src/icstate.h.
Dictionaries:: src/iddict.h, src/idict.h, src/idict.c, src/idictdef.h.
Names:: src/iname.c, src/iname.h, src/inamedef.h, src/inameidx.h, src/inames.h, src/inamestr.h.

Stacks

As mentioned above, each stack is allocated as a linked list of blocks. However, for reasonable performance, operators must normally be able to access their operands and produce their results using indexing rather than an access procedure. This is implemented by ensuring that all the operands of an operator are in the topmost block of the stack, using guard entries that cause an internal error if the condition isn't met. See src/iostack.h for more details.

Generic stacks:

src/isdata.h, src/istack.c, src/istack.h, src/istkparm.h.

Specific stacks:

Dictionary stack:: src/dstack.h, src/iddstack.h, src/idsdata.h, src/idstack.c, src/idstack.h.
Execution stack:: src/estack.h, src/iesdata.h, src/iestack.h.
Operand stack:: src/iosdata.h, src/iostack.h, src/ostack.h.

Interpreter loop

Files:: src/interp.c, src/interp.h.

Scanning/parsing

PostScript parsing consists essentially of token scanning, and is simple in principle. The scanner is complex because it must be able to suspend its operation at any time (i.e., between any two input characters) to allow an interpreter callout, if its input is coming from a procedure-based stream and the procedure must be called to provide more input data.

Main scanner:: src/iscan.c, src/iscan.h, src/iscannum.c, src/iscannum.h, src/scanchar.h, src/scantab.c.
Binary tokens:: src/btoken.h, src/ibnum.c, src/ibnum.h, src/inobtokn.c, src/iscanbin.c, src/iscanbin.h.
DSC parsing:: src/dscparse.c, src/dscparse.h.

Standard operators

Non-output-related:

Filters:: src/ifilter.h, src/ifilter2.h, src/ifrpred.h, src/ifwpred.h, src/istream.h, src/zfbcp.c, src/zfdctd.c, src/zfdcte.c, src/zfdecode.c, src/zfilter.c, src/zfilter2.c, src/zfilterx.c, src/zfjbig2.c, src/zfmd5.c, src/zfarc4.c, src/zfproc.c, src/zfrsd.c, src/zfzlib.c.
File and stream I/O:: src/files.h, src/itoken.h, src/zbseq.c, src/zdscpars.c, src/zfile.c, src/zfile1.c, src/zfileio.c, src/ztoken.c.
Data structures:: src/zarray.c, src/zdict.c, src/zgeneric.c, src/zpacked.c, src/zstring.c.
Functions:: src/ifunc.h, src/zfunc.c, src/zfunc0.c, src/zfunc3.c, src/zfunc4.c,
Other:: src/ivmem2.h, src/zarith.c, src/zcontext.c, src/zcontrol.c, src/zmath.c, src/zmatrix.c, src/zmisc.c, src/zmisc1.c, src/zmisc2.c, src/zmisc3.c, src/zrelbit.c, src/zstack.c, src/ztype.c, src/zusparam.c, src/zvmem.c, src/zvmem2.c.

Output-related:

Device management:: src/zdevcal.c, src/zdevice.c, src/zdevice2.c, src/ziodev.c, src/ziodev2.c, src/ziodevs.c, src/ziodevsc.c, src/ziodevst.c, src/zmedia2.c, src/zdfilter.c.
Fonts and text:: src/bfont.h, src/ccfont.h, src/iccfont.c, src/icfontab.c, src/ichar.h, src/ichar1.h, src/icharout.h, src/icid.h, src/ifcid.h, src/ifont.h, src/ifont1.h, src/ifont2.h, src/ifont42.h, src/zbfont.c, src/zcfont.c, src/zchar.c, src/zchar1.c, src/zchar2.c, src/zchar32.c, src/zchar42.c, src/zchar42.h, src/zcharout.c, src/zcharx.c, src/zcid.c, src/zcidtest.c, src/zfcid.c, src/zfcid0.c, src/zfcid1.c, src/zfcmap.c, src/zfont.c, src/zfont0.c, src/zfont1.c, src/zfont2.c, src/zfont32.c, src/zfont42.c, src/zfontenum.c.
A bridge to the True Type bytecode interpreter:: src/gxttfb.c, src/gxttfb.h, src/ttfoutl.h, src/ttfmain.c, src/ttfmemd.c, src/ttfmemd.h, src/ttfinp.c, src/ttfinp.h.
A reduced True Type bytecode interpreter: (this is based in part on the work of the Freetype Team and incorporates some code from the FreeType 1 project): src/ttfsfnt.h, src/ttcalc.c, src/ttcalc.h, src/ttcommon.h, src/ttconf.h, src/ttconfig.h, src/ttinterp.c, src/ttinterp.h, src/ttload.c, src/ttload.h, src/ttmisc.h, src/ttobjs.c, src/ttobjs.h, src/tttables.h, src/tttype.h, src/tttypes.h.
Color, pattern, and halftone:: src/icie.h, src/icolor.h, src/icremap.h, src/icsmap.h, src/iht.h, src/ipcolor.h, src/zcie.c, src/zcolor.c, src/zcolor1.c, src/zcolor2.c, src/zcolor3.c, src/zcrd.c, src/zcsdevn.c, src/zcsindex.c, src/zcspixel.c, src/zcssepr.c, src/zicc.c, src/zhsb.c, src/zht.c, src/zht1.c, src/zht2.h, src/zht2.c, src/zpcolor.c, src/zshade.c, src/ztrans.c.
Images:: src/iimage.h, src/iimage2.h, src/zimage.c, src/zimage2.c, src/zimage3.c.
Other graphics:: src/igstate.h, src/zdpnext.c, src/zdps.c, src/zdps1.c, src/zgstate.c, src/zpaint.c, src/zpath.c, src/zpath1.c, src/zrop.c, src/ztrap.c, src/zupath.c.

Operator support:

src/oparc.h, src/opcheck.h, src/opdef.h, src/oper.h, src/opextern.h.

Non-standard operators

The interpreter includes many non-standard operators. Most of these provide some part of the function of a standard operator, so that the standard operator itself can be implemented in PostScript: these are not of interest to users, and their function is usually obvious from the way they are used. However, some non-standard operators provide access to additional, non-standard facilities that users might want to know about, such as transparency, RasterOp, and in-memory rendering. These are documented at Language.htm#Additional_operators.

We don't document the complete set of non-standard operators here, because the set changes frequently. However, all non-standard operators are supposed to have names that begin with '.', so you can find them all by executing the following (Unix) command:

grep '{".[.]' src/[zi]*.c

In addition to individual non-standard operators implemented in the same files as standard ones, there are several independent optional packages of non-standard operators. As with other non-standard operators, the names of all the operators in these packages begin with '.'. We list those packages here.

src/zdosio.c: Provides access to PC hardware I/O through MS-DOS system calls. Probably no longer useful.
src/zdouble.c: Provides "double" floating point arithmetic, using 8-byte strings to hold values. Developed under a contract; probably used only by the group that funded the development.
src/zfsample.c,: Provides a special operator to sample a given function and create a new type 0 function.
src/zsysvm.c: Provides operators for allocating objects in specific VM spaces, disregarding the current VM mode.

Interpreter support

Memory management (refs, GC, save/restore) -- see below.

Font API :: src/ifapi.h, src/zfapi.c, src/fapiufst.c, src/fapi_ft.c, src/wrfont.h, src/wrfont.c, src/write_t1.h, src/write_t1.c, src/write_t2.h, src/write_t2.c,
Miscellaneous support:: src/ierrors.h, src/errors.h (deprecated), src/ghost.h, src/iconf.c, src/iconf.h, src/idparam.c, src/idparam.h, src/ilevel.h, src/inouparm.c, src/iparam.c, src/iparam.h, src/iparray.h, src/iutil.c, src/iutil.h, src/iutil2.c, src/iutil2.h, src/iutilasm.asm, src/iplugin.c, src/iplugin.h.

PostScript code

Initialization and language support:

All configurations:: lib/gs_init.ps, lib/gs_statd.ps.
Level 2:: lib/gs_btokn.ps, lib/gs_dps1.ps, lib/gs_dps2.ps, lib/gs_lev2.ps, lib/gs_res.ps, lib/gs_resmp.ps, lib/gs_resst.ps, lib/gs_stres.ps, lib/gs_setpd.ps.
LanguageLevel 3:: lib/gs_frsd.ps, lib/gs_ll3.ps, lib/gs_trap.ps.
Display PostScript:: lib/gs_dpnxt.ps, lib/gs_dps.ps.

Color Spaces and support:

Color Space Loading:: lib/gs_ciecs2.ps, lib/gs_ciecs3.ps, lib/gs_cspace.ps, lib/gs_devcs.ps, lib/gs_devn.ps, lib/gs_devpxl.ps, lib/gs_indxd.ps, lib/gs_patrn.ps, lib/gs_sepr.ps.
ICC color profiles:: lib/gs_icc.ps.

Font loading and support:

Font name mapping:: lib/Fontmap, lib/Fontmap.ATB, lib/Fontmap.ATM, lib/Fontmap.GS, lib/Fontmap.OS2, lib/Fontmap.OSF, lib/Fontmap.SGI, lib/Fontmap.Sol, lib/Fontmap.Ult, lib/Fontmap.VMS, lib/cidfmap, lib/FAPIcidfmap, lib/FAPIfontmap.
Generic:: lib/gs_ccfnt.ps, lib/gs_fonts.ps, lib/gs_fntem.ps.
Type 1 and CFF:: lib/gs_cff.ps, lib/gs_diskf.ps, lib/gs_type1.ps.
TrueType:: lib/gs_ttf.ps, lib/gs_typ42.ps.
CID-keyed:: lib/gs_cidcm.ps, lib/gs_cidfn.ps, lib/gs_cmap.ps, lib/gs_ciddc.ps, lib/gs_cidfm.ps, lib/gs_cidtt.ps.
Font API:: lib/gs_fapi.ps, lib/FAPIconfig, lib/xlatmap.
Other:: lib/gs_kanji.ps, lib/gs_pfile.ps, lib/gs_typ32.ps.

Encodings:

Adobe-specified:: lib/gs_ce_e.ps, lib/gs_dbt_e.ps, lib/gs_il1_e.ps, lib/gs_mex_e.ps, lib/gs_mro_e.ps, lib/gs_pdf_e.ps, lib/gs_std_e.ps, lib/gs_sym_e.ps, lib/gs_wan_e.ps.
Additional:: lib/gs_il2_e.ps, lib/gs_ksb_e.ps, lib/gs_wl1_e.ps, lib/gs_wl2_e.ps, lib/gs_wl5_e.ps.
Pseudo-encodings for internal use:: lib/gs_css_e.ps, lib/gs_lgo_e.ps, lib/gs_lgx_e.ps, lib/gs_mgl_e.ps.

Miscellaneous:

Image support:: lib/gs_img.ps,
Emulation of %disk IODevice:: lib/gs_diskn.ps,
Other support:: lib/gs_agl.ps, lib/gs_dscp.ps, lib/gs_epsf.ps, lib/gs_pdfwr.ps, lib/gs_rdlin.ps.
X Windows icon bitmaps:: lib/gs_l.xbm, lib/gs_l.xpm, lib/gs_l_m.xbm, lib/gs_m.xbm, lib/gs_m.xpm, lib/gs_m_m.xbm, lib/gs_s.xbm, lib/gs_s.xpm, lib/gs_s_m.xbm, lib/gs_t.xbm, lib/gs_t.xpm, lib/gs_t_m.xbm.
Not currently used:: lib/gs_cmdl.ps, lib/gs_fform.ps, lib/gs_l2img.ps.

PDF interpreter

Ghostscript's PDF interpreter is written entirely in PostScript, because its data structures are the same as PostScript's, and it is much more convenient to manipulate PostScript-like data structures in PostScript than in C. There is definitely a performance cost, but apparently not a substantial one: we considered moving the main interpreter loop (read a token using slightly different syntax than PostScript, push it on the stack if literal, look it up in a special dictionary for execution if not) into C, but we did some profiling and discovered that this wasn't accounting for enough of the time to be worthwhile.

Until recently, there was essentially no C code specifically for the purpose of supporting PDF interpretation. The one major exception is the PDF 1.4 transparency features, which we (but not Adobe) have made available to PostScript code.

In addition to patching the run operator to detect PDF files, the interpreter provides some procedures in lib/pdf_main.ps that are meant to be called from applications such as previewers.

Files:: lib/pdf_base.ps, lib/pdf_draw.ps, lib/pdf_font.ps, lib/pdf_main.ps, lib/pdf_rbld.ps, lib/pdf_ops.ps, lib/pdf_sec.ps.

Build process

Makefile structure

Ghostscript's makefiles embody a number of design decisions and assumptions that may not be obvious from a casual reading of the code.

All files are stored in subdirectories. The names of all subdirectories used in the build process are defined in the top-level makefiles for the various platforms: there are no "hard wired" directory names in any makefile rule. Subdirectory names in the makefiles are relative to the directory that is current at build time: normally this directory is the parent of the various subdirectories, and holds only a makefile, which in turn simply references the real top-level makefile in the source subdirectory.
All compiler and linker switches are likewise defined by macros, again preferably in the top-level platform makefile.
There is an absolute distinction between "source-like" subdirectories, which are read-only during the build process, and "object-like" subdirectories, all of whose contents are generated by the build process and which can be emptied (rm *) at any time with no bad effects. The source subdirectories are defined by macros named xxxSRCDIR.
Object subdirectories may distinguish further between those that hold the results of the build process that are needed at run time (i.e., that should be included in a run-time distribution), defined by BINDIR, and those that are not needed at run time, defined by xxxGENDIR and xxxOBJDIR. (The distinction between these is historical and probably no longer relevant.)
There may be multiple object subdirectories for different build configurations. On Unix, the obj and bin directories are used for normal production builds, the debugobj directory for debugging builds, and the pgobj directory for profiling builds; other platforms may use different conventions. The Unix makefiles support targets named debug and pg for debugging and profiling builds respectively; other platforms generally do not.
Makefiles will be maintained by hand. This requires editing the following makefile elements whenever the relevant source files changes:
- Every header (.h) file must have a corresponding macro definition in a makefile. If abc.h #includes def.h and xyz.h, the definition must have the form
```
xyz_h=$(xxxSRCD)xyz.h $(def_h) $(xyz_h)
```
  where xxxSRCD is the macro defining the relevant source directory (including a trailing '/'). Note that the '.' in the file name has been replaced by an underscore. Note also that the definition must follow all definitions it references, since some make programs expand macros in definitions at the time of definition rather than at the time of use.
- Every .c file must have a corresponding rule in a makefile. If abc.c #includes def.h and lmn.h, the rule must have approximately the form
```
$(xxxOBJD)abc.$(OBJ) : $(xxxSRCD)abc.c $(def_h) $(lmn_h)
    $(xxCC) $(xxO_)abc.$(OBJ) $(C_) $(xxxSRCD)abc.c
```
  where xxxSRCD is as before; xxxOBJD is the relevant object directory; xxCC defines the name of the C compiler plus the relevant compilation switches; and xxO_ and C_ are macros used to bridge syntactic differences between different make programs.

The requirement to keep makefiles up to date by hand has been controversial. Two alternatives are generally proposed.

Programs like makedeps, which generate build rules automatically from the #include lists in C files. We have found such programs useless: they "wire in" specific, concrete directory names, not only for our own code but even for the system header files; they have to be run manually whenever code files are added, renamed, or deleted, or whenever the list of #includes in any file changes; and they cannot deal with different source files requiring different compilation switches.
MSVC-style "project" files. These are equally useless: they are not portable across different vendors' tools -- in fact, there may not even be a usable import/export facility to convert their data to or from text form -- and they cannot combine configuration-independent data with configuration-specific data.

We have seriously considered writing our own build program in Tcl or Python that would eliminate these problems, or perhaps porting the tools developed by Digital's Vesta research project (if we can get access to them); however, either of these approaches would create potential portability problems of its own, not to mention difficulties in integrating with others' build systems.

For more information about makefiles:

For a detailed list of makefiles, and a discussion of makefile issues related to portability, see the Makefiles section below.
For more detailed information about editing configuration information in makefiles, see doc/Make.htm#Makefile_overview.
For a complete example of adding a new driver to a makefile, see doc/Drivers.htm#Adding_drivers.
For a few more notes on makefile coding conventions, see doc/C-style.htm#Makefiles.

.dev files

On top of the general conventions just described, Ghostscript's makefiles add a further layer of structure in order to support an open-ended set of fine-grained, flexible configuration options. Selecting an option (usually called a "module") for inclusion in the build may affect the build in many ways:

Almost always, it requires linking in some compiled code files.
It may require running some additional initialization procedures at startup.
It may require reading in some additional PostScript files at startup. For example, a Level 2 PostScript build requires support for PostScript resources and for setpagedevice, which are implemented in PostScript code.
It may require adding entries to a variety of internal tables that catalogue such things as drivers, IODevices, Function types, etc.
It may require that other particular modules be included. For example, the "PostScript Level 2" module requires the modules for various filters, color spaces, etc.
It may require removing some other (default) module from the build. For example, the core (Level 1) PostScript build has a "stub" for binary tokens, which are a Level 2 feature but are referenced by the core scanner: a Level 2 build must remove the stub. For more information about this, look for the string -replace in the makefiles and in src/genconf.c.

Each module is defined in the makefiles by rules that create a file named xxx.dev. The dependencies of the rule include all the files that make up the module (compiled code files, PostScript files, etc.); the body of the rule creates the .dev file by writing the description of the module into it. A program called genconf, described in the next section, merges all the relevant .dev files together. For examples of .dev rules, see any of the Ghostscript makefiles.

Ultimately, a person must specify the root set of modules to include in a build (which of course may require other modules, recursively). Ghostscript's makefiles do this with a set of macros called FEATURE_DEVS and DEVICE_DEVSn, defined in each top-level makefile, but nothing in the module machinery depends on this.

Generators

Ghostscript's build procedure is somewhat unusual in that it compiles and then executes some support programs during the build process. These programs then generate data or source code that is used later on in the build.

The most important and complex of the generator programs is genconf. genconf merges all the .dev files that make up the build, and creates three or more output files used in later stages:

gconfig.h, consisting mainly of macro calls, one call per "resource" making up the build, other than "resources" listed in the other output files.
gconfigf.h, produced only for PostScript builds with compiled-in fonts, consisting of one macro call per font.
A linker control file whose name varies from one platform to another, containing the list of compiled code files to be linked.
If necessary, another linker control file, also varying between platforms, that contains other information for the linker such as the list of system libraries to be searched. (On Unix platforms, the two linker control functions are combined in a single file.)

Source generators:

src/genarch.c: Creates a header file containing a variety of information about the hardware and compiler that isn't provided in any standard system header file. Always used.
src/genconf.c (also generates non-source): Constructs header files and linker control files from the collection of options and modules that make up the build. See above. Always used.
src/genht.c: Converts a PostScript halftone (in a particular constrained format) to a C data structure that can be compiled into an executable. Only used if any such halftones are included in the build.
src/geninit.c: Converts PostScript initialization files to C data structures that can be compiled into an executable. Only used when building a PostScript interpreter, and only if COMPILE_INITS was set to 1 in the makefile.

Other generators:

src/echogs.c: Implements a variety of shell-like functions to get around quirks, limitations, and omissions in the shells on various platforms. Always used.
src/genconf.c (also generates source): See above.
src/gendev.c (not used): Was intended as a replacement for genconf, but was never completed.

Support

There are a number of programs, scripts, and configuration files that exist only for the sake of the build process.

Files for PC environments:: src/gswin.icx, src/gswin16.icx, src/bcc32.cfg, src/cp.bat, src/cp.cmd, src/dw32c.def, src/dwmain.rc, src/dwmain16.def, src/dwmain32.def, src/dwsetup.def, src/dwsetup.rc, src/dwuninst.def, src/dwuninst.rc, src/gs16spl.def, src/gs16spl.rc, src/gsdll2.def, src/gsdll2.rc, src/gsdll32.def, src/gsdll32.rc, src/gsdll32w.lnk, src/gsos2.def, src/gsos2.icx, src/gsos2.rc, src/gspmdrv.def, src/gspmdrv.icx, src/gspmdrv.rc, src/gswin.rc, src/gswin32.rc, src/gswin386.rc, src/mv.bat, src/mv.cmd, src/rm.bat, src/rm.cmd, src/turboc.cfg.
Files for MacOS:: lib/Info-macos.plist.
Files for OpenVMS:: src/append_l.com, src/copy_one.com, src/rm_all.com, src/rm_one.com.
Other files:: src/bench.c, src/catmake, src/instcopy.

Utilities

Ghostscript comes with many utilities for doing things like viewing bitmap files and converting between file formats. Some of these are written in PostScript, some as scripts, and some as scripts that invoke special PostScript code.

Utilities in PostScript

These are all documented in doc/Psfiles.htm, q.v.

Utility scripts

Many of these scripts come in both Unix and MS-DOS (.bat versions; some also have an OS/2 (.cmd) version. The choice of which versions are provided is historical and irregular. These scripts should all be documented somewhere, but currently, many of them have man pages, a few have their own documentation in the doc directory, and some aren't documented at all.

Script files without PC versions:: lib/afmdiff.awk, lib/dvipdf, lib/fixmswrd.pl, lib/lprsetup.sh, lib/pj-gs.sh, lib/pphs, lib/printafm, lib/pv.sh, lib/sysvlp.sh, lib/unix-lpr.sh, lib/wftopfa.
Script files with PC versions:: lib/bdftops, lib/bdftops.bat, lib/bdftops.cmd, lib/dumphint, lib/dumphint.bat, lib/eps2eps, lib/eps2eps.bat, lib/eps2eps.cmd, lib/font2c, lib/font2c.bat, lib/font2c.cmd, lib/gsbj, lib/gsbj.bat, lib/gsdj, lib/gsdj.bat, lib/gsdj500, lib/gsdj500.bat, lib/gslj, lib/gslj.bat, lib/gslp, lib/gslp.bat, lib/gsnd, lib/gsnd.bat, lib/pdf2dsc, lib/pdf2dsc.bat, lib/pdf2ps, lib/pdf2ps.bat, lib/pdf2ps.cmd, lib/pdfopt, lib/pdfopt.bat, lib/pf2afm, lib/pf2afm.bat, lib/pf2afm.cmd, lib/pfbtopfa, lib/pfbtopfa.bat, lib/ps2ascii, lib/ps2ascii.bat, lib/ps2ascii.cmd, lib/ps2epsi, lib/ps2epsi.bat, lib/ps2epsi.cmd, lib/ps2pdf, lib/ps2pdf.bat, lib/ps2pdf.cmd, lib/ps2pdf12, lib/ps2pdf12.bat, lib/ps2pdf12.cmd, lib/ps2pdf13, lib/ps2pdf13.bat, lib/ps2pdf13.cmd, lib/ps2pdf14, lib/ps2pdf14.bat, lib/ps2pdf14.cmd, lib/ps2pdfwr, lib/ps2pdfxx.bat, lib/ps2ps, lib/ps2ps.bat, lib/ps2ps.cmd.
Script files with only PC versions:: lib/gsndt.bat, lib/gssetgs.bat, lib/gst.bat, lib/gstt.bat, lib/lp386.bat, lib/lp386r2.bat, lib/lpgs.bat, lib/lpr2.bat, lib/pftogsf.bat, lib/wmakebat.bat.

Memory management

Memory manager architecture

In many environments, the memory manager is a set of library facilities that implicitly manage the entire address space in a homogenous manner. Ghostscript's memory manager architecture has none of these properties:

Rather than a single library accessed as procedures, Ghostscript includes multiple allocator types, each of which in turn may have multiple instances (allocators). Allocators are 'objects' with a substantial set of virtual functions.
Rather than managing the entire address space, each allocator manages a storage pool, which it may or may not be able to expand or reduce by calling on a 'parent' allocator.
Rather than a single genus of untyped storage blocks, Ghostscript's allocators provide two genera -- type-tagged 'objects', and 'strings' -- with substantially different properties.

Objects vs strings

As noted above, allocators provide two different storage genera.

Objects:

Are aligned in storage to satisfy the most stringent alignment requirement imposed by the CPU or compiler;
Can be referenced only by pointers to their start, not to any internal location, unless special arrangements are made;
May contain pointers to other objects, or to strings;
Have an associated structure descriptor that specifies their size (usually) and the location of any pointers contained within them.

Given a pointer to an object, the allocator that allocated it must be able to return the object's size and the pointer to its structure descriptor. (It is up to the client to know what allocator allocated an object.)

Strings:

Are not aligned in storage;
Can be referenced by pointers (consisting of a starting address and a length) to any substring, starting anywhere within the string;
May not contain pointers;
Do not have a structure descriptor.

The object/string distinction reflects a space/capability tradeoff. The per-object space overhead of the standard type of allocator is typically 12 bytes; this is too much to impose on every string of a few bytes. On the other hand, restricting object pointers to reference the start of the object currently makes object garbage collection and compaction more space-efficient. If we were to redesign the standard allocator, we would probably opt for a different design in which strings were allocated within container objects of a few hundred bytes, and pointers into the middle of all objects were allowed.

Structure descriptors

Every object allocated by a Ghostscript allocator has an associated structure descriptor, which the caller provides when allocating the object. The structure descriptor serves several purposes:

Specifying the size of the object for allocation;
Providing pointer-enumeration and pointer-relocation procedures for the garbage collector;
Providing an optional finalization procedure to be called when the object is freed (either explicitly or automatically).

Structure descriptors are read-only, and are normally defined statically using one of the large set of gs_private_st_ or gs_public_st_ macros in src/gsstruct.h.

While the structure descriptor normally specifies the size of the object, one can also allocate an array of bytes or objects, whose size is a multiple of the size in the descriptor. For this reason, every object stores its size as well as a reference to its descriptor.

Because the standard Ghostscript garbage collector is non-conservative and can move objects, every object allocated by a Ghostscript allocator must have an accurate structure descriptor. If you define a new type of object (structure) that will be allocated in storage managed by Ghostscript, you must create an accurate descriptor for it, and use that descriptor to allocate it. The process of creating accurate descriptors for all structures was long and painful, and accounted for many hard-to-diagnose bugs.

By convention, the structure descriptor for structure type xxx_t is named st_xxx (this is preferred), or occasionally st_xxx_t.

Note that a structure descriptor is only required for objects allocated by the Ghostscript allocator. A structure type xxx_t does not require a structure descriptor if instances of that type are used only in the following ways:

Instances are allocated only on the C stack, e.g., as xxx_t xxx1, xxx2;, or on the C heap, with malloc or through the Ghostscript "wrapper" defined in src/gsmalloc.h.
Pointers to instances are not stored in places where the garbage collector will try to trace the pointer.
Code never attempts to get the structure type or size of an instance through the allocator API.

In general, structures without descriptors are problem-prone, and are deprecated; in new code, they should only be used if the structure is confined to a single .c file and its instances are only allocated on the C stack.

Files:: src/gsstruct.h, src/gsstype.h.

Garbage collection

The allocator architecture is designed to support compacting garbage collection. Every object must be able to enumerate all the pointers it contains, both for tracing and for relocation. As noted just above, the structure descriptor provides procedures that do this.

Whether or not a particular allocator type actually provides a garbage collector is up to the allocator: garbage collection is invoked through a virtual procedure. In practice, however, there are only two useful garbage collectors for Ghostscript's own allocator:

The "real" garbage collector associated with the PostScript interpreter, described below;
A "non" garbage collector that only merges adjacent free blocks.

As noted above, because the architecture supports compacting garbage collection, a "real" garbage collector cannot be run at arbitrary times, because it cannot reliably find and relocate pointers that are on the C stack. In general, it is only safe to run a "real" garbage collector when control is at the top level of the program, when there are no pointers to garbage collectable objects from the stack (other than designated roots).

Files:: src/gsgc.h, src/gsnogc.c, src/gsnogc.h.

Movability

As just noted, objects are normally movable by the garbage collector. However, some objects must be immovable, usually because some other piece of software must retain pointers to them. The allocator API includes procedures for allocating both movable (default) and immovable objects. Note, however, that even immovable objects must be traceable (have a structure descriptor), and may be freed, by the garbage collector.

Parent hierarchy

When an allocator needs to add memory to the pool that it manages, it requests the memory from its parent allocator. Every allocator has a pointer to its parent; multiple allocators may share a single parent. The ultimate ancestor of all allocators that can expand their pool dynamically is an allocator that calls malloc, described below. However, especially in embedded environments, an allocator may be limited to a fixed-size pool assigned to it when it is created.

Allocator API

In summary, the allocator API provides the following principal operations:

Allocate and free movable (default) or immovable objects and strings.
Return the structure type and size of an object.
Resize (shrink or grow) movable objects and strings, preserving the contents insofar as possible.
Report the size of the managed pool, and how much of it is in use.
Register and unregister root pointers for the garbage collector.
Free the allocator itself.
Consolidate adjacent free blocks to reduce fragmentation.

For details, see src/gsmemory.h.

The allocator API also includes one special hook for the PostScript interpreter: the concept of stable allocators. See the section on save and restore below for details.

Files:: src/gsmemraw.h, src/gsmemory.c, src/gsmemory.h, src/gsstruct.h, src/gsstype.h.

Freeing storage

Ghostscript's memory management architecture provides three different ways to free objects: explicitly, by reference counting, or by garbage collection. They provide different safety / performance / convenience tradeoffs; we believe that all three are necessary.

Objects are always freed as a whole; strings may be freed piecemeal.

An object may have an associated finalization procedure, defined in the structure descriptor. This procedure is called just before the object is freed, independent of which method is being used to free the object. A few types of objects have a virtual finalization procedure as well: the finalization procedure defined in the descriptor simply calls the one in the object.

Explicit freeing

Objects and strings may be freed explicitly, using the gs_free_ virtual procedures in the allocator API. It is up to the client to ensure that all allocated objects are freed at most once, and that there are no dangling pointers.

Explicit freeing is the fastest method, but is the least convenient and least safe. It is most appropriate when storage is freed in the same procedure where it is allocated, or for storage that is known to be referenced by only one pointer.

Reference counting

Objects may be managed by reference counting. When an object is allocated, its reference count may be set to 0 or 1. Subsequently, when the reference count is decremented to 0, the object is freed.

The reference counting machinery provides its own virtual finalization procedure for all reference-counted objects. The machinery calls this procedure when it is about to free the object (but not when the object is freed in any other way, which is probably a design bug). This is in addition to (and called before) any finalization procedure associated with the object type.

Reference counting is as fast as explicit freeing, but takes more space in the object. It is most appropriate for relatively large objects which are referenced only from a small set of pointers. Note that reference counting cannot free objects that are involved in a pointer cycle (e.g., A -> B -> C -> A).

Files:: src/gsrefct.h.

(Real) garbage collection

Objects and strings may be freed automatically by a garbage collector. See below.

Special implementations

malloc

As mentioned above, the ultimate ancestor of all allocators with an expandable pool is one that calls malloc.

Files:: src/gsmalloc.h, src/gsmalloc.c.

Locking

In a multi-threaded environment, if an allocator must be callable from multiple threads (for example, if it is used to allocate structures in one thread that are passed to, and freed by, another thread), the allocator must provide mutex protection. Ghostscript provides this capability in the form of a wrapper allocator, that simply forwards all calls to a target allocator under protection of a mutex. Using the wrapper technique, any allocator can be made thread-safe.

Files:: src/gsmemlok.h, src/gsmemlok.c.

Retrying

In an embedded environment, job failure due to memory exhaustion is very undesirable. Ghostscript provides a wrapper allocator that, when an allocation attempt fails, calls a client-provided procedure that can attempt to free memory, then ask for the original allocation to be retried. For example, such a procedure can wait for a queue to empty, or can free memory occupied by caches.

Files:: src/gsmemret.h, src/gsmemret.c.

Standard implementation

The standard Ghostscript allocator gets storage from its parent (normally the malloc allocator) in large blocks called chunks, and then allocates objects up from the low end and strings down from the high end. Large objects or strings are allocated in their own chunk.

The standard allocator maintains a set of free-block lists for small object sizes, one list per size (rounded up to the word size), plus a free-block list for large objects (but not for objects so large that they get their own chunk: when such an object is freed, its chunk is returned to the parent). The lists are not sorted; adjacent blocks are only merged if needed.

While the standard allocator implements the generic allocator API, and is usable with the library alone, it includes a special hook for the PostScript interpreter to aid in the efficient allocation of PostScript composite objects (arrays and dictionaries). See the section on Refs below for details.

Files:: src/gsalloc.c, src/gsalloc.h, src/gxalloc.h, src/gxobj.h.

PostScript interpreter extensions

The PostScript interpreter uses an allocator that extends the graphic library's standard allocator to handle PostScript objects, save and restore, and real garbage collection.

Refs (PostScript "objects")

Ghostscript represents what the PLRM calls PostScript "objects" using a structure called a ref, defined in src/iref.h; packed refs, used for the elements of packed arrays, are defined in src/ipacked.h. See those files for detailed information.

Files:: src/ipacked.h, src/iref.h.

The PLRM calls for two types of "virtual memory" (VM) space: global and local. Ghostscript adds a third space, system VM, whose lifetime is an entire session -- i.e., it is effectively "permanent". All three spaces are subject to garbage collection. There is a separate allocator instance for each VM space (actually, two instances each for global and local spaces; see below). In a system with multiple contexts and multiple global or local VMs, each global or local VM has its own allocator instance(s).

Refs that represent PostScript composite objects, and therefore include pointers to stored data, include a 2-bit VM space tag to indicate in which VM the object data are stored. In addition to system, global, and local VM, there is a tag for "foreign" VM, which means that the memory is not managed by a Ghostscript allocator at all. Every store into a composite object must check for invalidaccess: the VM space tag values are chosen to help make this check efficient. See src/ivmspace.h, src/iref.h, and src/store.h for details.

Files:: src/ivmspace.h.

PostScript composite objects (arrays and dictionaries) are usually small. Using a separate memory manager object for each composite object would waste a lot of space for object headers. Therefore, the interpreter's memory manager packs multiple composite objects (also called "ref-containing objects") into a single memory manager object, similar to the way the memory manager packs multiple objects into a chunk (see above). See src/gxalloc.h for details. This memory manager object has a structure descriptor, like all other memory manager objects.

Note that the value.pdict, value.refs, or value.packed member of a ref must point to a PostScript composite object, and therefore can point into the middle of a memory manager object. This requires special handling by the garbage collector (q.v.).

Files:: src/ialloc.c, src/ialloc.h, src/iastate.h, src/iastruct.h, src/ilocate.c, src/imemory.h, src/istruct.h.

save/.forgetsave/restore

In addition to save and restore, Ghostscript provides a .forgetsave operator that makes things as though a given save had never happened. (In data base terminology, save is "begin transaction", restore is "abort transaction", and .forgetsave is "end/commit transaction"). .forgetsave was implemented for a specific commercial customer (who may no longer even be using it): it was a pain to make work, but it's in the code now, and should be maintained. See the extensive comments in src/isave.c for more information about how these operations work.

Files:: src/idosave.h, src/isave.c, src/isave.h, src/isstate.h, src/store.h.

Stable allocators

Even though save and restore are concepts from the PostScript interpreter, the generic allocator architecture and API include a feature to support them, called stable allocators. Every allocator has an associated stable allocator, which tags pointers with the same VM space number but which is not subject to save and restore. System VM is intrinsically stable (its associated stable allocator is the same allocator), so there are only 5 allocators in ordinary single-context usage: system VM, stable global VM, ordinary global VM, stable local VM, ordinary local VM.

The reason that we cannot simply allocate all stable objects in system VM is that their refs must still be tagged with the correct VM space number, so that the check against storing pointers from global VM to local VM can be enforced properly.

All PostScript objects are normally allocated with the non-stable allocators. The stable allocators should be used with care, since using them can easily create dangling pointers: if storage allocated with a stable allocator contains any references to PostScript objects, the client is responsible for ensuring that the references don't outlive the referenced objects, normally by ensuring that any such referenced objects are allocated at the outermost save level.

The original reason for wanting stable allocators was the PostScript stacks, which are essentially PostScript arrays but are not subject to save and restore. Some other uses of stable allocators are:

Several per-context structures for DPS.
Paths (see gstate_path_memory in src/gsstate.c.
Row buffers for images (see gs_image_row_memory in src/gsimage.c), because the data-reading procedure for an image can invoke save and restore.
Notification lists for fonts, to handle the sequence allocate .. save .. register .. restore.
The parameter lists for pdfwrite and pswrite devices (in src/gdevpsdp.c), because the whole issue of local vs. global VM for setpagedevice is, in the words of Ed Taft of Adobe, "a mess".
Many places in the pdfwrite driver, because many of its bookkeeping structures must not be restorable.

For more specific examples, search the sources for references to gs_memory_stable.

Garbage collection

The interpreter's garbage collector is a compacting, non-conservative, mark-and-sweep collector.

It compacts storage because that is the only way to avoid permanent sandbars, which is essential in limited-memory environments.
It is non-conservative because conservative collectors (which attempt to determine whether arbitrary bit patterns are pointers) cannot compact.
It uses mark-and-sweep, rather than a more modern copying approach, because it cannot afford the extra memory required for copying.

Because the garbage collector is non-conservative, it cannot be run if there are any pointers to movable storage from the C stack. Thus it cannot be run automatically when the allocator is unable to allocate requested space. Instead, when the allocator has allocated a given amount of storage (the vm_threshold amount, corresponding to the PostScript VMThreshold parameter), it sets a flag that the interpreter checks in the main loop. When the interpreter sees that this flag is set, it calls the garbage collector: at that point, there are no problematic pointers from the stack.

Roots for tracing must be registered with the allocator. Most roots are registered during initialization.

"Mark-and-sweep" is a bit of a misnomer. The garbage collector actually has 5 main phases:

Sweep to clear marks;
Trace and mark;
Sweep to compute relocation;
Sweep to relocate pointers;
Sweep and compact.

There is some extra complexity to handle collecting local VM only. In this case, all pointers in global VM are treated as roots, and global VM is not compacted.

As noted above, PostScript arrays and strings can have refs that point within them (because of getinterval). Thus the garbage collector must mark each element of an array, and even each byte of a string, individually. Specifically, it marks objects, refs, and strings using 3 different mechanisms:

Objects have a mark bit in their header: see src/gxobj.h,
Refs and packed refs have a reserved mark bit: see src/iref.h and src/ipacked.h.
Strings use a separate bit table, with one bit per string byte: see src/gxalloc.h,

Similarly, it records the relocation information for objects, refs, and strings differently:

Objects record relocation in the object header.
Refs record relocation in unused fields of refs such as nulls that don't use their value field. Every memory manager object that stores ref-containing objects as described above has an extra, unused ref at the end for this purpose.
Strings use a separate relocation table.

Files:: src/igc.c, src/igc.h, src/igcref.c, src/igcstr.c, src/igcstr.h, src/ireclaim.c.

Portability

One of Ghostscript's most important features is its great portability across platforms (CPUs, operating systems, compilers, and build tools). The code supports portability through two mechanisms:

Structural mechanisms -- segregating platform-dependent information into files in a particular way.
Coding standards -- avoiding relying on byte order, scalar size, and platform-specific compiler or library features.

Structural

CPU and compiler

Ghostscript attempts to discover characteristics of the CPU and compiler automatically during the build process, by compiling and then executing a program called genarch. genarch generates a file obj/arch.h, which almost all Ghostscript files then include. This works well for things like word size, byte order, and floating point representation, but it can't determine whether or not a compiler supports a particular feature, because if a feature is absent, the compilation may fail.

Files:: src/genarch.c, obj/arch.h.

Library headers

Despite the supposed standardization of ANSI C, platforms vary considerably in where (and whether) they provide various standard library facilities. Currently, Ghostscript's build process doesn't attempt to sort this out automatically. Instead, for each library header file <xxx.h> there is a corresponding Ghostscript source file src/xxx_.h, containing a set of compile-time conditionals that attempt to select the correct platform header file, or in some cases substitute Ghostscript's own code for a missing facility. You may need to edit these files when moving to platforms with unusually non-standard libraries.

Files:: src/ctype_.h, src/dirent_.h, src/dos_.h, src/errno_.h, src/fcntl_.h, src/jerror_.h, src/malloc_.h, src/math_.h, src/memory_.h, src/pipe_.h, src/png_.h, src/stat_.h, src/stdint_.h, src/stdio_.h, src/string_.h, src/time_.h, src/unistd_.h, src/vmsmath.h, src/windows_.h, src/x_.h.

It has been suggested that the GNU configure scripts do the above better, for Unix systems, than Ghostscript's current methods. While this may be true, we have found configure scripts difficult to write, understand, and maintain; and the autoconf tool for generating configure scripts, which we found easy to use, doesn't cover much of the ground that Ghostscript requires.

Cross-platform APIs

For a few library facilities that are available on all platforms but are not well standardized, or that may need to be changed for special environments, Ghostscript defines its own APIs. It is an architectural property of Ghostscript that the implementations of these APIs are the only .c files for which the choice of platform (as opposed to choices of drivers or optional features) determines whether they are compiled and linked into an executable.

API:: src/gp.h, src/gpcheck.h, src/gpgetenv.h, src/gpmisc.h, src/gpsync.h.
Implementation files shared among multiple platforms:: src/gp_getnv.c, src/gp_mktmp.c, src/gp_nsync.c, src/gp_psync.c, src/gp_strdl.c, src/gpmisc.c.
Platform-specific implementation files:: src/gp_dosfe.c, src/gp_dosfs.c, src/gp_dvx.c, src/gp_iwatc.c, src/gp_msdos.c, src/gp_mshdl.c, src/gp_msio.c, src/gp_mslib.c, src/gp_mswin.c, src/gp_mswin.h, src/gp_ntfs.c, src/gp_os2.c, src/gp_os9.c, src/gp_stdia.c, src/gp_stdin.c, src/gp_sysv.c, src/gp_unifn.c, src/gp_unifs.c, src/gp_unix.c, src/gp_vms.c, src/gp_wgetv.c, src/gp_win32.c, src/gp_wsync.c.

Makefiles

For information on the structure and conventions used within makefiles, see the Makefile structure section above.

Ghostscript's makefiles are structured very similarly to the cross-platform library files. The great majority of the makefiles are portable across all platforms and all versions of make. To achieve this, the platform-independent makefiles must obey two constraints beyond those of the POSIX make program:

No conditionals or includes are allowed. While most make programs now provide some form of conditional execution and some form of inclusion, there is no agreement on the syntax. (Conditionals and includes are allowed in platform-dependent makefiles; in fact, an inclusion facility is required.)
There must be a space on both sides of the : that separates the target of a rule from its dependencies. This is required for compatibility with the OpenVMS MMS and MMK programs.

The top-level makefile for each platform (where "platform" includes the OS, the compiler, and the flavor of make) contains all the build options, plus includes for the generic makefiles and any platform-dependent makefiles that are shared among multiple platforms.

While most of the top-level makefiles build a PostScript and/or PDF interpreter configuration, there are also a few makefiles that build a test program that only uses the graphics library without any language interpreter. Among other things, this can be helpful in verifying that no accidental dependencies on the interpreter have crept into the library or drivers.

For families of similar platforms, the question arises whether to use multiple top-level makefiles, or whether to use a single top-level makefile that may require minor editing for some (or all) platforms. Ghostscript currently uses the following top-level makefiles for building interpreter configurations:

POSIX systems (inluding Linux and Unix):
- src/configure.ac, GNU Autoconf source script for automatic build configuration.
- src/Makefile.in, source for the top-level makefile used in the Autoconf build.
- src/unix-gcc.mak, for Unix with gcc.
- src/unixansi.mak, for Unix with an ANSI C compiler other than gcc.
PC:
- src/bcwin32.mak, for MS Windows with Borland C++ Builder.
- src/msvc32.mak, for MS Windows with Microsoft Visual C (MSVC).
- src/os2.mak, for MS-DOS or OS/2 GCC/EMX environment.
- src/watcw32.mak, for MS Windows with Watcom C.
Macintosh:
- src/macosx.mak, commandline makefile for MacOS X.
- src/macos-mcp.mak, dummy makefile to generate an xml project file for Metrowerks Codewarrior.
Other:
- src/all-arch.mak, for building on many Unix systems in a networked test environment.
- src/dvx-gcc.mak, for DesqView/X with gcc.
- src/openvms.mak, for OpenVMS with Digital's CC compiler and the MMS build program.
- src/openvms.mmk, for OpenVMS with Digital's CC compiler and the MMK build program.

The following top-level makefiles build the library test program:

src/ugcclib.mak, on Unix with gcc.
src/msvclib.mak, on MS Windows with MSVC.
src/watclib.mak, on extended MS-DOS with Watcom C.

The MSVC makefiles may require editing to select between different versions of MSVC, since different versions may have slightly incompatible command line switches or customary installation path names. The Unix makefiles often require editing to deal with differing library path names and/or library names. For details, see the Unix section of the documentation for building Ghostscript.

Library test program:

src/gslib.c.

Platform-independent makefiles:

Graphics library and support:: src/contrib.mak, src/devs.mak, src/gs.mak, src/lib.mak, src/version.mak.
PostScript interpreter and fonts:: src/cfonts.mak, src/int.mak, src/wmin.mak.
Third-party libraries:: src/icclib.mak, src/ijs.mak, src/jbig2.mak, src/jpeg.mak, src/libpng.mak, src/zlib.mak.

Shared platform-dependent makefiles:

Unix:: src/unix-aux.mak, src/unix-dll.mak, src/unix-end.mak, src/unixhead.mak, src/unixinst.mak, src/unixlink.mak.
Microsoft Windows and MS-DOS:: src/msvccmd.mak, src/msvctail.mak, src/pcwin.mak, src/wccommon.mak, src/wctail.mak, src/winint.mak, src/winlib.mak, src/winplat.mak.
Other:: src/dvx-head.mak, src/dvx-tail.mak.
src/macos-fw.mak, for building as a MacOS X Framework.

Coding

Coding for portability requires avoiding both explicit dependencies, such as platform-dependent #ifdefs, and implicit dependencies, such as dependencies on byte order or the size of the integral types.

Explicit dependencies

The platform-independent .c files never, ever, use #ifdef or #if to select code for specific platforms. Instead, we always try to characterize some abstract property that is being tested. For example, rather than checking for macros that are defined on those specific platforms that have 64-bit long values, we define a macro ARCH_SIZEOF_LONG that can then be tested. Such macros are always defined in a .h file, either automatically in arch.h, or explicitly in a xxx_.h file, as described in earlier sections.

Files:: src/std.h, src/stdpn.h, src/stdpre.h.

Implicit dependencies

The most common source of byte ordering dependencies is casting between types (T1 *) and (T2 *) where T1 and T2 are numeric types that aren't merely signed/unsigned variants of each other. To avoid this, the only casts allowed in the code are between numeric types, from a pointer type to a long integral type, and between pointer types.

Ghostscript's code assumes the following about the sizes of various types:

char: 8 bits
short: 16 bits
int: 32 or 64 bits
long: 32 or 64 bits
float: 32 bits (may work with 64 bits)
double: 64 bits (may work with 128 bits)

The code does not assume that the char type is signed (or unsigned); except for places where the value is always a literal string, or for interfacing to library procedures, the code uses byte (a Ghostscript synonym for unsigned char) almost everywhere.

Pointers are signed on some platforms and unsigned on others. In the few places in the memory manager where it's necessary to reliably order-compare (as opposed to equality-compare) pointers that aren't known to point to the same allocated block of memory, the code uses the PTR_relation macros rather than direct comparisons.

See the files listed above for other situations where a macro provides platform-independence or a workaround for bugs in specific compilers or libraries (of which there are a distressing number).

Platform-specific code

There are some features that are inherently platform-specific:

Microsoft Windows requires a lot of special top-level code, and also has an installer and uninstaller.
OS/2 requires a little special code.
MacOS also requires special top-level code (now distributed with the standard Ghostscript package).
All platforms supporting DLLs (currently all three of the above) share some special top-level code.

MS Windows files:: src/dpmain.c, src/dwdll.c, src/dwdll.h, src/dwimg.c, src/dwimg.h, src/dwinst.cpp, src/dwinst.h, src/dwmain.c, src/dwmain.h, src/dwmainc.c, src/dwnodll.c, src/dwreg.c, src/dwreg.h, src/dwsetup.cpp, src/dwsetup.h, src/dwtext.c, src/dwtext.h, src/dwtrace.c, src/dwtrace.h, src/dwuninst.cpp, src/dwuninst.h, src/gp_msdll.c, src/gp_mspol.c, src/gp_msprn.c, src/gs16spl.c, src/gsdllwin.h.
OS/2 files:: src/gsdllos2.h.
Unix files:: src/dxmain.c, src/dxmainc.c.
Macintosh files:: src/gdevmac.c, src/gdevmac.h, src/gdevmacpictop.h, src/gdevmacttf.h, src/gdevmacxf.c, src/gp_mac.c, src/gp_mac.h, src/gp_macio.c, src/gp_macpoll.c, src/gsiomacres.c, src/macgenmcpxml.sh, src/macsystypes.h, src/macos_carbon_pre.h, src/macos_carbon_d_pre.h, src/macos_classic_d_pre.h, src/dmmain.c, src/dmmain.r.
VMS files:: src/vms_x_fix.h.
DLL files:: src/gsdll.c, src/gsdll.h, src/gdevdsp.c, src/gdevdsp.h, src/gdevdsp2.h, src/iapi.c, src/iapi.h, src/idisp.c, src/idisp.h.
The new DLL interface (new as of 7.0) is especially useful with the new display device, so it is included here. Both are due to Russell Lang.

Adding features and options

[Ray, please supply more information about what you want here]

Troubleshooting

The Ghostscript code has many tracing and debugging features that can be enabled at run time using the -Z command line switch, if the executable was compiled with DEBUG defined. One particularly useful combination is -Z@\?, which fills free memory blocks with a pattern and also turns on run-time memory consistency checking. For more information, see doc/Use.htm#Debugging; you can also search for occurrences of if_debug or gs_debug_c in the source code. Note that many of these features are in the graphics library and do not require a PostScript interpreter.

The code also contains many run-time procedures whose only purpose is to be called from the debugger to print out various data structures, including all the procedures in src/idebug.c (for the PostScript interpreter) and the debug_dump_ procedures in src/gsmisc.c.

Files:: doc/Use.htm#Debugging, src/gdebug.h, src/gsmdebug.h, src/idebug.h, src/idebug.c.

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 the license contained in the file LICENSE in this distribution. For more information about licensing, please refer to http://www.ghostscript.com/licensing/. For information on commercial licensing, go to http://www.artifex.com/licensing/ or contact Artifex Software, Inc., 101 Lucas Valley Road #110, San Rafael, CA 94903, U.S.A., +1(415)492-9861.

Ghostscript version 8.14, 20 February 2004

Information for Ghostscript developers

Table of contents

Introduction

Architecture

Design goals

Design principles

Non-preemption

Multi-instantiability

Late configuration binding

Large-scale structure

Object-oriented constructs

File roadmap

Substrate

Memory manager

Streams

Platform-specific code

Miscellaneous

Graphics library

Support

Paths

Text

Images

Paint

Clipping

Other graphics

Font API support

Driver support

Visual Trace

Device drivers

Internal devices

PostScript and PDF writers

Other high-level devices

Other maintained drivers

Contributed drivers

PostScript interpreter

Main program

Data structures

Stacks

Interpreter loop

Scanning/parsing

Standard operators

Non-standard operators

Interpreter support

PostScript code

PDF interpreter

Build process

Makefile structure

.dev files

Generators

Support

Utilities

Utilities in PostScript

Utility scripts

Memory management

Memory manager architecture

Objects vs strings

Structure descriptors

Garbage collection

Movability

Parent hierarchy

Allocator API

Freeing storage

Explicit freeing

Reference counting

(Real) garbage collection

Special implementations

malloc

Locking

Retrying

Standard implementation

PostScript interpreter extensions

Refs (PostScript "objects")

save/.forgetsave/restore

Stable allocators

Garbage collection

Portability

Structural

CPU and compiler

Library headers

Cross-platform APIs