GSview 4.9 serial key or number

Table of contents

For other information, see the Ghostscript overview and, if necessary, how to install Ghostscript.

---

Invoking Ghostscript

This document describes how to use the command line Ghostscript client. Ghostscript is also used as a general engine inside other applications (for viewing files for example). Please refer to the documentation for those applications for using Ghostscript in other contexts.

The command line to invoke Ghostscript is essentially the same on all systems, although the name of the executable program itself may differ among systems. For instance, to invoke Ghostscript on unix-like systems type:

[options] {filename 1} ... [options] {filename N} ...

Here are some basic examples. The details of how these work are described below.

To view a file:

gs -dSAFER -dBATCH document.pdf

You'll be prompted to press return between pages.

To convert a figure to an image file:

gs -dSAFER -dBATCH -dNOPAUSE -sDEVICE=png16m -dGraphicsAlphaBits=4 \ -sOutputFile=tiger.png tiger.eps

To render the same image at 300 dpi:

gs -dSAFER -dBATCH -dNOPAUSE -sDEVICE=png16m -r300 \ -sOutputFile=tiger_300.png tiger.eps

To render a figure in grayscale:

gs -dSAFER -dBATCH -dNOPAUSE -sDEVICE=pnggray -sOutputFile=figure.png figure.pdf

To rasterize a whole document:

gs -dSAFER -dBATCH -dNOPAUSE -sDEVICE=pgmraw -r150 \ -dTextAlphaBits=4 -sOutputFile='paper-%00d.pgm' paper.ps

There are also a number of utility scripts for common to convert a PostScript document to PDF:

ps2pdf file.ps

The output is saved as file.pdf.

There are other utility scripts besides , including , , , , and . These just call Ghostscript with the appropriate (if complicated) set of options. You can use the 'ps2' set with eps files.

Ghostscript is capable of interpreting PostScript, encapsulated PostScript (EPS), DOS EPS (EPSF), and Adobe Portable Document Format (PDF). The interpreter reads and executes the files in sequence, using the method described under "File searching" to find them.

The interpreter runs in interactive mode by default. After processing the files given on the command line (if any) it reads further lines of PostScript language commands from the primary input stream, normally the keyboard, interpreting each line separately. To quit the interpreter, type "". The options in the examples above disable the interactive prompting. The interpreter also quits gracefully if it encounters end-of-file or control-C.

The interpreter recognizes many options. An option may appear anywhere in the command line, and applies to all files named after it on the line. Many of them include "" followed by a parameter. The most important are described in detail here. Please see the reference sections on options and devices for a more complete listing.

Help at the command line:

You can get a brief help message by invoking Ghostscript with the or switch, like this:

gs -h gs -?

The message shows for that version of the Ghostscript executable:

• the version and release information
• the general format of the command line
• a few of the most useful options
• the formats it can interpret
• the available output devices
• the search path
• the bug report address

On other systems the executable may have a different name:

System	Invocation Name
Unix
VMS
MS Windows 95 and later
OS/2

On Windows, the two digit number indicates the word length of the system for which the binary was built (so is for x86 Windows systems, whilst is for x86_64 Windows systems). And the suffix indicates a Windows console based binary (note that the window will still appear).

---

Selecting an output device

Ghostscript has a notion of 'output devices' which handle saving or displaying the results in a particular format. Ghostscript comes with a diverse variety of such devices supporting vector and raster file output, screen display, driving various printers and communicating with other applications.

The command line option 'device' selects which output device Ghostscript should use. If this option isn't given the default device (usually a display device) is used. Ghostscript's built-in help message () lists the available output devices. For complete description of the devices distributed with Ghostscript and their options, please see the devices section of the documentation.

Note that this switch must precede the name of the first input file, and only its first use has any effect. For example, for printer output in a configuration that includes an Epson printer driver, instead of just you might use

The output device can also be set through the environment variable.

Once you invoke Ghostscript you can also find out what devices are available by typing '' at the interactive prompt. You can set the output device and process a file from the interactive prompt as well:

(epson) selectdevice (myfile.ps) run

All output then goes to the Epson printer instead of the display until you do something to change devices. You can switch devices at any time by using the procedure, for instance like one of these:

(x11alpha) selectdevice (epson) selectdevice

Output resolution

Some printers can print at several different resolutions, letting you balance resolution against printing speed. To select the resolution on such a printer, use the switch:

printerXRESYRES

where XRES and YRES are the requested number of dots (or pixels) per inch. Where the two resolutions are same, as is the common case, you can simply use res.

The option is also useful for controlling the density of pixels when rasterizing to an image file. It is used this way in the examples at the beginning of this document.

Output to files

Ghostscript also allows you to control where it sends its output. With a display device this isn't necessary as the device handles presenting the output on screen internally. Some specialized printer drivers operate this way as well, but most devices are general and need to be directed to a particular file or printer.

To send the output to a file, use the switch or the switch (below). For instance, to direct all output into the file , use

When printing on MS Windows systems, output normally goes directly to the printer, . On Unix and VMS systems it normally goes to a temporary file which is sent to the printer in a separate step. When using Ghostscript as a file rasterizer (converting PostScript or PDF to a raster image format) you will of course want to specify an appropriately named file for the output.

Ghostscript also accepts the special filename '' which indicates the output should be written to standard output (the command shell).

Be aware that filenames beginning with the character have a special meaning in PostScript. If you need to specify a file name that actually begins with , you must prepend the filedevice explicitly. For example to output to a file named , you need to specify

Please see Ghostscript and the PostScript Language and the PostScript Language Reference Manual for more details on and filedevices.

Note that on MS Windows systems, the character also has a special meaning for the command processor (shell), so you will have to double it.

(on MS Windows)

Note, some devices (e.g. pdfwrite, ps2write, ...) only write the output file upon exit, but changing the OutputFile device parameter will cause these devices to emit the pages received up to that point and then open the new file name given by OutputFile.

For example, in order to create two PDF files from a single invocation of ghostscript the following can be used:

One page per file

Specifying a single output file works fine for printing and rasterizing figures, but sometimes you want images of each page of a multi-page document. You can tell Ghostscript to put each page of output in a series of similarly named files. To do this place a template '' in the filename which Ghostscript will replace with the page number.

Note: Since the character is used to precede the page number format specification, in order to represent a file name that contains a , double characters must be used. For example for the file the OutputFile string needs to be .

The format can in fact be more involved than a simple ''. The format specifier is of a form similar to the C format. The general form supported is:

For more information, please refer to documentation on the C printf format specifications. Some examples are:

produces '', ... , '', ..

produces '', ... , '', ...

produces '', ... , '', ... , ''

Note, however that the one page per file feature may not supported by all devices. Also, since some devices write output files when opened, there may be an extra blank page written (pdfwrite, ps2write, eps2write, pxlmono, pxlcolor, ...).

As noted above, when using MS Windows console (command.com or cmd.exe), you will have to double the character since the is used by that shell to prefix variables for substitution, e.g.,

-o option:

As a convenient shorthand you can use the option followed by the output file specification as discussed above. The option also sets the and options. This is intended to be a quick way to invoke ghostscript to convert one or more input files.

For instance, to convert somefile.ps to JPEG image files, one per page, use:

is equivalent to:

Choosing paper size

Ghostscript is distributed configured to use U.S. letter paper as its default page size. There are two ways to select other paper sizes from the command line:

• If the desired paper size is listed in the section on paper sizes known to Ghostscript below, you can select it as the default paper size for a single invocation of Ghostscript by using the switch, for instance
• Otherwise you can set the page size using the pair of switches

wh

Where w be the desired paper width and h be the desired paper height in points (units of 1/72 of an inch).

Individual documents can (and often do) specify a paper size, which takes precedence over the default size. To force a specific paper size and ignore the paper size specified in the document, select a paper size as just described, and also include the switch on the command line.

The default set of paper sizes will be included in the in the dictionary with each paper size as one of the entries. The last entry in the dictionary (which has numeric keys) is a non-standard (Ghostscript extension) type of PageSize where the array has four elements rather than the standard two elements. This four element array represents a page size range where the first two elements are the lower bound of the range and the second two are the upper bound. By default these are [0, 0] for the lower bound and [16#fffff, 16#fffff] for the upper bound.

The range type of PageSize is intended to allow flexible page size sepcification for non-printer file formats such as JPEG, PNG, TIFF, EPS, ...

For actual printers, either the entire dictionary should be replaced or the range type entry should not be included. To simplify using the default page sizes in the dictionary, the command line option can be used. Using this option will result in automatic rotation of the document page if the requested page size matches one of the default page sizes.

When the switch is given on the command line, the dictionary will only be populated with the single page size. This allows the option to fit the page size requested in a PostScript file to be rotated, scaled and centered for the best fit on the specified page.

Changing the installed default paper size

You can change the installed default paper size on an installed version of Ghostscript, by editing the initialization file . This file is usually in the directory somewhere in the search path. See the section on finding files for details.

Find the line

% /DEFAULTPAPERSIZE (a4) def

Then to make A4 the default paper size, uncomment the line to change this to

/DEFAULTPAPERSIZE (a4) def

For you can substitute any paper size Ghostscript knows.

This supecedes the previous method of uncommenting the line .

Sometimes the initialization files are compiled into Ghostscript and cannot be changed.

On Windows and some Linux builds, the default paper size will be selected to be a4 or letter depending on the locale.

---

Interacting with pipes

As noted above, input files are normally specified on the command line. However, one can also "pipe" input into Ghostscript from another program by using the special file name '' which is interpreted as standard input. Examples:

{some program producing ps} [options]

When Ghostscript finishes reading from the pipe, it quits rather than going into interactive mode. Because of this, options and files after the '' in the command line will be ignored.

On Unix and MS Windows systems you can send output to a pipe in the same way. For example, to pipe the output to , use the command

In this case you must also use the switch to prevent Ghostscript from writing messages to standard output which become mixed with the intended output stream.

Also, using the -sstdout=%stderr option is useful, particularly with input from PostScript files that may print to stdout.

Similar results can be obtained with the and filedevices. The example above would become

or

(again, doubling the character on MS Windows systems.)

In the last case, isn't necessary since Ghostscript handles the pipe itself and messages sent to stdout will be printed as normal.

---

Using Ghostscript with PDF files

Ghostscript is normally built to interpret both PostScript and PDF files, examining each file to determine automatically whether its contents are PDF or PostScript. All the normal switches and procedures for interpreting PostScript files also apply to PDF files, with a few exceptions. In addition, the utility uses Ghostscript to convert PDF to (Level 2) PostScript.

Switches for PDF files

Here are some command line options specific to PDF

Rather than selecting a PageSize given by the PDF MediaBox, BleedBox (see -dUseBleedBox), TrimBox (see -dUseTrimBox), ArtBox (see -dUseArtBox), or CropBox (see -dUseCropBox), the PDF file will be scaled to fit the current device page size (usually the default page size).

This is useful for creating fixed size images of PDF files that may have a variety of page sizes, for example thumbnail images.

This option is also set by the option.

Determines whether the file should be displayed or printed using the "screen" or "printer" options for annotations and images. With , the output will use the file's "print" options; with , the output will use the file's "screen" options. If neither of these is specified, the output will use the screen options for any output device that doesn't have an parameter, and the printer options for devices that do have this parameter.

Sets the page size to the BleedBox rather than the MediaBox. defines the region to which the contents of the page should be clipped when output in a production environment. This may include any extra bleed area needed to accommodate the physical limitations of cutting, folding, and trimming equipment. The actual printed page may include printing marks that fall outside the bleed box.

Sets the page size to the TrimBox rather than the MediaBox. The trim box defines the intended dimensions of the finished page after trimming. Some files have a TrimBox that is smaller than the MediaBox and may include white space, registration or cutting marks outside the CropBox. Using this option simulates appearance of the finished printed page.

Sets the page size to the ArtBox rather than the MediaBox. The art box defines the extent of the page's meaningful content (including potential white space) as intended by the page's creator. The art box is likely to be the smallest box. It can be useful when one wants to crop the page as much as possible without losing the content.

Sets the page size to the CropBox rather than the MediaBox. Unlike the other "page boundary" boxes, CropBox does not have a defined meaning, it simply provides a rectangle to which the page contents will be clipped (cropped). By convention, it is often, but not exclusively, used to aid the positioning of content on the (usually larger, in these cases) media.

password

Sets the user or owner password to be used in decoding encrypted PDF files. For files created with encryption method 4 or earlier, the password is an arbitrary string of bytes; with encryption method 5 or later, it should be text in either UTF-8 or your locale's character set (Ghostscript tries both).

Don't enumerate annotations associated with the page key. Annotations are shown by default.

In addition, finer control is available by defining an array . Annotation types listed in this array will be drawn, whilst those not listed will not be drawn.

To use this feature:
Where the array can contain one or more of the following names: , , , , , , , , and .

For example, adding the follow to the command line:
would draw only annotations with the subtypes "Text" and "UnderLine"

Show annotations referred from the Interactive Form Dictionary (AcroForm dictionary). By default, AcroForm is not enumerated because Adobe Acrobat doesn't do this. This option may be useful for debugging or recovery of incorrect PDF files that don't associate all annotations with the page objects.

Ignore parameter. This may be useful for backward compatibility with old versions of Ghostscript and Adobe Acrobat, or for processing files with large values of that otherwise exceed implementation limits.

If a glyph is not present in a font the normal behaviour is to use the /.notdef glyph instead. On TrueType fonts, this is often a hollow sqaure. Under some conditions Acrobat does not do this, instead leaving a gap equivalent to the width of the missing glyph, or the width of the /.notdef glyph if no /Widths array is present. Ghostscript now attempts to mimic this undocumented feature using a user parameter . The PDF interpreter sets this user parameter to the value of in systemdict, when rendering PDF files. To restore rendering of /.notdef glyphs from TrueType fonts in PDF files, set this parameter to true.

These command line options are no longer specific to PDF, but have some specific differences with PDF files

pagenumber

Begin on the designated page of the document. Pages of all documents in PDF collections are numbered sequentionally.

pagenumber

Stop after the designated page of the document. Pages of all documents in PDF collections are numbered sequentionally.

pagenumber

There are three possible values for this; even, odd or a list of pages to be processed. A list can include single pages or ranges of pages. Ranges of pages use the minus sign '-', individual pages and ranges of pages are separated by commas ','. A trailing minus '-' means process all remaining pages. For example;

-sPageList=1,3,5 indicates that pages 1, 3 and 5 should be processed. -sPageList=5-10 indicates that pages 5, 6, 7, 8, 9 and 10 should be processed. -sPageList=1,5-10,12- indicates that pages 1, 5, 6, 7, 8, 9, 10 and 12 onwards should be processed.

Note: Use of PageList overrides FirstPage and/or LastPage, if you set these as well as PageList they will be ignored. The list of pages should be given in increasing order, you cannot process pages out of order and inserting higher numbered pages before lower numbered pages in the list will generate an error.

The PDF interpreter and the other language interpreters handle these in slightly different ways. Because PDF files enable random access to pages in the document the PDF inerpreter only interprets and renders the required pages. PCL and PostScript cannot be handled in ths way, and so all the pages must be interpreted. However only the requested pages are rendered, which can still lead to savings in time. Be aware that using the '%d' syntax for OutputFile does not reflect the page number in the original document. If you chose (for example) to process even pages by using , then the output of would still be out0.png, out1.png, out2.png etc......

Because the PostScript and PCL interpreters cannot determine when a document terminates, sending multple files as input on the command line does not reset the PageList between each document, each page in the second and subsequent documents is treated as following on directly from the last page in the first document. The PDF interpreter, however, does not work this way. Since it knows about individual PDF files the PageList is applied to each PDF file separately. So if you were to set and then send two PDF files, the result would be pages 1 and 2 from the first file, and then pages 1 and 2 from the second file. The PostScript interpreter, by contrast, would only render pages 1 and 2 from the first file. This means you must exercise caution when using this switch, and probably should not use it at all when processing a mixture of PostScript and PDF files on the same command line.

The XPS language like the PDF language allows random access to pages. The XPS interpreter handles all the PageList cases discussed above. It also handles cases such as:

-sPageList=1,2,1,2 indicates repeated pages. Pages processed in order 1, 2, 1, 2. -sPageList=10-5 indicates pages will be processed in the order 10, 9, 8, 7, 6, 5. -sPageList=1-,-1 indicates first processing from page 1 to end and then from end to page 1.

In addition, the XPS interpreter allows the use of a -dLastPage < -dFirstPage. In this case the pages will be processed backwards from LastPage to FirstPage.

Problems interpreting a PDF file

Occasionally you may try to read or print a 'PDF' file that Ghostscript doesn't recognize as PDF, even though the same file can be opened and interpreted by an Adobe Acrobat viewer. In many cases, this is because of incorrectly generated PDF. Acrobat tends to be very forgiving of invalid PDF files. Ghostscript tends to expect files to conform to the standard. For example, even though valid PDF files must begin with , Acrobat will scan the first 1000 bytes or so for this string, and ignore any preceding garbage.

In the past, Ghostscript's policy has been to simply fail with an error message when confronted with these files. This policy has, no doubt, encouraged PDF generators to be more careful. However, we now recognize that this behavior is not very friendly for people who just want to use Ghostscript to view or print PDF files. Our new policy is to try to render broken PDF's, and also to print a warning, so that Ghostscript is still useful as a sanity-check for invalid files.

PDF files from standard input

The PDF language, unlike the PostScript language, inherently requires random access to the file. If you provide PDF to standard input using the special filename '', Ghostscript will copy it to a temporary file before interpreting the PDF.

---

Using Ghostscript with EPS files

Encapsulated PostScript (EPS) files are intended to be incorporated in other PostScript documents and may not display or print on their own. An EPS file must conform to the Document Structuring Conventions, must include a line to indicate the rectangle in which it will draw, must not use PostScript commands which will interfere with the document importing the EPS, and can have either zero pages or one page. Ghostscript has support for handling EPS files, but requires that the be in the header, not the trailer. To customize EPS handling, see EPS parameters.

For the official description of the EPS file format, please refer to the Adobe documentation in their tech note #5002. It is available from: http://partners.adobe.com/public/developer/ps/index_specs.html

---

Using Ghostscript with overprinting and spot colors

In general with PostScript and PDF interpreters, the handling of overprinting and spot colors depends upon the process color model of the output device. Devices that produce gray or RGB output have an additive process color model. Devices which produce CMYK output have a subtractive process color model. Devices may, or may not, have support for spot colors.

Note: The differences in appearance of files with overprinting and spot colors caused by the differences in the color model of the output device are part of the PostScript and PDF specifications. They are not due to a limitation in the implementation of Ghostscript or its output devices.

With devices which use a subtractive process color model, both PostScript and PDF allow the drawing of objects using colorants (inks) for one or more planes without affecting the data for the remaining colorants. Thus the inks for one object may the inks for another object. In some cases this produces a transparency like effect. (The effects of overprinting should not be confused with the PDF 1.4 blending operations which are supported for all output devices.) Overprinting is not allowed for devices with an additive process color model. With files that use overprinting, the appearance of the resulting image can differ between devices which produce RGB output versus devices which produce CMYK output. Ghostscript automatically overprints (if needed) when the output device uses a subtractive process color model. For example, if the file is using overprinting, differences can be seen in the appearance of the output from the tiff24nc and tiff32nc devices which use an RGB and a CMYK process color models.

Most of the Ghostscript output devices do not have file formats which support spot colors. Instead spot colors are converted using the tint transform function contained within the color space definition.. However there are several devices which have support for spot colors. The PSD format (Adobe Photoshop) produced by the psdcmyk device contains both the raster data plus an equivalent CMYK color for each spot color. This allows Photoshop to simulate the appearance of the spot colors. The display device (MS Windows, OS/2, gtk+) can be used with different color models: Gray, RGB, CMYK only, or CMYK plus spot colors (separation). The display device, when using its CMYK plus spot color (separation) mode, also uses an equivalent CMYK color to simulate the appearance of the spot color. The tiffsep device creates output files for each separation (CMYK and any spot colors present). It also creates a composite CMYK file using an equivalent CMYK color to simulate the appearance of spot colors. The xcfcmyk device creates output files with spot colors placed in separate alpha channels. (The XCF file format does not currently directly support spot colors.)

Overprinting with spot colors is not allowed if the tint transform function is being used to convert spot colors. Thus if spot colors are used with overprinting, then the appearance of the result can differ between output devices. One result would be obtained with a CMYK only device and another would be obtained with a CMYK plus spot color device. In a worst case situation where a file has overprinting with both process (CMYK) and spot colors, it is possible to get three different appearances for the same input file using the tiff24nc (RGB), tiff32nc (CMYK), and tiffsep (CMYK plus spot colors) devices.

In Adobe Acrobat, viewing of the effects of overprinting is enabled by the 'Overprint Preview' item in the 'Advanced' menu. This feature is not available in the free Acrobat Reader. The free Acrobat Reader also uses the tint transform functions to convert spot colors to the appropriate alternate color space.

---

How Ghostscript finds files

When looking for initialization files (, ), font files, the file, files named on the command line, and resource files, Ghostscript first tests whether the file name specifies an absolute path.

Testing a file name for an absolute path
System		Does the name ...
Unix		Begin with ?
MS Windows		Have as its second character, or begin with , , or ?
VMS		Contain a node, device, or root specification?

If the test succeeds, Ghostscript tries to open the file using the name given. Otherwise it tries directories in this order:

1. The current directory if enabled by the switch;
2. The directories specified by switches in the command line, if any;
3. The directories specified by the environment variable, if any;
4. If built with COMPILE_INITS=1 (currently the default build) the files in the and directories are built into the executable.
5. The directories specified by the macro (if any) in the makefile when this executable was built.

, , and the parameter may specify either a single directory or a list of directories separated by a character appropriate for the operating system ("" on Unix systems, "" on VMS systems, and "" on MS Windows systems). By default, Ghostscript no longer searches the current directory first but provides switch for a degree of backward compatibility.

Note that Ghostscript does not use this file searching algorithm for the or operators: for these operators, it simply opens the file with the name given. To run a file using the searching algorithm, use instead of .

Finding PostScript Level 2 resources

Adobe specifies that resources are installed in a single directory. Ghostscript instead maintains a list of resource directories, and uses an extended method for finding resource files.

The search for a resource file depends on whether the value of the system parameter specifies an absolute path. The user may set it as explained in Resource-related parameters.

If the user doesn't set the system parameter , or use the command line option, Ghostscript creates a default value for it by looking on the directory paths explained in How Ghostscript finds files, excluding the current directory. The first path with in it is used, including any prefix up to the path separator character following the string . For example, when COMPILE_INITS=1 (the current default build), if the first path is , then the systemparam will be set to by default.

If the value of the system parameter is an absolute path (the default), Ghostscript assumes a single resource directory. It concatenates :

1. The value of the system parameter ;
2. The name of the resource category (for instance, );
3. The name of the resource instance (for instance, ).

If the value of the system parameter is not an absolute path, Ghostscript assumes multiple resource directories. In this case it concatenates :

1. A directory listed in the section How Ghostscript finds files, except the current directory;
2. The value of the system parameter ;
3. The name of the resource category (for instance, );
4. The name of the resource instance (for instance, )

Due to possible variety of the part 1, the first successful combination is used. For example, if the value of the system parameter is the string (or its equivalent in the file path syntax of the underlying platform), Ghostscript searches for from all directories listed in How Ghostscript finds files. So in this example, if the user on a Windows platform specifies the command line option , Ghostscript searches for and then for .

To get a proper platform dependent syntax Ghostscript inserts the value of the system parameter (initially "" on Unix and Windows, "" on MacOS, "" or "" on OpenVMS). The string is replaced with a platform dependent equivalent.

In the case of multiple resource directories, the default procedure retrieves either a path to the first avaliable resource, or if the resource is not available it returns a path starting with . Consequently Postscript installers of Postscript resources will overwrite an existing resource or add a new one to the first resource directory.

To look up fonts, after exhausting the search method described in the next section, it concatenates together

1. the value of the system parameter (initially )
2. the name of the resource font (for instance, )

Note that even although the system parameters are named "somethingDir", they are not just plain directory names: they have "" on the end, so that they can be concatenated with the category name or font name.

Font lookup

Ghostscript has a slightly different way to find the file containing a font with a given name. This rule uses not only the search path defined by , , and as described above, but also the directory that is the value of the system parameter, and an additional list of directories that is the value of the environment variable (or the value provided with the switch, if present).

At startup time, Ghostscript reads in the files in every directory on the search path (or in the list provided with the switch, if present): these files are catalogs of fonts and the files that contain them. (See the documentation of fonts for details.) Then, when Ghostscript needs to find a font that isn't already loaded into memory, it goes through a series of steps.

• First, it looks up the font name in the combined Fontmaps. If there is an entry for the desired font name, and the file named in the entry can be found in some directory on the general search path (defined by , , and ), and the file is loaded successfully, and loading it defines a font of the desired name, that is the end of the process.
• If this process fails at any step, Ghostscript looks for a file whose name is the concatenation of the value of the system parameter and the font name, with no extension. If such a file exists, can be loaded, and defines a font of the desired name, that again is the end. The value of is normally the string , but it can be changed with the operator: see the PostScript Language Reference Manual for details.
• If that fails, Ghostscript then looks for a file on the general search path whose name is the desired font name, with no extension. If such a file exists, can be loaded, and defines a font of the desired name, that again is the end.
• If that too fails, Ghostscript looks at the environment variable (or the value provided with the switch, if present), which is also a list of directories. It goes to the first directory on the list, and it's descendants, looking for all files that appear to contain PostScript fonts (also Truetype fonts); it then adds all those files and fonts to the combined Fontmaps, and starts over.
• If scanning the first FONTPATH directory doesn't produce a file that provides the desired font, it adds the next directory on the FONTPATH list, and so on until either the font is defined successfully or the list is exhausted.
• Finally, if all else fails, it will try to find a substitute for the font from among the standard 35 fonts.

CID fonts (e.g. Chinese, Japanese and Korean) are found using a different method.

Differences between search path and font path
Search path		Font path
switch		switch
and environment variables		environment variable
Consulted first		Consulted only if search path and don't provide the file.
Font-name-to-file-name mapping given in Fontmap files; aliases are possible, and there need not be any relation between the font name in the Fontmap and the in the file.		Font-name-to-file-name mapping is implicit – the in the file is used. Aliases are not possible.
Only fonts and files named in Fontmap are used.		Every Type 1 font file in each directory is available; if TrueType fonts are supported (the feature was included when the executable was built), they are also available.

If you are using one of the following types of computer, you may wish to set the environment variable to the value indicated so that Ghostscript will automatically acquire all the installed Type 1 (and, if supported, TrueType) fonts (but see below for notes on systems marked with "*"):

Suggested GS_FONTPATH for different systems
		System type		GS_FONTPATH
		Digital Unix
		Ultrix
		HP-UX 9
		IBM AIX
		NeXT
*		SGI IRIX
		SunOS 4.x (NeWSprint only)
**		SunOS 4.x
**		Solaris 2.x
		VMS

* On SGI IRIX systems, you must use in place of or , because otherwise the entries in will take precedence over the fonts in the FONTPATH directories.

** On Solaris systems simply setting or using may not work, because for some reason some versions of Ghostscript can't seem to find any of the Type1 fonts in . (It says: "15 files, 15 scanned, 0 new fonts". We think this problem has been fixed in Ghostscript version 6.0, but we aren't sure because we've never been able to reproduce it.) See instead. Also, on Solaris 2.x it's probably not worth your while to add Sun's fonts to your font path and Fontmap. The fonts Sun distributes on Solaris 2.x in the directories

are already represented among the ones distributed as part of Ghostscript; and on some test files, Sun's fonts have been shown to cause incorrect displays with Ghostscript.

These paths may not be exactly right for your installation; if the indicated directory doesn't contain files whose names are familiar font names like Courier and Helvetica, you may wish to ask your system administrator where to find these fonts.

Adobe Acrobat comes with a set of fourteen Type 1 fonts, on Unix typically in a directory called .... There is no particular reason to use these instead of the corresponding fonts in the Ghostscript distribution (which are of just as good quality), except to save about a megabyte of disk space, but the installation documentation explains how to do it on Unix.

CID fonts

CID fonts are PostScript resources containing a large number of glyphs (e.g. glyphs for Far East languages, Chinese, Japanese and Korean). Please refer to the PostScript Language Reference, third edition, for details.

CID font resources are a different kind of PostScript resource from fonts. In particular, they cannot be used as regular fonts. CID font resources must first be combined with a CMap resource, which defines specific codes for glyphs, before it can be used as a font. This allows the reuse of a collection of glyphs with different encodings.

The simplest method to request a font composed of a CID font resource and a CMap resource in a PostScript document is

where is a name of any CID font resource, and is a name of a CMap resource designed for the same character collection. The interpreter will compose the font automatically from the specified CID font and CMap resources. Another method is possible using the operator.

CID fonts must be placed in the directory. They are not found using Font lookup on the search path or font path.

CID font substitution

Automatic CIDFont Substitution

In general, it is highly recommended that CIDFonts used in the creation of PDF jobs should be embedded or available to Ghostscript as CIDFont resources, this ensures that the character set, and typeface style are as intended by the author.

In cases where the original CIDFont is not available, the next best option is to provide Ghostscript with a mapping to a suitable alternative CIDFont - see below for details on how this is achieved. However, Ghostscript does provide the ability to use a "fall back" CIDFont substitute. As shipped, this uses the DroidSansFallback.ttf font. This font contains a large number of glyphs covering several languages, but it is not comprehensive. There is, therefore, a chance that glyphs may be wrong, or missing in the output when this fallback is used.

Internally, the font is referenced as CIDFont resource called , thus a different fallback from DroidSansFallback.ttf can be specified adding a mapping to your cidfmap file (see below for details) to map the name "CIDFallBack" as you prefer. For the mapping be a TrueType font or TrueType collection, it cannot be a Postscript CIDFont file.

As with any font containing large numbers of glyphs, DroidSansFallback.ttf is quite large (~3.5Mb at the of writing). If this is space you cannot afford in your use of Ghostscript, you can simply delete the file from: . The build system will cope with the file being removed, and the initialization code will avoid adding the internal fall back mapping if the file is missing.

If DroidSansFallback.ttf is removed, and no other mapping is supplied, the final "fall back" is to use a "dumb" bullet CIDFont, called . As the name suggests, this will result in all the glyphs from a missing CIDFont being replaced with a simple bullet point.

This type of generic fall back CIDFont substitution can be very useful for viewing and proofing jobs, but may not be appropriate for a "production" workflow, where it is expected that only the original font should be used. For this situation, you can supply Ghostscript with the command line option: . By combining with a production workflow can force a PDF with missing CIDFonts to error, and avoid realising a CIDFont was missing only after printing.

The directory in which the fallback TrueType font or collection can be specified by the command line parameter , or with the environment variable . The file name of the substitute TrueType font can be specified using the command line parameter or the environment variable .

Explicit CIDFont Substitution

Substitution of CID font resources is controlled, by default, by the Ghostscript configuration file , which defines a CID font resource map.

The file forms a table of records, each of which should use one of three formats, explained below. Users may modify to configure Ghostscript for a specific need. Note that the default Ghostscript build includes such configuration and resource files in a rom file system built into the executable. So, to ensure your changes have an effect, you should do one of the following: rebuild the executable; use the "-I" command line option to add the directory containing your modified file to Ghostscript's search path; or, finally, build Ghostscript to use disk based resources.

Format 1

To substitute a CID font resource with another CID font resource, add a record like this :

where is a name of CID font resource being used by a document, and is a name of an available CID font resource. Please pay attention that both them must be designed for same character collection. In other words, you cannot substitute a Japanese CID font resource with a Korean CID font resource, etc. CMap resource names must not appear in . The trailing semicolon and the space before it are both required.

Format 2

To substitute (emulate) a CID font resource with a TrueType font file, add a record like this :

Where are explained in the table below.

Key	Type	Description
string	A path to a TrueType font file. This must be an absolute path. If using , the directory containing the font file must be on one of the permitted paths.
name	Must be .
integer	(optional) Index of the font in font collection, such as TTC. This is ignored if doesn't specify a collection. The first font in a collection is 0. Default value is 0.
array of 2 or 3 elements	(required) Information for building . If the array consists of 2 elements, the first element is a string, which specifies ; the second element is a number, which specifies . If the array consists of 3 elements, the first element is a string, which specifies ; the second element is a string, which specifies ; the third element is a number, which specifies .

Currently only CIDFontType 2 can be emulated with a TrueType font. The TrueType font must contain enough characters to cover an Adobe character collection, which is specified in and used in documents.

Format 3

To point Ghostscript at a specific CIDFont file outside it's "normal" resource search path :

where is a name of CID font resource being used by a document, and is the path to the Postscript CIDFont file, including the file name. NOTE: the CIDFont file, when executed by the Postscript interpreter, must result in a CIDFont resource being defined whose CIDFontName matches the "CIDName" key for the current record. I.E. an entry with the key /PingHei-Bold must reference a file which creates a CIDFont resource called "PingHei-Bold". To substitute a file based CIDFont for a differently named CIDFont, use formats 1 and 3 in combination (the order of the entries is not important).

The trailing semicolon and the space before it are both required.

NOTE: Environment Variables

It is also possible to influence the path using standard, or your own environment variables, using the custom Postscript operator . Said operator takes a string parameter on the stack which is the environment variable to interrogate, and returns either a string, containing the value of the environment variable, and boolean to indicate success, or just a boolean to indicate failure. See below for an example of its use.

Examples :

The win32 installer of recent version of ghostscript has a checkbox for "Use Windows TrueType fonts for Chinese, Japanese and Korean" to optionally update lib/cidfmap with the common CJK fonts provided by Microsoft products. The script can also be run separately (e.g. against a network drive with windows CJK fonts):

Note that the font file path uses Postscript syntax. Because of this, backslashes in the paths must be represented as a double backslash.

This can complicate substitutions for fonts with non-Roman names. For example, if a PDF file asks for a font with the name . This cannot be used directly in a cidfmap file because the #xx notation in names is a PDF-only encoding. Instead, try something like:

Where is the same byte sequence converted to a hex string. This lets you specify a name using any sequence of bytes through the encodings available for Postscript strings.

Note that loading truetype fonts directly from is no longer supported. There is no reliable way to generate a character ordering for truetype fonts. The 7.0x versions of Ghostscript supported this by assuming a Japanese character ordering. This is replaced in the 8.0x and later releases with the more general mechanism.

The PDF specification requires CID font files to be embedded, however some documents omit them. As a workaround the PDF interpreter applies an additional substitution method when a requested CID font resource is not embedded and it is not available. It takes values of the keys and from the dictionary, and concatenates them with a dash inserted. For example, if a PDF CID font resource specifies

the generated subsitituite name is . The latter may look some confusing for a font name, but we keep it for compatibility with older Ghostscript versions, which do so due to a historical reason. Add a proper record to to provide it.

Please note that when a PDF font resource specifies

there is no way to determine the language properly. If the CID font file is not embedded, the record depends on the document and a correct record isn't possible when a document refers to multiple Far East languages. In the latter case add individual records for specific CID font names used in the document.

Consequently, if you want to handle any PDF document with non-embedded CID fonts (which isn't a correct PDF), you need to create a suitable by hand, possibly a specific one for each document.

Using Unicode True Type fonts

Ghostscript can make use of Truetype fonts with a Unicode character set. To do so, you should generate a (NOTE: non-standard!) Postscript or PDF job where the relevant text is encoded as UTF-16. Ghostscript may be used for converting such jobs to other formats (Postscript, PDF, PXL etc). The resulting output will be compliant with the spec (unlike the input).

To render an UTF-16 encoded text, one must do the following :

• Provide a True Type font with Unicode Encoding. It must have a table with equals to 3 (Windows), and eqials to 1 (Unicode).
• Describe the font in with special values for the key : .
• In the PS or PDF job combine the font with one of CMap (for the horizontal writing mode) or (for the vertical writing mode). Those CMaps are distributed with Ghostscript in .

Please note that won't properly work for Unicode documents, especially for the searchability feature (see CID font substitution).

Temporary files

Where Ghostscript puts temporary files
Platform		Filename		Location
MS Windows and OpenVMS		XX.XXX		Current directory
OS/2		XXXXXX		Current directory
Unix		XXXXX

You can change in which directory Ghostscript creates temporary files by setting the or environment variable to the name of the directory you want used. Ghostscript currently doesn't do a very good job of deleting temporary files if it exits because of an error; you may have to delete them manually from time to time.

---

Notes on specific platforms

Word size (32 or 64 bits)

The original PostScript language specification, while not stating a specific word sise, defines 'typical' limits which make it clear that it was intended to run as a 32-bit environment. Ghostscript was originally coded that way, and the heritage remains within the code base.

Because the Ghostscript PDF interpreter is currently written in PostScript, it proved necessary to add support for 64-bit integers so that we could process PDF files which exceed 2GB in size. This is the only real purpose in adding support for large integers, however since that time, we have made some efforts to allow for the use of 64-bit words; in particular the use of integers, but also lifting the 64K limit on strings and arrays, among other areas.

However this is, obviously, dependent on the operating system and compiler support available. Not all builds of Ghostscript will support 64-bit integers, though some 32-bit builds (eg Windows) will.

Even when the build supports 64-bit words, you should be aware that there are areas of Ghostscript which do not support 64-bit values. Sometimes these are dependent on the build and other times they are inherent in the architecture of Ghostscript (the graphics library does not support 64-bit co-ordinates in device space for example, and most likely never will).

Note that the extended support for 64-bit word size can be disabled by executing 'true .setcpsimode', This is important for checking the output of the Quality Logic test suite (and possibly other test suites) as the tests make assumptions about the sizes of integers (amongst other things). You can run /ghostpdl/Resource/Init/gs_cet.ps to change Ghostscript's behaviour so that it matches the observed behaviour of Adobe CPSI interpreters.

Unix

The Ghostscript distribution includes some Unix shell scripts to use with Ghostscript in different environments. These are all user-contributed code, so if you have questions, please contact the user identified in the file, not Artifex Software.

Preview a specified page of a file in an X window

System V 3.2 lp interface for parallel printer

Printing on an H-P PaintJet under HP-UX

Queue filter for under Unix; its documentation is intended for system administrators

Setup for

VMS

• To be able to specify switches and file names when invoking the interpreter, define as a foreign command:

diskdirectory"

where the "disk" and "directory" specify where the Ghostscript executable is located. For instance,

• On VMS systems, the last character of each "directory" name indicates what sort of entity the "directory" refers to. If the "directory" name ends with a colon "", it is taken to refer to a logical device, for instance

If the "directory" name ends with a closing square bracket "", it is taken to refer to a real directory, for instance

• Defining the logical

diskdirectory

allows Ghostscript to find its initialization files in the Ghostscript directory even if that's not where the executable resides.

• Although VMS DCL itself converts unquoted parameters to upper case, C programs such as Ghostscript receive their parameters through the C runtime library, which forces all unquoted command-line parameters to lower case. That is, with the command

Ghostscript sees the switch as , which doesn't work. To preserve the case of switches, quote them like this:

• If you write printer output to a file with and then want to print the file later, use "".

• PDF files (or PostScript files that use the operator) must be "stream LF" type files to work properly on VMS systems. (Note: This definitely matters if Ghostscript was compiled with DEC C; we are not sure of the situation if you use .) Because of this, if you transfer files by FTP, you probably need to do one of these two things after the transfer:
1. If the FTP transfer was in text (ASCII) mode:

input-file output-file

where the contents of the file are

FILE ORGANIZATION sequential RECORD BLOCK_SPAN yes CARRIAGE_CONTROL carriage_return FORMAT stream_lf

2. If the FTP transfer was in binary mode:

Using X Windows on VMS

If you are using on an X Windows display, you can set it up with the node name and network transport, for instance

and then run Ghostscript by typing at the command line.

MS Windows

The name of the Ghostscript command line executable on MS Windows is / so use this instead of the plain '' in the quickstart examples.

To run the batch files in the ghostscript directory, you must add gs\ and gs\ to the , where gs is the top-level Ghostscript directory.

When passing options to ghostcript through a batch file wrapper such as you need to substitute '#' for '=' as the separator between options and their arguments. For example:

ps2pdf -sPAPERSIZE#a4 file.ps file.pdf

Ghostscript treats '#' the same internally, and the '=' is mangled by the command shell.

There is also an older version for MS Windows called just that provides its own window for the interactive postscript prompt. The executable / is usually the better option since it uses the native command prompt window.

For printer devices, the default output is the default printer. This can be modified as follows.

Output to the named printer. If your printer is named "HP DeskJet 500" then you would use .

MS-DOS

Note: Ghostscript is no longer supported on MS-DOS.

Invoking Ghostscript from the command prompt in Windows is supported by the Windows executable described above.

X Windows

Ghostscript looks for the following resources under the program name and class name ; the ones marked "**" are calculated from display metrics:

X Windows resources
Name		Class		Default
		**
		**

X resources

• To set X resources, put them in a file (such as on Unix) in a form like this:

Then merge these resources into the X server's resource database:

• Ghostscript doesn't look at the default system background and foreground colors; if you want to change the background or foreground color, you must set them explicitly for Ghostscript. This is a deliberate choice, so that PostScript documents will display correctly by default -- with white as white and black as black -- even if text windows use other colors.
• The resource affects only window placement.
• Resolution is expressed in pixels per inch (1 inch = 25.4mm).
• The font tolerance gives the largest acceptable difference in height of the screen font, expressed as a percentage of the height of the desired font.
• The resource can be used to restrict Ghostscript to using a grayscale or monochrome palette.
• and control the maximum number of colors that ghostscript allocates ahead of time for the dither cube (ramp). Ghostscript never preallocates more than half the cells in a colormap. controls the maximum number of colors that Ghostscript will allocate dynamically in the colormap.

Working around bugs in X servers

The "..." resources exist primarily to work around bugs in X servers.

• Old versions of DEC's X server (DECwindows) have bugs that require setting or to .
• Some servers do not implement backing pixmaps properly, or do not have enough memory for them. If you get strange behavior or "out of memory" messages, try setting to .
• Some servers do not implement tiling properly. This appears as broad bands of color where dither patterns should appear. If this happens, try setting to .
• Some servers do not implement bitmap or pixmap displaying properly. This may appear as white or black rectangles where characters should appear; or characters may appear in "inverse video" (for instance, white on a black rectangle rather than black on white). If this happens, try setting to .

X device parameters

In addition to the device parameters recognized by all devices, Ghostscript's X driver provides parameters to adjust its performance. Users will rarely need to modify these. Note that these are parameters to be set with the switch in the command line (e.g., ), not resources to be defined in the file.

If , the driver updates the screen after each primitive drawing operation; if (the default), the driver uses an intelligent buffered updating algorithm.

If the amount of memory required to hold the pixmap for the window is no more than the value of , the driver will draw to a pixmap in Ghostscript's address space (called a "client-side pixmap") and will copy it to the screen from time to time; if the amount of memory required for the pixmap exceeds the value of , the driver will draw to a server pixmap. Using a client-side pixmap usually provides better performance -- for bitmap images, possibly much better performance -- but since it may require quite a lot of RAM (e.g., about 2.2 Mb for a 24-bit 1024x768 window), the default value of is 0.

These control various aspects of the driver's buffering behavior. For details, please consult the source file .

SCO Unix

Because of bugs in the SCO Unix kernel, Ghostscript will not work if you select direct screen output and also allow it to write messages on the console. If you are using direct screen output, redirect Ghostscript's terminal output to a file.

---

Command line options

Unless otherwise noted, these switches can be used on all platforms.

General switches

Input control

filename

Causes Ghostscript to read filename and treat its contents the same as the command line. (This was intended primarily for getting around DOS's 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 ...
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 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.

filename arg1 ...

Does the same thing as and , but expands filename arguments.

These are not really switches: they tell Ghostscript to read from standard input, which is coming from a file or a pipe, with or without buffering. On some systems, Ghostscript may read the input one character at a time, which is useful for programs such as ghostview that generate input for Ghostscript dynamically and watch for some response, but can slow processing. If performance is significantly slower than with a named file, try '' which always reads the input in blocks. However, '' is equivalent on most systems.

token ...
string ...

Interprets arguments as PostScript code up to the next argument that begins with "" followed by a non-digit, or with "". For example, if the file contains just the word "", then on the command line is equivalent to there. Each argument must be valid PostScript, either individual tokens as defined by the operator, or a string containing valid PostScript.

Because Ghostscript must initialize the PostScript environment before executing the commands specified by this option it should be specified after other setup options. Specifically this option 'bind's all operations and sets the systemdict to readonly.

Interprets following non-switch arguments as file names to be executed using the normal command. Since this is the default behavior, is useful only for terminating the list of tokens for the switch.

filename

Execute the given file, even if its name begins with a "" or "".

File searching

Note that by "library files" here we mean all the files identified using the search rule under "How Ghostscript finds files" above: Ghostscript's own initialization files, fonts, and files named on the command line.

directories
directories

Adds the designated list of directories at the head of the search path for library files.

Makes Ghostscript look first in the current directory for library files.

Makes Ghostscript not look first in the current directory for library files (unless, of course, the first explicitly supplied directory is ""). This is now the default.

Setting parameters

name
name

Define a name in systemdict with value=true.

nametoken
nametoken

Define a name in systemdict with the given value. The value must be a valid PostScript token (as defined by the operator). If the token is a non-literal name, it must be true, false, or null. It is recommeded that this is used only for simple values -- use (above) for complex values such as procedures, arrays or dictionaries.
Note that these values are defined before other names in systemdict, so any name that that conflicts with one usually in systemdict will be replaced by the normal definition during the interpreter initialization.

namestring
namestring

Define a name in systemdict with a given string as value. This is different from . For example, on the command line is equivalent to the program fragment

whereas is equivalent to

namestring

Define a name in systemdict with the parsed version of the given string as value. The string takes a parameter definition in (something very close to) postscript format. This allows more complex structures to be passed in than is possible with or . For example:

This means that can do the job of both and . For example:

can be equivalently performed by

and

can be equivalently performed by

Note, that there are some 'special' values that should be set using , not , such as and . Broadly, only use if you cannot set what you want using or .

Also, internally, after setting an parameter with we perform an operation. This is required to allow changes in parameters such as to take effect. This means that attempting to use other than at the start of a page is liable to give unexpected results.

name

Un-define a name, cancelling or .

Note that the initialization file makes read-only, so the values of names defined with , , , and cannot be changed -- although, of course, they can be superseded by definitions in or other dictionaries. However, device parameters set this way (, , etc.) are not read-only, and can be changed by code in PostScript files.

number1number2

Equivalent to number1 and number2, specifying the device width and height in pixels for the benefit of devices such as X11 windows and VESA displays that require (or allow) you to specify width and height. Note that this causes documents of other sizes to be clipped, not scaled: see below.

number (same as numbernumber)
number1number2

Equivalent to number1 and number2, specifying the device horizontal and vertical resolution in pixels per inch for the benefit of devices such as printers that support multiple X and Y resolutions.

Suppress messages

Quiet startup: suppress normal startup messages, and also do the equivalent of .

Parameter switches ( and )

As noted above, and define initial values for PostScript names. Some of these names are parameters that control the interpreter or the graphics engine. You can also use or to define a value for any device parameter of the initial device (the one defined with , or the default device if this switch is not used). For example, since the device has a numeric parameter that controls the number of bits per component, will make this the default device and set the number of bits per component to 4 (log2(16)).

Rendering parameters

On high-resolution devices (at least 150 dpi resolution, or specified), forces the use of separate halftone screens with different angles for CMYK or RGB if halftones are needed (this produces the best-quality output); uses separate screens with the same frequency and angle; forces the use of a single binary screen. The default if

---

Current stable NCO version is 4.9.5 released Wednesday, 23-Sep-2020 23:53:19 UTC

The NCO toolkit manipulates and analyzes data stored in netCDF-accessible formats, including DAP, HDF4, and HDF5. It exploits the geophysical expressivity of many CF (Climate & Forecast) metadata conventions, the flexible description of physical dimensions translated by UDUnits, the network transparency of OPeNDAP, the storage features (e.g., compression, chunking, groups) of HDF (the Hierarchical Data Format), and many powerful mathematical and statistical algorithms of GSL (the GNU Scientific Library). NCO is fast, powerful, and free.

---

Recent Releases & Milestones

• 2020 Oct ??: 4.9.6 In Progress...
• 2020 Sep 23: 4.9.5 A feature and fixes
• 2020 Sep 04: 4.9.4 High Frequency climos
• 2020 May 31: 4.9.3 Sundry features/fixes
• 2020 Feb 14: 4.9.2 BSD License
• 2019 Dec 19: 4.9.1 Sundry features/fixes
• 2019 Dec 04: 4.9.0 ncremap lollapalooza
• 2019 Jul 01: 4.8.1 Sundry features/fixes
• 2019 May 15; 4.8.0 Vertical interpolation
• 2019 Feb 20: 4.7.9 Sundry features/fixes
• 2018 Nov 16: 4.7.8 CMIP6
• 2018 Sep 21: 4.7.7 Sundry features/fixes
• 2018 Aug 11: 4.7.6 ncremap RRG, MWF
• 2018 Jun 10: 4.7.5 Sundry features/fixes
• 2018 Apr 06: 4.7.4 CF2-Group compliance
• 2018 Mar 02: 4.7.3 Sundry features/fixes
• 2018 Jan 25: 4.7.2 Tempest2
• Milestones from 200301–201712 (versions 2.8.4–4.7.1)
• News and Announcements from 199801–200212 (version 1.1.0–2.8.3) and earlier

---

What is NCO?

The netCDF Operators (NCO) comprise about a dozen standalone, command-line programs that take netCDF, HDF, and/or DAP files as input, then operate (e.g., derive new fields, compute statistics, print, hyperslab, manipulate metadata, regrid) and output the results to screen or files in text, binary, or netCDF formats. NCO aids analysis of gridded and unstructured scientific data. The shell-command style of NCO allows users to manipulate and analyze files interactively, or with expressive scripts that avoid some overhead of higher-level programming environments.

Traditional geoscience data analysis requires users to work with numerous flat (data in one level or namespace) files. In that paradigm instruments or models produce, and then repositories archive and distribute, and then researchers request and analyze, collections of flat files. NCO works well with that paradigm, yet it also embodies the necessary algorithms to transition geoscience data analysis from relying solely on traditional (or “flat”) datasets to allowing newer hierarchical (or “nested”) datasets.

The next logical step is to support and enable combining all datastreams that meet user-specified criteria into a single or small number of files that hold all the science-relevant data organized in hierarchical structures. NCO (and no other software to our knowledge) can do this now. We call the resulting data storage, distribution, and analysis paradigm Group-Oriented Data Analysis and Distribution (GODAD). GODAD lets the scientific question organize the data, not the ad hoc granularity of all relevant datasets. The User Guide illustrates GODAD techniques for climate data analysis:

Note that the “averagers” ( and ) are misnamed because they perform many non-linear statistics as well, e.g., total, minimum, RMS. Moreover, implements a powerful domain language which handles arbitrarily complex algebra, calculus, and statistics (using GSL). The operators are as general as netCDF itself: there are no restrictions on the contents of input file(s). NCO's internal routines are completely dynamic and impose no limit on the number or sizes of dimensions, variables, and files. NCO is designed to be used both interactively and with large batch jobs. The default operator behavior is often sufficient for everyday needs, and there are numerous command line (i.e., run-time) options, for special cases.

---

How to Contribute: Volunteer, Endorse, or Donate

NCO has always (since 1995) been Open Source. SourceForge.net started hosting NCO in March, 2000. This facilitated collaboration, code contributions, and support.

In March, 2015, NCO development moved to GitHub.com. We continue to use the SourceForge discussion fora for historical continuity (seventeen years of searchable Q&A). No matter what your programming background there is a task you can help with. From re-organizing the TODO list itself, to improving this cheesy webpage, to documentation, to designing and implementing new features and interfaces, we need your help! The project homepage contains mailing lists, discussion forums, and instructions to make contributing to NCO easy.

Many users feel unable to volunteer their time. An equally effective contribution in the long-run would be your endorsement, which may make the difference between a declined and an accepted proposal. An endorsement can be a few sentences that describes how NCO benefits your work or research. E-mail your endorsement to Charlie “my surname is zender” Zender with Subject: “NCO Proposal Endorsement”. This information is useful advocating for more NCO support. “What future proposals?” you ask, “Aren't you already funded?” Yes, in 2012 NASA funded us to implement netCDF4 groups and HDF support, and in 2014 NASA funded us to improve SLD handling. These funds are/were primarily for development and maintainance of specific features. To realize our grander ambition, i.e., to shift geoscience data analysis from a flat- to a hierarchical-paradigm (GODAD), will require a sustained effort and software ecosystem that understands and implement hierarchical dataset concepts. And it's hard to sell a federal agency on the wisdom of investing in a paradigm shift! Other more prosaic tasks that need work are, for example, I/O parallelization (!!!), user-defined and non-atomic types, more CF conventions, cloud-services, JSON back-end, and user-defined functions. If you send an endorsement, please include (at least) your Name, Title, and Institutional affiliation.

Lastly, as of June, 2003, if you're more strapped for time than money and want to contribute something back, consider a monetary donation. This may incentivize us to tackle your favorite items. Inspired by President Obama's plan to bring more transparency to government investment, these homepage donation counters track the influence of your monetary donations on NCO development:

Donations received between 20030624 and 20200804: US$219.77. Thank you, donors!

NCO features “incentivized” by these donations: More emoticons in the documentation :)

---

NSF EarthCube Project

The National Science Foundation Grant NSF ICER-1541031 funded the Unidata-led EarthCube Project, “EarthCube IA: Collaborative Proposal: Advancing netCDF-CF for the Geoscience Community” from 20150901–20170831 as part of the Integrative and Collaborative Education and Research (ICER) program. This URL, , points to the most up-to-date information on the EarthCube proposal.

UCI's primary role was to help extend CF to cover hierarchical data structures, aka groups. We developed the Group-Oriented Data Analysis and Distribution (GODAD) paradigm for geoscience data analysis. We helped convene workshops for interested stakeholders in Boulder in 2016 and 2017, at ESIP in 2018, and CF adopted our Groups proposal in 2019.

---

DOE E3SM (formerly ACME) Project

The Energy Exascale Earth System Model (E3SM) (formerly the Accelerated Climate Modeling for Energy, or ACME) project, a part of DOE's Earth System Modeling (ESM) program, has since 2015 supported our development of parallel climatology, timeseries splitting, and regridding workflows to help analyze E3SM output.

---

NASA ACCESS 2013 Project

The National Aeronautics and Space Administration (NASA) Advancing Collaborative Connections for Earth System Science (ACCESS 2013) program funded our project “Easy Access to and Analysis of NASA and Model Swath-like Data” from 20140701–20160630.

That ACCESS project supported development of NCO regridding capabilities for Swath-like data (SLD), i.e., datasets with non-rectangular and/or time-varying spatial grids in which one or more coordinates are multi-dimensional. It is often challenging and time-consuming to work with SLD, including all NASA Level 2 satellite-retrieved data, non-rectangular subsets of Level 3 data, and model data (e.g., CMIP) that are increasingly stored on non-rectangular grids. Spatially intelligent software tools is a key component of the Group-Oriented Data Analysis and Distribution (GODAD) paradigm we developed for geoscience data analysis.

---

NCO-Related Publications and Presentations

• Jelenak, A., P. Leonard, and C. S. Zender (2019): NASA Dataset Interoperability Recommendations for Earth Science, Presented by A. Jelenak to the Earth Science Information Partners (ESIP) 2019 Winter Meeting, Bethesda, MD, January 15–17, 2019. PDF
• Zender, C. S. (2018): NCO-JSON: A Flexible, Complete JavaScript Object Notation for netCDF, Presented to the American Geophysical Union Fall Meeting, Washington, DC, December 10–14, 2018. Eos Trans. AGU, 98(54), Fall Meet. Suppl., Abstract IN31B-30. iPosterPDF
• Zender, C. S. (2018), NCO-JSON: JavaScript Object Notation (JSON) for netCDF. Presented to the Earth Science Information Partners (ESIP) 2018 Summer Meeting, Tucson, AZ, July 17–20, 2018. PDF
• Zender, C. S. and D. Lee (2018), CF-2 Group Proposal. Presented to the Earth Science Information Partners (ESIP) 2018 Summer Meeting, Tucson, AZ, July 17–20, 2018. PDF
• Lee, D. and Zender, C. S. (2018), CF-2 Group Proposal. Presented by D. Lee to the 2018 netCDF-CF Workshop, National Centre for Atmospheric Science (NCAS), University of Reading, Reading, UK, June 19–20, 2018. PDF
• Zender, C. S. and J. D. Silver (2017), Bit-Grooming: Shave Your Bits with Razor-sharp Precision. Presented to the American Geophysical Union Fall Meeting, New Orleans, LA, December 11–15, 2017. Eos Trans. AGU, 97(54), Fall Meet. Suppl., Abstract IN11B-0037. PDF
• Zender, C. S. (2017): CF2-Group: Draft Climate/Forecast Conventions for Hierarchical Data+Metadata. Presented to the Earth Science Data Systems Working Group (ESDSWG) Dataset Interoperability Working Group (DIWG). Online meeting, September 20, 2017. PDF
• Zender, C. S. (2017), New Methods to Generate, Regrid, and Split Climate Data. Presented to the DOE Accelerated Climate Modeling for Energy (ACME) All-Hands Meeting, Potomac, MD, June 5–7, 2017. PDF
• Silver, J. D. and C. S. Zender (2017), The compression-error trade-off for large gridded data sets, Geosci. Model Dev., 10, 413–423, doi:10.5194/gmd-10-413-2017. PDF
• Zender, C. S. and J. D. Silver (2016), Bit Grooming: Put Climate Data on a Diet with Precision-Preserving Lossy Compression. Presented to the DOE Accelerated Climate Modeling for Energy (ACME) PI Meeting, Denver, CO, November 9–11, 2016. PDF
• Zender, C.  S. (2016), Bit Grooming: Statistically accurate precision-preserving quantization with compression, evaluated in the netCDF Operators (NCO, v4.4.8+), Geosci. Model Dev., 9, 3199–3211, doi:10.5194/gmd-9-3199-2016. PDF
• Zender, C. S. (2016): Regrid Curvilinear, Rectangular, and Unstructured Data (CRUD) with ncremap, a new netCDF Operator. Presented to the Earth Science Data Systems Working Group (ESDSWG) Meeting, Greenbelt, MD, April 6--8, 2016. PDF
• Zender, C. S. (2016): Regridding Swath, Curvilinear, Rectangular, and Unstructured Data (SCRUD). Presented to the NASA Goddard Earth Sciences (GES) Data and Information Services Center (DISC), Goddard Space Flight Center, Greenbelt, MD, April 5, 2016. PDF
• Zender, C. S. (2015): Regrid Curvilinear, Rectangular, and Unstructured Data (CRUD) with ncremap, a new netCDF Operator. Presented to the American Geophysical Union Fall Meeting, San Francisco, CA, December 14--18, 2015. Eos Trans. AGU, 95(54), Fall Meet. Suppl., Abstract IN31A-1744. PDF
• Zender, C. S. (2015): Optimizing Intrinsic Parallelism to generate climatologies with netCDF Operators (NCO). Presented to the DOE Accelerated Climate Modeling for Energy (ACME) PI Meeting, Albuquerque, NM, November 2--4, 2015. PDF
• Zender, C. S., P. Vicente, and W. Wang (2015): Use netCDF Operators (NCO) to Improve Data Interoperability and Usability. Presented to the Earth Science Data Systems Working Group (ESDSWG) Meeting, Greenbelt, MD, March 24--26, 2015. PDF
• Zender, C. S., P. Vicente, and W. Wang (2014): Simplifying and accelerating model evaluation by NASA satellite data. Presented to the Earth Science Data Systems Working Group (ESDSWG) Meeting, Greenbelt, MD, March 24--26, 2014. PDF
• Zender, C. S. (2014): Use Hierarchical Storage and Analysis to Exploit Intrinsic Parallelism. Presented to the NASA Goddard Earth Sciences (GES) Data and Information Services Center (DISC), Goddard Space Flight Center, Greenbelt, MD, March 27, 2014. PDF
• Zender, C. S., P. Vicente and W. Wang (2013): Use Hierarchical Storage and Analysis to Exploit Intrinsic Parallelism. Presented at the Fall Meeting of the American Geophysical Union, San Francisco, CA, December 9–13, 2013. Eos Trans. AGU, 93(53), Fall Meet. Suppl., Abstract IN52A-06. PDF
• Zender, C. S., P. Vicente and W. Wang (2013): The Future of Model Evaluation. Presented to the Chapman University Symposium on Big Data and Analytics: 44th Symposium on the Interface of Computing Science and Statistics, Chapman University, Orange, CA, April 4–6, 2013. PDF
• Zender, C. S., P. Vicente and W. Wang (2012): NCO: Simpler and faster model evaluation by NASA satellite data via unified file-level netCDF and HDF-EOS data post-processing tools.. Presented at the Fall Meeting of the American Geophysical Union, San Francisco, CA, December 3–7, 2012. Eos Trans. AGU, 93(53), Fall Meet. Suppl., Abstract IN34A-07. PDF
• Zender, C. S., P. Vicente and W. Wang (2012): Simplifying and accelerating model evaluation by NASA satellite data.. Presented to the Earth Science Data Systems Working Group (ESDSWG) Meeting, Annapolis MD, November 13–15, 2012. PDF
• Presentation and Publications from 2006–2011

---

Release Highlights

Stable releases receive unique tags and their tarballs are created and stored here at GitHub. Identical copies of those tarballs are also stored here on SourceForge for historical continuity. You may retrieve the source of tagged versions directly with, e.g., .

• NCO 5.0.0: (Distant Future) netCDF4 user-defined types support; better extensive variable treatment?; splitter support for regular expressions?; support ?;
• NCO 4.9.7: (Future) Byte-swap algoritm; small-circle weights;
• NCO 4.9.6: (In Progress, features in-progress or complete include) re-tune digit rounding; link to CCR; Numerator-only support for integration?; multi-subcycle output option; deconvolve sparse matrix fields (for CLM/ELM);
• NCO 4.9.5: (for CAM/EAM);
• NCO 4.9.4: (Current Stable Release) high-frequency climos; per-file weights; per-record weights; climatology bounds; promote integers; regridding vectorization; interleave output; distance-weighted extrapolation weight generation algorithm;
• NCO 4.9.3: map-file correction; for TR FV destination maps; parallelize K-D tree loading;
• NCO 4.9.2: improvements; ; unpacks all coordinates; pressure->hybrid flexibility; small-circle weights;
• NCO 4.9.1: spatial average timeseries; map; bugfix
• NCO 4.9.0: map-file evaluation; find all NaNs; simulaneous horizontal and vertical regridding; invokes NCO weight-generator; parallelism; sub-gridscale acceleration; vertical grid flexibility
• NCO 4.8.1: fixes single-file handling; fine-grained seasonal parallelism; supports vertical interpolation; interpolation; mesh-file output; infers n2s Gaussian grids; outputs n2s grids in CCW order; vertical interpolation supports ECMWF IFS;
• NCO 4.8.0: allows no input file; climo granularity; ~20x faster on Cori; kill not orphan children; NCO generates intersection meshes and weights; Check file for NaNs; for Conda-feedstock tests; Vertical interpolation/regridding;
• NCO 4.7.9: Improved compliance; Re-basing; depth-coordinates; SGS fix, lat/lon_dmn_nm;
• NCO 4.7.8: Double->Float map;
• NCO 4.7.7: Double->Float map; skeleton files; symmetric Gaussian interfaces; North-to-South grids; Deprecate filename sanitization whitelist; ERWG ; Extract with ;
• NCO 4.7.6: HPSS opt-in on all operators; strings under Windows; ENUM, VLEN subsetting; VLEN missing value braces; RRG, MWF modes;
• NCO 4.7.5: supports mpassi name and rx's; fix CLM PJCS bug; XML prefixes; ENUM, VLEN CDL/XML/JSON support; Sanitize exceptions for DAP4 protocol; pack() arguments;
• NCO 4.7.4: printing gracefully skips non-atomic types; supports ERWG 7.1.0r features conserve2nd, extrapolation; guesses column dimension for unstructured grids; Support absolute/relative Out-of-Group (OOG) variables in CF2-Group;
• NCO 4.7.3: Sanitize input/output filenames; Support and rx's; for printing; for TempestRemap2 ordering; silence compiler warnings;
• NCO 4.7.2: splitter ypf bugfix; canonical positional arguments; TempestRemap2 support;
• Release Highlights from 200001–201712 (versions 1.1.47–4.7.1)

---

Pre-built Executables

Pre-built binary executables are available for many platforms. Our source tarballs are always up-to-date, and work on our development systems (Fedora, Ubuntu, and Mac OS X). We also attempt to provide (theoretically) platform-independent sources in the most common Linux package formats (Debian and RPM). Below are one-line installation instructions and links to these and to packages for other platforms created by volunteers. Anyone willing to perform regular regression testing and porting of NCO to other platforms is welcome. We highly recommend the Anaconda method to first-time users, as it works on all platforms and is perhaps the most up-to-date pre-packaged version. Previous versions of these executables are still available by searching the directory index here.

AIX on IBM mainframes

• nco-4.2.5.aix53.tar.gz (9.5M): Executables AIX 5.3-compatible (last updated Tuesday, 29-Jan-2013 19:02:41 UTC). Maintained by NCO Project.
Newer (beta- or pre-release) packages are sometimes available for AIX users as described here. Thanks to NSF for supporting AIX machines at NCAR over the years.

Anaconda (for *NIX, MacOS, and Windows)

Anaconda is a coordinated, cross-platform Python environment that utilizes the package manager. Anaconda can be easily installed into a user-owned directory. This bypasses the normal headache of relying on system-administrators to install the latest NCO on shared systems like supercomputers. Miniconda (rather than the full Anaconda install) suffices for most purposes. Up-to-date Anaconda-compatible versions of NCO for Linux, MacOS, and Windows are maintained at conda-forge. Install NCO in your Anaconda framework with one command ‘’. Or, alternatively, permanently add conda-forge (which teems with goodies besides NCO) to your automatically-searched channels with ‘’, then install NCO with ‘’. The default NCO installed by is generally within a month of the latest release.
• nco-4.9.5 Executables Anaconda-compatible. Maintained by Filipe Fernandes.
Thanks to Rich Signell, Filipe Fernandes, Pedro Vicente, Xylar Asay-Davis and others for developing and maintaining the NCO package for conda.

Debian and Ubuntu GNU/Linux

Debian NCO and Ubuntu NCO homepages. ‘’ installs the standard NCO for your Debian-compatible OS. NCO packages in the Debian/Ubuntu repositories (e.g., Sid and Raring) generally lag the packages distributed here by 6–12 months. Newer (beta- or pre-release) packages are often available for intrepid Debian/Ubuntu users as described here.
Debian package for most recent NCO release (install with, e.g., ‘’):
• nco_4.9.5-1_amd64.deb : Executables AMD64-compatible
Thanks to Daniel Baumann, Sebastian Couwenberg, Barry deFreese, Francesco Lovergine, Brian Mays, Rorik Peterson, and Matej Vela for their help packaging NCO for Debian over the years.

Fedora, RedHat Enterprise Linux (RHEL), and Community ENTerprise Operating System (CentOS) GNU/Linux

The Fedora NCO RPMs are usually up-to-date so that ‘’ installs a recent version. RHEL NCO RPMs are documented at the Fedora site. OpenSUSE keeps NCO RPMs here. A comprehensive list of pre-built RPMs for many OS’s is here. Volunteers have updated and maintained fairly up-to-date NCO packages in Fedora since it was added by Ed Hill in about 2004. Thanks to Patrice Dumas, Ed Hill, Orion Poplawski, and Manfred Schwarb for packaging NCO RPMs over the years. Thanks to Gavin Burris and Kyle Wilcox for documenting build procedures for RHEL and CentOS.

Gentoo GNU/Linux

Mac OS X/Darwin

The most up-to-date executables are probably those in the tarball below. Those unfamiliar with installing executables from tarballs may try the (older) DMG files (you may need to add to your executable path to access those operators).
• nco-4.9.5.macosx.10.15.tar.gz (4.5M): Executables MacOSX 10.15-compatible (last updated Wednesday, 23-Sep-2020 23:55:55 UTC). (NB: These executables require the MacPortsdependencies for NCO). Maintained by NCO Project.
• nco-4.0.7_x86_10.6.dmg ( 35M): For Mac OS 10.6 (last updated Wednesday, 02-Mar-2011 20:17:21 UTC). Maintained by Chad Cantwell.
• Fink packages for NCO: Currently NCO 3.9.5. Maintained by Alexander Hansen.
• Homebrew packages for NCO: Currently NCO 4.6.X. Install with ‘’. Maintained by Ian Lancaster (Alejandro Soto’s instructions here).
• MacPorts infrastructure for NCO: Portfile: Currently NCO 4.6.6. Install with ‘’. Maintained by Takeshi Enomoto.

Microsoft Windows (version 10 and later) via Linux install

Installing a full linux subsystem in Windows 10 is straightforward: Search (e.g., in Google) for "install linux in windows 10". The first link, for example, is here. Follow those instructions. We suggest installing Ubuntu. Once you have, open a shell window and enter , just as you would do on any Debian or Ubuntu Linux platform. (These instructions are copied from Adrian Tompkins.)

Microsoft Windows (version 9 and earlier) (native build, compiled with Visual Studio 2015, use this if unsure)

These native Windows executables (64bit) are stand-alone, i.e., do not require users to have any additional software. This is a new feature as of 20120615, please send us feedback. To build NCO from source yourself using MSVC with CMake, please see example in .

• nco-4.9.4.windows.mvs.exe ( 27M): Windows Self-Extracting Installer (last updated Wednesday, 23-Sep-2020 21:05:22 UTC). Maintained by Pedro Vicente.

Microsoft Windows (running Cygwin environment, compiled with GNU-toolchain)

Before using, first install (in the "Web" category of Cygwin Setup), and set (or wherever is installed). Thanks to Mark Hadfield and Pedro Vicente for creating Cygwin tarballs. Thanks to Cygnus Solutions and RedHat Inc. for developing and supporting Cygwin over the years.

Python Bindings Source and Documentation

---

Documentation and Users Guide

The NCO Users Guide is available for reading in these formats:

• DVI Device Independent (, )
• HTML Hypertext (any browser)
• Info GNU Info (, )
• PDF Portable Document Format (, , , , )
• Postscript Printing (, )
• TeXInfo Documentation Source code ()
• Text Plain text ()
• XML Extensible Markup Language ()

is the most up-to-date. Files , , and contain all the mathematical formulae (typeset with TeX) missing from the screen-oriented formats. The screen-oriented formats—, , , and —contain all the documentation except the highly mathematical sections. Wenshan Wang of UCI contributed a Quick Reference Card (last updated Wednesday, 23-Sep-2020 20:58:31 UTC) suitable for printing, framing, and/or carrying on your person at all times.

Other documentation:

• This abbreviation key unlocks the mysteries of the source code abbreviations and acronyms.

---

FAQ: Frequently Asked Questions

These questions show up almost as frequently as my mother. But they are more predictable:

• I still have questions, how do I contact the NCO project? The NCO project has various Q&A and discussion forums described below.
• Where can I find prebuilt NCO executables? Pre-built executables of some versions of NCO for the operating systems described above (Debian-compatible GNU/Linux, Fedora/RedHat GNU/Linux, Gentoo GNU/Linux, and Mac OS X). Otherwise, you may be on your own.
• Does NCAR support NCO? The NCAR CISL Consulting Service Group (CSG) supports NCO like other software packages. The NCAR CISL-suported executables are made available through “modules” so try . If you notice problems with the NCO installation on CISL machines, or if you would benefit from a more recent release or patch, then ask cislhelp. If you have a comment, suggestion, or bug report, then contact the developers as described below.
• Is there an easy way to keep up with new NCO releases? Subscribe to the mailing list. This list is for NCO-related announcements, not for questions. is very low volume—one message every few months.

---

Help/Support/Contacts:

If you have support questions or comments please contact us via the Project Forums (rather than personal e-mail) so other users can benefit from and contribute to our exchange. Let us know how NCO is working for you—we'd like to hear. Have you read the documentation and browsed the forums to see if your question/comment has been reported before? Please read the Guide's suggestions for productive Help Requests and Bug Reports.

• Where should I ask my questions on how to use NCO? On the Help site.
• Where should I post suggestions/comments on NCO features and usage? On the Discussion site.
• Where are NCO development and new features discussed? On the Developer site.
• Where do I file an NCO bug-report? On the Bug Tickets site.

---

ANNOUNCE/ChangeLog/README/TODO

Files containing useful information about the current distribution:

• Notes on current release
• Change History since 1997 (version 0.9)
• Platforms and software required
• An unordered list of features and fixes we plan

---

Source Code

The simplest way to acquire the source is to download the compressed tarball:

• nco-4.9.5.tar.gz (5.1M compressed tar-file)
  MD5(src/nco-4.9.5.tar.gz)= 28edde9bfd7451722dfe6dfdd08a2af6
  SHA1(src/nco-4.9.5.tar.gz)= 874064fbe36b48bc3bc4817b29daace5b6ed0c65
  SHA256(src/nco-4.9.5.tar.gz)= 874c6040371207799ca9c2f3919c045b309b251bf7992ec92521d89cf3bf515f

The best way to acquire the source and occasionally update to the latest features is with Git. The browsable Repository contains up-to-the-minute sources and is the easiest way to stay synchronized with NCO features. Updating NCO source requires some familiarity with development tools, especially Git and Make. You may retrieve any NCO source code distribution you wish from GitHub. To avoid the churn that comes with using the latest snapshot, potential contributors may wish to retrieve a recent tagged (i.e., stable and released) version, This command retrieves the entire NCO repository (< 20 MB) and then checks out NCO version :

However, the most efficient way to actively track and develop NCO is to retrieve the current (“bleeding edge”) NCO snapshot. This command retrieves the latest NCO master branch into a local directory named : , or Track changes to the development version using One difference between running a "tagged" release (e.g., ) and the development version is that the tagged release operators will print a valid version number (e.g., ) when asked to do so with the flag (e.g., ). Snapshots will include the sub-version and patch-level in the version information (e.g., ).

Developer NCO Source Documentation

Automated source documentation, created by the Doxygen tool is available. Some developers find this documentation helpful, as it can clarify code and data relationships in the code.

The Doxygen documentation is infrequently (i.e., never since Daniel left) updated.

---

Compilation Requirements

Best Practices:
• Although building NCO yourself can be easy, sexy, and lucrative, we recommend that you first try the pre-built executables for your system, e.g., If pre-built executables do not satisfy you (e.g., are out-of-date) and you want the latest, greatest features, then the first steps to build (i.e., compile, for the most part) NCO from source code are to install the pre-requisites: ANTLR version 2.7.7 (like this onenot version 3.x or 4.x!) (required for ), GSL (desirable for ), netCDF (absolutely required), OPeNDAP (enables network transparency), and UDUnits (allows dimensional unit transformations). If possible, install this software stack from pre-built executables (commands to do so on Debian, Mac, and RPM systems follow below). ANTLR executables from major distributions are pre-built with the source patch necessary to allow NCO to link to ANTLR. If you must build the source stack yourself (e.g., due to lack of root access, or systems without packages such as AIX), build all libraries with the same compiler and switches. The ANTLR 2.x source file must include this line: or else will not compile (this ANTLR tarball is already patched). Recent versions of netCDF automatically build OPeNDAP and UDUnits. NCO is mostly written in C99, and although you may mix and match compilers, this is often difficult in practice and is not recommended. The exception is which is written in C++. ANTLR, OPeNDAP, and NCO must be built with the same C++ compiler to properly resolve the C++ name-mangling. NCO does not yet support newer ANTLR versions because the ANTLR 3.x and 4.x C++ interfaces are incomplete.
  For the reasons explained above (compiler compatibility) install as much pre-requisite and optional software as possible from pre-compiled packages. This is easy on modern package-oriented OSs. The NCL/ESMF packages provide ESMF_RegridWeightGen for use by , they are not required to build NCO. Remember, to compile NCO from source, you need not only the library dependencies the "devel" versions (which include the header files) of the For Debian-based systems (like Ubuntu) ( is similar to and interchangeable with ):
  For RPM-based systems like Fedora and CentOS (substitute for on older systems):
  For Mac OS X with MacPorts: Without MacPorts, the system TeXInfo may be too old to build the documentation. In this case use .
  For Windows with Cygwin, select and install the following packages with Cygwin Setup: As of 20131101 there is no Cygwin package for ANTLR, and the Cygwin netCDF package does not yet support DAP.
• Once you have installed the pre-requisites as shown above, you may then build the latest stable NCO and install it in, e.g., with:
• The CMake-equivalent to the autoconf/configure build-engine example above is: Unlike autoconf/configure, CMake works well on MS Windows. CMake tries to find header and dependency libraries in standard locations. Override these manually with, e.g.,
  Please post questions about building or installing NCO to the list only after reading and attempting to follow these instructions. To indicate you have done this, include the word “bonobo” in the first sentence of your post. Yes, “bonobo”. Otherwise we will likely redirect you here. For more sophisticated build/install options, see the next section.

Still having trouble building NCO from source? Read these (much older) Build Hints

---

Using NCO at UCI, NCAR, and other High Performance Computing Centers (HPCCs)

HPCCs unfortunately do not utilize modern package systems like RPMs or .debs, or do so on old OSs with no access to newer RPMs and .debs. Institution-supported executables are usually available with . These stable releases are often many versions (up to two years) old. Thanks to funding from external grants,

DOE, NCAR, and UCI HPCC users may find more recent pre-built NCO executableses the personal directories shown below. These are usually built from a recent tagged-version of NCO (e.g., 4.6.X-alphaY) not from the “bleeding-edge” of master which is usually untagged. One way to use these pre-built executables is to prepend them to your executable and library search paths, e.g., ,

• ANL ALCF Cooley :
• ANL ALCF Mira :
• ANL LCRC Blues :
• LLNL :
• NCAR CISL :
• NERSC Cori :
• ORNL OLCF Rhea :
• ORNL OLCF Titan :
• PNNL Compy :
• UCI ESS :

---

Known Problems from 2013 (version 4.2.4) Onwards

Recent Generic Run-time Problems:
• netCDF CDF5 corruption: netCDF libraries 4.4.0+ supports the CDF5 binary format. Unfortunately the CDF5 implementation is buggy for large (> 4 GiB) variables in library versions 4.4.0–4.6.0. We identified this netCDF CDF5 bug on 20170906. Writing CDF5 files with large variables is buggy unless there is only one such “large” variable and it is the last to be defined. If the file is an input dataset (i.e., NCO reads it) written by PnetCDF then the input data are fine (because PnetCDF writes CDF5 through a different mechanism than serial programs like NCO’s writer). And if the CDF5 dataset was originally written by any netCDF version 4.6.1 or greater, then it is unaffected by this bug. However, a CDF5 input file with large variables written by any serial netCDF writer (like NCO) employing netCDF library 4.4.0–4.6.0, is likely corrupt and variables were silently truncated when writing it. Output files (that NCO wrote) with large variables will definitely be corrupt if NCO was linked to netCDF library version 4.4.0–4.6.0 (so upgrade to netCDF 4.6.1+ ASAP). Here are two potential workarounds for data affected by this bug: 1. Re-write (using any netCDF version) original input files in netCDF4 format instead of CDF5, then process these as normal and write netCDF4 output (instead of CDF5); 2. Re-compile NCO with netCDF library 4.6.1+ or later and use it to convert non-corrupt datasets to netCDF4 format, then process the data. For more information on this nasty bug, see here and here. UPDATE: Unidata released netCDF 4.5.0 on 20171020. Unfortunately the patch to fix the CDF5 bug was not included. UPDATE: Unidata released netCDF 4.6.0 on 20180124. Unfortunately the patch to fix the CDF5 bug was not included. UPDATE: Unidata released netCDF 4.6.1 on 20180319. netCDF version 4.6.1 includes the patch that fixes the CDF5 bug. Yay!
• netCDF4 Strided Hyperslab bug: Multiple users complain that access to strided hyperslabs of netCDF4 datasets is orders of magnitude slower than expected. This occurs with NCO and also with related software like NCL. The cause appears to be that all recent versions of netCDF up to 4.3.3 access strided hyperslabs via an algorithm (in ) that becomes unwieldy and error-prone for large datasets. We developed and implemented a transparent workaround (that avoids the troublesome algorithm) for the most common case which is where strides are taken in only one dimension, e.g., . With the workaround introduced in NCO 4.4.6, strided access to netCDF4 datasets now completes in nearly the same amount of time as non-strided. This workaround works transparently with any version of netCDF. We are not yet sure that we have fully and correctly diagnosed the cause nor that our workaround is always effective. Comments welcome. Updates will be posted right here.
• netCDF4 Renaming bugs: Unforunately from 2007–present (February, 2015) the netCDF library (versions 4.0.0–4.3.3) contained bugs or limitations that prevent (and other netCDF4-based software) from correctly renaming coordinate variables, dimensions, groups, and attributes in netCDF4 files. (To our knowledge the netCDF library calls for renaming always work well on netCDF3 files so one workaround to netCDF4 bugs is convert to netCDF3, rename, then convert back). A summary of renaming limitations associated with particular versions of netCDF4 is maintained in the online manual here. Important updates will also be posted here on the homepage. There are still known bugs with renaming features as of netCDF library version 4.4.1.1 (November, 2016).

Recent Operator-specific Run-time Problems:
• Hyperslabbing masked and/or weighted variables bug: Versions 4.2.4—4.6.7 of incorrectly handle masking and weighting of hyperslabbed variables. Performing these actions simultaneously causes subtle arithmetic errors (the worst kind!), unless the hyperslab happens to start with the first element of the variable. In other words, results from commands of the form and are suspect. The workaround is to downgrade to NCO 4.2.3. The solution is to upgrade to NCO 4.6.8.
• Minimization/maximization of packed variables bug: Versions 4.3.y—4.4.5 of incorrectly handled packed variables during these operations. The two workarounds are to unpack first or to perform the statistics in single precision with the option. The solution is to upgrade to NCO 4.4.6.
• Promoting packed records with missing values bug: Versions 4.3.X—4.4.5 of could produce (wildly) inaccurate statistics when promoting (e.g., to double- from single-precision) variables that are packed and that have missing values. The two workarounds are to unpack first or to perform the statistics in single precision with the option. The solution is to upgrade to NCO 4.4.6.
• Chunking while hyperslabbing bug: Versions 4.3.X—4.4.4 of most operators could send incorrect chunking requests to the netCDF library, resulting in failures. This occurred only while simultaneously hyperslabbing. The solution is to upgrade to NCO 4.4.5.
• mask condition bug: All versions through 4.4.3 of could return incorrect mask values for negative numbers. Thanks to Keith Lindsay for report, and to Henry Butowsky for fix. Prior to this fix, the would drop the negative sign, if any, from the comparators appearing in the mask condition, e.g., was parsed as not . Hence, users of (or of ) should upgrade. NB: The form of masking is/was not buggy. Thus the workaround is to use the form of masking, while the long-term solution is to upgrade to NCO 4.4.4+.
• , , and file close bug: Versions 4.3.9—4.4.0 of , , and failed to correctly close and optionally remove input files. This could cause NCO to exceed system limits on the maximum number of open files when hundreds-to-thousands of input files were specified per NCO invocation. The exact failure point is OS-dependent (NCO commands on Mac OS X 10.9 would fail when processing more than 256 files at a time). This is embarassing because NCO has always been designed to work with arbitrary numbers of input files and we want power users to be comfortable running it on hundreds of thousands of input files. The workaround is to avoid versions 4.3.9—4.4.0, while the long-term solution is to upgrade to NCO 4.4.1+.
• MRO missing value bug: Versions 4.3.6—4.3.9 of could treat missing values incorrectly during double-precision arithmetic. A symptom was that missing values could be replaced by strange numbers like, well, infinity or zero. This mainly affects in MRO (multi-record output) mode, and the symptoms should be noticeable. The workaround is to run the affected versions of ncra using the switch, so that single-precision floating point numbers are not promoted prior to arithmetic. The solution is to upgrade to NCO 4.4.0+.
• hyperslabbing while averaging bug: Versions 4.3.3—4.3.5 of could return incorrect answers when user-specified hyperslabs were simultaneously extracted. In such cases, hyperslab limits were not consistently applied. This could produce incorrect answers that look correct. This bug only affected hyperslabbed statistics (those produced by simultaneously invoking and switches); “global averages” were unaffected. We urge all users to upgrade to NCO 4.3.6+.
• unpacking bug with auxiliary coordinates: Versions 4.3.2–4.3.3 of did not correctly store unpacked variables. These versions unpacked (when specified with or ) the values, but inadvertently stored their original packing attributes with the unpacked values. This would lead further operators to assume that the values were still packed. Hence consecutive operations could lead to incorrect values. Fixed in version 4.3.4. All users are encouraged to upgrade. NB: this bug did not affect the other arithmetic operators which unpack data prior to arithmetic.

Recent Platform-specific Run-time Problems: No known platform-specific problems with recent releases.

Known Problems through 2012 (version 4.2.3)

---

People:

Current Developers (please contact us via the project forums not via email):

• Charlie Zender, Professor of Earth System Science (ESS) and of Computer Science (CS). Role: Project PI. Contributions: Core library, porting, release manager Related Research: 1. Group-Oriented Data Analysis and Distribution (GODAD). 2. Extend empirically verified analytic model (described here) for terascale data reduction of gridded datasets to account for cluster- and network-effects. 3. Enable and optimize NCO for intra-file-level parallelism using netCDF4/HDF5 parallel filesystem features. Other Interests: Atmospheric Physics, Climate Change
• Henry Butowsky, software engineer Roles: Scientific programmer Current Research: 1. Efficient complex data analysis with storage-layer constraints. 2. Develop and thread the interpreter. Other Interests: Compilers and interpreters.
• Pedro Vicente, software engineer, 201206—201405, then NOAA, continues as volunteer contributor

Alumni Developers:

• Dr. Scott Capps, earned Earth System Science Ph.D. (2009) with Zender at UCI, then postdoc at UCLA, then Vertum Partners, now founder/CEO Atmospheric Data Solutions
• Stephen Jenks, former Assistant Professor of Electrical Engineering and Computer Science (EECS)
• Dr. Daniel Wang: earned EECS Ph.D. (2008) with Jenks and Zender at UCI, now at SLAC
• Dr. Wenshan Wang, Roles: Postdoc Current Research: 1. Causes and implications of Greenland snowmelt. 2. Rapid evaluation and exploitation of multi-model datasets. Other Interests: Automated Weather Station workflows

Thanks also to past NCO contributors

---

"Fossies" - the Fresh Open Source Software Archive

Member "gsview/Readme.htm" (17 Jan 2012, 17675 Bytes) of package /linux/misc/old/ghost/ghostgum/gsv50w64.exe:

---

---

GSview 5.0 PostScript previewer. Needs Ghostscript 7.04 or later.
Release date: 2012-01-17

Table of contents

Overview

GSview is a graphical interface for Ghostscript under MS-Windows, OS/2 and Unix. Ghostscript is an interpreter for the PostScript page description language used by laser printers. For documents following the Adobe PostScript Document Structuring Conventions, GSview allows selected pages to be viewed or printed. GSview requires Ghostscript 7.04 - 9.99.

Features include:

• Display and print PostScript and PDF files.
• View pages in arbitrary order (Next, Previous, Goto).
• Page size and Orientation are automatically selected from DSC comments or can be selected using the menu.
• Print selected pages using Ghostscript.
• Convert pages to bitmap, PDF or PostScript.
• Selectable display resolution, depth, alpha.
• Single button zoom.
• Extract selected pages to another file.
• Copy display bitmap to clipboard.
• Save clipboard bitmap as BMP file.
• Add bitmap or user preview to EPS file (Interchange, TIFF or Windows Metafile)
• Graphically select and show bounding box for EPS file.
• Extract bitmap preview or PostScript from DOS EPS file.
• Extract text or search for text.
• Can read gzip and bzip2 compressed PostScript and PDF files.
• On-line help.
• Win64, Win32. Older versions support GNU/Linux, OS/2 and Win16.
• Can be run directly off a CD-ROM or USB memory stick (Portable Application).
• English, Catalan, Dutch, French, German, Greek, Italian, Russian, Slovak, Spanish and Swedish languages.
• Per user initialisation files for Windows.
• Includes setup program.
• Free (Aladdin Free Public Licence).
• Works with Ghostscript 7.04 - 9.99 (GSview checks the Ghostscript version number). Some older versions of GSview will work with Ghostscript 4.03 - 6.99.

Changes in version 5.0:

• Minor bug fixes.
• Help file updated to work on Windows 7.
• Saving registration number fix on Windows 7.
• Non-English languages work on 64-bit Windows.
• GNU/Linux code has been removed while it is being updated to the current version of gtk+.

GSview was written by Russell Lang at Ghostgum Software Pty Ltd.

Installation

First uninstall any previous versions of GSview.

Win32

Obtain GSview (gsv50w32.exe) from

http://www.cs.wisc.edu/~ghost/gsview/get50.htm

Obtain GPL Ghostscript 9.02 (gs902w32.exe) from

http://www.cs.wisc.edu/~ghost/doc/GPL/gpl902.htm

First install the GPL Ghostscript self extracting archive gs902w32.exe (or a later version if available) Then install the GSview self extracting archive gsv50w32.exe. Run GSview.

Win32 location details

By default, GSview is installed in the directory , which creates the sub-directories and . The GSview executable is .

By default, GPL Ghostscript is installed in the directory , which creates the sub-directories and . The GPL Ghostscript executables are for console mode and for windowing mode.

GSview normally locates GPL Ghostscript using registry entries created by the GPL Ghostscript setup program. If these do not exist, GSview will assume that Ghostscript is in an adjacent directory to GSview, usually and .

Win64 (AMD64)

Obtain GSview (gsv50w64.exe) from

http://www.cs.wisc.edu/~ghost/gsview/get50.htm

First install the GPL Ghostscript self extracting archive gs902w64.exe (or a later version if available) Then install the GSview self extracting archive gsv50w64.exe. Run GSview.

This version requires that you have a 64-bit x64 processor (AMD64 or EM64T), and that you are also running a 64-bit version of Windows such as Windows XP x64 Edition. It will not run on the more common 32-bit Windows XP.

OS/2

Obtain GSview (gsv49os2.zip) from

http://www.cs.wisc.edu/~ghost/gsview/get49.htm

Obtain GPL Ghostscript 8.60 (gs860os2.zip) from

http://www.cs.wisc.edu/~ghost/doc/GPL/gpl860.htm

Unzip GSview to a temporary directory, change to the gsview2 subdirectory, place gs860os2.zip (or a later version) in the same directory, and then run os2setup.exe.

If you do not already have EMX installed on your system, you will also need to obtain the EMX Run Time library, emxrt.zip, from one of

ftp://ftp-os2.cdrom.com/pub/os2/emx09d/emxrt.zip
ftp://ftp-os2.nmsu.edu/pub/os2/dev/emx/v0.9d/emxrt.zip

If GSview refuses to run at all, make sure you do not have an old version of the emx DLL on your system.

GSview (gvpm.exe) will run under OS/2 2.1 and OS/2 Warp.

X11/Unix

Copy , , and to a directory on your search path. Copy to the directory . Copy to directory . GSview stores configuration information in .

You must have the shared object version of Ghostscript 7.04 - 9.19, which should be included in recent GNU/Linux distributions. If you don't have the ghostscript shared object, you must first install Ghostscript, then the additional shared object files. To build the ghostscript shared object files, use ''

A precompiled version is available for GNU/Linux. GSview can also be compiled for SunOS and SGI IRIX.

General

Make sure that the zip/exe files are transferred in binary mode.

The Ghostscript fonts are used by Ghostscript alone. Your system Fonts folder will not be modified.

If you don't like automatic installation programs, it is possible to install GSview and Ghostscript manually. For Ghostscript, read the file gsN.NN\doc\Install.htm. For GSview, read the file gsviewen.hlp

If you wish to use install GSview without any prompts, give a destination directory on the command line. For example:

setup "c:\Program Files\ghostgum"

This will not prompt for a destination directory and will overwrite files without asking.

Configuration of GSview will occur the first time it is run.

See the on-line help for more details. The 'Common Problems' topic is worth reading if GSview doesn't work.

Compilation

To compile GSview for Windows you need MS Visual C++ 5, 6, 7, 7.1, 8 or 9. Copy srcwin/win.mak to Makefile, edit Makefile to set and as required, then type ''. To build for Win64 use ''

To compile GSview for OS/2 you need IBM NMAKE.EXE and EMX/GCC 0.9d. To create the GSview online help you need the IBM toolkit. Copy srcos2/os2.mak to Makefile and edit COMPBASE and EMXPATH as required. Type 'nmake'

To compile GSview for X11/Unix you need gcc and the GTK+ 1.2 toolkit. Unzip the sources as follows to convert the line endings:

unzip -aa gsv49src.zip unzip -o gsv49src.zip "gsview-4.9/binary/*" cd gsview-4.9 cp srcunx/unx.mak Makefile make GSview may also be available in a tar.gz file which already has Unix line endings. To install, run See the X11/Unix topic for more notes on X11 GSview. For SunOS or SGI IRIX, uncomment the appropriate lines in the makefile. You also be able to use rpmbuild -ta gsview-4.9.tar.gz

X11/Unix

X11 GSview is written by a novice at X Windows programming. It might have serious problems. The GTK+ toolkit is used for most of the graphical interface, with a very small amount of Xlib.

GSview on Unix uses the Ghostscript shared object. Drawing (especially over a network when using anti-aliased text) should be faster.

Unimplemented features

• Help uses HTML and netscape. Gnome Help Browser is not used because it doesn't support #topic on the command line. For example: gnome-help-browser file:/path/gsview.htm#Page_Size If you know of a way to tell the Gnome Help Browser to jump to a particular topic, particularly without opening another copy of the browser, please let me know.
• Keyboard movement between widgets
• Full screen not implemented
• Clipboard operations
• Sounds

Known problems

• Fit window doesn't get the correct dimension of the scrolled window client area, so the resize is slightly wrong. At the moment we use the size of the scroll window less the two scroll bars.
• GSview still includes lots of debugging code.

Requests

Suggestions from GTK+ programmers about how to improve GSview.

Bug reports. Use "gsview -d9" to get debugging messages on stdout.

Bugs

Send bug reports to Russell Lang at Ghostgum Software Pty Ltd, at. When reporting bugs, please include the version number and date of GSview (from the Help | About box), the version number of Ghostscript, and the exact wording of any error messages. The text in the "Ghostscript Messages" dialog can be copied to the clipboard and pasted as text (not bitmap please!) into an email message. Do not send me large files (>100k bytes) unless requested. If you get a SYS3175 or GPF, please send the address of the GPF - I can use this to help locate the bug. Please distinguish between bugs in GSview and bugs in Ghostscript, by making sure that the problem only occurs when using GSview, and not when using Ghostscript alone. Don't expect a fast response - the work I'm paid to do has a higher priority. For a list of known bugs, see http://www.cs.wisc.edu/~ghost/gsview/bugs.htm

Updates

A World Wide Web home page for Ghostscript, Ghostview and GSview is at http://www.cs.wisc.edu/~ghost/

The latest version of GSview should be available from ftp://mirror.cs.wisc.edu/pub/mirrors/ghost/ghostgum/gsview*.zip

Obtaining Ghostscript

Ghostscript can be downloaded from the Internet.

To download, go to the Ghostscript home page then follow the link to Obtaining GPL Ghostscript.

Copyright, Licensing and Registration

GSview is copyright by Ghostgum Software Pty Ltd. GSview is distributed with the Aladdin Free Public Licence. This licence is contained in the file LICENCE .

This licence does not require any payment to the author; however the author would welcome any registrations of GSview to cover costs and time involved in developing and maintaining GSview. The registration fee is currently AUD$40. GSview can be registered online at http://www.ghostgum.com.au/ or by faxing or mailing the registration form. Ghostgum Software prefers that you use the online registration. On registration you will be sent a registration code to disable the nag screen.

The postal address for Ghostgum Software is:

Russell Lang
Ghostgum Software Pty Ltd
25 Kennedy St
GLEN WAVERLEY VIC 3150
AUSTRALIA

GSview uses Ghostscript to display the contents of the PostScript files. Ghostscript is a separate program from GSview; it is owned by Artifex Software Inc., not by Ghostgum Software Pty Ltd.

GSview uses pstotext in an external DLL. pstotext was written by Andrew Birrell and Paul McJones. It is Copyright (C) 1995-1996, Digital Equipment Corporation. See the licence in pstotext.txt or pstotext.zip for more details. If you do not agree to the pstotext licence, delete pstotext.zip, pstotxt2.dll and pstotxt3.dll. See http://www.research.digital.com/SRC/virtualpaper/pstotext.html

GSview can convert PostScript or PDF file to an editable vector using pstoedit in an external DLL. pstoedit is Copyright by Wolfgang Glunz and is licensed with the GNU Public Licence (GPL). pstoedit is not included with GSview. You will need to obtain pstoedit separately from the pstoedit homepage http://www.pstoedit.net/pstoedit or from http://www.cs.wisc.edu/~ghost/gsview/pstoedit.htm . Source code can be obtained from these sites.

GSview uses zlib 1.2.3 in an external DLL. zlib is Copyright (C) 1995-2005 Jean-loup Gailly and Mark Adler. See http://www.zlib.net/

GSview uses bzip2 in an external DLL. bzip2 is Copyright 1996-2006 by Julian Seward. See http://sources.redhat.com/bzip2/

The installation programs may use an unzip decompression library (DLL) by the Info-ZIP group. The original sources are freely available from ftp://ftp.info-zip.org/pub/infozip/

Other Useful Programs

GSPRINT is a command line tool for printing using Windows GDI printer drivers. This is included with GSview.

EPSTOOL is a command line tool for adding and removing previews from EPS files.

Acknowledgements

L. Peter Deutsch, for writing Ghostscript and for making changes to Ghostscript to support GSview.

Tim Theisen, who wrote Ghostview for X11 which provided the inspiration for GSview.

Paul McJones and Andrew Birrell of DEC, for making pstotext available and making changes to it for use with GSview.

Thomas Pfeiffer and Mrs. Stefanie Kolweyh for translating GSview into German/Deutsch. Thomas Hoffmann for updates.

Cyrille Chevallet for translating GSview into French/Français.

Antonio Guadagnin for translating GSview into Italian/Italiano.

Pascual Lucas for translating GSview into Spanish/Español.

Stamos Mylonas for translating GSview into Greek/Ellenika.

Kris Steenhaut for translating GSview into Dutch/Nederlands.

Oleg Bondar for translating GSview into Russian.

Björn Söderström for translating GSview into Swedish/Svenska.

Juo Verut for translating GSview into Slovak.

End of Readme