[Plplot-cvs] SF.net SVN: plplot:[11033] trunk/PROBLEMS

[<ai...@us...>]

Revision: 11033
          http://plplot.svn.sourceforge.net/plplot/?rev=11033&view=rev
Author:   airwin
Date:     2010-05-28 15:42:51 +0000 (Fri, 28 May 2010)

Log Message:
-----------
Remove problems that appear to be no longer relevant.

Modified Paths:
--------------
    trunk/PROBLEMS

Modified: trunk/PROBLEMS
===================================================================
--- trunk/PROBLEMS	2010-05-27 22:34:40 UTC (rev 11032)
+++ trunk/PROBLEMS	2010-05-28 15:42:51 UTC (rev 11033)
@@ -17,11 +17,6 @@
 
 * PLplot documentation of python, java, etc., interfaces.  Alan
 
-* Build our documentation on RedHat.  Alan
-
-* If x08.tcl (or any other multi-page example) is executed first, then the
-first page is skipped.
-
 "Would be nice", major effort required.
 ***************************************
 
@@ -43,30 +38,16 @@
 plsopt("plenv_advance", "0");
 plenv(...)
 
-* Maurice's idea (plplot_devel 8 Jan 2004) of using C-style format specifier
-for familying as in
-
-./x08f -dev png -fam -fflen 2 -o x08f.%02d.png
-
 * -the tk drivers ignore plconfig.tcl if it is in the user directory ~/tcl
 and a tclIndex file is generated. "auto_path" is correctly initialized to
 ~/tcl, pwd/tcl, etc, but plconfig is not executed.  Reported by Joao.  Status?
 
-* memory leak problems for -dev xwin, -dev tk, and -dev ntk. The
-valgrind results for these interactive devices typically show lots of
-alloced blocks of memory that have not been freed at exit. This might be
-caused by my rather old versions of the X and Tk libraries not being
-valgrind clean or it may be that our drivers do not properly close those
-libraries.
-
 * Maurice plans to finish his changes to implement handling strings as
 strings in the metafile format.
 
 * Geoffrey plans to at least evaluate remaining fidelity problems caused
 by our 16-bit integer approach.
 
-* Make plframe widget work for python/Tkinter front end.
-
 * Put in index limits for the plot3d API's so they can handle
 non-rectangular x,y regions.  This has already been done for plsurf and
 needs to be extended to plot3d.
@@ -74,7 +55,7 @@
 * Put in variation of "defined" callback function with user-defined data
 for plshade and plshades.  Rafael?
 
-* Put in "defined" callback function with user-defined data for for plcont,
+* Put in "defined" callback function with user-defined data for plcont,
 plot3d, and plsurf.  This will supersede the non-rectangular x,y regions
 change already done for plsurf and planned for plot3d, but this programming
 is harder than those previous or planned changes so it will probably take
@@ -109,14 +90,6 @@
 Then, the only way such an extended search would fail is if the packagers
 messed with our tcl install location.
 
-* standard octave examples should be made consistent with the C, C++, tcl,
-Java, python, fortran, and even yorick (yplot) examples as a test that the
-API is implemented correctly for octave and as a teaching device of how to
-produce *exactly* the same plot for the octave interface as you can for each
-of the other interfaces. Currently octave examples 2, 6, 7, 10, 12, and 18
-agree with their counterparts from the other interfaces, but octave examples
-1, 3, 4, 5, 8, 9, 11, 13, 15, and 16 are not consistent.
-
 * Use some well-recognized pdf verification tool (similar in spirit to the
 w3c verification tests for web sites) to be sure our results conform to the
 published pdf standards.  Currently there is no idea whether such a pdf
@@ -176,24 +149,11 @@
 
 II. Font problems associated with ps.c and either -dev psc or -dev ps.
 
-* Bounding box is still too large for ps.c results.  We will need some help
-  from somebody with postscript expertise to get this right.
-
 * The overall size of the text is systematically smaller than for Hershey or
   TrueType fonts.
 
-* ./x06c -dev psc -o test.ps -drvopt hrshsym=0
-
-  shows that symbols are positioned consistently too high when postscript
-  fonts are used for them (hrshsym=0).  The same problem exists for example
-  7 as well.  At the same time, the two examples show that text positioning
-  (the labels on the outside of the matrix of symbols) are positioned fine.
-
 III. Other font problems/issues.
 
-* Both pstex.c and xfig.c currently use EscText so they presumably need some
-  work to utilize the new core unicode font handling.
-
 * We should enable additional device drivers for unicode.  In particular,
   our two most heavily used interactive device drivers, xwin and tk, should
   give some outstanding looking results once they are unicode-enabled.


This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site.