PostScript Output

What is PostScript?


PostScript is a general-purpose programming language that contains a rich set of graphics operators. PostScript was designed and developed by Adobe Systems Incorporated; it began to be used by the general public in the mid 1980s. Since that time, the language has gained wide usage as a page description language. PostScript output is produced by many popular word processing and graphics packages and can be displayed on a wide variety of printers, plotters, and workstation screens.

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.


Any PostScript interpreter must support at least thirteen fonts: the Times family (regular, bold, italic, and bold-italic); the Courier family (regular, bold, oblique, and bold-oblique); the Helvetica family (regular, bold, oblique, and bold-oblique); and a symbol font containing lots of math symbols among others. Some interpreters support dozens or even hundreds of fonts.

File formats

There are some specially-formatted PostScript files (EPS and EPSI files) that you should know about.

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.

Recent revisions, level 2

In 1990 a revised version of the PostScript language was released by Adobe Systems. This revision is known as "PostScript Level 2." One of the major additions to the PostScript language was an operator to allow for display of color images, rather than just grayscale images as in PostScript Level 1. Many level 1 PostScript interpreters contain certain level 2 extensions.


Many books have been written to describe the PostScript language and how to use it. One of the best books for learning the language remains the PostScript Language Tutorial and Cookbook (ISBN 0-201-10179-3) written by Adobe Systems and published by Addison-Wesley in 1985.

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.

Producing PostScript Output from NCAR GKS

GKS Workstation Types for PostScript output

PostScript can be produced from the NCAR GKS package in a generic format, or in EPS (Encapsulated PostScript) format, or in EPSI (Encapsulated PostScript Interchange format). The output can be produced in either portrait mode (pictures displayed along the width of the paper or viewing window) or landscape mode (pictures displayed along the length). Also, an option exists for producing color pictures or monochrome pictures. In monochrome output, all colors, except the background color, are mapped to the foreground color. A monochrome plot will not look the same as a color plot viewed on a grayscale printer. The color plot viewed on a grayscale printer will have the colors mapped to shades of gray, whereas a monochrome plot will have only a single foreground color. If you are plotting a color image on a grayscale printer and find the results unsatisfactory since colors are getting mapped to light shades of gray that are difficult to see, it may be better to produce the picture in monochrome.

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

Output file names

The default file names of PostScript output from NCAR GKS are of the form gmetaXX.YY, where "XX" is the workstation ID used in the GOPWK call and "YY" is either "ps", "eps", or" epsi", as appropriate.

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

Utility Function for Selecting PostScript Workstation Types

In an attempt to make it possible to select the correct PostScript workstation type for the final argument of GOPWK without having to consult the table, a Fortran function
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 GACWK(3)

Simultaneously Active PostScript Workstations

You can open up to a maximum of fifteen PostScript workstations simultaneously. These workstations can be of any of the available types and can be moved in and out of the active state at any time while they are open.

Note on EPS and bounding boxes

Encapsulated PostScript files (.eps and .epsi files) are required to have bounding box information in them. A bounding box is the smallest rectangle enclosing all the marks on a page.

As of 19-Nov-03 the bounding box information in eps files produced by NCAR Grapics was changed from a default hard-wired setting compatible with a 7.5" x 7.5" square centered on an 8.5" x 11" page, to the settings specified by the internal parameters LX, LY, UX, and UY.

For eps/epsi files generated by the Fortran/C interface the default bounding box will remain as before, unless you specifically set the internal parameters LX, LY,UX, and UY. This bounding box will in general be larger than what it should be.

For eps/epsi files produced by NCL, the update of 19-Nov-03 will produce eps/epsi files that contain correct bounding boxes.

For regular PostScript files it is optional to have bounding box information in them. As opposed to eps/epsi files, regular PostScript files can have arbitrarily many pictures in them, so if bounding box information is in such a file, it should be the minimal rectangle that contains all marks on *all* pages. Regular ps files produced by NCAR Graphics have no bounding box information in them. Starting with a regular ps file, you can produce an epsi file that has an accurate bounding box in it by running the application "ps2espi" that is part of the ghostscript distribution. However, ps2epsi only produces correct bounding boxs as long as the pictures are contained within an 8.5" x 11" region.

Note on EPSI output

As of this writing, the preview bitmap contained in EPSI files produced from NCAR Graphics does not represent the picture contained in the EPSI file, but rather is simply a bitmap containing the message: APPLICATION CANNOT DISPLAY NCAR GRAPHIC HERE. VIEW THE POSTSCRIPT OUTPUT TO VERIFY SUCCESSFUL IMPORT. This message is produced on a gridded background. The reason for this situation is that it is not an easy thing to obtain a bitmap of a given PostScript page in a portable manner.

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 ghostscript distribution. 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.

Accessing PostScript fonts

Direct assess to PostScript fonts (rather than accessing the stroked or filled characters of the NCAR Graphics package) is now possible via the NCAR GKS PostScript workstations and the GKS function GTX. A translation has been effected for most of the fontcap-defined fonts and filled fonts available via the Plotchar package. PostScript source documentation for Plotchar is available. By selecting fonts with the GKS function GSTXFP and using GTX, you will get PostScript fonts in the resulting output file. These will not be stroked or filled representations of the characters, but characters to be rendered by the PostScript interpreter in use.

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                             

Cell array translation

GKS Cell Arrays are mapped into the "image" or "colorimage" operator in PostScript output from NCAR GKS. PostScript level 1 interpreters are only required to handle gray scale images, whereas PostScript level 2 allows for color images via the "colorimage" operator. What is put into a PostScript file resulting from a Cell Array in GKS is PostScript code that will check if the given PostScript interpreter supports "colorimage"; if it does, then a color image will be produced, and if it does not, then a grayscale image will be produced where the colors in the cell array are mapped to grayscale in accordance with the NTSC (National Television Standards Committee) equation: Intensity = 0.30*red + 0.59*green + 0.11*blue.

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.

GKS ESCAPE functions controlling PostScript Output

In what follows, details are given on the escape functions in NCAR GKS that apply specifically to PostScript workstations. These escape functions control aspects of the PostScript output that are language-specific and lie outside the scope of the GKS Standard. The user interface to these escape functions is via the entries NGSETI, NGSETR, and NGSETC.

Positioning PostScript output on the page

The GKS Standard requires that the aspect ratio of a plot be preserved in its mappings from world coordinates to normalized device coordinates ( NDC ) to device coordinates. In particular this means that in mapping the default NDC unit square onto the display surface of an output device it should be mapped onto a square. This prevents things like circles being turned into ellipses and squares being turned into rectangles. In the default case, PostScript output is placed on the output page in a square that is centered on the page.

On certain occasions it may be desirable to use the entire area of a rectangular 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 using control parameters LX, LY, UX, UY. These numbers are integers and 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. 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 in portrait mode, 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.

Using the full page

A common desire is to use a full printed page to display pictures. As discussed earlier, unless you can live with the undesirable results of simply scaling your plot to fill the entire page, you will need to restrict the drawable part of your original plot to using an aspect ratio that is compatible with the output page (11/8.5). To produce output on a full page, you will probably want to chose one of the landscape mode workstations. In the default case, a plot in landscape mode will be exactly what it was in portrait mode, except rotated clockwise by 90 degrees. Using the positioning parameters LX, LY, UX, and UY requires that you understand how landscape mode is implemented in the PostScript workstations. PostScript does not understand landscape and portrait modes - in the case of printing to and 8.5" x 11" page, the area bounded by the PostScript coordinates (0,0) and (612,792) is printed on the page. The concept of landscape mode is implemented in PostScript by rotating and translating a portrait mode plot. In landscape mode the parameters LX, LY, UX, and UY specify default PostScript coordinates (one unit equals 1/72 of an inch) that define the corner points (LX,LY) and (UX,UY) of a rectangle. The NDC unit square will be mapped onto this rectangle, then this rectangle will be rotated by 90 degrees clockwise about the point (LX,LY) and then translated by an amount so that the lower left corner of the rotated plot will coincide with the original lower left corner (LX,LY). In specifying the values for LX, LY, UX, and UY realize that, if the final plot is to fill the page in landscape mode, the value specified for UX would run off the right of an 8.5" x 11" page if plotted in portrait mode.

For example, suppose that you choose a landscape mode PostScript workstation and specify the following values:

     LX = 50
     LY = 50
     UX = 742
     UY = 562
Here is what happens using these specifications. The NDC unit square will first be mapped 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. This rectangle is then translated vertically by 692, giving 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 such that the drawable part has an aspect ratio suitable for filling an 8.5" x 11" page. Figure 19 and Figure 20 illustrate this. The landscape version in Figure 20 was positioned by 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 drawable part of the original plot is 4 to 3, and white space is left above the plot in order for it to be plotted correctly after it is rotated and translated. See the above discussion on positioning your output in order to understand the above subroutine calls.

Figure 19 - Plot in portrait mode

Figure 20 - Plot from Figure 19 scaled to fill the page in landscape mode

Notes on page positioning parameters:

Some experimenting with various settings for the workstation types and values for LX, LY, UX, and UY should give you a feeling for how they work.

Overriding Default File Names

Names for the PostScript output files can be assigned to override the default names. The name for the output file must be known at the time the workstation is opened with GOPWK. Making a call:
      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.

Selecting a color model

By default, PostScript produced from NCAR Graphics uses the RGB color model. You can make the PostScript output use the CMYK color model (particularly useful in printing) by making a call
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.

Background color.

Just as for output to NCGM or X11 windows, the value for GKS color index zero controls the background color setting for PostScript output. By default, the background color is applied to the normalized device coordinate viewport. If you want to have the background color apply to the entire output page for a given PostScript workstation, make the calls:
      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.

Line style attributes

PostScript has several line style attributes that are not part of GKS. Control over these attributes can be obtained using NGSETI calls. Figure 21 illustrates all of the line style attributes discussed in this section.

Line joins

The line join type controls the appearance of how line segments are connected. There are three possible values for the line join parameter: 0 for miter joins; 1 for rounded joins; 2 for bevel joins. For mitered joins, the edges of the line segments are extended until they meet. This join is also affected by the miter limit. For rounded joins, the line segments are joined with a circle at the join center where the circle has radius equal to the line width. For bevel joins, the line segments are drawn with butt ends (see the discussion of line caps) and the notch at the larger angle between the segments is filled with a triangle. Rounded joins are the default for PostScript produced from NCAR Graphics. Values for line join can be set by making the appropriate NGSETI call. See Figure 21 for an example.

Line caps

The line cap attribute controls how the ends of line segments are stroked. There are three possible values for the line cap parameter: 0 for butt caps; 1 for round caps; 2 for projecting square caps. For butt caps, the line segments are terminated with square ends perpendicular to the line path. For round caps, the line segments are terminated with semicircles centered at the line endpoint and having a radius equal to the line thickness. Projecting square caps are the same as butt caps except the cap is extended beyond the line end points by half a line width. Round caps are the default for PostScript produced from NCAR Graphics. Values for line cap can be set by making the appropriate NGSETI call. See Figure 21 for an example.

Miter limits

If, for mitered line joins, line segments meet at a very acute angle, then the mitered join can result in a spike that extends significantly beyond the intersection of the segments. To prevent this, PostScript switches from a mitered join to a beveled join at an angle that is controlled by the miter limit parameter. The smaller the miter limit is, the less tolerant PostScript is of exaggerated spikes at line joins. The default setting for the miter limit is 10. and the smallest the miter limit can ever be is 1. Setting the miter limit to 1. will essentially result in beveled line joins; setting the miter limit to values much higher than 10. will result in long spikes at lines joined at acute angles. Values for the miter limit can be set by making the appropriate NGSETI call.

Figure 21 - Line style attributes

Line widths

The GKS call GSLWSC can be used to set relative linewidths. The scale factor supplied to GSLWSC is applied to a default nominal line width. This nominal line width is implementation specific. You can control the size of this nominal linewidth for PostScript output by using the "NO" (for "Nominal linewidth") parameter in a call to NGSETR. For example, the calls:
      CALL NGSETR('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.

Figure 22 - Line widths

Size of the operand stack

As pointed out in the introduction to this documentation module, PostScript is a stack based language. Among other things, this means that all operators operate on elements that have been pushed onto the operand stack. The size of this stack is implementation dependent, but it must be able to contain at least 500 elements at the minimum. Most PostScript interpreters have a bigger operand stack than this.

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.

Maximum number of points in a path

In drawing lines and filled areas, PostScript builds a "path" and then strokes it out. For PostScript Level 1, the default limit on the maximum number of points in a path is 1500. Since most PostScript printers are now Level 2, and this limit was very minimal in any case, the maximum number of points in a path for NCAR Graphics has been increased to 10000000.

For filled areas that exceed the 10000000 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 using a PostScript printer that allows less points in a path than 10000000, then you will need to reset the default limit. You can do this by using the "PA" (or "Path size") parameter in an NGSETI call.

Setting the maximum path size to a small number can be used to force software fill, if that is ever desired.

Specifying spacing between software fill lines

When a filled area is requested that has more than the maximum number of points in it than are allowed, software fill is implemented. This amounts to drawing a sequence of horizontal lines that will fill the given area. These lines are chosen to have a thickness so that no gaps result between fill lines. The distance between fill lines is specified as a real number in the range 0. to 1. (normalized device coordinate space). By default this value is .0005 which will result in 2000 lines being used to fill the largest possible area.

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.

Specifying spacing between hatch pattern lines

The spacing between lines composing a hatch fill pattern can be controlled with the NGSETR parameter "HA" (or 'Hatch spacing'). This applies only when the fill area interior style is set to 3 (see GSFAIS). The fill spacing is specified as a real number between 0. and 1. , inclusive (normalized device coordinate space).

Figure 23 - Hatch line spacings

Specifying the user coordinate space resolution

The default user coordinate space in PostScript locates the origin at the lower left corner of the output page; the positive X axis extends horizontally to the right and the positive Y axis extends vertically upward. The length of a unit along either axis is 1/72 of an inch. Coordinates can be specified as either integers or real numbers.

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.

Links: GKS Index, GKS Home