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
|
Areas currently under development
---------------------------------
- Need developers! It is becoming too difficult to support PLplot on all
the many platforms it runs on. If you want it to run correctly on your
platform it needs your support. Current system supporters include:
Maurice LeBrun HP-UX, Super-UX
mjl@dino.ph.utexas.edu
Geoff Furnish Linux
furnish@dino.ph.utexas.edu
Paul Casteels DOS/BGI (bcc)
casteels@uia.ac.be
John C. Peterson OS/2
jcp@trg.saic.com
Paul Kirschner DOS/DJGPP
pek@logos.res.utc.com
Hiromi Kimura VMS port
hiromi@tac.tsukuba.ac.jp
This is not to say that other platforms are unsupported, as often we do
work on other platforms, and will fix whatever problems we encounter.
But there is no guarantee PLplot will work without problems on such
systems either. The systems we really need help to support (in order
of most urgent need) include:
Irix
Ultrix
SunOS 5.x
(any other *ix not mentioned)
Macintosh
Amiga
Unicos
AIX
SunOS 4.x
- Continue updating the manual.
- improve color dialogs for TK driver:
. inform client side that colors have been changed (right now only
plserver side knows about it)
. put in a better file selector for palette files
. rewrite palette tools in itcl
. add a way to pick direction in hue to use when interpolating between
colors
- Add an initialization file capability. This would be very nice from a
customization standpoint, and inevitably I will want to add it before
long. But it has some problems. For example, when does it get read?
If when you call plinit(), it may overwrite previous variables set by
the API or command-line. This is a thorny problem. A secondary issue
is deciding what libraries it should depend on. Using libX11 makes it
easier for color support, and Tcl for parsing, but with a bit extra
effort, I could support non-Unix systems too.
The real problem is that plplot has no command to "open the library".
I am VERY tempted to require a call to plopen() as the FIRST plplot
library call, just so that it could be absolutely sure it was the
first. Then, it could read the startup file. You could do this with
the Tk plframe widget because it must be created before you can send
commands to it, and the command to read the init file could be buried
in there. But it would probably be a bad idea to have one output
driver read an init file and another one ignore it, since most people
(myself included) rely on output from one driver to the next to be
basically the same, contingent on driver capabilities that is. So this
capability really needs to go into the core.
- 3-D plots should be clipped at the 3-D box boundary. Right now the 3-d
data is immediately transformed to 2-d lines on the projection plane.
No intermediate clipping is performed, meaning that only the 2-d
projected part is clipped.
- fix 2d function plotter API's: Most general function in each
category should accept transformer function and transformer data, to work
with arbitrary data layouts, but there should also be FE's for the
"usual data types". Work to be done:
- add contour plotter FE's
- add condition code array handler to plshade
(upgrade plAlloc.. to handle char variables?)
- fix API for surface plotter
- vector field plotter?
- better document the 2d function plotter API in plfcont, etc.
- File familying is iffy and needs a full check out.
- Write plcfill() or whatever to cheaply fill 2d functions based on cell
value only. Should be much faster than plshade for many grid points
(e.g. 128 x 128). The other option is raster, see below.
- The color map selection in the versaterm driver still doesn't work
quite right. When running x16c, the following happens:
o color 9 isn't set correctly. This doesn't make sense -- how
can the driver be messing up just for this one? Besides, it
works fine on my Amiga's tek4107 driver. Sounds like a bug
in versaterm. Need to check this code out on other Tek4107
emulators, like mskermit.
o There is sometimes some garbage at the beginning of the fill.
- implement some sort of raster-oriented output. GIF might be good since
it runs on lots of machines (originated with PC's but now supported
under Unix and Amiga). Any PD code for writing it from Unix?
- support command line arg reading from Fortran under whatever important
OS's support it. One trouble here is that it may require an additional
oddball library to be linked in, and I'm not thrilled about that.
- fix additional problems with custom color map support under X:
. Add command line switch to enable it, maybe switches to for all the
preprocessor constants in xwin.c controlling cmap allocation.
. When a custom colormap is used, it becomes the new top level TK
colormap, since the palette modification tools need to be using the
same colormap in order for the colors to come out the same. But
there is a minimum of color changing when the colormaps are swapped
(i.e. focus goes into or out of the plplot/TK application) because
the xwin driver copies as many colors out of the default as is
reasonable. Cases where this still isn't quite good enough include
the text widgets (such as help windows), for which the color is not
preallocated, and sometimes the TK menu bar, for which I think the
color is preallocated but exactly matches one already in use by the
window manager and thus does not get copied. Some strategies in
fixing this include: (a) providing a list of colors for the xwin
driver to copy and allocate and (b) do not install the xwin colormap
in the main window and instead share the colormap with windows that
want it through a plframe extension. Right now because of continued
uncertainties the custom colormap option in xwin.c is disabled.
- metafile produced on the Amiga isn't quite right! Compiler bug?
- How can I modify the surface plotter to do color overlays?
- Write Fortran counterparts to x14c and x15c?
- check out shared library support under SAS/C on the Amiga -- supposed to
be easy (6.0 and later)
- Split off Tcl-DP stuff from Tk stuff better, get it working with DP-lite.
- put pen width option in TK driver
- const'ify plplot API where appropriate.
- fix bugs in Amiga print driver.
- mouse dragging in TK driver text window should cause a scroll.
- get plplot up under gcc on the Amiga?
- fix problems with hidden line removal on "spiky" 3D plots on high
resolution (300 dpi or greater) devices. There are little gaps that
sometimes appear after a line reappears from behind a surface. In
Mathematica, hidden line removal is done by the device driver (which
receives PostScript) instead of beforehand. (There is a section in the
Mathematica manual where they mention hidden-line removal as an inherently
device dependent problem.)
Things planned for sometime in the future.
----------------------------------------------
- CGM driver. Shouldn't be too hard, just haven't gotten around to it
yet. Any volunteers? Should I assume the presence of a CGM library?
Or should I carry my own routines to do low-level operations to the CGM
file? (Here I could borrow from a freely distributable package that
deals with CGM files).
- graphical entities to be "objectized", so they are easier to manipulate
from plrender. Likely candidates: plot, string, character, tick, axis,
line, etc. But high performance must not be sacrificed.
- Better use of driver intelligence, esp. for text -- the postscript driver
should be capable of using postscript fonts instead of the Hershey fonts.
- Cloned streams, for plotting to multiple devices simultaneously.
- Fully document the plplot-driver interface.
- Japanese plplot/TK extensions?
- Japanese font extensions?
BUGS
----
The following are known bugs or failings of PLplot, that are unlikely to
be fixed any time soon if at all.
- ps output files do not work with up(1).
- The contour plotter has a bug that causes it to occasionally fail for
some data sets. One known example is if there is no x-dependence.
If you experience problems with other data try to work up a demo and
send it to me and then maybe I can track down the problem. There has
been some talk about replacing the contourer with a better algorithm.
Volunteers needed.
|
