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.