[Plplot-cvs] SF.net SVN: plplot:[12911] trunk/OLD-README.release

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

Revision: 12911
          http://sourceforge.net/p/plplot/code/12911
Author:   airwin
Date:     2013-12-22 22:28:45 +0000 (Sun, 22 Dec 2013)
Log Message:
-----------
Preserve the historical record of the 5.9.11 release notes by
prepending into OLD-README.release.

Modified Paths:
--------------
    trunk/OLD-README.release

Modified: trunk/OLD-README.release
===================================================================
--- trunk/OLD-README.release	2013-12-22 22:26:29 UTC (rev 12910)
+++ trunk/OLD-README.release	2013-12-22 22:28:45 UTC (rev 12911)
@@ -1,3 +1,1874 @@
+PLplot Release 5.9.11
+~~~~~~~~~~~~~~~~~~~~
+This is a development release of PLplot. It represents the ongoing efforts
+of the community to improve the PLplot plotting package. Development
+releases in the 5.9.x series will be available every few months. The next
+stable release will be 5.10.0.
+
+If you encounter a problem that is not already documented in the
+PROBLEMS file or on our bug tracker, then please send bug reports to
+PLplot developers via the mailing lists at
+<http://sourceforge.net/p/plplot/mailman/> (preferred for initial
+discussion of issues) and, if no quick resolution is possible, on our
+bug tracker at <http://sourceforge.net/p/plplot/bugs/>.
+
+Please see the license under which this software is distributed
+(LGPL), and the disclaimer of all warranties, given in the COPYING.LIB
+file.
+
+INDEX
+
+1. OFFICIAL NOTICES FOR USERS SINCE 5.9.10 (the previous development release)
+
+2. Tests made for release 5.9.11
+
+3. Changes relative to PLplot 5.9.10 (the previous development release)
+
+3.1 NUMERIC_INCLUDE_PATH ==> NUMPY_INCLUDE_PATH
+3.2 Major overhaul of the build system and bindings for Tcl and friends
+3.3 Substantial overhaul of the build system for the Qt-components of PLplot
+3.4 The epa_build project has been implemented
+
+
+4. OFFICIAL NOTICES FOR USERS SINCE 5.8.0 (the previous stable release)
+
+5. Changes relative to PLplot 5.8.0 (the previous stable release)
+
+5.1 All autotools-related files have now been removed
+5.2 Build system bug fixes
+5.3 Build system improvements
+5.4 Implement build-system infrastructure for installed Ada bindings and
+examples
+5.5 Code cleanup
+5.6 Date / time labels for axes
+5.7 Alpha value support
+5.8 New PLplot functions
+5.9 External libLASi library improvements affecting our psttf device
+5.10 Improvements to the cairo driver family
+5.11 wxWidgets driver improvements
+5.12 pdf driver improvements
+5.13 svg driver improvements
+5.14 Ada language support
+5.15 OCaml language support
+5.16 Perl/PDL language support
+5.17 Update to various language bindings
+5.18 Update to various examples
+5.19 Extension of our test framework
+5.20 Rename test subdirectory to plplot_test
+5.21 Website support files updated
+5.22 Internal changes to function visibility
+5.23 Dynamic driver support in Windows
+5.24 Documentation updates
+5.25 libnistcd (a.k.a. libcd) now built internally for -dev cgm
+5.26 get-drv-info now changed to test-drv-info
+5.27 Text clipping now enabled by default for the cairo devices
+5.28 A powerful qt device driver has been implemented
+5.29 The PLplot API is now accessible from Qt GUI applications
+5.30 NaN / Inf support for some PLplot functions
+5.31 Various bug fixes
+5.32 Cairo driver improvements
+5.33 PyQt changes
+5.34 Color Palettes
+5.35 Re-implementation of a "soft landing" when a bad/missing compiler is
+detected
+5.36 Make PLplot aware of LC_NUMERIC locale
+5.37 Linear gradients have been implemented
+5.38 Cairo Windows driver implemented
+5.39 Custom axis labelling implemented
+5.40 Universal coordinate transform implemented
+5.41 Support for arbitrary storage of 2D user data
+5.42 Font improvements
+5.42 Alpha value support for plotting in memory.
+5.43 Add a Qt device for in memory plotting.
+5.44 Add discrete legend capability.
+5.45 Add full bindings and examples for the D language.
+5.46 The plstring and plstring3 functions have been added
+5.47 The pllegend API has been finalized
+5.48 Octave bindings now implemented with swig
+5.49 Documentation redone for our swig-generated Python and Octave bindings
+5.50 Support large polygons
+5.51 Complete set of PLplot parameters now available for Fortran
+5.52 The plarc function has been added
+5.53 The format for map data used by plmap has changed
+5.54 Python support for Numeric has been dropped
+5.55 Backwards-incompatible API change to non-integer line widths
+5.56 Improvements to the build system for the Cygwin case
+5.57 The plcolorbar API has been finalized
+5.58 Documentation of the new legend and color bar capabilities of PLplot
+5.59 The D bindings and examples have been converted from the
+old version of D (D1) to the new version of D (D2)
+5.60 The DocBook documentation for PLplot is now generated using modern
+XML/XSL backend tools for DocBook
+5.61 Implement experimental build_projects sub-project
+5.62 Implement extremely simple "00" example
+5.63 Convert to using the Allura form of SourceForge software
+5.64 Use NON_TRANSITIVE linking by default for the shared libraries case for
+all non-windows systems
+5.65 Update f95 examples to take larger advantage of Fortran 95 capabilities
+5.66 Substantial additions to the doxygen documentation
+5.67 NUMERIC_INCLUDE_PATH ==> NUMPY_INCLUDE_PATH
+5.68 Major overhaul of the build system and bindings for Tcl and friends
+5.69 Substantial overhaul of the build system for the Qt-components of PLplot
+5.70 The epa_build project has been implemented
+
+1. OFFICIAL NOTICES FOR USERS SINCE 5.9.10 (the previous development release)
+
+(5.9.11) Backwards-incompatible API change.  The numerical symbolic
+constants that are #defined as macros in plplot.h have been
+repropagated to the Python, Java, Lua, Octave, Fortran 95, and Tcl
+language bindings using scripts.  Previously, this propagation was
+done by hand in a piece-meal manner so use of the scripts has created
+a number of changes in the PLplot symbolic constants for these
+languages.  These changes are the addition of 25 symbolic constants
+that were previously only available for C, no deletions of symbolic
+constants, no changes to numerical values, but the following
+backwards-incompatible name changes:
+
+PLESC_PLFLTBUFFERING ==> PLESC_DOUBLEBUFFERING
+PLESPLFLTBUFFERING_DISABLE ==> PLESC_DOUBLEBUFFERING_ENABLE
+PLESPLFLTBUFFERING_ENABLE ==> PLESC_DOUBLEBUFFERING_ENABLE
+PLESPLFLTBUFFERING_QUERY ==> PLESC_DOUBLEBUFFERING_QUERY
+
+So those users who were using the symbolic constants on the left for
+the above languages will have to change their source code or scripts
+to use the constants on the right.  No changes in source code or
+scripts should be required of other users.
+
+(5.9.11) Backwards-incompatible API change.  The PLplot build system
+and bindings for Tcl and friends have had a major overhaul, see below.
+Part of this change was to split the former libplplottcltk into two
+components.  The new libplplottcltk is now a pure Tcl/Tk extension
+that can be linked to the stub versions of the Tcl/Tk libraries and
+dynamically loaded from a tclsh or wish environment using the
+appropriate "package require" command.  The new libplplottcltk_Main
+library contains code (e.g., pltclMain and pltkMain) required by C
+plotting applications (e.g., pltcl, plrender, and xtk0[124].c) that
+link to libplplottcltk.
+
+(5.9.11) Backwards-incompatible change.  Our Fortran 77 bindings
+and examples have been completely removed because Fortran 95 is just a
+much better language which we have been supporting for a long time,
+and our judgement call based on user feedback we have received is
+nobody is interested in plotting using strict Fortran 77 language
+constructs any more.  However, if there is still some Fortran 77
+source code out there that uses PLplot, typically the only change you
+should have to do to port it to our Fortran 95 bindings is to place
+the command "use plplot" as the first line of the source code of the
+main routine.
+
+(5.9.11) Deprecation.  The functionality of the AGG backend and
+FreeType option in the wxwidgets device driver is provided (and in
+some cases exceeded) by other backends and options that we have
+implemented for this device driver.  The AGG backend and Freetype
+option are therefore deprecated with the intention to remove them in a
+future release.
+
+2. Tests made for release 5.9.11
+
+Note that "comprehensive tests" below refers to running
+scripts/comprehensive_test.sh in default mode (i.e., not dropping any
+tests).  For each of our three major configurations (shared
+libraries/dynamic devices, shared libraries/nondynamic devices, and
+static libraries/nondynamic devices) this test script runs ctest in
+the build tree and runs the test_noninteractive and test_interactive
+targets in the build tree, the installed examples tree configured with
+a CMake-based build system for the examples, and an installed examples
+tree configured with our traditional (Make + pkg-config) build system
+for the examples.
+
+Note that all tests mentioned below were successful ones unless
+noted differently.
+
+* Alan W. Irwin ran comprehensive tests for a complete system build
+environment on 64-bit Debian Wheezy Linux for AMD-64 hardware.
+
+* Alan W. Irwin ran comprehensive testsfor a limited (qt, cairo, wxwidgets,
+and octave PLplot components were dropped) epa_build environment on
+64-bit Debian Wheezy Linux for AMD-64 hardware.
+
+* Alan W. Irwin ran comprehensive tests for an almost complete epa_build
+environment (only the wxwidgets and octave components of PLplot were
+dropped) on 64-bit Debian Wheezy Linux for AMD-64 hardware.
+
+* Alan W. Irwin ran fairly comprehensive tests (i.e, for the shared
+library/dynamic devices case run ctest and also the
+test_noninteractive and test_interactive targets in the build tree)
+for a quite limited (qt, cairo, wxwidgets, octave, Tcl/Tk, and Java
+PLplot components were dropped) epa_build environment for 32-bit
+MinGW/MSYS/Wine for AMD-64 hardware.  The Wine version was a release
+candidate for Wine-1.6 that was built on Debian Wheezy Linux, the
+compiler was gcc-4.7.2, the CMake generator was "MSYS Makefiles", and
+the build command was "make" (i.e., the MSYS version, not the MinGW
+version).  An attempt was made to extend this successful test result
+to the installed examples built with the CMake-based build system, but
+for that case the Ada examples all failed at run time with a return
+code of 3 so no further attempt was made to widen the scope of these
+MinGW/MSYS/Wine tests.
+
+* Andrew Ross ran fairly comprehensive tests (i.e., for the shared
+library/dynamic devices case use the test_noninteractive and
+test_interactive targets in the build tree) for a complete system
+build environment on 64-bit Debian unstable Linux for AMD-64 hardware.
+
+* Andrew Ross ran comprehensive tests for a complete system build 
+environment on 64-bit Ubuntu Saucy (13.10) Linux for AMD-64 hardware.
+The only issue was a segmentation fault on the c++ qt_example for
+the nondynamic devices case only. This is reproducible on this
+system, but not on other Linux platforms so may be specific to the
+Ubuntu version of the Qt libraries. This is unlikely to affect most
+users since the default is to use dynamically loaded devices.
+
+* Andrew Ross ran limited tests with a limited number of nondynamic 
+devices (mem, null, psc, svg, xfig, xwin) and limited language 
+bindings (C / C++ / F95) for a CentOS 5.10 system with AMD64 hardware. 
+The build passed "make test_diff psc". The java version was too old 
+and java support had to be disabled. Ada support had to be 
+disabled due to a bug (now fixed). Cairo support also had to be 
+disabled due to too old a version of the library being installed.
+
+* Andrew Ross ran limited tests for an epa_build environment on CentOS 
+5.10. The buildtools and plplot_lite targets were built (with 
+nondynamic devices), again after disabling java, ada and cairo support. 
+This build added support for tcl / tk bindings and the pdf and tk based 
+devices. The build passed make test_noninteractive in the install tree, 
+but failed make test_interactive due to missing rpath information for the 
+itcl and itk libraries. This bug can be worked around by setting 
+LD_LIBRARY_PATH to point to the libraries, in which case the interactive
+test works fine.
+
+* Arjen Markus ran a fairly comprehensive test (i.e., for the shared
+library/dynamic devices case use the test_noninteractive target) for a
+incomplete system build environment (the Ada, D, itcl/itk, Lua, ocaml,
+octave, Java, and wxwidgets components of PLplot were dropped) on
+64-bit Cygwin with gcc-4.8.2.  That platform was installed on top of
+64-bit Windows 7, service pack 1 for AMD-64 hardware.  Java and
+wxwidgets were dropped because of build errors for those on Cygwin
+that have not been resolved yet.  The remaining components were
+dropped due to lack of time to investigate them so far.  There was
+close to complete success with the qt and cairo (aside from wincairo)
+device drivers which is an excellent Windows result since those
+device drivers add a lot of important capability to PLplot.
+
+* Arjen Markus ran build tests and limited run-time tests (checking by
+hand that some components of PLplot worked) for the shared
+libraries/dynamic devices case for a limited build environment (the
+qt, cairo, wxwidgets, pdf and the components mentioned above of PLplot
+were dropped except for Java which was included in this test) on
+32-bit MinGW.  That platform was installed on top of 64-bit Windows 7,
+service pack 1 for AMD-64 hardware.  The compiler was gcc-4.7.0, the
+CMake generator was "MinGW Makefiles", and the build command was
+mingw32-make.
+
+* Arjen Markus ran build tests and limited run-time tests (checking by
+hand that some components of PLplot worked) for the shared
+libraries/dynamic devices case for a limited build environment (the
+same limitations as for his MinGW tests above) for MSVC/C++ 2010 and Intel
+Fortran 2011 compilers on 64-bit Windows 7, service pack 1 for AMD-64
+hardware.  In general, the CMake generator "NMake Makefiles" and
+the corresponding build command "nmake" worked well for this platform.
+The attempted use of Visual Studio generators combined with the
+Visual Studio 2010 IDE available on that platform was more problematic.
+
+* Phil Rosenberg ran build tests and limited run-time tests (checking
+by hand that some components of PLplot worked) for the static
+libraries/nondynamic devices case for a limited build environment
+(virtually all PLplot components dropped other than C, C++ and
+wxwidgets 2.8) for the Visual Studio 2008 IDE (with associated MSVC
+compiler) on 32-bit Windows 7 for AMD-64 hardware.  The "Visual Studio
+9 2008" generator yielded good results.
+
+* Phil Rosenberg ran build tests and limited run-time tests (checking
+by hand that some components of PLplot worked) for the static
+libraries/nondynamic devices case for a limited build environment
+(virtually all PLplot components dropped other than C, CXX, and
+wxwidgets 3.0) for the Visual Studio 2012 IDE (with associated MSVC
+compiler) on Windows 8 for AMD-64 hardware.  Both x86 and x64 builds
+were tested.  The combination of "NMake Makefiles" generator and MSVC
+compiler yielded good build results if CMake patches (available at
+http://www.cmake.org/Bug/view.php?id=14587 and
+http://www.cmake.org/Bug/view.php?id=14642) to allow use of
+wxwidgets-3.0 were applied.  With those patches some run-time problems
+with the use of Plplot's wxWidgetsApp with wxWidgets 3.0 were observed
+in the examples, however plots embedded in wxWidgets apps seem to work
+fine.  The "Visual Studio 11" and "Visual Studio 11 Win64" generators
+had some additional issues which could be worked around but which
+nevertheless indicated there are some CMake bugs for those generators
+that need to be addressed.
+
+* Jerry Bauck ran build tests of PLplot for the C core library, the
+Ada, C++, Java, Lua, and Python bindings, and a fairly complete list
+of device drivers (including qt and cairo) for PLplot on Mac OS X
+Mountain Lion for AMD64 hardware.  Extremely narrow run-time tests of
+the Ada examples were a success, but all the standard testing scripts
+failed because for unknown reasons the lena.pgm file that is used in
+conjunction with our standard example 20 was not properly copied by
+our build and test system from the source tree to the correct
+locations in the build tree.
+
+* Felipe Gonzalez ran build tests of PLplot for the C core library and
+the C++, Fortran 95, and OCaml-4.01.0 bindings on Mac OS X Mountain
+Lion.  The report from Felipe stated the compiler suite used was
+probably from MacPorts, and did not state anything about the hardware
+type.
+
+3. Changes relative to PLplot 5.9.10 (the previous development release)
+
+3.1 NUMERIC_INCLUDE_PATH ==> NUMPY_INCLUDE_PATH
+
+We have long since dropped support for the Numeric Python module and
+are now exclusively using the numpy Python modules instead.
+Therefore, we have changed the CMake variable name used in our build
+system that holds the location of the numpy headers from the confusing
+misnomer, NUMERIC_INCLUDE_PATH, to NUMPY_INCLUDE_PATH.  This change
+only impacts PLplot users who in the past have used the cmake option
+-DNUMERIC_INCLUDE_PATH to set the CMake variable NUMERIC_INCLUDE_PATH
+to the location of the numpy header directory.  Note we discourage
+that method since without that user intervention, the build system
+uses python and numpy to find the location which should normally be
+foolproof and not subject to the inconsistencies or errors possible
+with setting the variable.  But if some users still insist on setting
+the variable, that variable's name should now be NUMPY_INCLUDE_PATH.
+
+3.2 Major overhaul of the build system and bindings for Tcl and friends
+
+After years of neglect we have worked very hard in the release cycle
+leading up to the release of 5.9.11 on our build system and code
+interfacing Tcl and friends (Tk, Itcl, Itk, and Iwidgets) with PLplot.
+The build system now does a much better job of finding a consistent
+set of components for Tcl and friends.  For example, switching from
+the system version of those components to a special build of those
+components is typically a matter of simply putting tclsh from the
+special build first on the PATH.  And after the components of Tcl and
+friends are found, the build system does extensive checking to make
+sure they are compatible with each other.  The plplottcktk library has
+now been split (see remarks in the above OFFICIAL NOTICES for more
+details).  Many bugs have been fixed, and all tests documented in
+examples/tcl/README.tcldemos and examples/tk/README.tkdemos have now
+been implemented as tests via the build system to help avoid any
+regressions in the build system and bindings for Tcl and friends in
+the future.
+
+As a consequence of these activities the ntk device has been enabled
+under Windows. The xwin and tkwin devices work under Cygwin.
+
+3.3 Substantial overhaul of the build system for the Qt-components of PLplot
+
+As a result of these improvements compiling and linking of our
+Qt-related components just got a lot more rational, and the
+long-standing memory management issues reported by valgrind for
+examples/c++/qt_example for the non-dynamic devices case have been
+resolved.
+
+3.4 The epa_build project has been implemented
+
+The goal of this project is to make builds of recent versions of
+PLplot dependencies (and PLplot itself) much more convenient on all
+platforms.  Once this goal is realized, it should make the full power
+of PLplot (which depends on the existence and quality of its
+dependencies) readily available on all platforms.  The epa_build
+project uses the power of CMake (especially the ExternalProject_Add
+command which is why we chose to use the prefix "epa_" in the name of
+epa_build) to organize downloading, updating, configuring, building,
+testing, and installing of any kind (not just those with CMake-based
+build systems) of software project with full dependency support
+between all the various builds.  For those users who are not
+satisified with the PLplot dependencies on their systems, learn how to
+use the epa_build project by consulting cmake/epa_build/README.
+
+The epa_build project is in pretty good shape on Linux; epa_build
+configurations work properly for build tools such as Tcl/Tk8.6, Itcl,
+Itk, and Iwidgets and for regular packages such as pango (needed for
+the cairo device driver), qt4_lite (needed for the qt device driver),
+the wxwidgets software package (needed for the wxwidgets device
+driver), and many smaller, but useful PLplot dependencies such as
+shapelib, libqhull, and libharu.  The total build time is roughly an
+hour for an ordinary PC which is not much of a price to pay to get
+access to up-to-date versions of virtually all dependencies of PLplot.
+In fact, the only known dependency of PLplot not currently covered by
+epa_build is octave.  In principle, it should be straightforward to
+add an epa_build configurations for octave and its many dependencies,
+but that possibility has not been explored yet.
+
+In principle, epa_build should work out of the box on Mac OS X
+platforms, but we haven't tested on that platform yet.
+
+Our testing for MinGW/MSYS and Cygwin shows the epa_build project is
+still in fairly rough shape on Windows.  It is known that the "plplot"
+case (PLplot with all its dependencies) fails in various ways on all
+Windows platforms.  Those issues are being actively worked on.  Note,
+however, that the "plplot_lite" case (PLplot with all the minor
+dependencies but without Tcl etc., build tools and without the pango,
+qt4_lite, and wxwidgets dependencies) has been shown to work on
+MinGW/MSYS and should probably also work on Cygwin although we haven't
+tested that specific case yet.
+
+4. OFFICIAL NOTICES FOR USERS SINCE 5.8.0 (the previous stable release)
+
+(5.9.11) Backwards-incompatible API change.  The numerical symbolic
+constants that are #defined as macros in plplot.h have been
+repropagated to the Python, Java, Lua, Octave, Fortran 95, and Tcl
+language bindings using scripts.  Previously, this propagation was
+done by hand in a piece-meal manner so use of the scripts has created
+a number of changes in the PLplot symbolic constants for these
+languages.  These changes are the addition of 25 symbolic constants
+that were previously only available for C, no deletions of symbolic
+constants, no changes to numerical values, but the following
+backwards-incompatible name changes:
+
+PLESC_PLFLTBUFFERING ==> PLESC_DOUBLEBUFFERING
+PLESPLFLTBUFFERING_DISABLE ==> PLESC_DOUBLEBUFFERING_ENABLE
+PLESPLFLTBUFFERING_ENABLE ==> PLESC_DOUBLEBUFFERING_ENABLE
+PLESPLFLTBUFFERING_QUERY ==> PLESC_DOUBLEBUFFERING_QUERY
+
+So those users who were using the symbolic constants on the left for
+the above languages will have to change their source code or scripts
+to use the constants on the right.  No changes in source code or
+scripts should be required of other users.
+
+(5.9.11) Backwards-incompatible API change.  The PLplot build system
+and bindings for Tcl and friends have had a major overhaul, see below.
+Part of this change was to split the former libplplottcltk into two
+components.  The new libplplottcltk is now a pure Tcl/Tk extension
+that can be linked to the stub versions of the Tcl/Tk libraries and
+dynamically loaded from a tclsh or wish environment using the
+appropriate "package require" command.  The new libplplottcltk_Main
+library contains code (e.g., pltclMain and pltkMain) required by C
+plotting applications (e.g., pltcl, plrender, and xtk0[124].c) that
+link to libplplottcltk.
+
+(5.9.11) Backwards-incompatible change.  Our Fortran 77 bindings
+and examples have been completely removed because Fortran 95 is just a
+much better language which we have been supporting for a long time,
+and our judgement call based on user feedback we have received is
+nobody is interested in plotting using strict Fortran 77 language
+constructs any more.  However, if there is still some Fortran 77
+source code out there that uses PLplot, typically the only change you
+should have to do to port it to our Fortran 95 bindings is to place
+the command "use plplot" as the first line of the source code of the
+main routine.
+
+(5.9.11) Deprecation.  The functionality of the AGG backend and
+FreeType option in the wxwidgets device driver is provided (and in
+some cases exceeded) by other backends and options that we have
+implemented for this device driver.  The AGG backend and Freetype
+option are therefore deprecated with the intention to remove them in a
+future release.
+
+(5.9.10) The minimum version of CMake has been bumped to 5.8.9.  This
+change allows our build system to take advantage of CMake features
+introduced in later versions of CMake.  Even more importantly it also
+updates user's builds to the CMake policy conventions (important
+backwards-incompatible changes in CMake behaviour introduced in later
+versions of CMake) to the default CMake policy used for 5.8.9.
+
+(5.9.10) The long deprecated support for the python Numeric package has been
+dropped. This is no longer supported and is superseded by numpy. Support for
+numpy has been the default in PLplot for a number of years so most users
+should notice no difference.
+
+(5.9.10) The current format for maps used by plmap has been deprecated in
+favour of using shapefiles (a standard format widely used for GIS and with
+suitable free data sources available). This requires the shapelib library
+to be installed. If this library is not installed then by default no map
+support will be available. Support for the old binary format is still
+available by setting the cmake variable PL_DEPRECATED, however this
+support will be removed in a future release of PLplot.
+
+(5.9.10) Those who use the Python version of plgriddata will have to
+change their use of this function for this release as follows (see
+examples/xw21.py)
+
+# old version (which overwrites preexisting zg in place):
+zg = reshape(zeros(xp*yp),(xp,yp))
+plgriddata(x, y, z, xg, yg, zg, alg, opt[alg-1])
+
+# new version (which uses a properly returned newly created NumPy array
+# as per the normal Python expectations):
+
+zg = plgriddata(x, y, z, xg, yg, alg, opt[alg-1])
+
+(5.9.10) Significant efforts have been made to ensure the PLplot code
+is standards compliant and free from warnings. Compliance has been
+tested using the gcc compiler suite -std, -pedantic and -W  flags. The
+language standards adopted are
+C: ISO C99 with POSIX.1-2001 base specification (required for a number
+of C library calls)
+C++: ISO C++ 1998 standard plus amendments
+F95: Fortran 95 standard
+
+Specifically, the following gcc / g++ / gfortran flags were used
+
+CFLAGS='-O3 -std=c99 -pedantic -D_POSIX_C_SOURCE=200112L -Wall  \
+-Wextra -Wmissing-prototypes -Wstrict-prototypes -Wnested-externs \
+-Wconversion -Wshadow -Wcast-qual -Wcast-align -Wwrite-strings'
+
+CXXFLAGS='-O3 -fvisibility=hidden -std=c++98 -pedantic -Wall -Wextra '
+
+FFLAGS='-std=f95 -O3 -fall-intrinsics -fvisibility=hidden -pedantic \
+-Wall -Wextra '
+
+Note that the code is not yet quite standards compliant or warning free,
+but this is our aim. We know that a number of common compilers do not
+support these standards "out of the box", so we will continue to develop
+and support workarounds to ensure that PLplot remains easily built on
+a variety of platforms and compilers. Standards compliance should make
+it easier to port to new systems in the future. Using aggressive
+warnings flags will help to detect and eliminate errors or problems in
+the libraries.
+
+The gfortran -fall-intrinsics flag is required for a couple of
+non-standard intrinsics which are used in the code. In the future
+adopting the fortran 2003 or 2008 standard should allow this to be
+removed.
+
+Note: currently this code cleanup does not apply to code generated by
+swig (octave, python, java, lua bindings) which gives a large number of
+code warnings.
+
+(5.9.10) For some years now we have had both FORTRAN 77 and Fortran 95
+bindings, but to the best of our knowledge, there are no longer
+any maintained FORTRAN 77 compilers left that do not also support
+Fortran 95. (g77 for instance has not been maintained for several
+years now. Its successor gfortran supports Fortran 95 and later standards
+as well all g77's legacy features).
+
+An important consequence is that we can not test the implementation for
+compliance to the FORTRAN 77 standard.
+Furthermore, we would prefer to concentrate all our Fortran
+development effort on our f95 bindings and strongly encourage all our
+Fortran users to use those bindings if they haven't switched from the
+f77 version already. Therefore, as of this release we are deprecating
+the f77 bindings and examples and plan no further support for them.
+We signal this deprecation by disabling f77 by default (although our
+users can still get access to these unsupported bindings and examples
+for now by specifying the -DENABLE_f77=ON cmake option).
+
+We plan to completely remove the f77 bindings and examples
+two releases after this one.
+
+(5.9.10) We have found that some distributions of the Windows
+MinGW/gfortran compiler (i.e., MinGW/gfortran 4.6.1 and 4.6.2 from
+http://www.equation.com) may cause a link error due to duplicate
+symbols like __gfortran_setarg_. These errors can be suppressed by
+adding the flag -Wl,--allow-multiple-define. It is very likely that
+this is a bug in these distributions.
+
+As building the libraries and the examples succeeds without any problem
+if you use most other distributions of Windows MinGW/gfortran,
+we have decided not to include this flag in our build system.
+
+Distributions that are known to work:
+- MinGW/gfortran-4.5 from http://www.equation.com,
+- MinGW/gfortran-4.5.2-1 that is installed using the latest
+  mingw-get-inst-20110802 automatic installer available at
+  http://sourceforge.net/projects/mingw/files/Installer/mingw-get-inst
+- MinGW/gfortran-4.6.2 from tdm-gcc.tdragon.net
+
+(Therefore it is not the 4.5.x versus 4.6.x version of MinGW/gfortran
+as such that causes this problem.)
+
+(5.9.9) This is a quick release to deal with two broken build issues
+that were recently discovered for our Windows platform.  Windows users should
+avoid 5.9.8 because of these problems for that release, and instead use
+5.9.9 which has been heavily tested on a number of platforms including
+Windows, see "Tests made for release 5.9.9" below.
+
+(5.9.8) For unicode-aware devices we now follow what is done for the
+Hershey font case for epsilon, theta, and phi.  This means the #ge,
+#gh, and #gf escapes now give users the Greek lunate epsilon, the
+ordinary Greek lower case theta, and the Greek symbol phi for Unicode
+fonts just like has occurred since the dawn of PLplot history for the
+Hershey font case.  Previously these legacy escapes were assigned to
+ordinary Greek lower-case epsilon, the Greek symbol theta (= script
+theta), and the ordinary Greek lower case phi for unicode fonts
+inconsistently with what occurred for Hershey fonts.  This change gets
+rid of this inconsistency, that is the #g escapes should give the best
+unicode approximation to the Hershey glyph result that is possible for
+unicode-aware devices.
+
+In general we encourage users of unicode-aware devices who might
+dislike the Greek glyph Hershey-lookalike choices they get with the
+legacy #g escapes to use instead either PLplot unicode escapes (e.g.,
+"#[0x03b5]" for ordinary Greek lower-case epsilon, see page 3 of
+example 23) or better yet, UTF-8 strings (e.g., "ε") to specify
+exactly what unicode glyph they want.
+
+(5.9.8) The full set of PLplot constants have been made available to
+our Fortran 95 users as part of the plplot module.  This means those
+users will have to remove any parameter statements where they have
+previously defined the PLplot constants (whose names typically start
+with "PL_" for themselves.  For a complete list of the affected
+constants, see the #defines in swig-support/plplotcapi.i which are
+used internally to help generate the plplot module.  See also Index
+item 5.51 below.
+
+(5.9.8) There has been widespread const modifier changes in the API
+for libplplotd and libplplotcxxd.  Those backwards-incompatible API
+changes are indicated in the usual way by a soversion bump in those
+two libraries which will force all apps and libraries that depend on
+those two libraries to be rebuilt.
+
+Specifically, we have changed the following arguments in the C library
+(libplplotd) case
+
+type * name1 ==> const type * name1
+type * name2 ==> const type ** name2
+
+and the following arguments in the C++ library (libplplotcxxd) case
+
+type * name1 ==> const type * name1
+type * name1 ==> const type * const * name2
+
+where name1 is the name of a singly dimensioned array whose values are
+not changed internally by the PLplot libraries and name2 is the name
+of a doubly dimensioned array whose values are not changed internally
+by the PLplot libraries.
+
+The general documentation and safety justification for such const
+modifier changes to our API is given in
+http://www.cprogramming.com/tutorial/const_correctness.html.
+Essentially, the above const modifier changes constitute our guarantee
+that the associated arrays are not changed internally by the PLplot
+libraries.
+
+Although it is necessary to rebuild all apps and libraries that depend
+on libplplotd and/or libplplotcxxd, that rebuild should be possible
+with unchanged source code without build errors in all cases.  For C
+apps and libraries (depending on libplplotd) there will be additional
+build warnings due to a limitation in the C standard discussed at
+http://c-faq.com/ansi/constmismatch.html unless all doubly dimensioned
+arrays (but not singly dimensioned) are explicitly cast to (const type
+**).  However, such source code changes will not be necessary to avoid
+warning messages for the C++ (libplplotcxxd) change because of the
+double use of const in the above "const type * const * name2" change.
+
+(5.9.8) The plarc API has changed in release 5.9.8.  The plarc API now
+has a rotation parameter which will eventually allow for rotated arcs.
+PLplot does not currently support rotated arcs, but the plarc function
+signature has been modified to avoid changing the API when this
+functionality is added.
+
+(5.9.6) We have retired the pbm driver containing the pbm (actually
+portable pixmap) file device. This device is quite primitive and
+poorly maintained. It ignores unicode fonts (i.e., uses the Hershey
+font fallback), falls back to ugly software fills, doesn't support
+alpha transparency, etc.  It also has a serious run-time issue with
+example 2 (double free detected by glibc) which probably indicates
+some fundamental issue with the 100 colors in cmap0 for that
+example. For those who really need portable pixmap results, we suggest
+using the ImageMagick convert programme, e.g., "convert
+examples/x24c01.pngqt test.ppm" or "convert examples/x24c01.pngcairo
+test.ppm" to produce good-looking portable pixmap results from our
+best png device results.
+
+(5.9.6) We have retired the linuxvga driver containing the linuxvga
+interactive device.  This device is quite primitive, difficult to
+test, and poorly maintained. It ignores unicode fonts (i.e., uses the
+Hershey font fallback), falls back to ugly software fills, doesn't
+support alpha transparency, etc.  It is Linux only, can only be run as
+root, and svgalib (the library used by linuxsvga) is not supported by
+some mainstream (e.g., Intel) chipsets.  All of these characteristics
+make it difficult to even test this device much less use it for
+anything serious.  Finally, it has had a well-known issue for years
+(incorrect colors) which has never been fixed indicating nobody is
+interested in maintaining this device.
+
+(5.9.6) We have retired our platform support of djgpp that used to
+reside in sys/dos/djgpp.  The developer (Andrew Roach) who used to
+maintain those support files for djgpp feels that the djgpp platform
+is no longer actively developed, and he no longer uses djgpp himself.
+
+(5.9.6) We have changed plpoin results for ascii codes 92, 94, and 95
+from centred dot, degree symbol, and centred dot glyphs to the correct
+backslash, caret, and underscore glyphs that are associated with those
+ascii indices.  This change is consistent with the documentation of
+plpoin and solves a long-standing issue with backslash, caret, and
+underscore ascii characters in character strings used for example by
+pl[mp]tex.  Those who need access to a centred dot with plpoin should
+use index 1.  The degree symbol is no longer accessible with plpoin,
+but it is available in ordinary text input to PLplot as Hershey escape
+"#(718)", where 718 is the Hershey index of the degree symbol, unicode
+escape "#[0x00B0]" where 0x00B0 is the unicode index for the degree
+symbol or direct UTF8 unicode string "°".
+
+(5.9.6) We have retired the gcw device driver and the related gnome2
+and pygcw bindings since these are unmaintained and there are good
+replacements.  These components of PLplot were deprecated as of
+release 5.9.3.  A good replacement for the gcw device is either the
+xcairo or qtwidget device.  A good replacement for the gnome2 bindings
+is the externally supplied XDrawable or Cairo context associated with
+the xcairo device and the extcairo device (see
+examples/c/README.cairo).  A good replacement for pygcw is our new
+pyqt4 bindings for PLplot.
+
+(5.9.6) We have deprecated support for the python Numeric array
+extensions. Numeric is no longer maintained and users of Numeric are
+advised to migrate to numpy. Numpy has been the standard for PLplot
+for some time. If numpy is not present PLplot will now disable python
+by default. If you still require Numeric support in the short term
+then set USE_NUMERIC to ON in cmake. The PLplot support for Numeric
+will be dropped in a future release.
+
+(5.9.5) We have removed pyqt3 access to PLplot and replaced it by
+pyqt4 access to PLplot (see details below).
+
+(5.9.5) The only method of specifying a non-default compiler (and
+associated compiler options) that we support is the environment
+variable approach, e.g.,
+
+export CC='gcc -g -fvisibility=hidden'
+export CXX='g++ -g -fvisibility=hidden'
+export FC='gfortran -g -fvisibility=hidden'
+
+All other CMake methods of specifying a non-default compiler and
+associated compiler options will not be supported until CMake bug 9220
+is fixed, see discussion below of the soft-landing re-implementation
+for details.
+
+(5.9.5) We have retired the hpgl driver (containing the hp7470,
+hp7580, and lj_hpgl devices), the impress driver (containing the imp
+device), the ljii driver (containing the ljii and ljiip devices), and
+the tek driver (containing the conex, mskermit, tek4107, tek4107f,
+tek4010, tek4010f, versaterm, vlt, and xterm devices).  Retirement
+means we have removed the build options which would allow these
+devices to build and install.  Recent tests have shown a number of
+run-time issues (hpgl, impress, and ljii) or build-time issues (tek)
+with these devices, and as far as we know there is no more user
+interest in them. Therefore, we have decided to retire these devices
+rather than fix them.
+
+(5.9.4) We have deprecated the pbm device driver (containing the pbm
+device) because glibc detects a catastrophic double free.
+
+(5.9.3) Our build system requires CMake version 5.6.0 or higher.
+
+(5.9.3) We have deprecated the gcw device driver and the related
+gnome2 and pygcw bindings since these are essentially unmaintained.
+For example, the gcw device and associated bindings still depends on
+the plfreetype approach for accessing unicode fonts which has known
+issues (inconsistent text offsets, inconvenient font setting
+capabilities, and incorrect rendering of CTL languages).  To avoid
+these issues we advise using the xcairo device and the externally
+supplied XDrawable or Cairo context associated with the xcairo device
+and the extcairo device (see examples/c/README.cairo) instead. If you
+still absolutely must use -dev gcw or the related gnome2 or pygcw
+bindings despite the known problems, then they can still be accessed
+by setting PLD_gcw, ENABLE_gnome2, and/or ENABLE_pygcw to ON.
+
+(5.9.3) We have deprecated the gd device driver which implements the
+png, jpeg, and gif devices.  This device driver is essentially
+unmaintained. For example, it still depends on the plfreetype approach
+for accessing unicode fonts which has known issues (inconsistent text
+offsets, inconvenient font setting capabilities, and incorrect
+rendering of CTL languages).  To avoid these issues for PNG format, we
+advise using the pngcairo or pngqt devices.  To avoid these issues for
+the JPEG format, we advise using the jpgqt device.  PNG is normally
+considered a better raster format than GIF, but if you absolutely
+require GIF format, we advise using the pngcairo or pngqt devices and
+then downgrading the results to the GIF format using the ImageMagick
+"convert" application.  For those platforms where libgd (the
+dependency of the gd device driver) is accessible while the required
+dependencies of the cairo and/or qt devices are not accessible, you
+can still use these deprecated devices by setting PLD_png, PLD_jpeg,
+or PLD_gif to ON.
+
+(5.9.3) We have re-enabled the tk, itk, and itcl components of PLplot
+by default that were disabled by default as of release 5.9.1 due to
+segfaults.  The cause of the segfaults was a bug (now fixed) in how
+pthread support was implemented for the Tk-related components of
+PLplot.
+
+(5.9.2) We have set HAVE_PTHREAD (now called PL_HAVE_PTHREAD as of
+release 5.9.8) to ON by default for all platforms other than Darwin.
+Darwin will follow later once it appears the Apple version of X
+supports it.
+
+(5.9.1) We have removed our previously deprecated autotools-based
+build system.  Instead, use the CMake-based build system following the
+directions in the INSTALL file.
+
+(5.9.1) We no longer support Octave-5.1.73 which has a variety of
+run-time issues in our tests of the Octave examples on different
+platforms. In contrast our tests show we get good run-time results
+with all our Octave examples for Octave-3.0.1. Also, that is the
+recommended stable version of Octave at
+http://www.gnu.org/software/octave/download.html so that is the only
+version of Octave we support at this time.
+
+(5.9.1) We have decided for consistency sake to change the PLplot
+stream variables plsc->vpwxmi, plsc->vpwxma, plsc->vpwymi, and
+plsc->vpwyma and the results returned by plgvpw to reflect the exact
+window limit values input by users using plwind. Previously to this
+change, the stream variables and the values returned by plgvpw
+reflected the internal slightly expanded range of window limits used
+by PLplot so that the user's specified limits would be on the graph.
+Two users noted this slight difference, and we agree with them it
+should not be there. Note that internally, PLplot still uses the
+expanded ranges so most users results will be identical.  However, you
+may notice some small changes to your plot results if you use these
+stream variables directly (only possible in C/C++) or use plgvpw.
+
+5. Changes relative to PLplot 5.8.0 (the previous stable release)
+
+N.B. This release includes many code cleanups and fixes relative to
+5.8.0 that are not mentioned in the list below.
+
+5.1 All autotools-related files have now been removed
+
+CMake is now the only supported build system. It has been tested on
+Linux / Unix, Mac OS-X and Windows platforms.
+
+5.2 Build system bug fixes
+
+Various fixes include the following:
+
+Ctest will now work correctly when the build tree path includes symlinks.
+
+Dependencies for swig generated files fixed so they are not rebuilt every
+time make is called.
+
+Various dependency fixes to ensure that parallel builds (using make -j)
+work under unix.
+
+5.3 Build system improvements
+
+We now transform link flag results delivered to the CMake environment by
+pkg-config into the preferred CMake form of library information.  The
+practical effect of this improvement is that external libraries in
+non-standard locations now have their rpath options set correctly for our
+build system both for the build tree and the install tree so you don't have
+to fiddle with LD_LIBRARY_PATH, etc.
+
+5.4 Implement build-system infrastructure for installed Ada bindings and
+examples
+
+Install source files, library information files, and the plplotada library
+associated with the Ada bindings.  Configure and install the pkg-config file
+for the plplotada library.  Install the Ada examples and a configured Makefile
+to build them in the install tree.
+
+5.5 Code cleanup
+
+The PLplot source code has been cleaned up to make consistent use of
+(const char *) and (char *) throughout. Some API functions have changed
+to use const char * instead of char * to make it clear that the strings
+are not modified by the function. The C and C++ examples have been updated
+consistent with this. These changes fix a large number of warnings
+with gcc-4.5. Note: this should not require programs using PLplot to be
+recompiled as it is not a binary API change.
+
+There has also been some cleanup of include files in the C++ examples
+so the code will compile with the forthcoming gcc-4.3.
+
+5.6 Date / time labels for axes
+
+PLplot now allows date / time labels to be used on axes. A new option
+('d') is available for the xopt and yopt arguments to plbox which
+indicates that the axis should be interpreted as a date / time. Similarly
+there is a new range of options for plenv to select date / time labels.
+The time format is seconds since the epoch (usually 1 Jan 1970). This
+format is commonly used on most systems. The C gmtime routine can be
+used to calculate this for a given date and time. The format for the
+labels is controlled using a new pltimefmt function, which takes a
+format string. All formatting is done using the C strftime function.
+See documentation for available options on your platform. Example 29
+demonstrates the new capabilities.
+
+N.B. Our reliance on C library POSIX time routines to (1) convert from
+broken-down time to time-epoch, (2) to convert from time-epoch to
+broken-down time, and (3) to format results with strftime have proved
+problematic for non-C languages which have time routines of variable
+quality.  Also, it is not clear that even the POSIX time routines are
+available on Windows. So we have plans afoot to implement high-quality
+versions of (1), (2), and (3) with additional functions to get/set the epoch
+in the PLplot core library itself.  These routines should work on all C
+platforms and should also be uniformly accessible for all our language
+bindings.
+
+WARNING.....  Therefore, assuming these plans are implemented, the present
+part of our date/time PLplot API that uses POSIX time routines will be
+changed.
+
+5.7 Alpha value support
+
+PLplot core has been modified to support a transparency or alpha value
+channel for each color in color map 0 and 1. In addition a number of new
+functions were added the PLplot API so that the user can both set and query
+alpha values for color in the two color maps. These functions have the same
+name as their non-alpha value equivalents, but with a an "a" added to the
+end. Example 30 demonstrates some different ways to use these functions
+and the effects of alpha values, at least for those drivers that support alpha
+values. This change should have no effect on the device drivers that do not
+currently support alpha values. Currently only the cairo, qt, gd, wxwidgets and
+aquaterm drivers support alpha values. There are some limitations with the gd
+driver due to transparency support in the underlying libgd library.
+
+5.8 New PLplot functions
+
+An enhanced version of plimage, plimagefr has been added. This allows images
+to be plotted using coordinate transformation, and also for the dynamic range
+of the plotted values to be altered. Example 20 has been modified to
+demonstrate this new functionality.
+
+To ensure consistent results in example 21 between different platforms and
+language bindings PLplot now includes a small random number generator within
+the library. plrandd will return a PLFLT random number in the range 0.0-1.0.
+plseed will allow the random number generator to be seeded.
+
+5.9 External libLASi library improvements affecting our psttf device
+
+Our psttf device depends on the libLASi library. libLASi-1.1.0 has just been
+released at http://sourceforge.net/svn/?group_id=187113 .  We recommend
+using this latest version of libLASi for building PLplot and the psttf
+device since this version of libLASi is more robust against glyph
+information returned by pango/cairo/fontconfig that on rare occasions is not
+suitable for use by libLASi.
+
+5.10 Improvements to the cairo driver family
+
+Jonathan Woithe improved the xcairo driver so that it can optionally be
+used with an external user supplied X Drawable. This enables a nice
+separation of graphing (PLplot) and window management (Gtk, etc..). Doug
+Hunt fixed the bugs that broke the memcairo driver and it is now fully
+functional. Additionally, a new extcairo driver was added that will plot
+into a user supplied cairo context.
+
+5.11 wxWidgets driver improvements
+
+Complete reorganization of the driver code. A new backend was added, based
+on the wxGraphicsContext class, which is available for wxWidgets 5.8.4
+and later. This backend produces antialiased output similar to the
+AGG backend but has no dependency on the AGG library. The basic wxDC
+backend and the wxGraphicsContext backend process the text output
+on their own, which results in much nicer plots than with the standard
+Hershey fonts and is much faster than using the freetype library. New
+options were introduced in the wxWidgets driver:
+ - backend: Choose backend: (0) standard, (1) using AGG library,
+                            (2) using wxGraphicsContext
+ - hrshsym: Use Hershey symbol set (hrshsym=0|1)
+ - text: Use own text routines (text=0|1)
+ - freetype: Use FreeType library (freetype=0|1)
+The option "text" changed its meaning, since it enabled the FreeType library
+support, while now the option enables the driver's own text routines.
+
+Some other features were added:
+ * the wxWidgets driver now correctly clears the background (or parts of it)
+ * transparency support was added
+ * the "locate mode" (already available in the xwin and tk driver) was
+   implemented, where graphics input events are processed and translated
+   to world coordinates
+
+5.12 pdf driver improvements
+
+The pdf driver (which is based on the haru library http://www.libharu.org)
+processes the text output now on its own. So far only the Adobe Type1
+fonts are supported. TrueType font support will follow. Full unicode
+support will follow after the haru library will support unicode strings. The
+driver is now able to produce A4, letter, A5 and A3 pages. The Hershey font
+may be used only for symbols. Output can now be compressed, resulting in
+much smaller file sizes.
+Added new options:
+ - text: Use own text routines (text=0|1)
+ - compress: Compress pdf output (compress=0|1)
+ - hrshsym: Use Hershey symbol set (hrshsym=0|1)
+ - pagesize: Set page size (pagesize=A4|letter|A3|A5)
+
+5.13 svg driver improvements
+
+This device driver has had the following improvements: schema for generated
+file now validates properly at http://validator.w3.org/ for the
+automatically detected document type of SVG 1.1; -geometry option now works;
+alpha channel transparency has been implemented; file familying for
+multipage examples has been implemented; coordinate scaling has been
+implemented so that full internal PLplot resolution is used; extraneous
+whitespace and line endings that were being injected into text in error have
+now been removed; and differential correction to string justification is now
+applied.
+
+The result of these improvements is that our SVG device now gives the
+best-looking results of all our devices.  However, currently you must be
+careful of which SVG viewer or editor you try because a number of them have
+some bugs that need to be resolved.  For example, there is a librsvg bug in
+text placement (http://bugzilla.gnome.org/show_bug.cgi?id=525023) that
+affects all svg use within GNOME as well as the ImageMagick "display"
+application.  However, at least the latest konqueror and firefox as well as
+inkscape and scribus-ng (but not scribus!) give outstanding looking results
+for files generated by our svg device driver.
+
+5.14 Ada language support
+
+We now have a complete Ada bindings implemented for PLplot. We also have a
+complete set of our standard examples implemented in Ada which give results
+that are identical with corresponding results for the C standard examples.
+This is an excellent test of a large subset of the Ada bindings. We now
+enable Ada by default for our users and request widespread testing of this
+new feature.
+
+5.15 OCaml language support
+
+Thanks primarily to Hezekiah M. Carty's efforts we now have a complete OCaml
+bindings implemented for PLplot. We also have a complete set of our standard
+examples implemented in OCaml which give results that are identical with
+corresponding results for the C standard examples. This is an excellent test
+of a large subset of the OCaml bindings. We now enable OCaml by default for
+our users and request widespread testing of this new feature.
+
+5.16 Perl/PDL language support
+
+Thanks to Doug Hunt's efforts the external Perl/PDL module,
+PDL::Graphics::PLplot version 0.46 available at
+http://search.cpan.org/dist/PDL-Graphics-PLplot has been brought up to date
+to give access to recently added PLplot API.  The instructions for how to
+install this module on top of an official PDL release are given in
+examples/perl/README.perldemos. Doug has also finished implementing a
+complete set of standard examples in Perl/PDL which are part of PLplot and
+which produce identical results to their C counterparts if the above updated
+module has been installed.  Our build system tests the version of
+PDL::Graphics::PLplot that is available, and if it is not 0.46 or later, the
+list of Perl/PDL examples that are run as part of our standard tests is
+substantially reduced to avoid examples that use the new functionality.  In
+sum, if you use PDL::Graphics::PLplot version 0.46 or later the full
+complement of PLplot commands is available to you from Perl/PDL, but
+otherwise not.
+
+5.17 Updates to various language bindings
+
+A concerted effort has been made to bring all the language bindings up to
+date with recently added functions. Ada, C++, f77, f95, Java, OCaml, Octave,
+Perl/PDL, Python, and Tcl now all support the common PLplot API (with the
+exception of the mapping functions which are not yet implemented for all
+bindings due to technical issues.) This is a significant step forward for
+those using languages other than C.
+
+5.18 Updates to various examples
+
+To help test the updates to the language bindings the examples have been
+thoroughly checked. Ada, C, C++, f77, f95, and OCaml now contain a full set
+of non-interactive tests (examples 1-31 excluding 14 and 17). Java, Octave,
+Python and Tcl are missing example 19 because of the issue with the mapping
+functions. The examples have also been checked to ensure consistent results
+between different language bindings. Currently there are still some minor
+differences in the results for the tcl examples, probably due to rounding
+errors.  Some of the Tcl examples (example 21) require Tcl version 8.5 for
+proper support for NaNs.
+
+Also new is an option for the plplot_test.sh script to run the examples
+using a debugging command. This is enabled using the --debug option. The
+default it to use the valgrind memory checker. This has highlighted at
+least one memory leaks in PLplot which have been fixed. It is not part
+of the standard ctest tests because it can be _very_ slow for a complete
+set of language bindings and device drivers.
+
+5.19 Extension of our test framework
+
+The standard test suite for PLplot now carries out a comparison of the
+stdout output (especially important for example 31 which tests most of our
+set and get functions) and PostScript output for different languages as a
+check.  Thanks to the addition of example 31, the inclusion of examples 14
+and 17 in the test suite and other recent extensions of the other
+examples we now have rigorous testing in place for almost the entirety
+of our common API.  This extensive testing framework has already helped
+us track down a number of bugs, and it should make it much easier for us
+to maintain high quality for our ongoing PLplot releases.
+
+5.20 Rename test subdirectory to plplot_test
+
+This change was necessary to quit clashing with the "make test" target which
+now works for the first time ever (by executing ctest).
+
+5.21 Website support files updated
+
+Our new website content is generated with PHP and uses CSS (cascaded style
+sheets) to implement a consistent style.  This new approach demanded lots of
+changes in the website support files that are used to generate and upload
+our website and which are automatically included with the release.
+
+5.22 Internal changes to function visibility
+
+The internal definitions of functions in PLplot have been significantly
+tidied up to allow the use of the -fvisibility=hidden option with newer
+versions of gcc. This prevents internal functions from being exported
+to the user where possible. This extends the existing support for this
+on windows.
+
+5.23 Dynamic driver support in Windows
+
+An interface based on the ltdl library function calls was established
+which allows to open and close dynamic link libraries (DLL) during
+run-time and call functions from these libraries. As a consequence
+drivers can now be compiled into single DLLs separate from the core
+PLplot DLL also in Windows. The cmake option ENABLE_DYNDRIVERS is now
+ON by default for Windows if a shared PLplot library is built.
+
+5.24 Documentation updates
+
+The DocBook documentation has been updated to include many of the
+C-specific functions (for example plAlloc2dGrid) which are not part
+of the common API, but are used in the examples and may be helpful
+for PLplot users.
+
+5.25 libnistcd (a.k.a. libcd) now built internally for -dev cgm
+
+CGM format is a long-established (since 1987) open standard for vector
+graphics that is supported by w3c (see http://www.w3.org/Graphics/WebCGM/).
+PLplot has long had a cgm device driver which depended on the (mostly)
+public domain libcd library that was distributed in the mid 90's by National
+Institute of Standards and Technology (NIST) and which is still available
+from http://www.pa.msu.edu/ftp/pub/unix/cd1.3.tar.gz.  As a convenience
+to our -dev cgm users, we have brought that
+source code in house under lib/nistcd and now build libnistcd routinely
+as part of our ordinary builds.  The only changes we have made to the
+cd1.3 source code is visibility changes in cd.h and swapping the sense of
+the return codes for the test executables so that 0 is returned on success
+and 1 on failure.  If you want to test libnistcd on your platform,
+please run
+
+make test_nistcd
+
+in the top-level build tree.  (That tests runs all the test executables
+that are built as part of cd1.3 and compares the results that are generated
+with the *.cgm files that are supplied as part of cd1.3.)
+
+Two applications that convert and/or display CGM results on Linux are
+ralcgm (which is called by the ImageMagick convert and display applications)
+and uniconvertor.
+
+Some additional work on -dev cgm is required to implement antialiasing and
+non-Hershey fonts, but both those should be possible using libnistcd according
+to the text that is shown by lib/nistcd/cdtext.cgm and lib/nistcd/cdexp1.cgm.
+
+5.26 get-drv-info now changed to test-drv-info
+
+To make cross-building much easier for PLplot we now configure the *.rc
+files that are used to describe our various dynamic devices rather than
+generating the required *.rc files with get-drv-info.  We have changed the
+name of get-drv-info to test-drv-info.  That name is more appropriate
+because that executable has always tested dynamic loading of the driver
+plug-ins as well as generating the *.rc files fro...
 
[truncated message content]