PostScript is an interpreted language rather than a compiled language like Fortran or C. Just like Fortran or C, however, PostScript programs are written as ASCII text files. To display PostScript requires that the program be passed through an interpreter that translates the high-level device-independent PostScript operators into a low-level raster data format for a particular output device.
PostScript is a stack based language and, for the Fortran or C programmer, it can take a bit of getting used to. Fortunately, most users will never need to program in PostScript directly, since user applications generate PostScript automatically. Generating PostScript from NCAR GKS is one good example of automatic PostScript generation.
PostScript fully integrates text and graphics. In fact, text characters are viewed as graphic objects in PostScript. Additionally, PostScript has operators for representing raster images in the language.
EPSF stands for "Encapsulated PostScript File". EPSF is a subset of regular PostScript. The acronym "EPS" stands for "Encapsulated PostScript". You will frequently see reference to "EPS file" or "EPS files" in the literature. EPS files are meant primarily for importing into applications that import PostScript. One primary restriction on EPS files is that they contain only a single page. Another important restriction is that an EPS file must have a comment line that gives the extent of the marks (the "bounding box" of the picture) on the PostScript page that follows. This is so the importing program can figure out where to put the plot. There are certain restrictions on PostScript operators that cannot be in EPS files, like restoring the clipping path to its default value. But these excluded operators are a small subset of the PostScript language that are not frequently used.
EPSI stands for Encapsulated PostScript Interchange format. EPSI files are EPS files that have a "preview bitmap" that represents the PostScript image contained in the file. This bitmap (and it is a bitmap and not a color map) can be used by an importing application to display quickly a picture of the imported file. This is used by applications that do not have a built-in PostScript interpreter. For example, FrameMaker will display this bitmap if it is in the imported file. If you save a FrameMaker document in PostScript format, the original imported PostScript file will be included in the FrameMaker document and you will get the precise picture that you started with. The Adobe manuals describe a portable hex format for the preview bitmap. Some applications want to see a specific type of bitmap in the preview section of an EPSI file, like a Sun raster image, or a GIF file, but how these are handled is vendor-specific.
If you are going to be doing any work with PostScript beyond using it as an output format, the book PostScript Language Reference Manual, second edition (ISBN 0-201-18127-4) is essential. This book was written by Adobe Systems and was published by Addison-Wesley in 1990. The book updates the original reference manual (it includes all Level 2 operators) and contains a wealth of information on the PostScript language.
The various PostScript output options are implemented in NCAR GKS as different workstation types. For an overview of workstation types in NCAR GKS, see the Workstation Functions documentation module.
The following table summarizes the PostScript workstation types in NCAR GKS:
Table 2: NCAR GKS Workstation Types for PostScript Output
--------------------------------------------------------
Workstation color/ PostScript
type orientaton monochrome format
--------------------------------------------------------
20 portrait color ps
21 portrait color eps
22 portrait color epsi
23 portrait monochrome ps
24 portrait monochrome eps
25 portrait monochrome epsi
26 landscape color ps
27 landscape color eps
28 landscape color epsi
29 landscape monochrome ps
30 landscape monochrome eps
31 landscape monochrome epsi
-------------------------------------------------------
Unless you want to produce a single picture for
importing into
some application, such as producing an illustration to import into
a word processing package, you most likely will want to select
generic PostScript as your output choice. In
particular, keep in
mind that the EPS and EPSI formats allow only a single picture in
them. If you are producing output files with multiple pictures,
then you must select the "ps" format.
As an example, let's look at a simple Fortran code fragment that opens and activates a workstation that produces a color EPS file in landscape mode:
CALL GOPKS(3,IDUMMY)
CALL GOPWK(3,0,27)
CALL GACWK(3)
After this code is executed, a file named "gmeta3.eps" will have
been produced that contains the desired PostScript output. It is
possible to override the default file name
.
INTEGER FUNCTION NGPSWK(PSTYPE, ORIENT, COLOR)
has been written.
All three arguments to this function are CHARACTER variables. The first argument can be one of 'PS', 'EPS', or 'EPSI'; the second argument can be one of 'PORTRAIT' or 'LANDSCAPE'; the final argument can be one of 'COLOR' or 'MONOCHROME'. In specifying the arguments, only enough characters need be entered so that the values can be differentiated. For example, to specify color, using 'C' as the third argument would be sufficient. Either upper case or lower case is accepted. Using this function, we could equivalently write the code fragment above as:
CALL GOPKS(3,IDUMMY)
CALL GOPWK(3,2,NGPSWK('EPS','LAND','COLOR'))
CALL GACWK(3)
If you are running on a system where ghostscript (Copyright (C) 1990, 1992 Aladdin Enterprises) is installed, then to get an appropriate preview bitmap in your EPSI file, you can use the utility "ps2epsi" that comes with the 2.6.1 release of ghostscript. Ghostscript has been ported to many systems and is distributed under the terms of the GNU Library General Public License. Many applications that import EPS files do not have a built-in PostScript interpreter, they simply display the preview bitmap contained in the imported file on the screen. However, the original PostScript in the imported file is contained in PostScript output from the application, so that when you print the PostScript you will see your original illustration in the file as desired.
There are equivalent PostScript characters for all of the characters from the filled fonts in Plotchar, except for a couple of the math symbols, and except for all of the WMO weather symbols. Additionally, the italic and bold italic fonts, not available in Plotchar, are available for the Helvetica, Times, and Courier font families.
There are no equivalents for all characters in all fontcap-defined fonts. For example, the script fonts and the old English font are entirely missing. Also things like the Zodiacal symbols from the NCAR Symbol Font are not available. If a requested character is not available from a PostScript font, NCAR GKS issues a warning message and suggests using Plotchar.
There are two big advantages to using PostScript fonts in place of Plotchar fonts. One is that there is a dramatic difference in PostScript file sizes. Plotchar inserts either strokes or filled areas into the output stream in order to render its characters. There may be dozens of coordinates (with each coordinate pair requiring a dozen bytes in the output PostScript) issued for a single character produced by Plotchar. Using the PostScript fonts requires using only a few bytes additional to those in the string to be rendered.
The second advantage to using PostScript fonts is that they will be rendered accurately at small sizes on low resolution output devices. A great deal of effort has gone into most PostScript interpreters to accurately render characters at all sizes. When the characters produced by Plotchar get too small, some of the areas may fall between pixels on the output device and do not get plotted.
The following table summarizes the relationships between the PostScript fonts and the NCAR GKS fonts:
Table 3: Mapping between NCAR GKS fonts and PostScript fonts
------------------------------------------------------------------------
NCAR GKS NCAR GKS font name PostScript equivalent
font number
------------------------------------------------------------------------
1 default Helvetica
-2 Hershey Cartographic Roman Helvetica (scaled small)
-3 Hershey Cartographic Greek Greek from Symbol font (scaled)
-4 Hershey Simplex Roman Helvetica
-5 Hershey Simplex Greek Greek from Symbol font
-6 Hershey Simplex Script none
-7 Hershey Complex Roman Times-Roman
-8 Hershey Complex Greek Greek from Symbol font
-9 Hershey Complex Script none
-10 Hershey Complex Italic Times-Italic
-11 Hershey Complex Cyrillic none
-12 Hershey Duplex Roman Helvetica
-13 Hershey Triplex Roman Times-Bold
-14 Hershey Triplex Italic Times Bold-Italic
-15 Hershey Gothic German none
-16 Hershey Gothic English none
-17 Hershey Gothic Italian none
-18 Hershey Math Symbols math symbols from Symbol font
-19 Hershey Symbol Set1 none
-20 Hershey Symbol Set2 none
-21 NCAR Helvetica Helvetica
-22 NCAR Helvetica-Bold Helvetica-Bold
-23 none Helvetica-Oblique
-24 none Helvetica-BoldOblique
-25 NCAR Times-Roman Times-Roman
-26 NCAR Times-Bold Times-Bold
-27 none Times-Italic
-28 none Times-BoldItalic
-29 NCAR Courier Courier
-30 NCAR Courier-Bold Courier-Bold
-31 none Courier-Oblique
-32 none Courier-BoldOblique
-33 NCAR Greek Greek from Symbol font
-34 NCAR Math Symbols math symbols from Symbol font
-35 NCAR Text Symbols text symbols from Symbol font
-36 NCAR Weather 1 none
-37 NCAR Weather 2 none
------------------------------------------------------------------------
Producing PostScript images from GKS cell arrays represents a significant savings in file sizes compared to producing an ncgm file and converting the ncgm file to PostScript via ctrans. The ctrans route draws a filled area for each cell in the cell array and the resultant PostScript file will, in general, be more than ten times larger than creating the PostScript file directly from NCAR GKS.
On certain occasions it may be desirable to use the entire rectangular area of the output page, or even to change the aspect ratio of the plot. PostScript output from NCAR GKS can be made to occupy any position on the page by way of setting coordinate boundaries via GKS escape function -1521. The integer variables that control this are LX, LY, UX, UY. These numbers specify corner points (LX,LY) and (UX,UY) that bound the output on the page. The numbers are specified in the default PostScript coordinate space where one unit corresponds to 1/72 of an inch. This means that an 8.5" x 11" page in portrait mode would be addressed from (0,0) in the lower left corner to (612,792) in the upper right corner. In order to preserve aspect ratio, the output rectangle should be specified as a square. For example, if you want your output to occupy a square in the upper left part of a page, you would make calls such as:
CALL NGSETI('LX',50)
CALL NGSETI('LY',500)
CALL NGSETI('UX',300)
CALL NGSETI('UY',750)
Values must be specified for all four parameters LX, LY, UX, and UY.
For example, suppose that you choose a landscape mode PostScript workstation and specify the following values:
LX = 50
LY = 50
UX = 742
UY = 562
The plot will originally be scaled to fit in the rectangle with
lower left corner (50,50) and upper right corner (742,562) [if drawn
in portrait mode, this plot would run off the right of an 8.5" x 11"
piece of paper]. This rectangle is then rotated by 90 degrees clockwise
about the point (50,50), giving a rectangle with coordinates (50,50)
at the upper left and (562,-642) at the lower right. Translating
this rectangle vertically by 692 gives a rectangle with corner points
(50,50) at the lower left and (562,742) at the upper right. Since the
extreme corners of a printed 8.5" x 11" page are (0,0) and (612,792),
the above rectangle will fit entirely within the page. The above
settings distort the aspect ratio of the plot by elongating it and
then rotating it so that it fits on the page.
You will probably not want to distort the aspect ratio of your plots when plotting to a full page, since the plots will have characters that look funny, circles will appear as ellipses, and so forth. In this case you should start with a plot that has the aspect ratio of a printed page (8.5/11) and scale it appropriately to fit the page. Figure 19 and Figure 20 illustrate this. The landscape version in Figure 20 was positioned using workstation type 28 (color EPSI in landscape mode) and making the following calls:
CALL NGSETI('LX',50)
CALL NGSETI('LY',50)
CALL NGSETI('UX',742)
CALL NGSETI('UY',742)
Notice that the aspect ratio of the plot being approximately 3 to 4
requires that white space be left above the plot in order for it to
be plotted correctly.
See the
above discussion on positioning your output
in order to understand the above subroutine calls.
CALL NGSETC('ME','postscript_file_name')
just prior to the GOPWK call that opens the workstation will
assign the desired name to the output file. The name can be up to
256 characters long.
You can assign 'stdout' to the output file name with a call to NGSETC and the output will go to standard out. This is only practical when you are writing to a single PostScript output file. Also, be aware that errors or warnings are usually written to the standard output file and intermingling these with the output PostScript will corrupt the PostScript.
CALL NGSETI('CM',IVAL)
where IVAL=0 (IVAL=1 selects the default RGB model).
The above call must be made just prior to the GOPWK call that opens the PostScript workstation.
CALL NGSETI('Workstation',WKID)
CALL NGSETI('Full background',1)
where WKID is an integer workstation identifier.
The setting for full background will apply only to the
workstation specified in the most recent NGSETI call that sets the
workstation ID.
CALL NGSETI('WO',WKID)
CALL NGSETI('NO',2.0)
would double the width of the nominal linewidth. This means that
all lines would uniformly appear to be twice as thick as they would
be in the default case. Figure 22
illustrates the result of
changing the size of the nominal linewidth and then changing linewidths
using GSLWSC. Just remember that the linewidth scale factors given to
GSLWSC apply to the nominal linewidth, whereas setting a new value
for the nominal linewidth will uniformly change the width of all lines.
The relevance of this value for PostScript output from NCAR GKS is the size of the output files that contain numerous filled areas. If all of the coordinates of a filled area can be pushed onto the stack, then a locally-defined macro can be utilized to save space and interpretation time. The savings here is not great, about 10% at most, so unless you are really concerned about file sizes and efficiency, resetting the size of the operand stack should be of little concern to you.
Also, keep in mind that you will lose portability by resetting this parameter. If you print the file using a PostScript interpreter that has a smaller operand stack than what is specified, then you will get an error from the PostScript interpreter. Changing the limit on the PostScript stack size can be effected by using the "ST" (or "Stack size") parameter in an NGSETI call.
Filled areas present a more difficult situation in that the entire path must be presented in its entirety to be filled. For filled areas that exceed the limit on the maximum path size, software fill is utilized. This means the instead of presenting an entire path to the PostScript fill operator, the area is filled by drawing a sequence of horizontal lines that are thick enough so that no gaps will be displayed. If you are generating filled areas that have more than 1300 points in them and you are using a PostScript interpreter that allows for more points than this, then you may want to consider increasing the limit on the maximum number of points in a path. You can do this by using the "PA" (or "Path size") parameter in an NGSETI call.
The savings in file size and interpretation time can be substantial (up to 50% or greater for files containing only large filled areas), but on the average (files that have one or two large filled areas) the savings are considerably more modest (1-10%). Also remember that you will lose portability by resetting this parameter. If you print the file using a PostScript interpreter that has a smaller path size than what is specified, then you will get an error from the PostScript interpreter. Setting the maximum path size to a small number can be used to force software fill, if that is ever desired.
If you are plotting on a device with crude resolution and could get by with many fewer lines than the default, then you may want to consider resetting this value, which can be done by using the "FI" (or "Fill lines") parameter in an NGSETR call. If you are going to a super high resolution device, then it is possible that you will see discrete line ends on edges of filled areas that are at an acute angle. If this is undesired, then you may consider decreasing the value for FI (increasing the number of fill lines). Remember that by tuning the number of fill lines for a specific device may cause undesirable results on another device. Also, remember that software fill is not invoked unless the number of points in a filled area exceeds the maximum number of points allowed in a path.
In the default user integer coordinate space, an 8.5" x 11" output page in portrait mode would have X coordinates in the range 0 to 612 and Y coordinates in the range 0 to 792.
This is a fairly crude resolution, and when it is mapped onto a device space with much higher resolution (such as a 300dpi printer), the increased resolution of the output device is not fully utilized. PostScript allows for scaling the user space so that you can use higher resolutions. The default user coordinate space in PostScript produced from NCAR GKS scales the normal default user space by 25. For an 8.5" x 11" page in portrait mode this produces coordinates in the range 0 to 15300 in X and 0 to 19800 in Y. This space is the default user space scaled by 25. This scale factor can be controlled by the NGSETI parameter 'CO' (or 'Coordinate scale'). By default it is 25 as discussed above. If you are plotting to a device with crude resolution, then you might consider setting this scale factor to something smaller than 25. By doing so, the file sizes will be reduced in accordance with the smaller number of characters needed to represent the coordinates in the resultant PostScript file. If you are plotting to a very high resolution printer and notice that you are not taking full advantage of the resolution of the device, then you may want to consider increasing the resolution of the PostScript user space by setting the scale factor controlled by 'CO' to something larger than 25.