File: PROBLEMS

package info (click to toggle)
plotutils 2.0-2
  • links: PTS
  • area: main
  • in suites: hamm
  • size: 5,964 kB
  • ctags: 2,522
  • sloc: ansic: 38,416; sh: 1,853; yacc: 856; makefile: 181; lex: 144
file content (249 lines) | stat: -rw-r--r-- 11,818 bytes parent folder | download
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
This is a list of minor problems with GNU `graph' and with GNU libplot, the
library which graph is built on.  We classify them as problems rather than
bugs.

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

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

graph-X and the libplot X driver
--------------------------------

1. 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 X Windows), 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 also 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.

2. Old (pre-X11R6) X servers do not support rotation, non-uniform scaling,
or shearing of fonts.  This problem is automatically worked around.  If
`graph -T X' or libplot's X driver is used to drive a display attached to
such a server, a default Hershey font will be automatically substituted for
any unavailable X font.

This problem shows up, e.g., when you attempt to label a y-axis.  By
default the y-axis label on a plot produced by `graph' is rotated ninety
degrees.  You may turn this rotation off by using the
--toggle-rotate-y-label option, preventing the font substitution.

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

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 libplot's
PS driver, and the two sub-labels don't match up properly when you view the
result, it may 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 estimating 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'.  But the problem turns out to be with bbfig, not with 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.

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

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

1. There is a 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 for this is to upgrade to release
3.2 of xfig.

2. The xfig graphics editor 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.

This does not affect graph -T fig, since it never produces such fonts (it
sets up an affine map from the user frame, in which it internally draws
graphics, to the device frame, which involves uniform rather than
non-uniform scaling).

However, if an application that uses libplot's xfig driver calls the setup
function space() or space2() so as to define a drawing window in the user
frame which 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.  In
such cases a default Hershey font will be substituted for the Postscript font.

3. Another problem with libplot's xfig driver and `graph -T fig' worth
mentioning is that "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.

3. If libplot's xfig driver or `graph -T fig' is used to draw a label
(i.e. a text string) that includes a printable non-ASCII (i.e. 8-bit)
character followed by a digit, the label may be drawn incorrectly when the
output file is displayed with xfig.  This is a bug in xfig 3.1; the fix is
to upgrade to xfig 3.2.

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

graph -T hpgl and libplot's HP-GL driver
----------------------------------------

`graph -T hpgl', and any other application that uses libplot's HP-GL
driver, produces an HP-GL/2 or HP-GL output file which may be imported into
a wide variety of applications.  It is useful to be able to print the file
directly, however.

If you have a PCL 5 or PCL 6 printer such as a LaserJet 6, 5, 4, or III,
you may do this very easily.  Precede the HP-GL/2 file by the four-byte
escape sequence
		ESC % 0 B

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

		ESC % 0 A

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

If your printer is one of the above LaserJets, but is equipped with the
Postscript personality and is functioning as a Postscript printer, you will
need to switch it from Postscript mode to PCL mode before following the
preceding instructions.

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

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 kermit Tektronix emulator
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 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
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 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).

The xterm Tektronix emulator has a curious feature (bug?), which 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 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 necessarily 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 only one of its drivers which
displays sheared thick lines correctly.  The problem is evident only for
unusually thick lines, of course.

GNU `graph' does not ask libplot to perform shearing transformations, so
the problem is visible only by calling, directly, the libplot non-PS
drivers.

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

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.