Information for Ghostscript developers

Table of contents

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


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.



Design goals

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

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.


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:

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.


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.

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.

  1. 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.
  2. The layer above the substrate is the graphics layer. It consists of two separate sub-parts. The graphics layer is written in C.
  3. 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.
  4. 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.


Memory manager

See below.


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:
src/scf.h, src/scfd.c, src/scfdgen.c, src/scfdtab.c, src/scfe.c, src/scfetab.c, src/scfparam.c, src/scfx.h.
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.
Other compression/decompression:
src/slzwc.c, src/slzwce.c, src/slzwd.c, src/slzwx.h, src/srld.c, src/srle.c, src/srlx.h.
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.


Library top level:
src/gsinit.c, src/gslib.h.
src/gconf.c, src/gconf.h, src/gscdef.c, src/gscdefs.h.
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.
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.

Graphics library


Bitmap processing:
src/gsbitcom.c, src/gsbitmap.h, src/gsbitops.c, src/gsbitops.h, src/gsbittab.c, src/gsbittab.h, src/gsflip.c, src/gsflip.h, src/gxbitmap.h, src/gxbitops.h, src/gxsample.c, src/gxsample.h.
src/gsfunc.c, src/gsfunc.h, src/gsfunc0.c, src/gsfunc0.h, src/gsfunc3.c, src/gsfunc3.h, src/gsfunc4.c, src/gsfunc4.h, src/gsfuncv.c, src/gsfuncv.h, src/gxfunc.h.
Parameter lists:
src/gscparam.c, src/gsparam.c, src/gsparam.h, src/gsparam2.c (not used), src/gsparams.c, src/gsparams.h, src/gsparamx.c, src/gsparamx.h.
src/gdevpipe.c, src/gsfname.c, src/gsfname.h, src/gsio.h, src/gsiodev.c, src/gsiodevs.c, src/gxiodev.h.


Coordinate transformation:
src/gscoord.c, src/gscoord.h, src/gsmatrix.c, src/gsmatrix.h, src/gxcoord.h, src/gxmatrix.h.
Path building:
src/gsdps1.c, src/gspath.c, src/gspath.h, src/gspath1.c, src/gspath2.h, src/gxpath.c, src/gxpath.h, src/gxpath2.c, src/gxpcopy.c, src/gxpdash.c, src/gxpflat.c, src/gzpath.h.
Path rendering:
src/gdevddrw.c, src/gsdps1.c, src/gspaint.c, src/gspaint.h, src/gspenum.h, src/gxfill.c, src/gxpaint.c, src/gxpaint.h, src/gxstroke.c.
See under Clipping below.


Fonts, generic:
src/gsfont.c, src/gsfont.h, src/gxfont.h.
Fonts, specific FontTypes:
src/gsfcid.c, src/gsfcmap.c, src/gsfcmap.h, src/gsfont0.c, src/gxcid.h, src/gxfcid.h, src/gxfcmap.h, src/gxfont0.h, src/gxfont1.h, src/gxfont42.h, src/gxftype.h, src/gxttf.h.
Character rendering + font cache, generic:
src/gsccode.h, src/gschar.c, src/gschar.h, src/gscpm.h, src/gstext.c, src/gstext.h, src/gxbcache.c, src/gxbcache.h, src/gxccache.c, src/gxccman.c, src/gxchar.c, src/gxchar.h, src/gxfcache.h, src/gxtext.h.
Character rendering, specific FontTypes:
src/gschar0.c, src/gscrypt1.c, src/gscrypt1.h, src/gstype1.c, src/gstype1.h, src/gstype2.c, src/gstype42.c, src/gxchrout.c, src/gxchrout.h, src/gxhint1.c, src/gxhint2.c, src/gxhint3.c, src/gxop1.h, src/gxtype1.c, src/gxtype1.h.


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:
src/gsiparm4.h, src/gximage1.c, src/gximage4.c.
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.


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

  1. 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.
  2. 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.
  3. 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: 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.
  4. 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/gxdither.c, 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.

The halftone level for rendering a color is computed in src/gxdither.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).

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.

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.

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.

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. ****** TO BE COMPLETED ******

Compositing architecture:
src/gscompt.h, src/gxcomp.h.
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.


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.

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/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.

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/gdevmr1.c, src/gdevmr2n.c, src/gdevmr8n.c.
Alpha-related devices:
src/gdevabuf.c, src/gdevalph.c.
Other devices:
src/gdevdflt.c, src/gdevhit.c, src/gdevht.c, src/gdevht.h, 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).

Shared support:
Writing fonts:
src/gdevpsf.h, src/gdevpsf1.c, src/gdevpsf2.c, src/gdevpsfm.c, src/gdevpsft.c, src/gdevpsfu.c, src/gdevpsfx.c.
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):
src/gdevpdfo.c, src/gdevpdfo.h, src/gdevpdfr.c, src/gdevpdfu.c.
Text and fonts:
src/gdevpdfe.c, src/gdevpdff.c, src/gdevpdff.h, src/gdevpdfs.c, src/gdevpdft.c, src/gdevpdfw.c.
src/gdevpdfc.c, src/gdevpdfd.c, src/gdevpdfg.c, src/gdevpdfg.h, src/gdevpdfv.c.
src/gdevpdfb.c, src/gdevpdfi.c, src/gdevpdfj.c.
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:

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.
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:

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/gdevhpij.c, src/gdevhpij.h, 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/gdevstp.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. src/gdevhl12.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. 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.

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:

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.)

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.

General data structures:
src/icontext.c, src/icontext.h, src/icstate.h.
src/iddict.h, src/idict.h, src/idict.c, src/idictdef.h.
src/iname.c, src/iname.h, src/inamedef.h, src/inameidx.h, src/inames.h, src/inamestr.h.
src/isdata.h, src/istack.c, src/istack.h, src/istkparm.h.
Specific stacks:
Dictionary stack:
src/dstack.h, src/estack.h, src/iddstack.h, src/idsdata.h, src/idstack.c, src/idstack.h.
Execution stack:
src/iesdata.h, src/iestack.h.
Operand stack:
src/iosdata.h, src/iostack.h, src/ostack.h.

Interpreter loop

src/interp.c, src/interp.h.


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

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/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/zfileio.c, src/ztoken.c.
Data structures:
src/zarray.c, src/zdict.c, src/zgeneric.c, src/zpacked.c, src/zstring.c.
src/ifunc.h, src/zfunc.c, src/zfunc0.c, src/zfunc3.c, src/zfunc4.c,
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.
Device management:
src/zdevcal.c, src/zdevice.c, src/zdevice2.c, src/ziodev.c, src/ziodev2.c, src/ziodevs.c, src/ziodevsc.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/zcharout.c, src/zcharx.c, src/zcid.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.
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/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.c, src/zpcolor.c, src/zshade.c, src/ztrans.c.
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.

Provides access to PC hardware I/O through MS-DOS system calls. Probably no longer useful.
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.
Provides operators for allocating objects in specific VM spaces, disregarding the current VM mode.
Provides an operator for building a color cube from an arbitrary tint transform, so that tint transforms can be applied from inside the graphics library without calling back to the PostScript interpreter.

Interpreter support

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

Miscellaneous support:
src/errors.h, 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.

PostScript code

Initialization and language support:
All configurations:
lib/, lib/
Level 2:
lib/, lib/, lib/, lib/, lib/, lib/
LanguageLevel 3:
lib/, lib/, lib/
Display PostScript:
lib/, lib/
ICC color profiles:
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.
CIDFont name mapping:
lib/CIDFnmap, lib/CIDFnmap.ARP, lib/CIDFnmap.Bae, lib/CIDFnmap.CJK, lib/CIDFnmap.Koc, lib/CIDFnmap.Ore, lib/CIDFnmap.Sol, lib/CIDFnmap.Win, lib/CIDFnmap.b5, lib/, lib/CIDFnmap.ksx, lib/
lib/, lib/
Type 1 and CFF:
lib/, lib/, lib/
lib/, lib/
lib/, lib/, lib/
lib/, lib/, lib/
Pseudo-encodings for internal use:
lib/, lib/, lib/, lib/
Other support:
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/, lib/, lib/

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/ that are meant to be called from applications such as previewers.


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.

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

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.

In the meantime, to ease the pain for mortal users and developers on Unix platforms, we have adopted the standard autoconf tool to systematically generate an appropriate top-level makefile for the target system. As currently implemented, its use makes no deep changes to the Ghostscript build system, but rather generates a makefile, more or less the same as would be achieved by starting from a platform-specific toplevel makefile and hand-editing. The relevant autoconf sources are in src/, and These sources are used in the release process to create a configure script in the toplevel directory of releases. Also, there is an script to automate the autoconf process somewhat. The names and locations of these files were chosen to be clear to those familiar with autoconf, even though they represent a slight departure from Ghostscript tradition.

For more information about 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:

Each module is defined in the makefiles by rules that create a file named 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.


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:

Source generators:
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.
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.
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:
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.


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:
Files for OpenVMS:
src/, src/, src/, src/
Other files:
src/bench.c, src/catmake, src/ccgs, src/instcopy.


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/, lib/, lib/pfbtopfa, lib/, lib/pphs, lib/printafm, lib/, lib/, lib/, lib/wftopfa.
Script files with PC versions:
lib/bdftops, lib/bdftops.bat, lib/bdftops.cmd, 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/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:

Objects vs strings

As noted above, allocators provide two different storage genera.


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.)


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:

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 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:

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.

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:

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


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:

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.

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).


(Real) garbage collection

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

Special implementations


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

src/gsmalloc.h, src/gsmalloc.c.


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.

src/gsmemlok.h, src/gsmemlok.c.


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.

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.

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.

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.


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.).

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


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.

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.) For more 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.

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:

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:

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

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


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:


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.

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.

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/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.

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.


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:

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:

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

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:
Platform-independent makefiles:
Graphics library and support:
src/contrib.mak, src/devs.mak, src/gnudevs.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/jpeg.mak, src/libpng.mak, src/zlib.mak.
Shared platform-dependent makefiles:
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.
src/dvx-head.mak, src/dvx-tail.mak,
src/macos-fw.mak, for building as a MacOS X Framework.


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.

src/std.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:

8 bits
16 bits
32 or 64 bits
32 or 64 bits
32 bits (may work with 64 bits)
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:

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/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:
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/ src/macsysstat.h. src/macsystypes.h.
VMS files:
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]


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.

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

Copyright © 2001 artofcode LLC. All rights reserved.


Ghostscript version 7.07, 17 May 2003