lostecho/oldlinux-files
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

add directory Linux-0.98

Browse Source
This commit is contained in:
gohigh
2024-02-19 00:21:16 -05:00
parent 265896c4ae
commit 56596ada90
13765 changed files with 3471432 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

2481
Linux-0.98/Yggdrasil-0.98.3/usr/lib/ghostscript/doc/NEWS Normal file
View File

File diff suppressed because it is too large Load Diff

552
Linux-0.98/Yggdrasil-0.98.3/usr/lib/ghostscript/doc/drivers.doc Normal file
View File

@@ -0,0 +1,552 @@
Copyright (C) 1989, 1990, 1991, 1992 Aladdin Enterprises.
All rights reserved.
Distributed by Free Software Foundation, Inc.
This file is part of Ghostscript.
Ghostscript is distributed in the hope that it will be useful, but
WITHOUT ANY WARRANTY. No author or distributor accepts responsibility
to anyone for the consequences of using it or for whether it serves any
particular purpose or works at all, unless he says so in writing. Refer
to the Ghostscript General Public License for full details.
Everyone is granted permission to copy, modify and redistribute
Ghostscript, but only under the conditions described in the Ghostscript
General Public License. A copy of this license is supposed to have been
given to you along with Ghostscript so you can know your rights and
responsibilities. It should be in a file named COPYING. Among other
things, the copyright notice and this notice must be preserved on all
copies.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
This file, drivers.doc, describes the interface between Ghostscript and
device drivers.
For an overview of Ghostscript and a list of the documentation files, see
README.
********
******** Adding a driver ********
********
To add a driver to Ghostscript, all you need to do is edit devs.mak in
two places. The first is the list of devices, in the section headed
# -------------------------------- Catalog ------------------------------- #
Pick a name for your device, say smurf, and add smurf to the list.
(Device names must be 1 to 8 characters, consisting of only letters,
digits, and underscores, of which the first character must be a letter.
Case is significant: all current device names are lower case.)
The second is the section headed
# ---------------------------- Device drivers ---------------------------- #
Suppose the files containing the smurf driver are called joe and fred.
Then you should add the following lines:
# ------ The SMURF device ------ #
smurf_=joe.$(OBJ) fred.$(OBJ)
smurf.dev: $(smurf_)
$(SHP)gssetdev smurf $(smurf_)
joe.$(OBJ): joe.c ...and whatever it depends on
fred.$(OBJ): fred.c ...and whatever it depends on
If the smurf driver also needs special libraries, e.g., a library named
gorf, then the gssetdev line should look like
$(SHP)gssetdev smurf $(smurf_)
$(SHP)gsaddmod smurf -lib gorf
********
******** Driver structure ********
********
A device is represented by a structure divided into three parts:
- procedures that are shared by all instances of each device;
- parameters that are present in all devices but may be different
for each device or instance; and
- device-specific parameters that may be different for each instance.
Normally, the procedure structure is defined and initialized at compile
time. A prototype of the parameter structure (including both generic and
device-specific parameters) is defined and initialized at compile time,
but is copied and filled in when an instance of the device is created.
The gx_device_common macro defines the common structure elements, with the
intent that devices define and export a structure along the following
lines:
typedef struct smurf_device_s {
gx_device_common;
... device-specific parameters ...
} smurf_device;
smurf_device gs_smurf_device = {
sizeof(smurf_device), * params_size
{ ... procedures ... }, * procs
... generic parameter values ...
... device-specific parameter values ...
};
The device structure instance *must* have the name gs_smurf_device, where
smurf is the device name used in devs.mak.
All the device procedures are called with the device as the first
argument. Since each device type is actually a different structure type,
the device procedures must be declared as taking a gx_device * as their
first argument, and must cast it to smurf_device * internally. For
example, in the code for the "memory" device, the first argument to all
routines is called dev, but the routines actually use md to reference
elements of the full structure, by virtue of the definition
#define md ((gx_device_memory *)dev)
(This is a cheap version of "object-oriented" programming: in C++, for
example, the cast would be unnecessary, and in fact the procedure table
would be constructed by the compiler.)
Structure definition
--------------------
This essentially duplicates the structure definition in gxdevice.h.
typedef struct gx_device_s {
int params_size; /* size of this structure */
gx_device_procs *procs; /* pointer to procedure structure */
char *name; /* the device name */
int width; /* width in pixels */
int height; /* height in pixels */
float x_pixels_per_inch; /* x density */
float y_pixels_per_inch; /* y density */
gs_rect margin_inches; /* margins around imageable area, */
/* in inches */
gx_device_color_info color_info; /* color information */
int is_open; /* true if device has been opened */
} gx_device;
The name in the structure should be the same as the name in devs.mak.
gx_device_common is a macro consisting of just the element definitions.
If for any reason you need to change the definition of the basic device
structure, or add procedures, you must change the following places:
- This document and NEWS (if you want to keep the
documentation up to date).
- The definition of gx_device_common and/or the procedures
in gxdevice.h.
- The null device in gsdevice.c.
- The tracing "device" in gstdev.c.
- The "memory" devices in gdevmem.h and gdevmem*.c.
- The command list "device" in gxclist.c.
- The clip list accumulation and clipping "devices" in gxcpath.c.
- The generic printer device macros in gdevprn.h.
- The generic printer device code in gdevprn.c.
- All the real devices in the standard Ghostscript distribution,
as listed in devs.mak. (Most of the printer devices are
created with the macros in gdevprn.h, so you may not have to
edit the source code for them.)
- Any other drivers you have that aren't part of the standard
Ghostscript distribution.
You may also have to change the code for gx_default_get_props and/or
gx_default_put_props (in gsdevice.c).
********
******** Types and coordinates ********
********
Coordinate system
-----------------
Since each driver specifies the initial transformation from user to device
coordinates, the driver can use any coordinate system it wants, as long as
a device coordinate will fit in an int. (This is only an issue on MS-DOS
systems, where ints are only 16 bits. User coordinates are represented as
floats.) Typically the coordinate system will have (0,0) in the upper
left corner, with X increasing to the right and Y increasing toward the
bottom. This happens to be the coordinate system that all the currently
supported devices use. However, there is supposed to be nothing in the
rest of Ghostscript that assumes this.
Drivers must check (and, if necessary, clip) the coordinate parameters
given to them: they should not assume the coordinates will be in bounds.
Color definition
----------------
Ghostscript represents colors internally as RGB values. In communicating
with devices, however, it assumes that each device has a palette of colors
identified by integers (to be precise, elements of type gx_color_index).
Drivers may provide a uniformly spaced gray ramp or color cube for
halftoning, or they may do their own color approximation, or both.
The color_info member of the device structure defines the color and
gray-scale capabilities of the device. Its type is defined as follows:
typedef struct gx_device_color_info_s {
int num_components; /* 1 = gray only, 3 = RGB, */
/* 4 = CMYK (not supported) */
int depth; /* # of bits per pixel */
gx_color_value max_gray; /* # of distinct gray levels -1 */
gx_color_value max_rgb; /* # of distinct color levels -1 */
/* (only relevant if num_comp. > 1) */
gx_color_value dither_gray; /* size of gray ramp for halftoning */
gx_color_value dither_rgb; /* size of color cube ditto */
/* (only relevant if num_comp. > 1) */
} gx_device_color_info;
The following macros (in gxdevice.h) provide convenient shorthands for
initializing this structure for ordinary black-and-white or color devices:
#define dci_black_and_white { 1, 1, 1, 0, 2, 0 }
#define dci_color(depth,maxv,dither) { 3, depth, maxv, maxv, dither, dither }
The idea is that a device has a certain number of gray levels (max_gray
+1) and a certain number of colors (max_rgb +1) that it can produce
directly. When Ghostscript wants to render a given RGB color as a device
color, it first tests whether the color is a gray level. (If
num_components is 1, it converts all colors to gray levels.) If so:
- If max_gray is large (>= 31), Ghostscript asks the device to
approximate the gray level directly. If the device returns a
gx_color_value, Ghostscript uses it. Otherwise, Ghostscript assumes that
the device can represent dither_gray distinct gray levels, equally spaced
along the diagonal of the color cube, and uses the two nearest ones to the
desired color for halftoning.
If the color is not a gray level:
- If max_rgb is large (>= 31), Ghostscript asks the device to
approximate the color directly. If the device returns a
gx_color_value, Ghostscript uses it. Otherwise, Ghostscript assumes
that the device can represent dither_rgb * dither_rgb * dither_rgb
distinct colors, equally spaced throughout the color cube, and uses
two of the nearest ones to the desired color for halftoning.
Types
-----
Here is a brief explanation of the various types that appear as parameters
or results of the drivers.
gx_color_value (defined in gxdevice.h)
This is the type used to represent RGB color values. It is
currently equivalent to unsigned short. However, Ghostscript may use less
than the full range of the type to represent color values:
gx_color_value_bits is the number of bits actually used, and
gx_max_color_value is the maximum value (equal to
2^gx_max_color_value_bits - 1).
gx_device (defined in gxdevice.h)
This is the device structure, as explained above.
gs_matrix (defined in gsmatrix.h)
This is a 2-D homogenous coordinate transformation matrix, used by
many Ghostscript operators.
gx_color_index (defined in gxdevice.h)
This is meant to be whatever the driver uses to represent a device
color. For example, it might be an index in a color map. Ghostscript
doesn't ever do any computations with these values: it gets them from
map_rgb_color and hands them back as arguments to several other
procedures. The special value gx_no_color_index (defined as
(gx_color_index)(-1)) means "transparent" for some of the procedures. The
type definition is simply:
typedef unsigned long gx_color_index;
gs_prop_item (defined in gsprops.h)
This is an element of a property list, which is used to read and
set attributes in a device. See the comments in gsprops.h, and the
description of the get_props and put_props procedures below, for more
detail.
gx_bitmap (defined in gxbitmap.h)
This structure type represents a bitmap to be used as a tile for
filling a region (rectangle). Here is a copy of the relevant part of the
file:
/*
* Structure for describing stored bitmaps.
* Bitmaps are stored bit-big-endian (i.e., the 2^7 bit of the first
* byte corresponds to x=0), as a sequence of bytes (i.e., you can't
* do word-oriented operations on them if you're on a little-endian
* platform like the Intel 80x86 or VAX). Each scan line must start on
* a (32-bit) word boundary, and hence is padded to a word boundary,
* although this should rarely be of concern, since the raster and width
* are specified individually. The first scan line corresponds to y=0
* in whatever coordinate system is relevant.
*
* For bitmaps used as halftone tiles, we may replicate the tile in
* X and/or Y, but it is still valuable to know the true tile dimensions.
*/
typedef struct gx_bitmap_s {
byte *data;
int raster; /* bytes per scan line */
gs_int_point size; /* width, height */
gx_bitmap_id id;
ushort rep_width, rep_height; /* true size of tile */
} gx_bitmap;
********
******** Driver procedures ********
********
All the procedures that return int results return 0 on success, or an
appropriate negative error code in the case of error conditions. The
error codes are defined in gserrors.h. The relevant ones for drivers
are as follows:
gs_error_invalidfileaccess
An attempt to open a file failed.
gs_error_limitcheck
An otherwise valid parameter value was too large for
the implementation.
gs_error_rangecheck
A parameter was outside the valid range.
gs_error_VMerror
An attempt to allocate memory failed. (If this
happens, the procedure should release all memory it
allocated before it returns.)
If a driver does return an error, it should use the return_error
macro rather than a simple return statement, e.g.,
return_error(gs_error_VMerror);
This macro is defined in gx.h, which is automatically included by
gdevprn.h but not by gserrors.h.
Most procedures are optional. If a device doesn't supply an optional
procedure proc, the entry in the procedure structure should be
gx_default_proc, e.g. gx_default_tile_rectangle. The device procedure
must also call this procedure if it doesn't implement the function for
particular values of the arguments.
Open/close/sync
---------------
int (*open_device)(P1(gx_device *)) [OPTIONAL]
Open the device: do any initialization associated with making the
device instance valid. This must be done before any output to the device.
The default implementation does nothing.
void (*get_initial_matrix)(P2(gx_device *, gs_matrix *)) [OPTIONAL]
Construct the initial transformation matrix mapping user
coordinates (nominally 1/72" per unit) to device coordinates. The default
procedure computes this from width, height, and x/y_pixels_per_inch on the
assumption that the origin is in the upper left corner, i.e.
xx = x_pixels_per_inch/72, xy = 0,
yx = 0, yy = -y_pixels_per_inch/72,
tx = 0, ty = height.
int (*sync_output)(P1(gx_device *)) [OPTIONAL]
Synchronize the device. If any output to the device has been
buffered, send / write it now. Note that this may be called several times
in the process of constructing a page, so printer drivers should NOT
implement this by printing the page. The default implementation does
nothing.
int (*output_page)(P3(gx_device *, int num_copies, int flush)) [OPTIONAL]
Output a fully composed page to the device. The num_copies
argument is the number of copies that should be produced for a hardcopy
device. (This may be ignored if the driver has some other way to specify
the number of copies.) The flush argument is true for showpage, false for
copypage. The default definition just calls sync_output. Printer drivers
should implement this by printing and ejecting the page.
int (*close_device)(P1(gx_device *)) [OPTIONAL]
Close the device: release any associated resources. After this,
output to the device is no longer allowed. The default implementation
does nothing.
Color mapping
-------------
gx_color_index (*map_rgb_color)(P4(gx_device *, gx_color_value red,
gx_color_value green, gx_color_value blue)) [OPTIONAL]
Map a RGB color to a device color. The range of legal values of
the RGB arguments is 0 to gx_max_color_value. The default algorithm
returns 1 if any of the values exceeds gx_max_color_value/2, 0 otherwise.
Ghostscript assumes that for devices that have color capability
(i.e., color_info.num_components > 1), map_rgb_color returns a color index
for a gray level (as opposed to a non-gray color) iff red = green = blue.
int (*map_color_rgb)(P3(gx_device *, gx_color_index color,
gx_color_value rgb[3])) [OPTIONAL]
Map a device color code to RGB values. The default algorithm
returns (0 if color==0 else gx_max_color_value) for all three components.
Drawing
-------
All drawing operations use device coordinates and device color values.
int (*fill_rectangle)(P6(gx_device *, int x, int y,
int width, int height, gx_color_index color))
Fill a rectangle with a color. The set of pixels filled is
{(px,py) | x <= px < x + width and y <= py < y + height}. In other words,
the point (x,y) is included in the rectangle, as are (x+w-1,y), (x,y+h-1),
and (x+w-1,y+h-1), but *not* (x+w,y), (x,y+h), or (x+w,y+h). If width <=
0 or height <= 0, fill_rectangle should return 0 without drawing anything.
int (*draw_line)(P6(gx_device *, int x0, int y0, int x1, int y1,
gx_color_index color)) [OPTIONAL]
Draw a minimum-thickness line from (x0,y0) to (x1,y1). The
precise set of points to be filled is defined as follows. First, if y1 <
y0, swap (x0,y0) and (x1,y1). Then the line includes the point (x0,y0)
but not the point (x1,y1). If x0=x1 and y0=y1, draw_line should return 0
without drawing anything.
Bitmap imaging
--------------
Bitmap (or pixmap) images are stored in memory in a nearly standard way.
The first byte corresponds to (0,0) in the image coordinate system: bits
(or polybit color values) are packed into it left-to-right. There may be
padding at the end of each scan line: the distance from one scan line to
the next is always passed as an explicit argument.
int (*copy_mono)(P11(gx_device *, const unsigned char *data, int data_x,
int raster, gx_bitmap_id id, int x, int y, int width, int height,
gx_color_index color0, gx_color_index color1))
Copy a monochrome image (similar to the PostScript image
operator). Each scan line is raster bytes wide. Copying begins at
(data_x,0) and transfers a rectangle of the given width at height to the
device at device coordinate (x,y). (If the transfer should start at some
non-zero y value in the data, the caller can adjust the data address by
the appropriate multiple of the raster.) The copying operation writes
device color color0 at each 0-bit, and color1 at each 1-bit: if color0 or
color1 is gx_no_color_index, the device pixel is unaffected if the image
bit is 0 or 1 respectively. If id is different from gx_no_bitmap_id, it
identifies the bitmap contents unambiguously; a call with the same id will
always have the same data, raster, and data contents.
This operation is the workhorse for text display in Ghostscript,
so implementing it efficiently is very important.
int (*tile_rectangle)(P10(gx_device *, const gx_bitmap *tile,
int x, int y, int width, int height,
gx_color_index color0, gx_color_index color1,
int phase_x, int phase_y)) [OPTIONAL]
Tile a rectangle. Tiling consists of doing multiple copy_mono
operations to fill the rectangle with copies of the tile. The tiles are
aligned with the device coordinate system, to avoid "seams".
Specifically, the (phase_x, phase_y) point of the tile is aligned with the
origin of the device coordinate system. (Note that this is backwards from
the PostScript definition of halftone phase.) phase_x and phase_y are
guaranteed to be in the range [0..tile->width) and [0..tile->height)
respectively.
If color0 and color1 are both gx_no_color_index, then the tile is
a color pixmap, not a bitmap: see the next section.
Pixmap imaging
--------------
Pixmaps are just like bitmaps, except that each pixel occupies more than
one bit. All the bits for each pixel are grouped together (this is
sometimes called "chunky" or "Z" format). The number of bits per pixel is
given by the color_info.depth parameter in the device structure: the legal
values are 1, 2, 4, 8, 16, 24, or 32. The pixel values are device color
codes (i.e., whatever it is that map_rgb_color returns).
int (*copy_color)(P9(gx_device *, const unsigned char *data, int data_x,
int raster, gx_bitmap_id id, int x, int y, int width, int height))
Copy a color image with multiple bits per pixel. The raster is in
bytes, but x and width are in pixels, not bits. If the device doesn't
actually support color, this is OPTIONAL; the default is equivalent to
copy_mono with color0 = 0 and color1 = 1. If id is different from
gx_no_bitmap_id, it identifies the bitmap contents unambiguously; a call
with the same id will always have the same data, raster, and data
contents.
tile_rectangle can also take colored tiles. This is indicated by the
color0 and color1 arguments both being gx_no_color_index. In this case,
as for copy_color, the raster and height in the "bitmap" are interpreted
as for real bitmaps, but the x and width are in pixels, not bits.
Reading bits back
-----------------
int (*get_bits)(P5(gx_device *, int y,
byte *str, unsigned int size, int pad_to_word)) [OPTIONAL]
Read bits back from the device into the area of size bytes
starting at str, starting with scan line y. If the bits cannot be read
back (e.g., from a printer), return -1; otherwise return a value as
described below. The contents of the bits beyond the last valid bit in
the scan line (as defined by the device width) are unpredictable.
If pad_to_word is 0, scan lines are only padded to a byte boundary; the
normal return value is 0.
If pad_to_word is 1, scan lines are padded to a multiple of 4 bytes; the
normal return value is 0.
If pad_to_word is -1, scan lines are padded to a multiple of 4 bytes, and
in addition, the bytes may be swapped within a word. The normal return
value is 0 if no byte swapping is needed, 2 if bytes must be swapped
within a 16-bit word, or 4 if bytes must be swapped within a 32-bit word.
Properties
----------
Devices may have an open-ended set of properties, which are simply pairs
consisting of a name and a value. The value may be of various types:
integer, boolean, float, string, array of integer, or array of float.
Property lists are somewhat complex. If your device has properties beyond
those of a straightforward display or printer, we strongly advise using
the code for the default implementation of get_props and put_props in
gsdevice.c as a model for your own code.
int (*get_props)(P2(gx_device *dev, gs_prop_item *plist)) [OPTIONAL]
Read all the properties of the device into the property list at
plist. Return the number of properties. See gsprops.h for more details,
gx_default_get_props in gsdevice.c for an example.
If plist is NULL, just return the number of properties plus the
total number of elements in all array-valued properties. This is how the
getdeviceprops operator finds out how much storage to allocate for the
property list.
int (*put_props)(P3(gx_device *dev, gs_prop_item *plist,
int count)) [OPTIONAL]
Set the properties of the device from the property list at plist.
Return 0 if everything was OK, an error code
(gs_error_undefined/typecheck/rangecheck/limitcheck) if some property had
an invalid type or out-of-range value. See gsprops.h for more details,
gx_default_put_props in gsdevice.c for an example.
Changing device properties may require closing the device and
reopening it. If this is the case, the put_props procedure should
just close the device; a higher-level routine (gs_putdeviceprops)
will reopen it.

264
Linux-0.98/Yggdrasil-0.98.3/usr/lib/ghostscript/doc/fonts.doc Normal file
View File

@@ -0,0 +1,264 @@
Copyright (C) 1990, 1991 Aladdin Enterprises. All rights reserved.
Distributed by Free Software Foundation, Inc.
This file is part of Ghostscript.
Ghostscript is distributed in the hope that it will be useful, but
WITHOUT ANY WARRANTY. No author or distributor accepts responsibility
to anyone for the consequences of using it or for whether it serves any
particular purpose or works at all, unless he says so in writing. Refer
to the Ghostscript General Public License for full details.
Everyone is granted permission to copy, modify and redistribute
Ghostscript, but only under the conditions described in the Ghostscript
General Public License. A copy of this license is supposed to have been
given to you along with Ghostscript so you can know your rights and
responsibilities. It should be in a file named COPYING. Among other
things, the copyright notice and this notice must be preserved on all
copies.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
This file, fonts.doc, describes the fonts and font facilities supplied
with Ghostscript.
For an overview of Ghostscript and a list of the documentation files, see
README.
About Ghostscript fonts
=======================
The fonts included with Ghostscript come in several parts:
- Font data in files *.gsf: each file defines one
(transformable) font specified in outline form.
- BuildChar procedures in gs_fonts.ps: these provide the
algorithms for interpreting the data in the .gsf files.
- The Fontmap file: this relates Ghostscript font names to .gsf
file names.
Currently, most of the fonts supplied with Ghostscript are based on
various public domain bitmap fonts, primarily the ones supplied with the
X11 distribution from MIT, and on the public domain Hershey fonts. The
fonts are distributed in the file `ghostscript-N.NNfonts.tar.Z'. The
bitmap-derived fonts include the usual Helvetica, Times-Roman, and so on;
see the file `Fontmap' for the complete list, in the usual roman, italic,
bold, and bold italic styles (for the most part). The Hershey fonts, on
the other hand, are quite different from traditional ones; the file
`hershey.doc' describes them in more detail.
There is also a single rather heavy home-grown font called Ugly. This
font is the file `uglyr.gsf' in the Ghostscript source distribution.
The file gs_fonts.ps, which is loaded as part of Ghostscript
initialization, arranges to load fonts on demand using the information
from Fontmap. If you want to preload all of the known fonts, invoke the
procedure
loadallfonts
This is not done by default, since the fonts occupy about 50K each and there
are a lot of them.
Ghostscript fonts are actually ordinary Ghostscript programs: they use the
extension .gsf instead of .ps simply to be informative. This convention
is only embodied in the Fontmap file: there is no code that knows about
it.
If you want to try out the fonts, prfont.ps contains code for printing a
sampler. Load this program, by including it in the gs command line or by
invoking
(prfont.ps) run
and then to produce a sampler of a particular font, invoke
/fontName DoFont
e.g.
/Times-Roman DoFont
Contents of fonts
-----------------
A Ghostscript font is a dictionary with a standard set of keys as follows.
The keys marked with a * have the same meanings as in P*stScr*pt fonts;
those marked with # have the same meanings as in Adobe Type 1 fonts. Note
that FontName is required; StrokeWidth is required for all stroked or
outlined fonts; and Metrics is not currently supported.
* - FontMatrix <array>: the transformation from character
coordinates to user coordinates.
* - FontType <integer>: the type of the font, either 1 or 3.
* - FontBBox <array>: the bounding box of the font.
* - Encoding <array>: the map from character codes to character
names.
* - FontName <name>: the name of the font.
* - PaintType <integer>: an indication of how to interpret the
character description from CharInfo.
* - StrokeWidth <number>: the stroke width for outline fonts.
* - FontInfo <dictionary>: additional information about the font
(optional, not used by the standard Ghostscript software).
* - UniqueID <integer>: a unique number identifying the font.
* - BuildChar <procedure>: the procedure for showing a character
(not required in type 1 fonts).
# - CharStrings <dictionary>: the map from character names to character
descriptions (relevant only in type 1 fonts).
# - Private <dictionary>: additional information used by the
algorithms for rendering outlines fonts (relevant only in type 1
fonts).
The format of values in the CharStrings and Private dictionaries are
described in the Adobe Type 1 Font Format book.
Adding your own fonts
=====================
Ghostscript can use any Type 1 or Type 3 font that is acceptable to other
PostScript language interpreters. Ghostscript also provides a way to
construct a Type 1 font from a bitmap font in BDF format, which is a
popular format in the Unix world.
If you want to add fonts of your own, you must edit Fontmap to include an
entry for your new font at the end. The format for entries is documented
in the Fontmap file. Since later entries in Fontmap override earlier
entries, any fonts you add will supersede the corresponding fonts supplied
with Ghostscript.
In the PC world, Type 1 fonts are customarily given names ending in .PFA
or .PFB. Ghostscript can use these directly; you just need to make the
entry in Fontmap. If you are going to use a commercial Type 1 font (such
as fonts obtained in conjunction with Adobe Type Manager) with
Ghostscript, please read carefully the license that accompanies the font;
Aladdin Enterprises and the Free Software Foundation take no
responsibility for any possible violations of such licenses.
If you want to convert a BDF file to a scalable outline, use the program
bdftops.ps (and invoking shell script bdftops.bat or bdftops). Run the
shell command
bdftops <BDF_file_name> [<AFM_file1_name> ...] <your_gsf_file_name>
<font_name> <uniqueID> [<encoding_name>]
e.g.,
bdftops pzdr.bdf ZapfDingbats.afm pzdr.gsf ZapfDingbats 4100000
Then make an entry for the .gsf file in Fontmap as described above. You
may find it helpful to read, and to add an entry to, the fonts.mak file,
which is a makefile for converting the standard Ghostscript fonts.
Precompiling fonts
==================
You can compile any Type 1 font into C and link it into the Ghostscript
executable. (Type 1 fonts include any font whose name ends with .pfa or
.pfb, and it also includes all the Ghostscript .gsf fonts except for the
Hershey fonts.) This doesn't have any effect on rendering speed, but it
eliminates the time for loading the font dynamically, which may make a big
difference in total rendering time, especially for multi-page documents.
(Because of RAM and compiler limitations, you should only use compiled
fonts on MS-DOS systems if you are using a 32-bit compiler such as Watcom
C/386 or djgpp; you will run out of memory if you use compiled fonts with
the Borland compiler.) Fonts that have been precompiled and linked in
this way do not need to appear in the Fontmap, although if they do appear
there, no harm is done.
The utility for precompiling fonts is called font2c. (Note that font2c is
a PostScript language program, so you must have some version of
Ghostscript already running to be able to run font2c.) For example, to
precompile the Times-Italic font,
font2c Times-Italic ptmri.c
where the first argument is the font name and the second is the name of
the .c file. You can use any file name you want, as long as it ends in
.c. It doesn't have to be limited to 8 characters, unless your operating
system requires this. We suggest that you use names xxxx.c, where
xxxx.gsf or xxxx.pfa is the name of the font file in the Fontmap file,
just so you don't have to keep track of another set of names. (If you are
running on a VMS platform, or another platform where the C compiler has a
limit on the length of identifiers, you must do something slightly more
complicated; see the section 'Platforms with identifier length limits'
below.)
Besides running font2c, you must arrange things so that the file will be
compiled from C to machine code, and linked into the executable. All
environments except VMS use the same procedure for this, which we will now
describe. For VMS environments, the necessary information is contained in
comments in the command files (vms-cc.mak and vms-gcc.mak); if you are
using Ghostscript on VMS, ignore the rest of this subsection.
First, you must add the compiled fonts "feature" to your platform-specific
makefile. On MS-DOS systems, you edit turboc.mak, tbcplus.mak, or
watc.mak; on Unix systems, you edit makefile. Find the definition of
FEATURE_DEVS in the makefile, e.g.,
FEATURE_DEVS=filter.dev dps.dev
Add ccfonts.dev on the end, e.g.,
FEATURE_DEVS=filter.dev dps.dev ccfonts.dev
Next, you must add the specific fonts to the generic makefile. On MS-DOS
systems, you edit gs.mak; on Unix systems, you edit makefile. Find the
line in the relevant makefile that says
ccfonts_=ugly.$(OBJ)
Edit this to add your compiled font file names, e.g.,
ccfonts_=ugly.$(OBJ) ptmri.$(OBJ)
Then find the line that says
$(SHP)gsaddmod ccfonts_ -font Ugly
Add your own fonts to the end of this line, e.g.,
$(SHP)gsaddmod ccfonts_ -font Ugly Times_Italic
Notice that you must replace `-' by `_' in the font name. If the line
gets too long, add another line of the same form, e.g.,
$(SHP)gsaddmod ccfonts_ -font Ugly
$(SHP)gsaddmod ccfonts_ -font Times_Italic
Now find the lines that say
ugly.$(OBJ): ugly.c $(CCFONT)
$(CCCF) ugly.c
Add a similar pair of lines for each font, separating these entries from
the existing entries and from each other by a blank line. (The makefile
includes lines for a few more fonts than this already.) In our example,
ugly.$(OBJ): ugly.c $(CCFONT)
$(CCCF) ugly.c
ptmri.$(OBJ): ptmri.c $(CCFONT)
$(CCCF) ptmri.c
Finally, run `make'. The executable will now include the fonts you added.
They will be present in FontDirectory when Ghostscript starts up.
Note that ugly.c, ncrr.c, etc. are not supplied with the Ghostscript
fileset, since they are quite large and can easily be recreated using the
font2c program as described above.
Platforms with identifier length limits
---------------------------------------
On some platforms, the C compiler and/or linker have a limit on the number
of significant characters in an identifier. On such platforms, you must
do a little extra work.
Let N be the maximum number of significant characters in an identifier
(typically 31). For each font whose name is longer than N-5 characters,
pick an arbitrary identifier that we will call the "short name". This can
be any string you want, as long as it contains only letters, digits, and
underscores; is no longer than N-5 characters; and is not the same as any
other font name or short name. A good choice for this would be to use the
name of the C file. (There is no harm in doing this for fonts with names
shorter than N-5 characters, it's just not necessary.)
You must do two different things for fonts that require a short name.
First, you must supply the short name as a third argument to the font2c
program. For example, to compile NewCenturySchlbk-BoldItalic using the
short name "pncbi",
font2c NewCenturySchlbk-BoldItalic pncbi.c pncbi
Then when you add the font to the gsaddmod line in the makefile, use the
short name, not the actual font name, e.g.,
$(SHP)gsaddmod ccfonts_ -font pncbi
instead of
$(SHP)gsaddmod ccfonts_ -font NewCenturySchlbk_BoldItalic
Everything else is as described above.
This procedure doesn't change the name of the font in the Fontmap, or as
seen from within Ghostscript; it's just a workaround for a limitation of
some older compilers.

261
Linux-0.98/Yggdrasil-0.98.3/usr/lib/ghostscript/doc/hershey.doc Normal file
View File

@@ -0,0 +1,261 @@
This file is part of Ghostscript. Unlike the rest of Ghostscript, it
consists entirely of information copied directly from public sources. It
therefore is not covered by the Ghostscript copyright or license.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Mod.sources: Volume 4, Issue 42
Submitted by: pyramid!octopus!pete (Pete Holzmann)
This is part 1 of five parts of the first Usenet distribution of
the Hershey Fonts. See the README file for more details.
Peter Holzmann, Octopus Enterprises
USPS: 19611 La Mar Court, Cupertino, CA 95014
UUCP: {hplabs!hpdsd,pyramid}!octopus!pete
Phone: 408/996-7746
This distribution is made possible through the collective encouragement
of the Usenet Font Consortium, a mailing list that sprang to life to get
this accomplished and that will now most likely disappear into the mists
of time... Thanks are especially due to Jim Hurt, who provided the packed
font data for the distribution, along with a lot of other help.
This file describes the Hershey Fonts in general, along with a description of
the other files in this distribution and a simple re-distribution restriction.
USE RESTRICTION:
This distribution of the Hershey Fonts may be used by anyone for
any purpose, commercial or otherwise, providing that:
1. The following acknowledgements must be distributed with
the font data:
- The Hershey Fonts were originally created by Dr.
A. V. Hershey while working at the U. S.
National Bureau of Standards.
- The format of the Font data in this distribution
was originally created by
James Hurt
Cognition, Inc.
900 Technology Park Drive
Billerica, MA 01821
(mit-eddie!ci-dandelion!hurt)
2. The font data in this distribution may be converted into
any other format *EXCEPT* the format distributed by
the U.S. NTIS (which organization holds the rights
to the distribution and use of the font data in that
particular format). Not that anybody would really
*want* to use their format... each point is described
in eight bytes as "xxx yyy:", where xxx and yyy are
the coordinate values as ASCII numbers.
*PLEASE* be reassured: The legal implications of NTIS' attempt to control
a particular form of the Hershey Fonts *are* troubling. HOWEVER: We have
been endlessly and repeatedly assured by NTIS that they do not care what
we do with our version of the font data, they do not want to know about it,
they understand that we are distributing this information all over the world,
etc etc etc... but because it isn't in their *exact* distribution format, they
just don't care!!! So go ahead and use the data with a clear conscience! (If
you feel bad about it, take a smaller deduction for something on your taxes
next week...)
The Hershey Fonts:
- are a set of more than 2000 glyph (symbol) descriptions in vector
( <x,y> point-to-point ) format
- can be grouped as almost 20 'occidental' (english, greek,
cyrillic) fonts, 3 or more 'oriental' (Kanji, Hiragana,
and Katakana) fonts, and a few hundred miscellaneous
symbols (mathematical, musical, cartographic, etc etc)
- are suitable for typographic quality output on a vector device
(such as a plotter) when used at an appropriate scale.
- were digitized by Dr. A. V. Hershey while working for the U.S.
Government National Bureau of Standards (NBS).
- are in the public domain, with a few caveats:
- They are available from NTIS (National Technical Info.
Service) in a computer-readable from which is *not*
in the public domain. This format is described in
a hardcopy publication "Tables of Coordinates for
Hershey's Repertory of Occidental Type Fonts and
Graphic Symbols" available from NTIS for less than
$20 US (phone number +1 703 487 4763).
- NTIS does not care about and doesn't want to know about
what happens to Hershey Font data that is not
distributed in their exact format.
- This distribution is not in the NTIS format, and thus is
only subject to the simple restriction described
at the top of this file.
Hard Copy samples of the Hershey Fonts are best obtained by purchasing the
book described above from NTIS. It contains a sample of all of the Occidental
symbols (but none of the Oriental symbols).
This distribution:
- contains
* a complete copy of the Font data using the original
glyph-numbering sequence
* a set of translation tables that could be used to generate
ASCII-sequence fonts in various typestyles
* a couple of sample programs in C and Fortran that are
capable of parsing the font data and displaying it
on a graphic device (we recommend that if you
wish to write programs using the fonts, you should
hack up one of these until it works on your system)
- consists of the following files...
hershey.doc - details of the font data format, typestyles and
symbols included, etc.
hersh.oc[1-4] - The Occidental font data (these files can
be catenated into one large database)
hersh.or[1-4] - The Oriental font data (likewise here)
*.hmp - Occidental font map files. Each file is a translation
table from Hershey glyph numbers to ASCII
sequence for a particular typestyle.
hershey.f77 - A fortran program that reads and displays all
of the glyphs in a Hershey font file.
hershey.c - The same, in C, using GKS, for MS-DOS and the
PC-Color Graphics Adaptor.
Additional Work To Be Done (volunteers welcome!):
- Integrate this complete set of data with the hershey font typesetting
program recently distributed to mod.sources
- Come up with an integrated data structure and supporting routines
that make use of the ASCII translation tables
- Digitize additional characters for the few places where non-ideal
symbol substitutions were made in the ASCII translation tables.
- Make a version of the demo program (hershey.c or hershey.f77) that
uses the standard Un*x plot routines.
- Write a banner-style program using Hershey Fonts for input and
non-graphic terminals or printers for output.
- Anything else you'd like!
SHAR_EOF
This file provides a brief description of the contents of the Occidental
Hershey Font Files. For a complete listing of the fonts in hard copy, order
NBS Special Publication 424, "A contribution to computer typesetting
techniques: Tables of Coordinates for Hershey's Repertory of Occidental
Type Fonts and Graphic Symbols". You can get it from NTIS (phone number is
+1 703 487 4763) for less than twenty dollars US.
Basic Glyph (symbol) data:
hersh.oc1 - numbers 1 to 1199
hersh.oc2 - numbers 1200 to 2499
hersh.oc3 - numbers 2500 to 3199
hersh.oc4 - numbers 3200 to 3999
These four files contain approximately 19 different fonts in
the A-Z alphabet plus greek and cyrillic, along with hundreds of special
symbols, described generically below.
There are also four files of Oriental fonts (hersh.or[1-4]). These
files contain symbols from three Japanese alphabets (Kanji, Hiragana, and
Katakana). It is unknown what other symbols may be contained therein, nor
is it known what order the symbols are in (I don't know Japanese!).
Back to the Occidental files:
Fonts:
Roman: Plain, Simplex, Duplex, Complex Small, Complex, Triplex
Italic: Complex Small, Complex, Triplex
Script: Simplex, Complex
Gothic: German, English, Italian
Greek: Plain, Simplex, Complex Small, Complex
Cyrillic: Complex
Symbols:
Mathematical (227-229,232,727-779,732,737-740,1227-1270,2227-2270,
1294-1412,2294-2295,2401-2412)
Daggers (for footnotes, etc) (1276-1279, 2276-2279)
Astronomical (1281-1293,2281-2293)
Astrological (2301-2312)
Musical (2317-2382)
Typesetting (ffl,fl,fi sorts of things) (miscellaneous places)
Miscellaneous (mostly in 741-909, but also elsewhere):
- Playing card suits
- Meteorology
- Graphics (lines, curves)
- Electrical
- Geometric (shapes)
- Cartographic
- Naval
- Agricultural
- Highways
- Etc...
ASCII sequence translation files:
The Hershey glyphs, while in a particular order, are not in an
ASCII sequence. I have provided translation files that give the
sequence of glyph numbers that will most closely approximate the
ASCII printing sequence (from space through ~, with the degree
circle tacked on at the end) for each of the above fonts:
File names are made up of fffffftt.hmp,
where ffffff is the font style, one of:
roman Roman
greek Greek
italic Italic
script Script
cyril Cyrillic (some characters not placed in
the ASCII sequence)
gothgr Gothic German
gothgb Gothic English
gothit Gothic Italian
and tt is the font type, one of:
p Plain (very small, no lower case)
s Simplex (plain, normal size, no serifs)
d Duplex (normal size, no serifs, doubled lines)
c Complex (normal size, serifs, doubled lines)
t Triplex (normal size, serifs, tripled lines)
cs Complex Small (Complex, smaller than normal size)
The three sizes are coded with particular base line (bottom of a capital
letter) and cap line (top of a capital letter) values for 'y':
Size Base Line Cap Line
Very Small -5 +4
Small -6 +7
Normal -9 +12
(Note: some glyphs in the 'Very Small' fonts are actually 'Small')
The top line and bottom line, which are normally used to define vertical
spacing, are not given. Maybe somebody can determine appropriate
values for these!
The left line and right line, which are used to define horizontal spacing,
are provided with each character in the database.
SHAR_EOF
Format of Hershey glyphs:
5 bytes - glyphnumber
3 bytes - length of data length in 16-bit words including left&right numbers
1 byte - x value of left margin
1 byte - x value of right margin
(length*2)-2 bytes - stroke data
left&right margins and stroke data are biased by the value of the letter 'R'
Subtract the letter 'R' to get the data.
e.g. if the data byte is 'R', the data is 0
if the data byte is 'T', the data is +2
if the data byte is 'J', the data is -8
and so on...
The coordinate system is x-y, with the origin (0,0) in the center of the
glyph. X increases to the right and y increases *down*.
The stroke data is pairs of bytes, one byte for x followed by one byte for y.
A ' R' in the stroke data indicates a 'lift pen and move' instruction.

27
Linux-0.98/Yggdrasil-0.98.3/usr/lib/ghostscript/doc/history.doc Normal file
View File

@@ -0,0 +1,27 @@
Copyright (C) 1992 Aladdin Enterprises. All rights reserved.
Distributed by Free Software Foundation, Inc.
This file is part of Ghostscript.
Ghostscript is distributed in the hope that it will be useful, but
WITHOUT ANY WARRANTY. No author or distributor accepts responsibility
to anyone for the consequences of using it or for whether it serves any
particular purpose or works at all, unless he says so in writing. Refer
to the Ghostscript General Public License for full details.
Everyone is granted permission to copy, modify and redistribute
Ghostscript, but only under the conditions described in the Ghostscript
General Public License. A copy of this license is supposed to have been
given to you along with Ghostscript so you can know your rights and
responsibilities. It should be in a file named COPYING. Among other
things, the copyright notice and this notice must be preserved on all
copies.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
This file, history.doc, formerly described the changes in the various
releases of Ghostscript. As of release 2.5, this file is now named
NEWS.
For an overview of Ghostscript and a list of the documentation files, see
README.

52
Linux-0.98/Yggdrasil-0.98.3/usr/lib/ghostscript/doc/humor.doc Normal file
View File

@@ -0,0 +1,52 @@
Copyright (C) 1989 Aladdin Enterprises. All rights reserved.
Distributed by Free Software Foundation, Inc.
This file is part of Ghostscript.
Ghostscript is distributed in the hope that it will be useful, but
WITHOUT ANY WARRANTY. No author or distributor accepts responsibility
to anyone for the consequences of using it or for whether it serves any
particular purpose or works at all, unless he says so in writing. Refer
to the Ghostscript General Public License for full details.
Everyone is granted permission to copy, modify and redistribute
Ghostscript, but only under the conditions described in the Ghostscript
General Public License. A copy of this license is supposed to have been
given to you along with Ghostscript so you can know your rights and
responsibilities. It should be in a file named COPYING. Among other
things, the copyright notice and this notice must be preserved on all
copies.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
This file, humor.doc, contains a humorous message, verbatim except for
minor spelling corrections, received from a friend out in network-land.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Regarding Ghostscript: I hate to say this to you but I've already
implemented a Ghostscript interpreter. I'm happy to see that someone else
has recognized the need dead people have for computers. I have included an
example of the output of my Ghostscript at the end of this letter.
The interpreter is written in a language called cant-C, developed by Mr.
Turing last year. The compiler is easily ported to any environment you
care to name. I would be more than happy to send you a copy, but you must
first contact my lawyer for this venture, Thomas Jefferson of Phila. Pa..
(As a side note, Mr. Jefferson is very excited by Ghostscript. Look for
The Declaration of Independance V1.1 RSN).
The possibilities for Ghostscript go far beyond Deathtop publishing, I'm
sure you'll agree. I have contacted numerous authors who may be interested
in using Ghostscript (Shakespeare, Hemingway, etc) and all have been very
excited by what they've seen. (Shakespeare wants to write a modern Romeo
and Juliette, called Romeo and Julio, the story of 2 gay hispanic men kept
apart by their parents.)
Anyway, here is the Ghostscript example I promised. Feel free to show this
to your friends and colleagues, I'm sure they'll all be suitably impressed.
------Cut Here--------------------------------------
------Cut Here--------------------------------------

380
Linux-0.98/Yggdrasil-0.98.3/usr/lib/ghostscript/doc/language.doc Normal file
View File

@@ -0,0 +1,380 @@
Copyright (C) 1989-1992 Aladdin Enterprises. All rights reserved.
Distributed by Free Software Foundation, Inc.
This file is part of Ghostscript.
Ghostscript is distributed in the hope that it will be useful, but
WITHOUT ANY WARRANTY. No author or distributor accepts responsibility
to anyone for the consequences of using it or for whether it serves any
particular purpose or works at all, unless he says so in writing. Refer
to the Ghostscript General Public License for full details.
Everyone is granted permission to copy, modify and redistribute
Ghostscript, but only under the conditions described in the Ghostscript
General Public License. A copy of this license is supposed to have been
given to you along with Ghostscript so you can know your rights and
responsibilities. It should be in a file named COPYING. Among other
things, the copyright notice and this notice must be preserved on all
copies.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
This file, language.doc, describes the Ghostscript language.
For an overview of Ghostscript and a list of the documentation files, see
README.
The Ghostscript interpreter, except as noted below, is intended to execute
properly any source program written in a language defined by reference to
the December 1990 printing of the PostScript Language Reference Manual
(Second Edition) published by Addison-Wesley (ISBN 0-201-18127-4). The
Ghostscript language includes the following elements of the PostScript
(TM) language:
- The full PostScript Level 1 language, as also defined in the
first edition of the PostScript Language Reference Manual, ISBN
0-201-10174-2, Addison-Wesley, 1985.
- The CMYK color, file system, version 25.0 language, and
miscellaneous additions listed in sections A.1.4, A.1.6, A.1.7, and A.1.8
of the Second Edition respectively.
- The Display PostScript extensions listed in section A.1.3 of the
Second Edition, but excluding the operators listed in section A.1.2, and
also excluding setbbox, xshow, xyshow, and yshow. These extensions are
only available if the dps feature was selected at the time that
Ghostscript was compiled and linked.
- A few other PostScript Level 2 operators, listed below.
Ghostscript also includes a number of operators defined below that are not
in the PostScript language.
Stub facilities
---------------
The following operators, while provided in the current release, have only
a partial or dummy implementation.
Character and font operators:
cshow, rootfont, setcachedevice2
Graphics state operators:
currentblackgeneration, currentcmykcolor, currentcolorscreen,
currentcolortransfer, currenthalftonephase, currentundercolorremoval,
setblackgeneration, setcmykcolor, setcolorscreen,
setcolortransfer, sethalftonephase, setundercolorremoval,
currenthalftone, sethalftone,
setbbox
Interpreter parameter operators:
setucacheparams, ucachestatus
Path construction operators:
ucache
Virtual memory operators:
currentshared, scheck, setshared, setvmthreshold, shareddict,
SharedFontDirectory, vmreclaim
Level 2 operators
-----------------
The following PostScript Level 2 operators are available in
Ghostscript. Unless otherwise noted, these are only available if the
level2 feature was selected at the time that Ghostscript was compiled
and linked.
File operators:
filter (not all filters are implemented, and most of the
implemented ones are only available if the filter feature was
selected when Ghostscript was built)
Graphics state operators:
currentcolor, currentcolorspace, setcolor, setcolorspace
(for DeviceGray, DeviceRGB, and DeviceCMYK only)
currentstrokeadjust, setstrokeadjust (even if level2 is
not selected)
In addition, Ghostscript supports the following Level 2 facilities:
- Use of a string with the status operator (even if level2 is
not selected);
- Use of a dictionary with the image and imagemask operators;
- Use of a string or a file as data source with the image,
imagemask, and colorimage operators (even if level2 is not selected).
Ghostscript-specific additions
==============================
Miscellaneous
-------------
^Z is counted as whitespace.
run can take either a string or a file as its argument. In the former
case, it uses findlibfile to open the file (searching directories as
needed). In the latter case, it just runs the file, closing it at the
end, and trapping errors just as for the string case.
Mathematical operators
----------------------
<number> arccos <number>
Computes the arc cosine of a number between -1 and 1.
<number> arcsin <number>
Computes the arc sine of a number between -1 and 1.
Dictionary operators
--------------------
<dict> <integer> setmaxlength -
Changes the capacity of a dictionary, preserving its
contents. Causes a dictfull error if the requested
capacity is less than the current number of occupied
entries.
String operators
----------------
<string|name|other> <patternString> stringmatch <boolean>
Determines whether the string or name matches the given
pattern. In the pattern, `*' matches any substring of
the string, `?' matches any single character, and `\'
quotes the next character. If the first argument is not
a string or name, stringmatch returns true if
patternString is a single *, and false otherwise.
<state> <fromString> <toString> type1encrypt <newState> <toSubstring>
Encrypts fromString according to the algorithm for Adobe
Type 1 fonts, writing the result into toString.
toString must be at least as long as fromString or a
rangecheck error occurs. state is the initial state of
the encryption algorithm (a 16-bit non-negative
integer); newState is the new state of the algorithm.
<state> <fromString> <toString> type1decrypt <newState> <toSubstring>
Decrypts fromString according to the algorithm for Adobe
Type 1 fonts, writing the result into toString. Other
specifications are as for type1encrypt.
Relational operators
--------------------
<number|string> <number|string> max <number|string>
Returns the larger of two numbers or strings.
<number|string> <number|string> min <number|string>
Returns the smaller of two numbers or strings.
File operators
--------------
<string> findlibfile <foundstring> <file> true or <string> false
Opens the file of the given name for reading. If the file
cannot be opened using the supplied name, searches
through directories as described in use.doc. If the
search fails, findlibfile simply pushes false on the
stack and returns, rather than causing an error.
<file> <integer> unread -
Pushes back the last-read character onto the front of the
file. If the file is only open for writing, or if the
integer argument is not the same as the last character
read from the file, causes an ioerror error. May also
cause an ioerror if the last operation on the file was not
a reading operation.
<file> <device> writeppmfile -
Writes the contents of the device, which must be an image
device, onto the file, in Portable PixMap (ppm) format.
Does not close the file.
Path operators
--------------
<x> <y> <width> <height> rectappend -
<numarray> rectappend -
<numstring> rectappend -
Appends a rectangle or rectangles to the current path, in
the same manner as rectfill, rectclip, etc. Only
defined if the dps option is selected.
Filters
-------
Ghostscript supports all standard filters except DCTEncode and
DCTDecode. Ghostscript does not support the use of a procedure as a
data source or sink, only a file or a string. In addition,
Ghostscript supports two non-standard filters:
<file|string> <seed_integer> /eexecDecode filter <file>
Creates a filter for decrypting data that has been
encrypted using eexec encryption as described in the
Adobe Type 1 Font Format documentation. The
seed_integer must be 55665 for proper operation.
<file|string> <hex_boolean> /PFBDecode filter <file>
Creates a filter that decodes data in .PFB format, the
usual semi-binary representation for Type 1 font files
on IBM PC and compatible systems. If hex_boolean is true,
binary packets are converted to hex; if false, binary
packets are not converted.
Miscellaneous operators
-----------------------
- currenttime <number>
Returns the current value of a continuously-running timer,
in minutes. The initial value of this timer is undefined.
<string> getenv <string> true or false
Looks up a name in the shell environment. If the name is
found, returns the corresponding value and true; if the
name is not found, returns false.
<name> <array> makeoperator <operator>
Constructs and returns a new operator that is actually the
given procedure in disguise. The name is only used for
printing. The operator has the executable attribute.
<string> <boolean> setdebug -
If the Ghostscript interpreter was built with the DEBUG
flag set, sets or resets any subset of the debugging
flags normally controlled by -Z in the command line.
Has no effect otherwise.
Device operators
----------------
<device> copydevice <device>
Copies a device.
<index> getdevice <device>
Returns a device from the set of devices known to the
system. The first device, which is default, is numbered
0. If the index is out of range, causes a rangecheck
error.
<matrix> <width> <height> <palette> makeimagedevice <device>
Makes a new device that accumulates an image in memory.
matrix is the initial transformation matrix: it must be
orthogonal (i.e., [a 0 0 b x y] or [0 a b 0 x y]).
palette is a string of 2^N or 3*2^N elements, specifying
how the 2^N possible pixel values will be interpreted.
Each element is interpreted as a gray value, or as RGB
values, multiplied by 255. For example, if you want
a monochrome image for which 0=white and 1=black, the
palette should be <ff 00>; if you want a 3-bit deep
image with just the primary colors and their complements
(ignoring the fact that 3-bit images are not supported),
the palette might be <000000 0000ff 00ff00 00ffff
ff0000 ff00ff ffff00 ffffff>. At present,
the palette must contain exactly 2 or 256 entries,
and must contain an entry for black and an entry
for white; if it contains any entries that aren't black,
white, or gray, it must contain at least the six primary
colors (red, green, blue, and their complements cyan,
magenta, and yellow); aside from this, its contents are
arbitrary. (4-entry or 16-entry palettes, corresponding
to 2- or 4-bit pixels, may be supported eventually.)
Alternatively, palette can be null. This is interpreted
as 32-bit-per-pixel color, where the four bytes of each
pixel are respectively unused, R, G, and B.
Note that one can also make an image device (with the same
palette as an existing image device) by copying a device
using the copy operator.
<device> <index> <string> copyscanlines <substring>
Copies one or more scan lines from an image device into a
string, starting at a given scan line in the image.
The data is in the same format as for the image
operator. Error if the device is not an image device or
if the string is too small to hold at least one complete
scan line. Always copies an integral number of scan
lines.
<device> setdevice -
Sets the current device to the specified device. Also
resets the transformation and clipping path to the
initial values for the device.
- currentdevice <device>
Gets the current device from the graphics state.
<device> devicename <string>
Gets the name of a device.
<device> <matrix> deviceinitialmatrix <matrix>
Gets the initial matrix of a device, i.e., the one that
defaultmatrix would return if the device were the
current device.
<device> getdeviceprops <mark> <name1> <value1> ... <namen> <valuen>
Gets all the properties of a device. Currently defined
names and values for all devices are:
HWResolution [<float> <float>]
X and Y resolution in pixels/inch.
HWSize [<integer> <integer>]
X and Y size in pixels.
InitialMatrix [<6 floats>]
Initial transformation matrix.
Name <string>
Read-only. The device name.
For printers, the following are also defined:
BufferSpace <integer>
Buffer space for band lists, if the bitmap
is too big to fit in RAM.
MaxBitmap <integer>
Maximum space for a full bitmap in RAM.
OutputFile <string>
() means send to printer directly,
otherwise specifies the file name for
output; a %d is replaced by the page #;
on Unix systems, (|command) writes to a pipe
PageCount <integer>
Read-only. Counts the number of pages
printed on the device.
<mark> <name1> <value1> ... <namen> <valuen> <device>
putdeviceprops <device>
Sets properties of a device. May cause undefined,
typecheck, rangecheck, or limitcheck errors.
- flushpage -
On displays, flushes any buffered output, so that it
is guaranteed to show up on the screen; on printers,
has no effect.
Character operators
-------------------
<string> type1addpath -
Adds the description of a character to the current path,
and then optionally renders the character. The string
argument is a scalable description encoded in Adobe Type
1 format. This operator is only valid in the context of
a show operator, like setcharwidth and setcachedevice.
It uses information from the current font, in addition
to the argument.
<font> <char> Type1BuildChar -
This is not a new operator: rather, it is a name known
specially to the interpreter. Whenever the interpreter
needs to render a character (during a ...show,
stringwidth, or charpath), it looks up the name
BuildChar in the font dictionary to find a procedure to
run. If it does not find this name, and if the FontType
is 1, the interpreter instead uses the value (looked up
on the dictionary stack in the usual way) of the name
Type1BuildChar.
The standard definition of Type1BuildChar is in gs_fonts.ps.
Users should not need to redefine Type1BuildChar, except
perhaps for tracing or debugging.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
PostScript is a trademark of Adobe Systems, Incorporated.

79
Linux-0.98/Yggdrasil-0.98.3/usr/lib/ghostscript/doc/lib.doc Normal file
View File

@@ -0,0 +1,79 @@
Copyright (C) 1989 Aladdin Enterprises. All rights reserved.
Distributed by Free Software Foundation, Inc.
This file is part of Ghostscript.
Ghostscript is distributed in the hope that it will be useful, but
WITHOUT ANY WARRANTY. No author or distributor accepts responsibility
to anyone for the consequences of using it or for whether it serves any
particular purpose or works at all, unless he says so in writing. Refer
to the Ghostscript General Public License for full details.
Everyone is granted permission to copy, modify and redistribute
Ghostscript, but only under the conditions described in the Ghostscript
General Public License. A copy of this license is supposed to have been
given to you along with Ghostscript so you can know your rights and
responsibilities. It should be in a file named COPYING. Among other
things, the copyright notice and this notice must be preserved on all
copies.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
This file, lib.doc, describes the Ghostscript library, a collection of C
procedures that implement the primitive graphic operations of the
Ghostscript language.
For an overview of Ghostscript and a list of the documentation files, see
README.
********
******** The Ghostscript library ********
********
Ghostscript is actually two programs: a language interpreter, and a
graphics library. The library provides, in the form of C procedures, all
the graphics functions of the language, i.e., approximately those
facilities listed in section 6.2 of the PostScript manual starting with
the graphics state operators. In addition, the library provides some
lower-level graphics facilities that offer higher performance in exchange
for less generality.
To be specific, the highest level of the library implements all the
operators in the "graphics state", "coordinate system and matrix", "path
construction", "painting", "character and font", and "font cache" sections
of the PostScript manual, with the following deliberate exceptions:
settransfer, currenttransfer
definefont, findfont
FontDirectory, StandardEncoding
The following "device" operators are implemented:
showpage (synchronizes the display)
nulldevice
There are slight differences in the operators that return multiple values,
since C's provisions for this are awkward. Also, the control structure
for the operators involving (an) auxiliary procedure(s) (setscreen,
pathforall, image, imagemask) is partly inverted: the client calls a
procedure to set up an enumerator object, and then calls another procedure
for each iteration. The ...show operators, charpath, and stringwidth
also use an inverted control structure.
Files named gs*.c implement the higher level of the graphics library.
To use the facilities of gs?.c, a client program should include
gs?.h. As might be expected, all procedures, variables, and
structures available at this level begin with gs_. Structures that
appear in these interfaces, but whose definitions may be hidden from
clients, also have names beginning with gs_, i.e., the prefix
reflects at what level the abstraction is made available, not the
implementation.
Files named gx*.c implement the lower level of the graphics library.
To use the facilities of gx?.c, a client program should include
gx?.h. The interfaces at the gx level are less stable, and expose
more of the implementation detail, than those at the gs level: in
particular, the gx interfaces generally use device coordinates in an
internal fixed-point representation, as opposed to the gs interfaces
that use floating point user coordinates. Named entities at this
level begin with gx_.
Files named gz*.c and gz*.h are internal to the Ghostscript
implementation, and not designed to be called by clients.

524
Linux-0.98/Yggdrasil-0.98.3/usr/lib/ghostscript/doc/make.doc Normal file
View File

@@ -0,0 +1,524 @@
Copyright (C) 1989, 1990, 1991 Aladdin Enterprises. All rights reserved.
Distributed by Free Software Foundation, Inc.
This file is part of Ghostscript.
Ghostscript is distributed in the hope that it will be useful, but
WITHOUT ANY WARRANTY. No author or distributor accepts responsibility
to anyone for the consequences of using it or for whether it serves any
particular purpose or works at all, unless he says so in writing. Refer
to the Ghostscript General Public License for full details.
Everyone is granted permission to copy, modify and redistribute
Ghostscript, but only under the conditions described in the Ghostscript
General Public License. A copy of this license is supposed to have been
given to you along with Ghostscript so you can know your rights and
responsibilities. It should be in a file named COPYING. Among other
things, the copyright notice and this notice must be preserved on all
copies.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
This file, make.doc, describes how to install Ghostscript, and how to
build Ghostscript executables from source.
For an overview of Ghostscript and a list of the documentation files, see
README.
********
******** Installing Ghostscript
********
To install the interpreter, you need:
- The interpreter executable:
- On MS-DOS and VMS systems, gs.exe.
- On MS-DOS systems, if you are using the Watcom compiler,
the DOS extender, dos4gw.exe.
- On Unix systems, gs.
- The interpreter initialization files: gs_*.ps and sym__enc.ps.
- The font map: Fontmap.
- The default font: uglyr.gsf.
See use.doc for a description of the search algorithm used to find these
files.
You do not need any of these files when using the library; however, the
library currently provides no way to install fonts. This is obviously
ridiculous and will be fixed sometime in the future.
********
******** Building Ghostscript from source
********
Ghostscript is generally distributed in the form of a compressed tar file.
When unpacked, this file puts all the Ghostscript files in a directory
called gs. Ghostscript is also available in the form of PC-compatible ZIP
files.
Ghostscript is described by a collection of several makefiles:
gs.mak - a generic makefile used on all platforms (except VMS).
devs.mak - a makefile listing all the device drivers.
*.mak - the makefiles for specific platforms.
You may need to edit the platform-specific makefile if you wish to change
any of the following options:
- The default search path(s) for the initialization and font files
(macro GS_LIB_DEFAULT);
- The debugging options (macro TDEBUG);
- The set of device drivers to be included (DEVICE_DEVS
and DEVICE_DEVS2..5 macros);
- The set of optional features to be included (FEATURE_DEVS macro).
The platform-specific makefile will include comments describing all of
these items except the DEVICE_DEVS options. The DEVICE_DEVS options are
described in devs.mak, even though the file that must be edited is the
platform-specific makefile.
The makefiles distributed with Ghostscript define these options as
follows:
- GS_LIB_DEFAULT: on Unix systems, the current directory at build
time; on MS-DOS systems, C:\GS.
- TDEBUG: no debugging code included in the build.
- DEVICE_DEVS*: platform-specific, see below.
- FEATURE_DEVS: platform-specific.
There are also platform-specific options described below under the
individual platforms. See the "Options" section near the beginning of the
relevant makefile for more information.
If you are including a dot-matrix printer driver, you may wish to
customize the default resolution parameters in devs.mak.
To build the interpreter, you need all the .h and .c files (and .asm files
for MS-DOS) included in the distribution, as well as the makefiles.
The command
make clean
removes all the files created by the build process (relocatables,
executables, and miscellaneous scratch files). If you want to save the
executable, you should move it to another directory first.
********
******** How to build Ghostscript from source (MS-DOS version) ********
********
To find out what devices the makefiles distributed with Ghostscript
select for inclusion in the executable, find the lines in the
appropriate makefiles of the form
FEATURE_DEVS=<list of features>
and
DEVICE_DEVS=<list of devices>
(similarly DEVICE_DEVS2... up to DEVICE_DEVS5)
The relevant makefiles are:
Turbo C: turboc.mak
Borland C++, MS-DOS: tbcplus.mak
Borland C++, MS Windows: bcwin.mak
Watcom C/386, MS-DOS: watc.mak
The options were chosen to strike a balance between RAM consumption
and likely usefulness. (Turbo C is limited to 640K and does not
support code overlaying; Borland C++ is limited to 640K, but supports
code overlaying under MS-DOS; Watcom C/386 is not limited to 640K.)
To build Ghostscript, you need MS-DOS version 3.3 or later, and a Borland
C/C++ development system or the Watcom C/386 development system. Details
are given below.
As noted above, the default configuration generates an executable that
assumes the directory where 'make' was run should be the final default
directory for looking up the Ghostscript initialization and font files.
To build the Ghostscript executable, all you need to do is give the
command
make
You must have COMMAND.COM in your path to build Ghostscript.
There is a special 'make' target that simply attempts to compile all the
.c files in the current directory. Some of these compilations will fail,
but the ones that succeed will go considerably faster, because they don't
individually pay the overhead of loading the compiler into memory. So a
good strategy for building the executable for the first time, or after a
change to a very widely used .h file, is:
make begin
and then
make
to do the compilations that failed the first time.
Note: if you get the Ghostscript sources from a Unix 'tar' file and unpack
the file on a MS-DOS machine, the files will all have linefeed instead of
carriage return + linefeed as the line terminator, which will make the C
compiler unhappy. I don't know the simplest way to fix this: just reading
each file into an editor and writing it back out again may be sufficient.
Borland environment
-------------------
To compile Ghostscript with the Borland environment, you need either Turbo
C (version 2.0 or later) or Turbo C++ or Borland C++ (version 1.0 or
later); specifically, the compiler, 'make' utility, and linker. You also
need either the Borland assembler (version 1.0 or later) or the Microsoft
assembler (version 4.0 or later). Before compiling or linking, you should
execute
echo !include "turboc.mak" >makefile
(for Turbo C and MS-DOS), or
echo !include "tbcplus.mak" >makefile
(for Turbo C++ or Borland C++ and MS-DOS), or
echo !include "bcwin.mak" >makefile
(for Turbo C++ or Borland C++ and Microsoft Windows), or
Besides the source files and the makefiles, you need:
turboc.cfg (the flags and switches for Turbo C)
gs.tr (the linker commands for the interpreter)
*.bat (a variety of batch files used in the build process)
There are extensive comments in the aforementioned .mak files
regarding various configuration parameters. If your configuration is
different from the following, you should definitely read those
comments and see if you want or need to change any of the parameters:
- The compiler files are in c:\tc (for Turbo C) or c:\bc (for
Turbo C++ or Borland C++) and its subdirectories.
- You are using the Borland assembler (tasm).
- You want an executable that will run on any PC-compatible,
regardless of processor type (8088, 8086, V20, 80186, 80286, V30, 80386,
80486) and regardless of whether a math coprocessor (80x87) is present.
NOTE: Borland C++ 3.0 has two problems that affect Ghostscript:
- The assembler, tasm, often crashes when attempting to
assemble gdevegaa.asm. If this happens, try again, or use another
assembler (e.g., an older version of tasm) if you have one, or set
USE_ASM=0 in the makefile.
- The math library for Microsoft Windows, mathwl.lib, has a
bug that causes floating point numbers to print incorrectly. Contact
Borland for a corrected version.
Watcom environment
------------------
To avoid annoying messages from the DOS extender, add the line
set DOS4G=quiet
to your autoexec.bat file.
To compile Ghostscript with the Watcom C/386 compiler, you need to create
a makefile by executing
echo !include watc.mak >makefile
To build Ghostscript, execute
wmake -u
********
******** How to build Ghostscript from source (Unix version) ********
********
The makefile distributed with Ghostscript selects the following devices
for inclusion in the build:
X Windows driver only.
Before compiling or linking, you should execute
ln -s unix-cc.mak makefile
or ln -s unix-gcc.mak makefile
or ln -s unix-ansi.mak makefile
depending on whether your C compiler is a standard Kernighan & Ritchie C
compiler, gcc being used in ANSI mode, or an ANSI C compiler other than
gcc respectively. (If you want to use gcc in non-ANSI mode, use
unix-cc.mak and define the CC macro to refer to gcc.)
If the X11 client header files are located in some directory which your
compiler does not automatically search, you must change the XINCLUDE macro
the makefile to include a specific -I switch. See the comment preceding
XINCLUDE in the makefile.
The only important customization of the X11 driver is the choice of
whether or not to use a backing pixmap. If you use a backing pixmap,
Ghostscript windows will redisplay properly when they are covered and
exposed, but drawing operations will go slower. This choice is controlled
by a line in the file gdevxini.c that says
private int use_backing = 1;
Changing this line to read
private int use_backing = 0;
will disable the use of a backing pixmap. However, portions of the
Ghostscript window may not be properly redrawn after the window is
restored from an icon or exposed after being occluded by another window.
Some versions of the X server do not implement tiling properly. This will
show up as broad bands of color where dither patterns should appear. If
this happens, in the file gdevx.c, change
private int use_XSetTile = 1;
to
private int use_XSetTile = 0;
and recompile. The result will run a lot slower, but the output should be
correct. If this fixes the problem, report it to whoever made your X
server.
Similarly, some versions of the X server do not implement bitmap/pixmap
displaying properly. This may show up as white or black rectangles where
characters should appear, or characters may appear in "inverse video"
(e.g., white on a black rectangle). If this happens, it may help you to
change, in the file gdevx.c,
private int use_XPutImage = 1;
to
private int use_XPutImage = 0;
and recompile. Again, there will be a serious performance penalty; again,
if this fixes the problem, notify the supplier of your X server.
Currently Ghostscript is set up to compile and link in a generic Unix
environment. Some Unix environments may require changing the LDFLAGS
macro in the makefile.
All you need to do to make an executable is invoke the shell command
make
Ghostscript uses ANSI syntax for function definitions. Because of this,
when compiling with cc, it must preprocess each .c file to convert it to
the older syntax defined in Kernighan and Ritchie, which is what most
current Unix compilers (other than gcc) support. This step is
automatically performed by a utility called ansi2knr, which is included in
the Ghostscript distribution. The makefile automatically builds ansi2knr.
The ansi2knr preprocessing step is included in the makefile rule for
compiling .c files. ansi2knr creates a file called _temp_.c to hold the
converted code. If you want to change this name for some reason, it is
defined in unix-cc.mak.
Note that the abovementioned makefiles are actually generated mechanically
from *head.mak, *tail.mak, gs.mak, and devs.mak. If you want to change
the makefile, edit the appropriate one of these files, and then invoke the
tar_cat
shell script to reconstruct the unix-*.mak makefile.
Platform-specific notes
-----------------------
386 Unix:
Due to a compiler bug, if you are building Ghostscript on an Intel
80386 system using a version of gcc older than version 1.38, you must not
use the -O option.
X11R5 may need #include <stddef.h> in x_.h.
Also see below regarding System V platforms.
Apollo:
You must run the compiler in ANSI-compatible mode (i.e., set AK=
<null string> in the makefile); otherwise, it gives incorrect error
messages for any function declared as returning a float value.
Convex:
Use unix-ansi.mak. Do not invoke optimization (-O1): there
are compiler bugs that lead to incorrect code. Set CFLAGS to
-fn -tm -no c1
DEC (Ultrix):
Many versions of DEC's X server (DECwindows) have bugs that
require setting use_XPutImage or use_XSetTile to 0, as described above.
H-P 700 series:
Use the compiler flags -Aa +O3 (*not* -O).
ISC Unix:
For ISC Unix with gcc, an appropriate make invocation is:
make XCFLAGS="-D__SVR3 -posix" LDFLAGS="-shlib -posix" \
EXTRALIBS="-linet -lnsl_s"
If this doesn't work for you, try removing the -shlib. ISC Unix may
also need one or more of the following in EXTRALIBS: -lpt, -lc_s.
See also under "386 Unix" above.
MIPS:
There is apparently a bug in the MIPS C compiler which causes
gxdither.c to compile incorrectly if optimization is enabled (-O). Until
a work-around is found, do not use -O with the MIPS C compiler.
Any platform with GNU make:
GNU make 3.59 can't handle the final linking step in some cases;
use the platform's standard make (e.g., /bin/make) if this happens.
RS/6000:
IBM RS/6000, you must define _POSIX_SOURCE and you must use the
c89 compiler, not cc, e.g.:
make -f unix-ansi.mak CC=c89 XCFLAGS=-D_POSIX_SOURCE \
XINCLUDE=-I/usr/misc/X11/include XLIBDIRS=-L/usr/misc/X11/lib
Apparently some (but not all) releases of the C library declare the hypot
function: if the declaration in math_.h produces an error message, try
removing it. Also, the IBM X11R3 server is known to be buggy: use the MIT
X server if possible. Even beyond all this, many people have trouble with
Ghostscript on the RS/6000. The usual symptom is that it compiles and
links OK, but produces garbaged output on the screen. The problem may be
related to particular versions of AIX or the X server; we don't have
enough information at this time. The following combinations of AIX and X
are known to fail:
AIX 3.1.5, MIT X11R4, c89
The following combinations are known to work:
AIX 3.1.5, MIT X11R5, c89
AIX 3.2, MIT X11R5, xlc 1.2.0.9
SCO Unix:
The SCO Unix C compiler apparently can't handle the Pn macros
in std.h. If you get strange compilation errors on SCO Unix, see if
you can get a compiler fix from SCO. Meanwhile, to use gcc with SCO
ODT, see gcc-head.mak for the appropriate switch settings. See also
under "386 Unix" above.
Sun:
The Sun unbundled C compiler (SC1.0) doesn't compile Ghostscript
properly if the -fast option is selected: Ghostscript core-dumps in
build_gs_font. Use -g, or use gcc.
The standard Sun cc may not compile iscan.c correctly if
optimization (-O) is selected. One symptom is that numbers such as 1.e-3
give a syntax error. This has been observed on a SPARCstation running
SunOS 4.1.1. If this happens, use -g for this file, or use gcc.
System V Unix platforms:
If you are using a stock System V platform that lacks rename
and gettimeofday, change PLATFORM=unix_ in the makefile to
PLATFORM=sysv_.
********
******** How to build Ghostscript from source (VAX/VMS version) ********
********
The files VMS-CC.MAK and VMS-GCC.MAK are VMS DCL command files which
build Ghostscript from scratch using either the DEC C compiler, CC, or
the Free Software Foundation's GNU C compiler, GCC. Accordingly, you
must have one of these two compilers installed in order to build
Ghostscript. (Other C compilers may work: CC and GCC are the only two
compilers tested to date.) These two command files build and store
the Ghostscript library in the object library GS.OLB. If you have
DECwindows (X11) installed on your system, the executable images GS.EXE,
GT.EXE, and XLIB.EXE will also be built.
In some environments (perhaps only Motif, as opposed to DECWindows,
environments), it may be necessary to add
SYS$SHARE:DECW$XLIBSHR/SHARE or SYS$SHARE:DECW$XTSHR.EXE/SHARE to the
list of link libraries, in addition to DWTLIBSHR. Only two users
have reported this problem, and we don't know under what
circumstances it occurs.
The only important customization of the X11 driver is the choice of
whether or not to use a backing pixmap. If you use a backing pixmap,
Ghostscript windows will redisplay properly when they are covered and
exposed, but drawing operations will go slower. This choice is controlled
by the line in the file gdevx.c that reads
private int use_backing = 1;
Changing this line to read
private int use_backing = 0;
will disable the use of a backing pixmap. However, portions of the
Ghostscript window may not be properly redrawn after the window is
restored from an icon or exposed after being occluded by another window.
Many versions of DEC's X server (DECwindows) have bugs that require
setting use_XPutImage or use_XSetTile to 0, as described above. These
show up as broad bands of color where dither patterns should appear, or
characters displayed white on top of black rectangles or not displayed at
all. If this happens, change use_XSetTile or use_XPutImage to 0 as
described above. The result will run a lot slower, but the output will be
correct. Report the problem to DEC, or whoever supplied your X server.
Ghostscript uses ANSI syntax for function definitions. Thus, when using
the DEC C compiler, each .C file is converted to the older C syntax defined
in the first edition of Kernighan and Ritchie and stored in a .CC file.
This step is performed by VMS-CC.MAK using the ansi2knr utility included
in the Ghostscript distribution. If you are building a debuggable
configuration, the .CC files will be left behind by VMS-CC.MAK for use by
the VMS Debugger; otherwise, they will be deleted.
If you have DEC's C compiler, issue the DCL command
$ @VMS-CC.MAK
to build Ghostscript. If you have GNU C, issue the DCL command
$ @VMS-GCC.MAK
to build Ghostscript.
The option "DEBUG" may be specified with either command file in order to
build a debuggable Ghostscript configuration:
$ @VMS-CC.MAK DEBUG -or- $ @VMS-GCC.MAK DEBUG
In order to specify switches and file names when invoking the interpreter,
define GS as a foreign command:
$ GS == "$disk:[directory]GS.EXE"
where "disk" and "directory" specify the disk and directory where Ghostscript
is located. For instance,
$ GS == "$DUA1:[GHOSTSCRIPT]GS.EXE"
To allow the interpreter to be run from any directory, define the logical
GS_LIB which points to the Ghostscript directory
$ DEFINE GS_LIB disk:[directory]
This allows Ghostscript to locate its initialization files stored in the
Ghostscript directory -- see use.doc for further details. Finally, to
invoke the interpreter, merely type GS. Although DCL normally converts
unquoted parameters to upper case, C programs receive their parameters in
lower case. That is, the command
$ GS -Isys$login:
passes the switch "-isys$login" to the interpreter. To preserve the
case of switches, enclose them in double quotes; e.g.,
$ GS "-Isys$login:"
If you add compiled fonts to your system as described in the fonts.doc
file, you must C-compile them in an environment that includes some
definitions from vms-cc.mak. Find the section of vms-cc.mak with the
comment "Give ourself a healthy search list for C include files" and
execute the immediately following DEFINE commands before C-compiling the
fonts.
********
******** A guide to the files ********
********
General
-------
There are very few machine dependencies in Ghostscript. A few of the .c
files are machine-specific. These have names of the form
gp_<platform>.c
specifically
gp_dosfb.c (all MS-DOS platforms)
gp_msdos.c (all MS-DOS platforms)
gp_itbc.c (MS-DOS, Borland compilers)
gp_iwatc.c (MS-DOS, Watcom compiler)
gp_unix.c (all Unix)
gp_sysv.c (System V Unix)
gp_vms.c (VMS)
There are also some machine-specific conditionals in files with names
<something>_.h. If you are going to extend Ghostscript to new
machines or operating systems, you should check the *_.h files for
ifdef's on things other than DEBUG, and you should probably count on
making a new makefile and a new gp_ file.
Library
-------
Files beginning with gs, gx, or gz (both .c and .h), other than gs.c
and gsmain.c, are the Ghostscript library. Files beginning with gdev
are device drivers or related code, also part of the library. Other
files beginning with g are library files that don't fall neatly into
either the kernel or the driver category.
Interpreter
-----------
gs.c is the main program for the language interpreter.
Files beginning with z are Ghostscript operator files. The names of the
files generally follow the section headings of the operator summary in
section 6.2 of the PostScript manual.
.c files beginning with i, and .h files not beginning with g, are the
rest of the interpreter. See the makefile for a little more information
on how the files are divided functionally.
There are a few files that are logically part of the interpreter, but that
are potentially useful outside Ghostscript, whose names don't begin with
either g, z, or i:
s*.c (a flexible stream package, including the Level 2 PostScript
'filters' supported by Ghostscript);

123
Linux-0.98/Yggdrasil-0.98.3/usr/lib/ghostscript/doc/psfiles.doc Normal file
View File

@@ -0,0 +1,123 @@
Copyright (C) 1990, 1992 Aladdin Enterprises. All rights reserved.
Distributed by Free Software Foundation, Inc.
This file is part of Ghostscript.
Ghostscript is distributed in the hope that it will be useful, but
WITHOUT ANY WARRANTY. No author or distributor accepts responsibility
to anyone for the consequences of using it or for whether it serves any
particular purpose or works at all, unless he says so in writing. Refer
to the Ghostscript General Public License for full details.
Everyone is granted permission to copy, modify and redistribute
Ghostscript, but only under the conditions described in the Ghostscript
General Public License. A copy of this license is supposed to have been
given to you along with Ghostscript so you can know your rights and
responsibilities. It should be in a file named COPYING. Among other
things, the copyright notice and this notice must be preserved on all
copies.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
This file, psfiles.doc, describes the .ps files distributed with
Ghostscript, other than fonts.
For an overview of Ghostscript and a list of the documentation files, see
README.
System files
------------
gs_init.ps - Ghostscript reads this automatically when it starts up. It
contains definitions of many standard procedures and initialization for a
wide variety of things.
gs_fonts.ps - gs_init.ps reads this in. It initializes Ghostscript's font
machinery and provides some utility procedures that work with fonts.
gs_statd.ps - gs_init.ps reads this in. It creates a dummy statusdict and
some other environmental odds and ends for the benefit of P*stScr*pt files
that really want to be printed on a LaserWriter.
gs_2asc.ps - This utility file helps extract the ASCII text from
PostScript source files. It redefines many operators. For more
information, see the comments in the file.
gs_dps1.ps - gs_init.ps reads this in if the dps feature is included in
the configuration. It provides support for various Display PostScript and
Level 2 features.
sym__enc.ps - the Symbol encoding, loaded only if referenced.
Art
---
chess.ps - A black-and-white chessboard.
golfer.ps - A gray-scale picture of a stylishly dressed woman swinging a
golf club.
escher.ps - A colored version of a hexagonally symmetric Escher drawing of
interlocking butterflies. Can be printed on monochrome devices, with
somewhat less dramatic results.
cheq.ps - A chessboard "font" used by chess.ps (obtained from the Adobe
file server).
snowflak.ps - A rectangular grid of intricate colored snowflakes.
(Renders very slowly.)
colorcir.ps - A set of nested ellipses made up of colored bars.
tiger.ps - A dramatic colored picture of a tiger's head.
Utilities
---------
For more information on these utility programs, see the comments at the
beginning of the files.
bdftops.ps - a utility for converting BDF fonts to outline form: see
fonts.doc for more information.
decrypt.ps - a utility for decrypting the eexec section of a font.
gslp.ps - a utility for doing "line printing" of plain text files.
impath.ps - a utility for reconstructing outlines from bitmap images,
used by bdftops.
landscap.ps - a file that you can put in front of your own files to get
them rendered in landscape mode.
pstoppm.ps - a utility for rendering PostScript files onto PPM (bitmap)
files.
ps2image.ps - a utility for converting an arbitrary PostScript file into a
.ps file consisting of just PostScript bitmaps, one per page.
wrfont.ps - a utility for writing out an unprotected Type 1 font, such as
the standard Ghostscript fonts.
Odds and ends
-------------
empty.ps - an empty file.
lines.ps - a test program for line joins and caps.
pcharstr.ps - a program to print out the CharStrings and Subrs in a Type 1
font.
ppath.ps - a couple of utilities for printing out the current path, for
debugging.
prfont.ps - a program to print a font catalog.
quit.ps - a file containing just the word "quit".
traceop.ps - a memory usage monitor for debugging.
type1ops.ps - the Type 1 font format opcodes.
unprot.ps - a program to disable access checking.

122
Linux-0.98/Yggdrasil-0.98.3/usr/lib/ghostscript/doc/readme.doc Normal file
View File

@@ -0,0 +1,122 @@
Copyright (C) 1990, 1992 Aladdin Enterprises. All rights reserved.
Distributed by Free Software Foundation, Inc.
This file is part of Ghostscript.
Ghostscript is distributed in the hope that it will be useful, but
WITHOUT ANY WARRANTY. No author or distributor accepts responsibility
to anyone for the consequences of using it or for whether it serves any
particular purpose or works at all, unless he says so in writing. Refer
to the Ghostscript General Public License for full details.
Everyone is granted permission to copy, modify and redistribute
Ghostscript, but only under the conditions described in the Ghostscript
General Public License. A copy of this license is supposed to have been
given to you along with Ghostscript so you can know your rights and
responsibilities. It should be in a file named COPYING. Among other
things, the copyright notice and this notice must be preserved on all
copies.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
This file, readme.doc, describes problems and new features in the
current release of Ghostscript. This file describes version 2.5.2 of
Ghostscript.
For an overview of Ghostscript and a list of the documentation files, see
README.
New features
============
Note: this is not a complete list of new features. See the most recent
section of NEWS for full details.
The DeskJet and LaserJet drivers (finally) work correctly.
You can now set all settable device properties (OutputFile,
BufferSpace, MaxBitmap) using -s or -d on the command line.
Known problems
==============
Interpreter
-----------
The interactive interpreter requires that every statement fit on a line,
i.e., you can't have an unpaired ( or {.
On a MS-DOS system, interrupting Ghostscript by typing ^C doesn't restore
the display mode.
Operators
---------
The Ghostscript language does not include the following operators of the
PostScript language:
resetfile
banddevice, renderbands (these are obsolete)
The following are not implemented completely:
%statementedit (file name): interpreted as equivalent to
%lineedit.
Most of the new color operators, particularly those that support the CMYK
color model, are implemented as Ghostscript language procedures, and they
essentially emulate CMYK using RGB.
The following operators that expect arrays won't accept packed arrays:
definefont (Subrs (type 1 fonts))
setdash (dash pattern)
setcachedevice (bounding box)
makeimagedevice (palette)
The file operator only recognizes modes r and w, not the newer modes r+,
w+, a, and a+.
Limitations
-----------
Floating point exceptions terminate Ghostscript, rather than producing a
rangecheck error.
Some access checks aren't implemented.
copypage does nothing in the MS-DOS implementation, and merely
synchronizes the X connection in the Unix implementation. showpage is a
procedure that does a copypage and then beeps the bell and waits for the
user to hit a key. (copypage does do the right thing for printers.)
Graphics bugs
-------------
strokepath produces incorrect output for dashed lines.
The implementation only looks at the PaintType of the font when doing
show, not when doing charpath. Because of this, stroked fonts don't work
correctly with charpath.
arcto gives an error for negative radii.
Changing the contents of the Encoding array or the Metrics dictionary of a
font dynamically doesn't produce the expected result (may have no effect)
if character caching is enabled.
Halftone patterns "flip over" at the 50% coverage point, producing
anomalous visual effects on some color devices.
We have not been able to test 2-, 4-, and 16-bit memory devices as
thoroughly as 1-, 8-, 24-, and 32-bit devices; please report any
problems.
Opening more than one window device at the same time doesn't work.
This is the case for both X Windows and Microsoft Windows.
Non-graphics bugs
-----------------
restore doesn't properly undo currentgstate.
copy doesn't handle gstates.

462
Linux-0.98/Yggdrasil-0.98.3/usr/lib/ghostscript/doc/use.doc Normal file
View File

@@ -0,0 +1,462 @@
Copyright (C) 1989, 1992 Aladdin Enterprises. All rights reserved.
Distributed by Free Software Foundation, Inc.
This file is part of Ghostscript.
Ghostscript is distributed in the hope that it will be useful, but
WITHOUT ANY WARRANTY. No author or distributor accepts responsibility
to anyone for the consequences of using it or for whether it serves any
particular purpose or works at all, unless he says so in writing. Refer
to the Ghostscript General Public License for full details.
Everyone is granted permission to copy, modify and redistribute
Ghostscript, but only under the conditions described in the Ghostscript
General Public License. A copy of this license is supposed to have been
given to you along with Ghostscript so you can know your rights and
responsibilities. It should be in a file named COPYING. Among other
things, the copyright notice and this notice must be preserved on all
copies.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
This file, use.doc, describes how to use the Ghostscript language
interpreter.
For an overview of Ghostscript and a list of the documentation files, see
README.
********
******** How to use the Ghostscript interpreter ********
********
The file name of the Ghostscript interpreter is gs.exe (MS-DOS and VMS) or
gs (Unix). To run it, you also need some external initialization files:
gs_*.ps (gs_2asc.ps, gs_dps1.ps,
gs_fonts.ps, gs_init.ps, gs_lev2.ps, gs_statd.ps)
sym__enc.ps
uglyr.gsf
Fontmap
as well as any other fonts from the Ghostscript distribution (.gsf and
.pfa files).
To invoke the interpreter, give the command
gs <filename1> ... <filenameN>
The interpreter will read in the files in sequence and execute them.
After doing this, it reads further input from the primary input stream
(normally the keyboard). Each line (i.e. characters up to a <return>) is
interpreted separately. To exit from the interpreter, type quit<return>.
The interpreter also exits gracefully if it encounters end-of-file.
Typing the interrupt character, e.g., control-C, is also safe.
The interpreter recognizes several switches described below, which may appear
anywhere in the command line and apply to all files thereafter.
You can get a help message by invoking Ghostscript with
gs -h
or
gs -?
This message also lists the available devices. For a little more
information, a one-line description of each device appears near the
beginning of the file devs.mak.
Choosing the output device
--------------------------
Ghostscript may be built with multiple output devices. Ghostscript
normally opens the first one and directs output to it. To use device xyz
as the initial output device, include the switch
-sDEVICE=xyz
in the command line. Note that this switch must precede the first .ps
file, and only its first invocation has any effect. For example, for
printer output in a normal configuration that includes an Epson printer
driver, you might use the shell command
gs -sDEVICE=epson myfile.ps
instead of just
gs myfile.ps
Alternatively, you can type
(epson) selectdevice
(myfile.ps) run
All output then goes to the printer instead of the display until further
notice. You can switch devices at any time by using the selectdevice
procedure, e.g.,
(vga) selectdevice
or
(epson) selectdevice
As yet a third alternative, you can define an environment variable
GS_DEVICE as the desired default device name. The order of precedence for
these alternatives, highest to lowest, is:
selectdevice
(command line)
GS_DEVICE
(first device in build list)
To select the density on a printer, use
gs -sDEVICE=<device> -r<xres>x<yres>
For example, on a 9-pin Epson-compatible printer, you can get the
lowest-density (fastest) mode with
gs -sDEVICE=epson -r60x72
and the highest-density mode with
gs -sDEVICE=epson -r240x72.
On a 24-pin printer, the lowest density is
gs -sDEVICE=epson -r60x60
and the highest-density 24-pin mode is
gs -sDEVICE=epson -r360x180
If you select a printer as the output device, Ghostscript also allows you
to control where the device sends its output. Normally, output goes
directly to the printer (PRN) on MS-DOS systems, and to a scratch file on
Unix or VMS systems. To send the output to a series of files foo1.xyz,
foo2.xyz, ..., use the switch
-sOutputFile=foo%d.xyz
(For compatibility with older versions of Ghostscript, -sOUTPUTFILE=
also works.) The %d is a printf format specification; you can use
other formats like %02d. Each file will receive one page of output.
Alternatively, to send the output to a single file foo.xyz, with all
the pages concatenated, use the switch
-sOutputFile=foo.xyz
On Unix systems, you can send the output directly to a pipe. For
example, to pipe the output to the command `lpr' (which, on many Unix
systems, is the command that spools output for a printer), use the
switch
-sOutputFile=\|lpr
To find out what devices are available, type
devicenames ==
after starting up Ghostscript. Alternatively you can use the -h or
-? switch in the command line, as described above.
Device configuration
--------------------
Ghostscript is normally configured to expect U.S. letter paper,
although there is a way to make A4 paper the default for certain
printers at compilation time (see devs.mak for details). To select a
different paper size as the default, use the switch
-sPAPERSIZE=a_known_paper_size
e.g.,
-sPAPERSIZE=a4
or
-sPAPERSIZE=legal
You can use any paper size listed in the table at the beginning of
gs_statd.ps. (Individual documents can also specify a paper size,
which will take precedence over the one specified on the command
line.)
Printing on a Hewlett-Packard DeskJet or LaserJet at full resolution
(300 DPI) requires a printer with at least 1.5 Mb of memory. 150 DPI
printing requires only .5 Mb. You can select 150 DPI printing with
the command line switch
-r150
On MS-DOS systems using the Borland compiler, if Ghostscript gives
you a 'limitcheck in setdevice' error, it may mean Ghostscript's
standard buffer size wasn't large enough. Likewise, if Ghostscript
gives you a 'VMerror in setdevice' error, it means the buffer size
was too large. You can use the -dBufferSpace= switch to set the
buffer size to a different value, e.g.,
-dBufferSpace=50000
The default value is 25000; the smallest value Ghostscript accepts is
10000; the largest valid value is 65000.
File searching
--------------
When looking for the initialization files (gs_*.ps), the files related to
fonts, or the file for the 'run' operator, Ghostscript first tries opening
the file with the name as given (i.e., using the current working directory
if none is specified). If this fails, and the file name doesn't specify
an explicit directory or drive (i.e., doesn't begin with '/' on Unix
systems; doesn't contain a ':' or begin with a '/' or '\' on MS-DOS
systems; doesn't contain a ':' or a square bracket on VMS systems),
Ghostscript will try directories in the following order:
- The directory/ies specified by the -I switch(es) in the command
line (see below), if any;
- The directory/ies specified by the GS_LIB environment variable,
if any;
- The directory/ies specified by the GS_LIB_DEFAULT macro in the
Ghostscript makefile, if any.
Each of these (GS_LIB_DEFAULT, GS_LIB, and -I parameter) may be either a
single directory, or a list of directories separated by a character
appropriate for the operating system (':' on Unix systems, ';' on VMS
systems, ';' on MS-DOS systems).
VMS-specific notes
------------------
On VMS systems, the last character of each "directory" name indicates what
sort of entity the "directory" references. If the "directory" name ends
with a colon, it is taken as referring to a logical device, e.g.:
$ DEFINE GHOSTSCRIPT_DEVICE DUA1:[GHOSTSCRIPT_14]
$ DEFINE GS_LIB GHOSTSCRIPT_DEVICE:
If the "directory" name ends with a closing square bracket, it is taken as
referring to a real directory, e.g.:
$ DEFINE GS_LIB DUA1:[GHOSTSCRIPT]
To run Ghostscript with switches, you must type a command like
$ gs "-dNODISPLAY"
because the C run time library will convert the command
parameters/arguments to lowercase unless you enclose them in double quotes
which preserves the case.
If you are on an X Windows display (for which gs is built), you can do
$ set display/create/node="domain-name"/transport=tcpip
For example,
$ set display/create/node="doof.city.com"/transport=tcpip
and then run Ghostscript
$ gs
If you write printer output to a file and then want to print the file
later, use the "/PASSALL" qualifier to the PRINT command.
MS-DOS notes
------------
There are three MS-DOS executables in the standard Ghostscript
distribution:
- GS.EXE runs on any MS-DOS machine, but is limited to 640K.
- GS386.EXE runs on any 386 or 486 machine, and will use all
available extended (not expanded) memory.
- GSWIN.EXE runs under Microsoft Windows 3.n in enhanced
mode, and will use all available memory.
If you are running Ghostscript on a MS-DOS machine with a display
that is not EGA/VGA compatible, you must use the Borland compiler.
You must build Ghostscript with the BGI driver as the default, and
you will need the appropriate .BGI file from the Borland Turbo C
library. (Ghostscript includes the EGA/VGA driver in the
executable.)
If you are using the BGI driver, two additional environment variables
become relevant:
BGIPATH - defines the directory where Ghostscript will look for
the appropriate BGI driver. If BGIPATH is not defined, Ghostscript will
look in the directory defined as BGIDIR in the makefile. In either case,
if no driver is found in the designated directory, Ghostscript will look
in the current directory.
BGIUSER - a string of the form nn.dname, where nn is a hexadecimal
number giving a display mode and dname is the name of a file containing a
user-supplied BGI driver. If BGIUSER is defined and the BGI device is
selected, Ghostscript will supply nn as the display mode and will obtain
the driver from the file named dname.
Some applications, such as Microsoft Word, require a prologue in front of
the PostScript files they output. In the case of Word, this is one of the
*.ini files included with the Word distribution. Other applications may
require other prologues. These may be specified on the Ghostscript
command line, e.g.,
gs prologue.ini myfile.ps
X Windows resources
-------------------
Ghostscript looks for the following resources under the program name
"Ghostscript":
borderWidth - the border width in pixels
default = 1
borderColor - the name of the border color
default = black
geometry - the window size and placement, WxH+X+Y
default = ???
xResolution - the number of x pixels per inch
default is computed from WidthOfScreen and WidthMMOfScreen
yResolution - the number of y pixels per inch
default is computed from HeightOfScreen and HeightMMOfScreen
To set these resources, put them in a file (such as ~/.Xdefaults) in the
following form:
Ghostscript*geometry: 612x792-0+0
Ghostscript*xResolution: 72
Ghostscript*yResolution: 72
Then load the defaults into the X server:
% xrdb -merge ~/.Xdefaults
Normal switches
---------------
@filename
Causes Ghostscript to read filename and treat its
contents the same as the command line. (This is
intended primarily for getting around DOS'
128-character limit on the length of a command line.)
Switches or file names in the file may be separated by
any amount of white space (space, tab, line break);
there is no limit on the size of the file.
-- filename arg1 ...
Takes the next argument as a file name as usual, but takes
all remaining arguments (even if they have the syntactic
form of switches) and defines the name ARGUMENTS in
userdict (not systemdict) as an array of those strings,
*before* running the file. When Ghostscript finishes
executing the file, it exits back to the shell.
-Dname=token
-dname=token
Define a name in systemdict with the given definition.
The token must be exactly one token (as defined by the
'token' operator) and must not contain any whitespace.
-Dname
-dname
Define a name in systemdict with value=null.
-Sname=string
-sname=string
Define a name in systemdict with a given string as value.
This is different from -d. For example,
-dname=35
is equivalent to the program fragment
/name 35 def
whereas
-sname=35
is equivalent to
/name (35) def
-q
Quiet startup -- suppress normal startup messages,
and also do the equivalent of -dQUIET.
-gnumber1xnumber2
Equivalent to -dDEVICEWIDTH=number1 and
-dDEVICEHEIGHT=number2. This is for the benefit of
devices (such as X11 windows and VESA displays) that require
(or allow) width and height to be specified.
-rnumber
-rnumber1xnumber2
Equivalent to -dDEVICEXRESOLUTION=number1 and
-dDEVICEYRESOLUTION=number2. This is for the benefit of
devices (such as printers) that support multiple
X and Y resolutions.
-Idirectories
Adds the designated list of directories at the head of the
search path for library files.
-
This is not really a switch. It indicates to Ghostscript
that the standard input is coming from a file or a pipe.
Ghostscript reads from stdin until reaching end-of-file,
executing it like any other file, and then continues
processing the command line. At the end of the command
line, Ghostscript exits rather than going into its
interactive mode.
Note that gs_init.ps makes systemdict read-only, so the values of names
defined with -D/d/S/s cannot be changed (although, of course, they can be
superseded by definitions in userdict or other dictionaries.)
Special names
-------------
-dDISKFONTS
causes individual character outlines to be loaded from the disk
the first time they are encountered. (Normally Ghostscript loads all the
character outlines when it loads a font.) This may allow loading more
fonts into RAM, at the expense of slower rendering.
-dNOBIND
disables the 'bind' operator. Only useful for debugging.
-dNOCACHE
disables character caching. Only useful for debugging.
-dNODISPLAY
suppresses the normal initialization of the output device. This
may be useful when debugging.
-dNOPAUSE
disables the prompt and pause at the end of each page. This may
be desirable for applications where another program is 'driving'
Ghostscript.
-dSAFER
disables the deletefile and renamefile operators, and the
ability to open files in any mode other than read-only. This may be
desirable for spoolers or other sensitive environments.
-dWRITESYSTEMDICT
leaves systemdict writable. This is necessary when running
special utility programs such as font2c and pcharstr, which must bypass
normal PostScript access protection.
-sDEVICE=device
selects an alternate initial output device, as described above.
-sOutputFile=filename
selects an alternate output file (or pipe) for the initial output
device, as described above.
Debugging switches
------------------
The -Z switch only applies if the interpreter was built for a
debugging configuration (DEBUG=1 or -DDEBUG selected at compile
time).
-A Turn on allocator debugging (gs_malloc and gs_free).
-e Turn on tracing of error returns from operators.
-E Abort when any operator returns with an error.
-Mn Force the interpreter's allocator to acquire additional
memory in units of nK, rather than the default (currently
20K on MS-DOS systems, 50K on Unix). n is a positive
decimal integer (not exceeding 63 on MS-DOS systems).
-Zxxx Turn on debugging printout.
Each of the xxx characters selects an option:
if the string is empty, all options are selected.
Case is significant.
1 = type 1 font interpreter (type1addpath)
2 = curve subdivider/rasterizer
a = allocator (large blocks only)
A = allocator (all calls)
b = bitmap image processor
B = bitmap images, detail
c = color/halftone mapper
d = dictionary put/undef
f = fill algorithm (summary)
F = fill algorithm (detail)
g = gsave/grestore[all]
h = halftone renderer
i = interpreter, just names
I = interpreter, everything
k = character cache
K = character cache, every access
l = command lists, bands
L = command lists, everything
m = makefont and font cache
n = name lookup (new names only)
o = outliner (stroke)
p = path tracer
q = clipping
r = arc renderer
s = scanner
t = tiling algorithm
u = undo saver (for save/restore)
U = undo saver, more detail
v = rectangle fill
V = device-level output
w = compression encoder/decoder
x = transformations
z = trapezoid fill