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):
-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.
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.
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.
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:
pscaps yourfile.psThis modifies the file(s) in place.
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
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.
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 blackalthough a call to PGSCR or PGSCRN in the program will override these.
drivers.listfile 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.htmlYou 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.,
ld.so.1: pgdemo1: fatal: libpgplot.so: can't open file: errno=2 Killed
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 -lpgplotThe -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:
f77 -o example example.f -L/usr/local/pgplot -Bstatic -lpgplot \ -Bdynamic -lX11This will result in a big executable (and you also have to specify the -LX11 option to include the X11 library).
setenv LD_LIBRARY_PATH /usr/local/pgplot:/usr/openwin/lib:/usr/dt/lib f77 -o example example.f -lpgplotThe 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.
setenv LD_RUN_PATH /usr/local/pgplot f77 -o example example.f -L/usr/local/pgplot -lpgplotThe 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.
f77 -o example example.f -R/usr/local/pgplot:/opt/SUNWspro/lib \ -L/usr/local/pgplot -lpgplot -lX11
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.
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.
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.
The following information is from Absoft support (email@example.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
You can download our modifications from:
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.
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.