Output formats

In the first version of MolScript there was only the PostScript output format. With the introduction of several other output formats, first with Raster3D in v1.4, and now with VRML 2.0 and OpenGL (and the image file formats based on OpenGL), there is now an issue of how to make output in different modes as similar as possible when the same input file is used.

The goal is obviously to make the output as similar as possible in different output modes. However, completely identical output is difficult to obtain. There are cases when the implementation of a particular command or state parameter is too difficult or would be very inefficient for a particular output format.

Sometimes a particular output format has special features which are quite useful. These features may be used by MolScript, even if there is no counterpart in the other output formats. One such example is the anchor command which is meaningful only in the VRML 2.0 output format.

PostScript file

The PostScript output mode was the original output mode for MolScript. Much effort has gone into keeping the output for PostScript mode identical in appearance (but not necessarily in implementation) for this version compared with the previous versions.

The hidden-surface algorithm in the PostScript mode relies on the graphical segments being sufficiently small. The introduction of some new commands, e.g. cylinder and object, have necessitated the addition of the segmentsize parameter which controls the subdivision of certain graphical segments. Another addition is the labelbackground parameter which is useful for labels in cluttered regions of the image.

Transparency and explicit light sources have not been implemented for PostScript in the current version of MolScript.

In previous versions of MolScript (v1.4 and older), the Encapsulated PostScript (EPS) format was exactly identical to the PostScript output, apart from a few lines of output code. However, this caused considerable confusion, since much software (desktop publishing and other office applications) apparently seems to assume the existence of a pixmap in an EPS file. In this version of MolScript, the EPS implementation is completely new and has now been decoupled from the PostScript implementation. This is a major departure from the policy of backwards compatibility, but since the EPS format in v1.4 (and older) was such a fiasco something had to be done.

Raster3D input file

MolScript can generate an input file for the Raster3D package written by Ethan A. Merritt and others. The Raster3D package is a freely available ray-tracing program optimized for 3D molecular models. If you publish images made with MolScript and Raster3D, be sure to cite both programs (Merritt & Murphy, 1994).

MolScript produces an input file for the render program, which produces an image file in either SGI (aka RGB) format, or TIFF format, depending on how you compiled the Raster3D package. Version 2.4b (or later) of Raster3D is required for use with MolScript v2.1. It is now also possible to compile a version of render which produces JPEG image files directly.

It is now possible to output labels to the Raster3D file, provided that you have compiled MolScript with the GLUT library.

MolScript now allows a larger degree of control over the values written to the header section of the Raster3D input file, mainly through the command-line options. This includes the size of the image (in pixels), the aliasing scheme and the background colour.

However, it is still possible to use a manually edited header section, by having a file called header.r3d present in the directory where MolScript is executed. The content of this file must be valid for the render program of Raster3D; MolScript does not check the contents. If the file is present, MolScript will use it instead of generating the header itself.

Note: The header file feature was kept just for backwards compatibility, and may be removed in future versions. It is badly designed.

The control of the light source features is incomplete for the Raster3D format. This is largely due to the differences in the Raster3D lighting model compared to some other systems.

Warning: There may be changes in the implementation of the lighting parameters for the Raster3D output mode in future versions of MolScript.

VRML 2.0 file

VRML 2.0 (Virtual Reality Modeling Language) is a file format for specifying 3D objects with geometry, appearance, Web links and behaviours. The files are intended for transmission over the Internet in a fashion similar to HTML files. VRML 2.0 is specified in an international standard (where it has been officially renamed "VRML 97") and is described in Hartman & Wernecke 1996 and Carey & Bell 1997. A VRML file (or world) is viewed in a browser, which most often is a so-called plug-in for an ordinary Web browser (such as Netscape or Microsoft's Internet Explorer), and which can usually be obtained from some web site. The ability to use Web links and behaviours in VRML opens the avenue for creating content-rich and informative 3D models of molecules, especially such complex entities as proteins.

The current version of MolScript contains support for the output of all graphical objects and also Web links (anchors). Experimental implementations of features to support dynamical behaviour in VRML have been made, and some are actually present in the current version. However, since these features are just experimental it is highly likely that they will change in design and implementation, and it was therefore decided to let these features remain undocumented, so as to avoid future confusion in the user community.

Interactive OpenGL

The OpenGL graphics mode allows interactive rotation and scaling of the displayed objects, and has features that simplify the creation and fine-tuning of complex input files. The graphical objects created in this implementation utilise the features in the OpenGL API (Neider et al 1993) for high-quality rendering.

The GLUT library is used for the interaction between OpenGL and the computer windowing system. The copyright notice for the GLUT library is given here.

The number of bits used for the various image buffers is output as a diagnostic message. These values are the maximum available on the system that is used.

The mouse buttons have different functions depending on whether the Shift key is pressed down when the mouse button is clicked:

Mouse button No key pressed Shift key pressed
left rotate scale (up-down)
middle pick atom change slab
right menu choice menu choice

The menu choices available through the right mouse button are activated by holding down the button, moving the mouse over the menu option so that it becomes highlighted, and then releasing the button. The available menu items are:

menu item action
Full screen The window is enlarged to fill the entire screen, its borders are removed, and it is stacked on top of all other windows. The exact action depends on the window system of your computer. The menu option is changed to "Normal window" (see below).
Normal window The window is reduced back to the its original size, with normal borders. The menu option is changed back to "Full screen" (see above).
Output view Output to the stderr (standard error) the current values for the window and slab parameters, and the transformation matrix to be used in a transform command applied to all atoms to give the current view of the molecule. This feature allows the user to find a good view in an interactive fashion. The output text can be cut-and-pasted into the input file.
Reset view Reset the view parameters (see above) to the original values before the interactive changes made by the user.
Re-read input file Read the input file again, as if the program had been started from scratch. This allows the user to modify the input file using a text editor, and then quickly view the effect of the changes. If an error is encountered the input file, then interpretation stops, but the graphics objects rendered so far should be visible. This item will appear only if the command-line option -in has been used.
Quit Quit the current session. The keyboard Esc key can also be used to quit the the current session.

Image files (based on OpenGL)

The image file output mode depends entirely on the OpenGL implementation. If your computer system does not allow an installation using the OpenGL implementation, then none of the image file output formats will be available. Also, the current version relies on the X window system extension GLX for OpenGL, which implies that a UNIX system is required.

The image is created via the OpenGL rendering system in exactly the same way as the interactive OpenGL mode, except that the image is rendered to a pixmap in memory instead of a window on the display. The pixmap is read off and written to a file having the requested format. The rendering is exactly identical for all image file formats.

The number of bits used for the various image buffers is output as a diagnostic message. These values are the maximum available on the system, and may differ from those used by the interactive OpenGL mode.

Note that if the image file format includes compression of some kind (JPEG, GIF, optionally PNG), it no longer is identical to the OpenGL image, just a resonable approximation of it.

SGI (aka RGB)

The SGI image file format, also know as RGB format, is a loss-less run-length-encoded format for 2D images. It is very well suited for MolScript images.

The SGI image format is in principle specific to SGI IRIX machines, but it is used in some software on other systems as well.

The implementation in MolScript relies on no third-party software, only on a package that is part of the MolScript distribution. This package is based on the published specification of the SGI image file format.

Encapsulated PostScript (EPS)

The Encapsulated PostScript (EPS) format in MolScript v2.0 is a pixmap encoding of the image rendered by the OpenGL implementation. It can be included in PostScript documents by many kinds of office and desktop-publishing software.

Note that this EPS implementation is quite different from that in the previous versions of MolScript (v1.4 and older). This is a proper pixmap encoding, while the previous versions were basically just ordinary PostScript files with a few small differences.


The JPEG format is a compressed, lossy image file format in widespread use on the Web. It is a generally accepted, machine-independent standard.

Unfortunately, JPEG was designed mainly with real-world pictures in mind, so the compression algorithm used is not optimal for the images rendered by MolScript. The main problem arises for large surfaces with homogenous colours. These may look blotchy, particularly if a low quality parameter is used.

The implementation relies on the publicly available JPEG library. The copyright notice for the JPEG library is given here.


The PNG format is a format that may be either compressed or not, and the compression may be loss-less. It is very well suited for MolScript images.

The PNG image format is intended as a replacement for both the patent-afflicted GIF format and the JPEG format. New Web browsers are supposed to support PNG. The VRML 2.0 specification requires support for PNG images.

The implementation relies on the publicly available PNG and zlib libraries. The copyright notice for the PNG library is given here, and for the zlib library here.


The GIF image file format is very common on the Web. It is a compressed format using a colour map restricted to a maximum of only 256 entries, so it is not very well suited for MolScript images. The current implementation in MolScript uses a so-called error diffusion algorithm (Foley et al, 1990) to minimize the visual artifacts.

The implementation relies on the publicly available gd 1.3 library for creation of the GIF files. The copyright notice for the gd 1.3 library is given here.

The GIF format usually uses LZW compression, which is patented by Unisys. This creates a legal problem for commercial software. The current implementation uses version 1.3 of the gd library, which does not use LZW compression, thus avoiding the patent issue. Unfortunately, the run-length encoding it uses instead is less efficient, so the GIF files produced by MolScript are much bigger (by about a factor of 2.5) than they ought to be.

Top page