PGPLOT Frequently Asked Questions

  1. Problems with subscripts, superscripts, and Greek letters
  2. Color Map Problems (X-Window)
  3. Encapsulated PostScript
  4. Changing the Background Color
  5. License requirements for GIF
  6. Solaris can't find libpgplot.so
  7. Why doesn't PGPLOT redraw the plot when the window size is changed?
  8. Will PGPLOT ever do three-dimensional graphics?
  9. Will PGPLOT be rewritten to use Fortran-90 constructions?
  10. Does PGPLOT have a Y2K problem?
  11. My compiler complains about use of %VAL in some drivers
  12. Can PGPLOT be used in a Web-based CGI application?
  13. How do I compile PGPLOT for Linux using the Absoft Fortran compiler?
  14. Is there a double precision version of PGPLOT?
  15. My publisher has requested that I provide my PostScript color image in CMYK rather than RGB format. Can I do that with PGPLOT?

Problems with subscripts, superscripts, and Greek letters

I am trying to use escape sequences for subscripts and superscripts and greek letters, however the output is as follows:

      call pglab('h/D','\ge\ur\d','TE\u011\d') 

The y-axis label turns out to be 'geurd', and similar results occur for the title.

Many UNIX Fortran compilers treat a backslash (\) in a literal Fortran string as a UNIX escape character, converting '\n' to the code for new-line, for example. If you have one of these compilers, and if you want to use '\' as a PGPLOT escape character, you must do either one or other of the following (but not both):

  1. Double all backslashes in literal strings in your code (e.g., change '\ge\ur\d' to '\\ge\\ur\\d'); the compiler will translate '\\' to '\'.
  2. Enable the compiler option that suppresses this behavior. Most UNIX compilers have such an option, but it isn't always well documented. Some possibilities for various compilers are:
     
            -assume backslash
            -backslash
            -qnoescape
            -xl                     (Solaris f77)
            -!bs                    (f2c)
            -fno-backslash          (g77)
    
    If you can't find the option, or can't make it work, consult your compiler supplier.
  3. An ingenious way to write a program that will work with most compilers is the following: define
          CHARACTER BACKSL
          PARAMETER (BACKSL = '\\')
    
    and then use concatenation, e.g.
          call pglab('h/D', BACKSL//'ge'//BACKSL//'ur'//BACKSL//'d',
                     'TE'//BACKSL//'u011'//BACKSL//'d') 
    
    This rapidly leads to unreadable code.

Color Map Problems (X-Window)

I am seeing an unusual situation when running PGPLOT (using the X-Window device) when a previous executable is using up a lot of the available colors. I am running Netscape and PGPLOT on an ncd 19c (color). when Netscape starts first, it grabs alot of the colors so when i do a pgbegin from my application (or run one of the supplied pgdemo programs) the entire terminal screen is blacked out and then the PGPLOT window appears. in fact when i do a pgbegin from my application and before calling any other PGPLOT routine, the entire termianl screen is blacked out and i can only get my windows to appear again by clicking with the mouse over the area where i know a terminal exists. then everything appears as normal and the nnormal PGPLOT window appears. have you seen this problem before?

Colors are a limited resource on X displays: most are 8-bit devices that can display only 256 different colors simultaneously. Different client programs have to divide the available colors between them. If no colors are available for a new window, it either has to make do by sharing colors that are already in use by other windows (in which case it shouldn't change them), or it has to allocate a ``private color map'' which will display the correct colors, but only while the cursor is in that window: colors of other windows will be incorrect. The problem is much less severe for 24-bit displays which have many more colors available.

Netscape is particularly bad: it appears to grab all the available colors, forcing PGPLOT to use a private color map, which produces the result you see. You can tell Netscape to use less colors (see its documentation, under Help:Frequently Asked Questions:Netscape Navigator for X: item 14). Or you can open the PGPLOT window before the Netscape window: this forces Netscape to use less colors (create an /XSERVE window and keep it around for your PGPLOT programs). You can also tell PGPLOT to allocate less colors for each window (using X resources: see xwdriv), which may reduce conflicts with other applications, but not with greedy ones like Netscape.

PGPLOT initializes its color map to all black until you start plotting in the window. This exacerbates the problem, and we will try to improve this in a future version.


Encapsulated PostScript

What is the difference between a file produced by PGPLOT using /ps and an encapsulated PostScript file, or is there none?

A PostScript (ps) file produced by PGPLOT is a valid encapsulated PostScript file, except for the following:

  1. It must be a single page. Multi-page plots are not valid EPS.
  2. The ``BoundingBox'' comment is at the end of the file, not the beginning. [The reason for this is that PGPLOT doesn't know what the bounding-box will be until it has finished creating the file.] If the program that is trying to read the file complains, you can move this comment from the end of the file to the beginning. It is simplest to use the UNIX script ``pscaps'' in the PGPLOT directory:
        pscaps yourfile.ps
    
    This modifies the file(s) in place.
  3. Some EPS files include a ``screen-preview'' section to allow them to be displayed by programs that cannot interpret PostScript. The format of this is machine-dependent (different for Macintosh and DOS, for example). PGPLOT does not write a screen-preview section.

All PGPLOT PostScript files, both single-page and multi-page, are labelled at the beginning %!PS-Adobe-3.0 EPSF-3.0 Some programs, including GhostView for Windows, apparently have problems if a multi-page file has an EPSF header. If necessary, change the first line of the PostScript file to read %!PS-Adobe-3.0. Some users have reported that the CUPS printing system on Linux prints all pages superimposed on a single page unless this change is made. This sounds like a bug in CUPS, or in the configuration files. Other versions of CUPS, e.g., in MacOS X, do not have this problem.

For more information about PGPLOT PS files, see the manual.


Changing the Background Color

I am using PGPLOT to plot stuff on an X-Window machine. The color scheme by default is white on a black background. I was able to change the color of the image using PGSCI, but how does on control the color of the background?

The background is color index 0. You can change what color it is by using PGSCR or PGSCRN.

You can also change background and foreground (color indices 0 and 1) with environment variables at run time, e.g., to draw in black on white instead of white on black:

    setenv PGPLOT_BACKGROUND white
    setenv PGPLOT_BACKGROUND black
although a call to PGSCR or PGSCRN in the program will override these.

License requirements for GIF

The drivers.list file indicates that using the GIF driver may require a license from Unisys. Do you have any further information on the licensing requirements?

I cannot give you an authoritative statement on this. The furore seems to have died down a bit, but I believe that Unisys still requires a license, certainly for commercial use. See, for example,

http://www.unisys.com/LeadStory/lzwfaq.html
You can find much more about this by searching for, say, "unisys", "gif", and "compuserve".

At least one new graphics format to replace GIF is under development: PNG (Portable Network Graphics), but I don't intend to add this to PGPLOT until it is clear that it is going to be widely adopted. See, e.g.,

http://www.wco.com/~png/
http://www.group42.com/png.htm

Solaris can't find libpgplot.so

When I run pgdemo*, for example pgdemo1, I get the error-message
ld.so.1: pgdemo1: fatal: libpgplot.so: can't open file: errno=2 Killed
What could be the reason? libpgplot.a is seen by the program.

This is a ``feature'' of shared libraries under Solaris 2.x.

Under Solaris, as with most UNIX systems, you link a program with PGPLOT with a command like the following:

f77 -o example example.f -L/usr/local/pgplot -lpgplot
The -L option tells the linker where to look for the library. Unfortunately, this information is not recorded in the executable file, and the run-time shared library loader thus doesn't know where to find the PGPLOT library. There are a number of solutions to this problem:
  1. Link the program statically:
    f77 -o example example.f -L/usr/local/pgplot -Bstatic -lpgplot \
        -Bdynamic -lX11
    
    This will result in a big executable (and you also have to specify the -LX11 option to include the X11 library).
  2. Add the directory of the PGPLOT library to the list of directories in your LD_LIBRARY_PATH environment variable, e.g.,
    setenv LD_LIBRARY_PATH /usr/local/pgplot:/usr/openwin/lib:/usr/dt/lib
    f77 -o example example.f -lpgplot
    
    The LD_LIBRARY_PATH variable is read both by the compile-time linker and the run-time linker so you no longer have to use -L. The only disadvantage of this method is that if somebody else wants to use your program they will also have to modify their LD_LIBRARY_PATH before running it.
  3. Place the directory of the PGPLOT library in your LD_RUN_PATH environment variable.
    setenv LD_RUN_PATH /usr/local/pgplot
    f77 -o example example.f -L/usr/local/pgplot -lpgplot
    
    The contents of the LD_RUN_PATH variable are recorded in the executable and thereafter used as the path to search for shared libraries. In this case you still have to use -L or set your LD_LIBRARY_PATH appropriately to tell the linker where to find the library at link time, but thereafter anybody will be able to run the program without modifying their LD_LIBRARY_PATH or LD_RUN_PATH variables.
  4. Use the -R switch of f77 in place of setting LD_RUN_PATH. This can be more problematic because f77 quietly appends the path of its run-time libraries to the LD_RUN_PATH variable, and this is ignored when -R is used. As a result you have to remember to specify the directory of the f77 libraries (usually /opt/SUNWspro/lib):
    f77 -o example example.f -R/usr/local/pgplot:/opt/SUNWspro/lib \
        -L/usr/local/pgplot -lpgplot -lX11
    
[Thanks to Martin Shepherd.]

Why doesn't PGPLOT redraw the plot when the window size is changed?

PGPLOT cannot automatically redraw the plot at a new scale when the window size is changed. If you use the PGPLOT X-window driver (device /XSERV or /XWIN), PGPLOT, in concert with the X-server, maintains an off-screen pixmap (a pixel-by-pixel copy of the screen picture) which is used to redraw the picture when it is de-iconized, uncovered, resized, etc. However the pixmap cannot be rescaled. PGPLOT does not keep a record of the elements comprising the plot (vectors, polygons, etc.) which could be used to redraw the plot at a new scale; such a record could potentially require a very large amount of memory and slow down the PGPLOT process. If you want your application to redraw the plot, you should call PGPAGE and re-issue the subroutine calls required to draw the plot. If you do not have to recalculate your data this should be quite quick. If the window has been resized, PGPLOT becomes aware of the new size when PGPAGE is called. There is one problem though: how does your application tell that the window has been resized and that the plot must be redrawn? This is an "asynchronous event" (it could happen at any time during the execution of your program) and it is difficult for a standard Fortran program, with a single thread of execution, to respond to such an event, and it is also difficult to get access to the X-events from the program.

Will PGPLOT ever do three-dimensional graphics?

No. A comprehensive 3D capability (including projection, hidden-line and hidden-surface removal, and lighting) is beyond the scope of PGPLOT. Some of the PGPLOT demonstration programs do rudimentary 3D graphics, but they take care of projection and hidden-line removal themselves, and pass only 2D data to PGPLOT. For 3D graphics a number of packages are available, such as OpenGL and PHIGS.

Will PGPLOT be rewritten to use Fortran-90 constructions?

I do not plan to rewrite PGPLOT in Fortran-90. I do not think that Fortran-90 has yet taken over from Fortran-77 (e.g., there are no free compilers), and I do not have the resources to maintain two versions.

You should be able to call PGPLOT routines from f90 with no problem. I recommend that you compile PGPLOT with an f77 compiler, and link it into your f90 program. I would hope that your f90 compiler can handle the argument passing conventions of f77, but this may depend on which compilers you use. Alternatively, you can compile PGPLOT with the f90 compiler, but you will be unable to use some of the drivers which use non-standard extensions to Fortran-77. I intend to address this by rewriting these drivers in C rather than Fortran-90.


Does PGPLOT have a Y2K problem?

I am checking our software for Year2000 compliancy and was wondering if I should be concerned about any functions in pgplot.

No, you should not be concerned. The only routine in PGPLOT that does anything with dates is PGQINF, which can return the current date, obtained from the operating system, to the caller. It uses a 4-digit year. There should be no Y2K problem unless the underlying operating system has a problem. No Y2K problems with PGPLOT have been reported.


My compiler complains about use of %VAL in some drivers

My Fortran-77 compiler doesn't understand the syntax %VAL() that is used in some of the PGPLOT device drivers. What should I do?

Unfortunately some of the PGPLOT device drivers require dynamically-allocated memory and cannot be written using standard Fortran-77; in these cases the drivers are written either in C or in non-standard Fortran. If your compiler does not understand the %val() extension (used for passing an argument by value instead of address, and used in PGPLOT to pass a dynamically-allocated array to a subroutine), you will be unable to use these drivers unless you rewrite them. There are standard mechanisms in both C and Fortran-90 for handling dynamically-allocated memory, and I may in a future version replace these drivers with C or Fortran-90 versions.


Can PGPLOT be used in a Web-based CGI application?

Yes! Several people have used PGPLOT in a Web CGI application to generate plots in GIF format on-the-fly. In most UNIX systems, the CGI script is required to send the plot to standard output; in PGPLOT, use a device specification "-/GIF" in PGOPEN or PGBEG. Alternatively, the script may create a temporary named GIF file and return HTML code for a Web page that includes the GIF file using an IMG tag. If the Web server is a Windows system, it may be a little more complicated. Bernhard Rupp has put some hints for using a Fortran PGPLOT program in a CGI script on his web page: http://www-structure.llnl.gov/Xray/comp/gif_prog.htm.

How do I compile PGPLOT for Linux using the Absoft Fortran compiler?

The following information is from Absoft support (support@absoft.absoft.com). It will be included in PGPLOT 5.2.1.

We've had source modifications for using PGPLOT with our Fortran compilers on Linux available on our ftp site for some time now. We provide three different configuration files (fold to upper, fold to lower, and fold to lower/append an underscore) so that the end user can choose the name space that fits his/her project. We also include an absoft_src directory under sys_linux that contains the necessary source mods to build the library. The installation procedure is

  1. tar -xzvf pgplot5.2.tar.gz
  2. cd pgplot
  3. tar -xzvf pgplot_absoft50_linux.tar.gz
  4. makemake [where]/pgplot linux absoftucs_gcc (or absoftg77_gcc or absoftlcs_gcc).

You can download our modifications from:

ftp://ftp.absoft.com/pub/linux/profortran5.0/pgplot_absoft50_linux.tar.gz

Is there a double precision version of PGPLOT?

PGPLOT is only available in single precision (Fortran REAL). All floating-point arguments passed to PGPLOT routines should be of type REAL, not DOUBLE PRECISION or REAL*8, for example. Higher precision is not needed internally by PGPLOT, given the limited resolution of most graphics devices.

If the data that you wish to plot are DOUBLE PRECISION quantities, you need to convert them to REAL before passing them to PGPLOT. If this is very inconvenient, you can in principle compile PGPLOT in double precision (some Fortran compilers have an option to do this), but you also need to change the C support routines, so I do not recommend this.

The above remarks apply to Fortran: for C, arguments should be float, not double. In some cases the function prototypes will direct the C compiler to automatically convert double to float for you, but this does not happen with array arguments.

I may in future distribute two versions of the library for REAL and DOUBLE PRECISION; if I do, the double precision routines would have different names.


My publisher has requested that I provide my PostScript color image in CMYK rather than RGB format. Can I do that with PGPLOT?

PGPLOT uses the "device RGB" color model in PostScript files. All PostScript interpreters should convert RGB to CMYK when the output device requires it, so there is no real need for a CMYK option in PGPLOT. Some publishers prefer CMYK because they believe that it gives better color fidelity. However, consistency of color is difficult to achieve using either RGB or CMYK because different devices use different methods to represent color, and different devices produce different ranges of colors. You will see differences, e.g., between a printout and an on-screen display of a PGPLOT PostScript file. If color fidelity is important, I recommend that you import the PGPLOT file into a graphics application such as Adobe Photoshop on a PC or Macintosh with color management software (modern versions of Windows and MacOS are good about this, but Unix is not). After adjusting the colors to your liking, save the file in PDF or PS format from that program, using any options recommended by your publisher.


PGPLOT
Tim Pearson, California Institute of Technology, tjp·astro.caltech.edu
Copyright © 1996-1999 California Institute of Technology