This is a list of minor problems with the GNU plotting utilities `graph',
`plot', and `tek2plot', and with GNU libplot, the library which they are
built on.  We classify them as problems rather than bugs.

Most of them are due to idiosyncrasies of (or bugs in) the display devices
and applications that libplot must produce output for.

======================================================================

`graph -T X' and the libplot X driver
-------------------------------------

1. Old (pre-X11R6) X Window System servers do not support rotation,
non-uniform scaling, or shearing of fonts.

This problem is automatically worked around.  A default Hershey font
(HersheySerif) will be automatically substituted for any unavailable X
font.  So `graph -T X', and any other application that uses libplot's X
driver, may be used to drive such an older X display.

This problem may show up in `graph -T X' when you label a y-axis.  By
default, the y-axis label on a plot produced by `graph -T X' is rotated
ninety degrees.  You may turn this rotation off by using the
`--toggle-rotate-y-label' option, preventing the font substitution if any.

2. Applications that use libplot's X driver, such as `graph -T X', when
displaying output on Sun workstations running old versions of OpenWindows
(Sun's version of the X Window System), may not draw square roots very well.

For example, doing

	echo 0 0 1 1 2 0 | graph -T X -L '\sr\mk2\rt\rn is irrational!'

may produce a plot in which the square root in the title looks funny.  The
horizontal overbar in the square root may be displaced downward slightly.

This is not a bug in libplot; it is a bug in OpenWindows.  The OpenWindows
Symbol font (supplied in Sun's proprietary Folio format, and opaque to
investigation) contains two characters: a square root symbol, and a
matching overbar.  At least in OpenWindows version 3, their heights above
the baseline did not match as they should.

Some versions of OpenWindows may include bitmapped versions of the Symbol
font in which the horizontal overbar is displaced horizontally, as well as
vertically.  This makes the problem even worse.

The fix for the square root problem is to uninstall OpenWindows and replace
it with industry-standard X11; in particular, X11R6.

----------------------------------------------------------------------

`graph -T ps' and the libplot PS driver
---------------------------------------

1. There are a lot of buggy Postscript interpreters out there.  If you
switch fonts in the middle of drawing a label with `graph -T ps', or when
drawing a multi-font string with libplot's PS driver, and the sub-labels
don't match up properly when you view the result, it may very well be the
fault of your interpreter.  Even for the 35 standard Postscript fonts, some
vendors don't agree with Adobe as to the width of the printable `8-bit'
(non-ASCII) characters.  Sun SparcPrinters in particular have been observed
to space such characters incorrectly.

If you are using the freely distributable Ghostscript interpreter, it is
recommended that you use a version at least as recent as release 4.xx.
Earlier releases of Ghostscript are reported to have had similar problems.

2. It has been reported that the freeware `bbfig' program, which is widely
used for computing the bounding boxes of Postscript files, does not
necessarily compute the correct bounding box when it is applied to the
output of libplot's PS driver; for example, to a graph produced by 
`graph -T ps'.

The bug here is in bbfig, not in libplot.  You should never need to run
`bbfig' on Postscript files produced by this package, since they already
contain accurate bounding boxes.

3. As seen by the idraw drawing editor, a Postscript file produced by
`graph -T ps' or libplot's PS driver will have its colors quantized.  Both
pen color and fill color will be quantized.  

These quantizations are due to limitations of idraw.  Line widths will be
quantized too, since the width of a line in idraw must be an integer number
of printer's points.

No such quantizations will take place if the Postscript file is viewed with
a Postscript interpreter such as Ghostscript, sent to a printer, or
included in another document.

4. [Relevant only if configuration used the --enable-lj-fonts option.]
If you use `idraw' to edit a Postscript file prepared with `graph -T ps' or
libplot's PS driver that contains the Wingdings font, some of the Wingdings
characters will be incorrectly interchanged.

This problem is due to idraw, which does not know that Wingdings is not an
ISO-Latin-1 font.  The fix is to use a text editor to remove the line

	/Tidbits reencodeISO def

from the edited Postscript file.  (The plotting utilities refer to
Wingdings internally as `Tidbits'.)

----------------------------------------------------------------------

`graph -T fig' and libplot's xfig driver
----------------------------------------

1. There is a bug in release 3.1 of the xfig graphics editor (and earlier
versions), which is triggered by the output from `plotfont'.  If you do
something like `plotfont -T fig Helvetica > map.fig' to get a character map
of a font, and the backslash character of the font displays in xfig as
garbage, you should upgrade to release 3.2 as soon as possible.

2. There is another bug in release 3.1 of xfig (and earlier versions),
which may be triggered under some circumstances.  If a printable `8-bit'
(i.e. non-ascii) character in a label is immediately followed by a digit,
xfig may not display it correctly.  The fix, again, is to upgrade to xfig 3.2.

3. xfig supports rotation and uniform scaling of the 35 standard Postscript
fonts, but not non-uniform scaling or shearing.  So libplot's xfig driver
does not support them: it replaces anisotropically transformed Postscript
fonts by a default Hershey font (HersheySerif).  Hershey fonts may always
be anisotropically transformed.

This does not affect `graph -T fig', since it never uses anisotropically
transformed fonts.  However, if an application that uses libplot's xfig
driver calls the setup function space() or space2() so as to define a
user-frame drawing window that is not square, the affine map from the user
frame to the device frame will involve a non-uniform scaling, and possibly
even a shearing.  So in the device frame, any Postscript font will need to
be anamorphically transformed.

3. In libplot's xfig driver and in `graph -T fig', "dotdashed" lines
(obtained e.g. with the "-m 3" option to `graph') are supported in a
painful way.  xfig supports dotted lines (with user-specifiable inter-dot
gap) and dashed lines (with user-specifiable length for the on and off
segments).  So we can fully support the traditional libplot line modes
"solid", "dotted", "shortdashed", and "longdashed".  But xfig doesn't
support anything so exotic as "dotdashed" lines.  So we map them into
dotted lines with a large inter-dot gap, to distinguish them for
conventional dotted lines.

----------------------------------------------------------------------

`graph -T hpgl' and libplot's HP-GL/2 driver
--------------------------------------------

1. Internally, the LaserJet 4L and 5L use a different number for the
Wingdings font than other LaserJets.  (That is because they include an
Intellifont version of the font, rather than a TrueType version.)  So if
any HP-GL/2 output that uses the Wingdings font is sent to a 4L or a 5L
from `graph -Thpgl' or any other of the plotting utilities, it won't print
correctly.

If you need to work around this problem, you can search for the number
`31402' in the file libplot/g_fontdb.c, change it to `6826', and recompile.
HP-GL/2 output will then use the typeface ID that is appropriate for 
the 4L and 5L.

A less drastic remedy is to do a search-and-replace on the HP-GL/2 output
with a text editor, replacing each occurrence of the string "31402" by "6826".

2. `graph -T hpgl', `plot -T hpgl', and any other applications that use
libplot's HP-GL driver, by default produce HP-GL/2 output files that may be
imported into a wide variety of applications.  However, it is useful to be
able to print HP-GL/2 files directly on a PCL 5 or PCL 6 device such as a
LaserJet III, 4, 5, or 6.

If you have a PCL 5 or PCL 6 printer or plotter, and the file contains only
a single page of graphics, you may do this easily.  Precede the HP-GL/2
file by the four-byte escape sequence

		ESC % 0 B

which will switch the printer or plotter from PCL mode to HP-GL/2 mode, and
follow it by the four-byte escape sequence

		ESC % 0 A

which will switch it back to PCL mode.  Then send the file, as modified, to
your printer port.  The printer or plotter should accept it and print it.

If you have one of the above LaserJets, but it is equipped with the
Postscript personality and is functioning as a Postscript printer, the
above technique will not work.  Instead, follow the instructions in #3,
below.

There is a problem with using the above technique to print an HP-GL/2 file
that contains more than a single page of graphics.  It will not work
properly, since PCL 5 devices, when in HP-GL/2 mode, do not allow pages to
be ejected and new ones to be begun.

If necessary, this problem can be worked around with a text editor.  Simply
replace each "PG0;BP;IN;" command sequence in the multipage HP-GL/2 file,
which would normally eject the current page and initialize the next one, by
the nine-byte sequence

	ESC % 0 A FF ESC % 0 B

Then each page of graphics will be ejected as it should be.  (Here `FF'
means a form feed, i.e., control-L.)  As you can see, this sequence
switches the printer from HP-GL/2 mode to PCL mode and back.  Page ejection
within PCL mode, by a form feed, is allowed.

3. If you have a LaserJet 4, 5, or 6 that is functioning as a Postscript
printer, e.g., a LaserJet 4MP, 5MP, or 6MP, you can use it to print
single-page HP-GL/2 files.  The technique is a bit complicated, however.
The following explanation assumes that you are using a Unix-style `lpr'
program, and that the printing of jobs is controlled by a `lpd' daemon, the
configuration file for which is /etc/printcap.

Add to the entry for your printer in /etc/printcap a field like

	cf=/usr/local/lib/hpglf

where /usr/local/lib/hpglf will be a shell script that you will install.
This entry will make it possible to use the `lpr -c' command to 
print HP-GL/2 files on your Postscript LaserJet.  The `-c' option is
normally unused.

The /usr/local/lib/hpglf script should be the following.  As you can see,
it first sends a command to the printer that switches it to PCL mode.  The
command is in PJL, Printer Job Language.  Then the technique explained in
#2 above is used to switch the printer to HP-GL/2 mode and back.  Finally,
the printer is switched back to Postscript mode.

This technique will work on Postscript versions of the LaserJet 4, 5, and 6.
It will not work on LaserJet III's that are equipped with Postscript
cartridges, since their Postscript functionality cannot be turned off in
software (they do not support PJL).

#!/bin/sh

# This filter permits HP-GL/2 data to be printed on an HP LaserJet
# that is functioning as a Postscript printer.  It may be installed
# as the `c' filter in /etc/printcap, so that `lpr -c' will invoke it.

# switch LaserJet printer from PS to PCL mode
# (echo is assumed to support the -e option)
echo -e '\033%-12345X@PJL ENTER LANGUAGE=PCL'

# enter HP-GL/2 mode, begin functioning as a standalone plotter
echo -e '\033%-1B'

# take input from standard input, send to standard output
cat

# exit HP-GL/2 mode
echo -e '\033%0A'

# switch LaserJet printer from PCL mode to PS mode
echo -e '\033%-12345X@PJL ENTER LANGUAGE=POSTSCRIPT'

#EOF

----------------------------------------------------------------------

`graph -T tek' and libplot's Tektronix driver
---------------------------------------------

`graph -T tek' (along with libplot's Tektronix driver, which it uses) does
not support the filling of regions, so the -q option does not work; also,
multiplotting, which normally `blanks out' regions by filling them with
white, may result in messy-looking plots.  `graph -T tek' also does not
support the 35 standard Postscript fonts; the Hershey fonts must be used
instead.  (The default font is HersheySerif rather than Helvetica.)  The
fact that the ZapfDingbats font is not supported means that `graph -T tek'
does not support marker symbols greater than or equal to 32, or more
accurately it does not select them from the font (ZapfDingbats) that one
would expect.

Filling of regions is not supported because Tektronix storage tubes did not
support filling, for obvious reasons.  The Tektronix emulator in the DOS
version of kermit apparently supports a restricted sort of region filling,
but there are currently no plans to extend libplot to use it.

The 35 Postscript fonts could in principle be supported by libplot's
Tektronix driver, if Type 1 or TrueType rasterizer code were added to
libplot.  There are plans for this, though libplot at present includes no
bitmap driver.  It probably will, eventually.  But most people are
interested in using such a driver to produce bitmaps for the Web, not in
using it to draw Type 1 or TrueType fonts on Tek displays.  (The phrase
"bolting a V-8 onto a Model T" comes to mind.)

In `graph -T tek' the `--line-width' and `--frame-line-width' options also
do not work, since the Tektronix driver does not support lines with other
than a default width (it also does not support the setting of `cap mode'
and `join mode' for polylines).

A final comment. The xterm Tektronix emulator has a curious feature (bug?)
that no one seems to have commented on.  When any line of type other than
"solid" (i.e. "dotted", "dotdashed", "shortdashed", "longdashed") is drawn,
the pattern of illuminated and non-illuminated pixels along the line is the
opposite of what one would expect.  So "dotted" lines (obtained e.g. with
the "-m 2" option to graph) look more like dashed lines.  This bug, if
that's what it is, is easily fixed by changing the xterm source code.

======================================================================

Problems with thick lines drawn with libplot
--------------------------------------------

A `line segment' is conceptually a rectangle (usually rather thin).  But if
the affine map from user coordinates to device coordinates involves a
shear, each such rectangle is sheared into a parallelogram in the device
frame.  However, most display devices cannot treat line segments in this
way: their `lines', no matter how thick, are always drawn as rectangles.

X Windows does not support such sheared thick lines.  Nor do the xfig or
idraw drawing editors, or the HP-GL and HP-GL/2 languages.  However,
Postscript supports them.

As a consequence, libplot's PS driver is the only one of its drivers which
displays sheared thick lines correctly.  The problem is evident only for
unusually thick lines, of course.

======================================================================

Problems using libplot with libcurses
-------------------------------------

There is a name conflict between libplot and the `curses' library for
terminal-independent screen handling.  The two functions erase() and move()
occur in both libraries.

If you wish to link an application with both libraries, there is an easy
workaround.  As far as the curses library goes, `erase' and `move' are
macros.  They are defined in the header file <curses.h>.  So you should
include the following lines at the head of your source file(s):

	#include <stdio.h>
	#include <curses.h>
	#undef erase
	#undef move
	#define curses_erase() werase(stdscr)
	#define curses_move(y,x) wmove(stdscr,y,x)
	#include <plot.h>

Here the definitions of the macros curses_erase() and curses_move() should
be taken from your <curses.h> file; they may differ from the above.
<plot.h> is the usual header file for libplot.

In the body of your program, you would use curses_erase() and curses_move()
for the erase and move operations of the curses library, and erase() and
move() for the erase and move operations of libplot.

