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