ARM Club 3/TheARMClub_PDCD3.iso/hensa/maths/plplot/plplot_2/ToDo

Text File | 1994-09-05 | 9KB | 218 lines

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
    [e-mail]

    Geoff Furnish            Linux
    [e-mail]

    Paul Casteels            DOS/BGI (bcc)
    [e-mail]

    John C. Peterson        OS/2
    [e-mail]

    Paul Kirschner            DOS/DJGPP
    [e-mail]

    Mark Olesen            DOS/EMX
    [e-mail]

   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)
    Amiga
    Unicos
    AIX
    SunOS 4.x

    (also VMS, if anyone ever gets the package working there again)
    (also Macintosh -- there is a very old port for it around somewhere)

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

 - Various color drivers should be upgraded to work similar to the tek
   driver, with support for setting the color palette from the user
   program (API) as well as cmap1.  I (Maurice) will probably only be
   supporting the tek, X, ps, and Amiga drivers in this regard, so
   contributions are welcomed.  The tek driver shows how to get the most
   out of a 16 color display.

 - 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?

 - start using m4 to preprocess the Fortran demos?

 - figure out why plrender is barfing on my old metafiles under ~/data

 - add support for shared libs on AIX, Irix, Alpha/OSF

 - check out shared library support under SAS/C -- supposed to be easy
   (6.0 and later)

 - Do something about the Tcl/TK shared lib situation (not really PLplot,
   but related).

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

 - Option in TK driver to preserve aspect ratio during zooms.

 - 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?




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.