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 pcl' and libplot's PCL 5 driver
--------------------------------------------

1. There are some small errors in the positioning of text strings when
producing PCL 5 output that uses the Symbol font.  For example, if you do
`plotfont -Tpcl --box Symbol > symbol.pcl' to get a PCL 5 file that is a
character map of the Symbol font, you will notice that in the character
map, some of the characters do not quite line up with their boxes.

This problem is due to problems in HP's documentation.  HP has released
useful information on its 45 PCL 5 fonts (i.e., "LaserJet fonts"),
including Symbol.  (This includes font metrics, etc.; see ./INSTALL.fonts.)
However, their information on the Symbol font appears to be incorrect.  As
a consequence, horizontal positioning of text strings in the Symbol font is
slightly in error.  This problem does not affect the other 44 PCL 5 fonts.

`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. There are some small errors in the positioning of text strings when
producing HP-GL/2 output that uses the Symbol font.  For example, if you do
`plotfont -Thpgl --box Symbol > symbol.plt' to get an HP-GL/2 file that is
a character map of the Symbol font, you will notice that in the character
map, some of the characters do not quite line up with their boxes.

This problem is due to problems in HP's documentation.  HP has released
useful information on its 45 LaserJet fonts, including Symbol.  (This
includes font metrics, etc.; see ./INSTALL.fonts.)  However, their
information on the Symbol font appears to be incorrect.  As a consequence,
horizontal positioning of text strings in the Symbol font is slightly in
error.  This problem does not affect the other 44 LaserJet fonts.

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

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

