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

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

Revision: 12561
          http://sourceforge.net/p/plplot/code/12561
Author:   airwin
Date:     2013-10-01 06:22:48 +0000 (Tue, 01 Oct 2013)
Log Message:
-----------
Prepend README.release for 5.9.10 to this file.

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

Modified: trunk/OLD-README.release
===================================================================
--- trunk/OLD-README.release	2013-09-30 23:24:39 UTC (rev 12560)
+++ trunk/OLD-README.release	2013-10-01 06:22:48 UTC (rev 12561)
@@ -1,3 +1,1648 @@
+PLplot Release 5.9.10
+~~~~~~~~~~~~~~~~~~~~
+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/mail/?group_id=2915 (preferred) or on our bug tracker
+at http://sourceforge.net/tracker/?group_id=2915&atid=102915.
+
+     Please see the license under which this software is distributed
+(LGPL), and the disclaimer of all warranties, given in the COPYING.LIB
+file.
+
+INDEX
+
+OFFICIAL NOTICES FOR USERS
+
+CHANGES
+
+-1. Important changes we should have mentioned in previous release announcements.
+
+-1.1 Add full bindings and examples for the D language.
+
+0. Tests made for release 5.9.10
+
+1. Changes relative to PLplot 5.9.9 (the previous development release)
+
+1.1 The format for map data used by plmap has changed
+1.2 Python support for Numeric has been dropped
+1.3 Backwards-incompatible API change to non-integer line widths
+1.4 Improvements to the build system for the Cygwin case
+1.5 The plcolorbar API has been finalized
+1.6 Documentation of the new legend and color bar capabilities of PLplot
+1.7 The D bindings and examples have been converted from the
+old version of D (D1) to the new version of D (D2)
+1.8 The DocBook documentation for PLplot is now generated using modern
+XML/XSL backend tools for DocBook
+1.9 Implement experimental build_projects sub-project
+1.10 Implement extremely simple "00" example
+1.11 Convert to using the Allura form of SourceForge software
+1.12 Use NON_TRANSITIVE linking by default for the shared libraries case for
+all non-windows systems
+1.13 Update f95 examples to take larger advantage of Fortran 95 capabilities
+1.14 Substantial additions to the doxygen documentation
+
+2. Changes relative to PLplot 5.8.0 (the previous stable release)
+
+2.1 All autotools-related files have now been removed
+2.2 Build system bug fixes
+2.3 Build system improvements
+2.4 Implement build-system infrastructure for installed Ada bindings and
+examples
+2.5 Code cleanup
+2.6 Date / time labels for axes
+2.7 Alpha value support
+2.8 New PLplot functions
+2.9 External libLASi library improvements affecting our psttf device
+2.10 Improvements to the cairo driver family
+2.11 wxWidgets driver improvements
+2.12 pdf driver improvements
+2.13 svg driver improvements
+2.14 Ada language support
+2.15 OCaml language support
+2.16 Perl/PDL language support
+2.17 Update to various language bindings
+2.18 Update to various examples
+2.19 Extension of our test framework
+2.20 Rename test subdirectory to plplot_test
+2.21 Website support files updated
+2.22 Internal changes to function visibility
+2.23 Dynamic driver support in Windows
+2.24 Documentation updates
+2.25 libnistcd (a.k.a. libcd) now built internally for -dev cgm
+2.26 get-drv-info now changed to test-drv-info
+2.27 Text clipping now enabled by default for the cairo devices
+2.28 A powerful qt device driver has been implemented
+2.29 The PLplot API is now accessible from Qt GUI applications
+2.30 NaN / Inf support for some PLplot functions
+2.31 Various bug fixes
+2.32 Cairo driver improvements
+2.33 PyQt changes
+2.34 Color Palettes
+2.35 Re-implementation of a "soft landing" when a bad/missing compiler is
+detected
+2.36 Make PLplot aware of LC_NUMERIC locale
+2.37 Linear gradients have been implemented
+2.38 Cairo Windows driver implemented
+2.39 Custom axis labelling implemented
+2.40 Universal coordinate transform implemented
+2.41 Support for arbitrary storage of 2D user data
+2.42 Font improvements
+2.42 Alpha value support for plotting in memory.
+2.43 Add a Qt device for in memory plotting.
+2.44 Add discrete legend capability.
+2.45 Add full bindings and examples for the D language.
+2.46 The plstring and plstring3 functions have been added
+2.47 The pllegend API has been finalized
+2.48 Octave bindings now implemented with swig
+2.49 Documentation redone for our swig-generated Python and Octave bindings
+2.50 Support large polygons
+2.51 Complete set of PLplot parameters now available for Fortran
+2.52 The plarc function has been added
+2.53 The format for map data used by plmap has changed
+2.54 Python support for Numeric has been dropped
+2.55 Backwards-incompatible API change to non-integer line widths
+2.56 Improvements to the build system for the Cygwin case
+2.57 The plcolorbar API has been finalized
+2.58 Documentation of the new legend and color bar capabilities of PLplot
+2.59 The D bindings and examples have been converted from the
+old version of D (D1) to the new version of D (D2)
+2.60 The DocBook documentation for PLplot is now generated using modern
+XML/XSL backend tools for DocBook
+2.61 Implement experimental build_projects sub-project
+2.62 Implement extremely simple "00" example
+2.63 Convert to using the Allura form of SourceForge software
+2.64 Use NON_TRANSITIVE linking by default for the shared libraries case for
+all non-windows systems
+2.65 Update f95 examples to take larger advantage of Fortran 95 capabilities
+2.66 Substantial additions to the doxygen documentation
+
+
+OFFICIAL NOTICES FOR USERS
+
+(5.9.10) The minimum version of CMake has been bumped to 2.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 2.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 2.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 2.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-2.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.
+
+CHANGES
+
+0. Tests made for release 5.9.10
+
+Comprehensive testing that showed no non-zero return codes or other
+obvious run-time issues such as segfaults was done for the Debian
+Wheezy platform.  These tests were done with the
+scripts/comprehensive_test.sh which does 21 major tests.  Those tests
+consist of seven tests (ctest, and "make test_noninteractive" and make
+"test_interactive" results for the build tree, and "make
+test_noninteractive" and make "test_interactive" results for both the
+traditional and CMake-based build systems for the installed examples
+tree) for each of our three major configurations (shared
+libraries/dynamic devices, shared libraries/non-dynamic devices,
+static libraries/non-dynamic devices).
+
+More limited testing that showed no non-zero return codes or other
+obvious run-time issues such as segfaults was done on a large number
+of different platforms including the following:
+
+Fedora with "Unix Makefiles" generator
+Ubuntu with "Unix Makefiles" generator
+Debian unstable with "Unix Makefiles" generator
+Debian wheezy with "Ninja" generator
+Wine version of Windows with "MSYS Makefiles" generator
+Wine version of Windows with "MinGW Makefiles" generator
+Wine version of Windows with "NMake Makefiles JOM" generator
+Microsoft version of Windows with Cygwin and with "Unix Makefiles" generator
+Microsoft version of Windows with "MinGW Makefiles" generator
+Microsoft version of Windows with "MSYS Makefiles" generator
+Microsoft version of Windows with "NMake Makefiles" generator
+
+1. Changes relative to PLplot 5.9.9 (the previous development release)
+
+N.B. This release includes many code cleanups and fixes relative to
+5.9.9 that are not mentioned in the list below.
+
+1.1 The format for map data used by plmap has changed
+
+The format for map data used by plmap is now the shapefile format.
+This is a widely used standard format and there are many sources of data
+in this format. This replaces the custom binary format that PLplot used
+to use. The support for reading shapefiles is provided by the shapelib
+library, which is a new dependency for PLplot. If users do not have this
+installed then, by default, they will not get any map capabilities with
+PLplot. Support for the old format can still be enabled by setting the
+PL_DEPRECATED cmake variable, but this support will be removed in a
+subsequent PLplot release.
+
+1.2 Python support for Numeric has been dropped
+
+Support for the python Numeric package has been dropped. This has been
+deprecated since 5.9.6. Numeric 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.
+
+1.3 Backwards-incompatible API change to non-integer line widths
+
+All functions which take line width arguments (plwidth, plshade*,
+pllegend) now use PLFLT values for the line width. This allows device
+drivers which are based on modern graphics libraries such as Qt4 and
+pango/cairo to make full use (e.g., extremely fine line widths) of the
+floating-point line width capabilities of those libraries.  The
+replacement of plwid by plwidth, and the change in argument lists for
+plshade* and pllegend constitute a backwards incompatible API change
+from previous releases and the soname of libraries has been bumped
+accordingly (which forces users to recompile PLplot).
+
+1.4 Improvements to the build system for the Cygwin case
+
+The Cygwin platform provides a full-featured Unix environment on
+Windows.  CMake has recently been changed (at the request of Cygwin
+developers) to emphasize the Unix aspects of the Cygwin platform and
+deemphasize the Windows aspects of that platform.  It was argued this
+change would tend to make CMake builds of software much more reliable
+on Cygwin, and after some small but important changes to our
+CMake-based build system to adjust for these recent CMake changes for
+Cygwin, we have indeed confirmed that prediction for the PLplot case.
+There are still some Cygwin platform issues left which are being
+discussed on our Wiki at http://www.miscdebris.net/plplot_wiki/index.php?title=Setup_cygwin,
+but some fundamental breakthroughs have also been made for the Cygwin case
+that should interest all our Windows users.  For example, for the
+first time ever we have been able to build our cairo and qt device
+drivers on the Cygwin platform giving our Windows users convenient
+access to the many high-quality PLplot devices that are available with
+these two different device drivers.
+
+1.5 The plcolorbar API has been finalized
+
+The function plcolorbar allows users to create a color bar (an
+annotated subplot representing a continuous range of colors within the
+main plot and typically identifying certain colors with certain
+numerical values using an axis).  The plcolorbar capabilities are
+documented in our DocBook (and doxygen) documentation and demonstrated
+in standard examples 16 and 33.
+
+N.B. The previous two releases (5.9.8 and 5.9.9) contained
+unadvertised experimental versions of plcolorbar.  Any PLplot user who
+found and tried those capabilities will have to reprogramme their
+plcolorbar calls to be compatible with the argument list of the latest
+version.
+
+1.6 Documentation of the new legend and color bar capabilities of PLplot
+
+The pllegend and plcolorbar API has been documented in both doxygen
+and DocBook forms.  In addition, the "advanced use" chapter of the
+DocBook form of documentation now contains a section giving an
+overview of pllegend and plcolorbar.
+
+N.B. Although we feel the pllegend and plcolorbar API has now been
+finalized with regard to the PLplot core developers own interests and
+needs, we also realize that as more and more PLplot users take
+advantage of these new PLplot capabilities there will likely be calls
+to add additional features to pllegend or plcolorbar based on
+additional experience with these powerful capabilities.  In general,
+we would welcome such feature requests.
+
+1.7 The D bindings and examples have been converted from the
+old version of D (D1) to the new version of D (D2)
+
+This change should make PLplot much more relevant for D users
+going forward.
+
+See http://en.wikipedia.org/wiki/D_(programming_language)#History for
+a discussion of the differences between these two variants of D.
+
+1.8 The DocBook documentation for PLplot is now generated using modern
+XML/XSL backend tools for DocBook
+
+These modern backend tools (such as xmlto) replace the
+deprecated/unmaintained SGML/DSSL tools we have used before.  For
+developers this means generation of our DocBook generation is much
+easier. much faster, and much less error-prone.  End users will notice
+some improvements in the results (e.g., the table of Greek letters) as
+well as some minor style changes.
+
+1.9 Implement experimental build_projects sub-project
+
+The idea here (see cmake/build_projects) is to automate the build of
+all PLplot dependencies and the build and test of PLplot itself for
+platforms (such as Linux enterprise distributions and all forms of
+Windows platforms other than Cygwin) that do not come with modern
+versions of PLplot soft dependencies such as Pango/Cairo and Qt.
+This project is beginning to work properly for the Linux case, but
+still needs lots of work for the Windows case.
+
+1.10 Implement extremely simple "00" example
+
+The point of this standard example is to give the users an extremely
+simple tutorial example to help them to get started with 2D plotting
+with PLplot.
+
+1.11 Convert to using the Allura form of SourceForge software
+
+We use sourceforge.net as our software hosting facility.  Early in
+2013 Sourceforge updated essentially all their support software as
+part of the so-called Allura project.  This made it necessary to make
+some minor internal PLplot changes such as script changes and different URL's
+in the website referring to SourceForge facilities.  The most important
+change from the user perspective is the URL for the Allura form
+of the svn repository that we use now:
+
+http://svn.code.sf.net/p/plplot/code/trunk/
+
+1.12 Use NON_TRANSITIVE linking by default for the shared libraries case for
+all non-windows systems
+
+The point of this change is to reduce overlinking and therefore
+the problems caused by overlinking that are mentioned
+at http://en.altlinux.org/UnderOverLinkProblems.
+
+Non-transitive linking means link only to libraries that directly
+resolve undefined symbols, i.e., do not link to a library just because
+it is a dependency of a dependency.
+
+1.13 Update f95 examples to take larger advantage of Fortran 95 capabilities
+
+Previously our f95 examples tended to use legacy Fortran capabilities, but
+that situation has substantially changed for this release.
+
+1.14 Substantial additions to the doxygen documentation
+
+One of the on-going documentation projects is to create doxygen
+documentation of every single argument of the public API for PLplot.
+A substantial increase in such documentation has been implemented
+in this release cycle.
+
+2. 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.
+
+2.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.
+
+2.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.
+
+2.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.
+
+2.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.
+
+2.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.2. 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.
+
+2.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.
+
+2.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.
+
+2.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.
+
+2.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.
+
+2.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.
+
+2.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 2.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
+
+2.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)
+
+2.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.
+
+2.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.
+
+2.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.
+
+2.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.
+
+2.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.
+
+2.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.
+
+2.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.
+
+2.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).
+
+2.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.
+
+2.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.
+
+2.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.
+
+2.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.
+
+2.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.
+
+2.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 from the information gleaned
+from that dynamic loading.  Now, we simply run test-drv-info as an option
+(defaults to ON unless cross-building is enabled) and compare the resulting
+*.rc file with the one configured by cmake to be sure the dynamic device
+has been built correctly.
+
+2.27 Text clipping now enabled by default for the cairo devices
+
+When correct text clipping was first implemented for cairo devices, it was
+discovered that the libcairo library of that era (2007-08) did that clipping
+quite inefficiently so text clipping was disabled by default.  Recent tests
+of text clipping for the cairo devices using libcairo 1.6.4 (released in
+2008-04) shows text clipping is quite efficient now.  Therefore, it is now
+enabled by default.  If you notice a significant slowdown for some libcairo
+version prior to 1.6.4 you can use the option -drvopt text_clipping=0 for
+your cairo device plots (and accept the improperly clipped text results that
+might occur with that option).  Better yet, use libcairo 1.6.4 or later.
+
+2.28 A powerful qt device driver has been implemented
+
+Thanks to the efforts of Alban Rochel of the QSAS team, we now have a new qt
+device driver which delivers the following 9 (!) devices: qtwidget, bmpqt,
+jpgqt, pngqt, ppmqt, tiffqt, epsqt, pdfqt, and svgqt. qtwidget is an
+elementary interactive device where, for now, the possible interactions
+consist of resizing the window and right clicking with the mouse (or hitting
+<return> to be consistent with other PLplot interactive devices) to control
+paging.  The qtwidget overall size is expressed in pixels. bmpqt, jpgqt,
+pngqt, ppmqt, and tiffqt are file devices whose overall sizes are specified
+in pixels and whose output is BMP (Windows bitmap), JPEG, PNG, PPM (portable
+pixmap), and TIFF (tagged image file format) formatted files. epsqt, pdfqt,
+svgqt are file devices whose overall sizes are specified in points (1/72 of
+an inch) and whose output is EPS (encapsulated PostScript), PDF, and SVG
+formatted files.  The qt device driver is based on the powerful facilities
+of Qt4 so all qt devices implement variable opacity (alpha channel) effects
+(see example 30).  The qt devices also use system unicode fonts, and deal
+with CTL (complex text layout) languages automatically without any
+intervention required by the user.  (To show this, try qt device results
+from examples 23 [mathematical symbols] and 24 [CTL languages].)
+
+Our exhaustive Linux testing of the qt devices (which consisted of detailed
+comparisons for all our standard examples between qt device results and the
+corresponding cairo device results) indicates this device driver is mature,
+but testing on other platforms is requested to confirm that maturity. Qt-4.5
+(the version we used for most of our tests) has some essential SVG
+functionality so we recommend that version (downloadable from
+http://www.qtsoftware.com/downloads for Linux, Mac OS X, and Windows) for
+svgqt.  One of our developers found that pdfqt was orders of magnitude
+slower than the other qt devices for Qt-4.4.3 on Ubuntu 8.10 installed on a
+64 bit box.  That problem was completely cured by moving to the downloadable
+Qt-4.5 version.  However, we have also had good Qt-4.4.3 pdfqt reports on
+other platforms.  One of our developers also found that all first pages of
+examples were black for just the qtwidget device for Qt-4.5.1 on Mac OS X.
+From the other improvements we see in Qt-4.5.1 relative to Qt-4.4.3 we
+assume this black first page for qtwidget problem also exists for Qt-4.4.3,
+but we haven't tested that combination.
+
+In sum, Qt-4.4.3 is worth trying if it is already installed on your machine,
+but if you run into any difficulty with it please switch to Qt-4.5.x (once
+Qt-4.5.x is installed all you have to do is to put the 4.5.x version of
+qmake in your path, and cmake does the rest).  If the problem persists for
+Qt-4.5, then it is worth reporting a qt bug.
+
+2.29 The PLplot API is now accessible from Qt GUI applications
+
+This important new feature has been implemented by Alban Rochel of the QSAS
+team as a spin-off of the qt device driver project using the extqt device
+(which constitutes the tenth qt device).  See examples/c++/README.qt_example
+for a brief description of a simple Qt example which accesses the PLplot API
+and which is built in the installed examples tree using the pkg-config
+approach. Our build system has been enhanced to configure the necessary
+plplotd-qt.pc file.
+
+2.30 NaN / Inf support for some PLplot functions
+
+Some PLplot now correctly handle Nan or Inf values in the data to be plotted.
+Line plotting (plline etc) and image plotting (plimage, plimagefr) will
+now ignore NaN / Inf values. Currently some of the contour plotting / 3-d
+routines do not handle NaN / Inf values. This functionality will
+depend on whether the language binding used supports NaN / Inf values.
+
+2.31 Various bug fixes
+
+Various bugs in the 5.9.3 release have been fixed including:
+
+- Include missing file needed for the aqt driver on Mac OS X
+- Missing library version number for nistcd
+- Fixes for the qt examples with dynamic drivers disabled
+- Fixes to several tcl examples so they work with plserver
+- Fix pkg-config files to work correctly with Debug / Release build types set
+- Make Fortran command line argument parsing work with shared libraries on Windows
+
+2.32 Cairo driver improvements
+
+Improvements to the cairo driver to give better results for bitmap
+formats when used with anti-aliasing file viewers.
+
+2.33 PyQt changes
+
+Years ago we got a donation of a hand-crafted pyqt3 interface to PLplot
+(some of the functions in plplot_widgetmodule.c in bindings/python) and a
+proof-of-concept example (prova.py and qplplot.py in examples/python), but
+this code did not gain any developer interest and was therefore not
+understood or maintained. Recently one of our core developers has
+implemented a sip-generated pyqt4 interface to PLplot (controlled by
+plplot_pyqt4.sip in bindings/qt_gui/pyqt4) that builds without problems as a
+python extension module, and a good-looking pyqt4 example (pyqt4_example.py
+in examples/python) that works well.  Since this pyqt4 approach is
+maintained by a PLplot developer it appears to have a good future, and we
+have therefore decided to concentrate on pyqt4 and remove the pyqt3 PLplot
+interface and example completely.
+
+2.34 Color Palettes
+
+Support has been added to PLplot for user defined color palette files.
+These files can be loaded at the command line using the -cmap0 or
+-cmap1 commands, or via the API using the plspal0 and plspal1 commands.
+The commands cmap0 / plspal0 are used to load cmap0 type files which
+specify the colors in PLplot's color table 0. The commands cmap1 /
+plspal1 are used to load cmap1 type files which specify PLplot's color
+table 1. Examples of both types of files can be found in either the
+plplot-source/data directory or the PLplot installed directory
+(typically /usr/local/share/plplotx.y.z/ on Linux).
+
+2.35 Reimplementation of a "soft landing" when a bad/missing compiler is
+detected
+
+The PLplot core library is written in C so our CMake-based build system will
+error out if it doesn't detect a working C compiler.  However all other
+compiled languages (Ada, C++, D, Fortran, Java, and OCaml) we support are
+optional.  If a working compiler is not available, we give a "soft landing"
+(give a warning message, disable the optional component, and keep going).
+The old implementation of the soft landing was not applied consistently (C++
+was unnecessarily mandatory before) and also caused problems for ccmake (a
+CLI front-end to the cmake application) and cmake-gui (a CMake GUI front-end
+to the cmake application) which incorrectly dropped languages as a result
+even when there was a working compiler.
+
+We now have completely reimplemented the soft landing logic.  The result
+works well for cmake, ccmake, and cmake-gui.  The one limitation of this new
+method that we are aware of is it only recognizes either the default
+compiler chosen by the generator or else a compiler specified by the
+environment variable approach (see Official Notice XII above).  Once CMake
+bug 9220 has been fixed (so that the OPTIONAL signature of the
+enable_language command actually works without erroring out), then our
+soft-landing approach (which is a workaround for bug 9220) will be replaced
+by the OPTIONAL signature of enable_language, and all CMake methods of
+specifying compilers and compiler options will automatically be recognized
+as a result.
+
+2.36 Make PLplot aware of LC_NUMERIC locale
+
+For POSIX-compliant systems, locale is set globally so any external
+applications or libraries that use the PLplot library or any external
+libraries used by the PLplot library or PLplot device drivers could
+potentially change the LC_NUMERIC locale used by PLplot to anything those
+external applications and libraries choose. The principal consequence of
+such choice is the decimal separator could be a comma (for some locales)
+rather than the period assumed for the "C" locale.  For previous versions of
+PLplot a comma decimal separator would have lead to a large number of
+errors, but this issue is now addressed with a side benefit that our plots
+now have the capability of displaying the comma (e.g., in axis labels) for
+the decimal separator for those locales which require that.
+
+If you are not satisfied with the results for the default PLplot locale set
+by external applications and libraries, then you can now choose the
+LC_NUMERIC locale for PLplot by (a) specifying the new -locale command-line
+option for PLplot (if you do not specify that option, a default loca...
 
[truncated message content]