File: OLD-README.release

package info (click to toggle)
plplot 5.10.0%2Bdfsg-1
links: PTS, VCS
area: main
in suites: jessie, jessie-kfreebsd
size: 26,280 kB
ctags: 13,512
sloc: ansic: 83,001; xml: 27,081; ada: 18,878; cpp: 15,966; tcl: 11,651; python: 7,075; f90: 7,058; ml: 6,974; java: 6,665; perl: 5,029; sh: 2,210; makefile: 199; lisp: 75; sed: 25; fortran: 7
file content (13390 lines) | stat: -rw-r--r-- 658,152 bytes
parent folder | download | duplicates (2)
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 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.

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

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

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

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

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

5.32 Cairo driver improvements

Improvements to the cairo driver to give better results for bitmap
formats when used with anti-aliasing file viewers.

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

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

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

5.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 locale is
chosen depending on applications and libraries external to PLplot (see
comments above), and (b) setting an environment variable (LC_ALL,
LC_NUMERIC, or LANG on Linux, for example) to some locale that has been
installed on your system.  On Linux, to find what locales are installed, use
the "locale -a" option. The "C" locale is always installed, but usually
there is also a principal locale that works on a platform such as
en_US.UTF8, nl_NL.UTF8, etc.  Furthermore, it is straightforward to build
and install any additional locale you desire.  (For example, on Debian Linux
you do that by running "dpkg-reconfigure locales".)

Normally, users will not use the -locale option since the period
decimal separator that you get for the normal LC_NUMERIC default "C"
locale used by external applications and libraries is fine for their needs.
However, if the resulting decimal separator is not what the user
wants, then they would do something like the following to (a) use a period
decimal separator for command-line input and plots:

LC_ALL=C examples/c/x09c -locale -dev psc -o test.psc -ori 0.5

or (b) use a comma decimal separator for command-line input and plots:

LC_ALL=nl_NL.UTF8 examples/c/x09c -locale -dev psc -o test.psc -ori 0,5

N.B. in either case if the wrong separator is used for input (e.g., -ori 0,5
in the first case or -ori 0.5 in the second) the floating-point conversion
(using atof) is silently terminated at the wrong separator for the locale,
i.e., the fractional part of the number is silently dropped.  This is
obviously not ideal, but on the other hand there are relatively few
floating-point command-line options for PLplot, and we also expect those who
use the -locale option to specifically ask for a given separator for plots
(e.g., axis labels) will then use it for command-line input of
floating-point values as well.

Certain critical areas of the PLplot library (e.g., our color palette file
reading routines and much of the code in our device drivers) absolutely
require a period for the decimal separator.  We now protect those critical
areas by saving the normal PLplot LC_NUMERIC locale (established with the
above -locale option or by default by whatever is set by external
applications or libraries), setting the LC_NUMERIC "C" locale, executing the
critical code, then restoring back to the normal PLplot LC_NUMERIC locale.
Previous versions of PLplot did not have this protection of the critical
areas so were vulnerable to default LC_NUMERIC settings of external
applications that resulted in a comma decimal separator that did not work
correctly for the critical areas.

5.37 Linear gradients have been implemented

The new plgradient routine draws a linear gradient (based on the
current color map 1) at a specified angle with the x axis for a
specified polygon.  Standard examples 25 and 30 now demonstrate use of
plgradient.  Some devices use a software fallback to render the
gradient.  This fallback is implemented with plshades which uses a
series of rectangles to approximate the gradient. Tiny alignment
issues for those rectangles relative to the pixel grid may look
problematic for transparency gradients.  To avoid that issue, we try
to use native gradient capability whenever that is possible for any of
our devices.  Currently, this has been implemented for our svg, qt,
and cairo devices.  The result is nice-looking smooth transparency
gradients for those devices, for, e.g., example 30, page 5.

5.38 Cairo Windows driver implemented

A cairo Windows driver has been implemented. This provides an
interactive cairo driver for Windows similar to xcairo on Linux.
Work to improve its functionality is ongoing.

5.39 Custom axis labelling implemented

Axis text labels can now be customized using the new plslabelfunc function.
This allows a user to specify what text should be draw at a given position
along a plot axis.  Example 19 has been updated to illustrate this function's
use through labelling geographic coordinates in degrees North, South, East and
West.

5.40 Universal coordinate transform implemented

A custom coordinate transformation function can be set using plstransform.
This transformation function affects all subsequent plot function calls which
work with plot window coordinates.  Testing and refinement of this support is
ongoing.

5.41 Support for arbitrary storage of 2D user data

This improvement courtesy of David MacMahon adds support for arbitrary
storage of 2D user data.  This is very similar to the technique employed
by some existing functions (e.g. plfcont and plfshade) that use "evaluator"
functions to access 2D user data that is stored in an arbitrary format.
The new approach extends the concept of a user-supplied (or predefined)
"evaluator" function to a group of user-supplied (or predefined) "operator"
functions.  The operator functions provide for various operations on the
arbitrarily stored 2D data including: get, set, +=, -=, *=, /=, isnan,
minmax, and f2eval.

To facilitate the passing of an entire family of operator functions (via
function pointers), a plf2ops_t structure is defined to contain a
pointer to each type of operator function.  Predefined operator
functions are defined for several common 2D data storage techniques.
Variables (of type plf2ops_t) containing function pointers for these
operator functions are also defined.

New variants of functions that accept 2D data are created.  The new
variants accept the 2D data as two parameters: a pointer to a plf2ops_t
structure containing (pointers to) suitable operator functions and a
PLPointer to the actual 2D data store.  Existing functions that accept
2D data are modified to simply pass their parameters to the
corresponding new variant of the function, along with a pointer to the
suitable predefined plf2ops_t structure of operator function pointers.

The list of functions for which new variants are created is:
c_plimage, c_plimagefr, c_plmesh, c_plmeshc, c_plot3d, c_plot3dc,
c_plot3dcl, c_plshade1, c_plshades, c_plsurf3d, and c_plsurf3dl, and
c_plgriddata.  The new variants are named the same as their
corresponding existing function except that the "c_" prefix is changed
to "plf" (e.g. the new variant of c_plmesh is called plfmesh).

Adds plfvect declaration to plplot.h and changes the names (and only the
names) of some plfvect arguments to make them slightly clearer.  In
order to maintain backwards API compatibility, this function and the
other existing functions that use "evaluator" functions are NOT changed
to use the new operator functions.

Makes plplot.h and libplplot consistent vis-a-vis pltr0f and pltr2d.
Moves the definitions of pltr2f (already declared in plplot.h) from the
sccont.c files of the FORTRAN 77 and Fortran 95 bindings into plcont.c.
Removes pltr0f declaration from plplot.h.

Changes x08c.c to demonstrate use of new support for arbitrary storage
of 2D data arrays.  Shows how to do surface plots with the following
four types of 2D data arrays:

1) PLFLT z[nx][ny];
2) PLfGrid2 z;
3) PLFLT z[nx*ny]; /* row major order */
4) PLFLT z[nx*ny]; /* column major order */

5.42 Font improvements

We have added the underscore to the Hershey glyphs (thanks to David
MacMahon) and slightly rearranged the ascii index to the Hershey
indices so that plpoin now generates the complete set of printable
ascii characters in the correct order for the Hershey fonts (and therefore
the Type1 and TrueType fonts as well).

We have improved how we access TrueType and Type1 fonts via the Hershey
font index (used by plpoin, plsym, and the Hershey escape sequences in pl*tex
commands).  We have added considerably to the Hershey index to Unicode index
translation table both for the compact and extended Hershey indexing scheme,
and we have adopted the standard Unicode to Type1 index translation tables
from http://unicode.org/Public/MAPPINGS/VENDORS/ADOBE/.

We have also dropped the momentary switch to symbol font that was
implemented in the PLplot core library.  That switch was designed to partially
compensate for the lack of symbol glyphs in the standard Type1 fonts.  That
was a bad design because it affected TrueType font devices as well as
the desired Type1 font devices.  To replace this bad idea we now
change from Type1 standard fonts to the Type1 Symbol font (and vice
versa) whenever there is a glyph lookup failure in the Type1 font
device drivers (ps and pdf).

5.42 Alpha value support for plotting in memory.

The function plsmema() was added to the PLplot API. This allows the user
to supply a RGBA formatted array that PLplot can use to do in memory
plotting with alpha value support. At present only the memcairo device
is capable of using RGBA formatted memory. The mem device, at least
for the time being, only supports RGB formatted memory and will exit
if the user attempts to give it RGBA formatted memory to plot in.

5.43 Add a Qt device for in memory plotting.

A new device called memqt has been added for in memory plotting using
Qt. This device is the Qt equivalent of the memcairo device.

5.44 Add discrete legend capability.

A new routine called pllegend has been added to our core C API.
(N.B. This is an experimental API that may be subject to further
change as we gain more experience with it.)  This routine creates a
discrete plot legend with a plotted box, line, and/or line of symbols
for each annotated legend entry. The arguments of pllegend provide
control over the location and size of the legend within the current
subpage as well as the location and characteristics of the elements
(most of which are optional) within that legend. The resulting legend
is clipped at the boundaries of the current subpage

5.45 Add full bindings and examples for the D language.

As of release 5.9.5 we added full bindings and examples for the D
language.  The results for the D examples are generally consistent
with the corresponding C examples which helps to verify the D
bindings.

Since the release of 5.9.5 it has come to our attention that the
version of gdc supplied with several recent versions of Ubuntu has a
very serious bug on 64-bit systems (see
https://bugs.launchpad.net/ubuntu/+source/gdc-4.2/+bug/235955) which
causes several of the plplot D examples to crash. If this affects you,
you are recommended to disable the d bindings or switch to an
alternative d compiler (the Digital Mars compiler is reported to be
good).

5.46 The plstring and plstring3 functions have been added

The plstring function largely supersedes plpoin and plsym
because many(!) more glyphs are accessible with plstring.  The glyph
is specified with a PLplot user string.  As with plmtex and plptex,
the user string can contain FCI escapes to determine the font, UTF-8
code to determine the glyph or else PLplot escapes for Hershey or
unicode text to determine the glyph.  Standard examples 4 and 26 use
plstring.

The plstring3 function largely supersedes plpoin3 for the same (access
to many more glyphs) reasons.  Standard example 18 uses plstring3.

5.47 The pllegend API has been finalized

The function pllegend allows users to create a discrete plot legend
with a plotted colored box, line, and/or line of symbols for each
annotated legend entry.  The pllegend function was first made
available for 5.9.7. Due to feedback from early adopters of pllegend,
we have now added substantially to the pllegend capabilities. and we
now believe pllegend is ready for prime time.  The pllegend
capabilities are documented in our DocBook documentation and
demonstrated in standard examples 4, 26, and 33.

N.B. The current set of changes required a backwards-incompatible
change to the pllegend API.  This requires users who tried this new
functionality for 5.9.7 to reprogramme their pllegend calls.  Since
the pllegend API was labelled experimental for 5.9.7, we will not be
bumping the soversions of the affected PLplot libraries.

5.48 Octave bindings now implemented with swig

Octave is a powerful platform that demands a first-class PLplot
solution, but we were finding it difficult to realize that goal
because we were running up against limitations of the previous
matwrap-generated Octave bindings.  Accordingly, a swig-generated
version of the Octave bindings has now been implemented that builds on
the prior matwrapped bindings effort but also extends it with, e.g.,
bindings for plstring, plstring3, pllegend, and plcolorbar.  These new
octave bindings (which now completely replace the prior matwrapped
bindings) make it possible to run examples 4, 18, 26, and 33 (all of
which have now have been updated to use those functions) and get
consistent results with the corresponding C examples.

Like the matwrapped bindings before it, the new swig-generated octave
bindings currently do not have a number of the PLplot functions
wrapped (e.g., "plmap") that are needed by standard example 19.
However, because of the power of swig we now have some confidence we
can solve this issue in the future.

5.49 Documentation redone for our swig-generated Python and Octave bindings

Through the docstring %feature, swig can generate documentation
strings for certain of the languages it supports (currently Python,
Octave, and Ruby).  We have now removed all such hand-crafted swig
documentation data from bindings/swig-support/plplotcapi.i and
replaced it with generated documentation in the file
bindings/swig-support/swig_documentation.i.  That file is generated
from doc/docbook/src/api.xml using the perl script
doc/docbook/bin/api2swigdoc.pl.  The build system Unix target
"check_swig_documentation" now runs that script and compares results
with bindings/swig-support/swig_documentation.i in the source tree to
make sure that latter file is consistent with any changes that might
have occurred in doc/docbook/src/api.xml.

The resulting Octave and Python user-documentation (obtained by 'help
<PLplot_command_name>' in Octave and 'print ("%s" %
<PLplot_command_name>.__doc__)' in Python is much more detailed than
what was available before using the hand-crafted documentation.  If we
ever decided to generate PLplot bindings for Ruby with swig, this
high-quality user-documentation would be available for that language
as well.

5.50 Support large polygons

Previous releases had an implicit limitation with respect to the
number of vertices in a polygon. This was due to the use of statically
defined arrays (to avoid allocating and freeing memory for each polygon
to be drawn). José Luis García Pallero found this limitation and
provided patches to eliminate this limitation. The strategy is
that for small polygons, the original statically defined arrays
are used and for large polygons new arrays are allocated and freed.
This strategy has been applied to all relevant source files.

5.51 Complete set of PLplot parameters now available for Fortran

The #defines in bindings/swig-support/plplotcapi.i (which are
consistent with those in include/plplot.h) define the complete set of
important PLplot constants (whose names typically start with "PL_").
We have implemented automatic methods of transforming that complete
set of #defines into Fortran parameters that can be used from either
Fortran 77 or Fortran 95.

For Fortran 77, the user must insert an

      include 'plplot_parameters.h'

statement in every function/subroutine/main programme where he expects
to use PLplot constants (whose names typically start with "PL_".  (See
examples/f77/*.fm4 for examples of this method).  When compiling he
must also insert the appropriate -I option to find this file (in
bindings/f77/ in the source tree and currently in
$prefix/lib/fortran/include/plplot$version in the install tree
although that install location may be subject to change).  Note, the
above method does not interfere with existing apps which have
necessarily been forced to define the needed PLplot constants for
themselves.  But for future f77 use, the above statement is
more convenient and much less subject to error than a whole bunch of
parameter statements for the required constants.

For Fortran 95, the complete set of parameters are made available as
part of the plplot module.  So access to this complete set of
parameters is automatic wherever the "use plplot" statement is used.
This is extremely convenient for new Fortran 95 apps that use PLplot,
but, in general, changes will have to be made for existing apps. (See
announcement XX above for the details).

5.52 The plarc function has been added

The plarc function allows drawing filled and outlined arcs in PLplot.
Standard example 3 uses plarc.

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

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

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

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

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

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

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

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

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

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

5.63 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/

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

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

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

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

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

5.69 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 drivers case have been
resolved.

5.70 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.
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 locale is
chosen depending on applications and libraries external to PLplot (see
comments above), and (b) setting an environment variable (LC_ALL,
LC_NUMERIC, or LANG on Linux, for example) to some locale that has been
installed on your system.  On Linux, to find what locales are installed, use
the "locale -a" option. The "C" locale is always installed, but usually
there is also a principal locale that works on a platform such as
en_US.UTF8, nl_NL.UTF8, etc.  Furthermore, it is straightforward to build
and install any additional locale you desire.  (For example, on Debian Linux
you do that by running "dpkg-reconfigure locales".)

Normally, users will not use the -locale option since the period
decimal separator that you get for the normal LC_NUMERIC default "C"
locale used by external applications and libraries is fine for their needs.
However, if the resulting decimal separator is not what the user
wants, then they would do something like the following to (a) use a period
decimal separator for command-line input and plots:

LC_ALL=C examples/c/x09c -locale -dev psc -o test.psc -ori 0.5

or (b) use a comma decimal separator for command-line input and plots:

LC_ALL=nl_NL.UTF8 examples/c/x09c -locale -dev psc -o test.psc -ori 0,5

N.B. in either case if the wrong separator is used for input (e.g., -ori 0,5
in the first case or -ori 0.5 in the second) the floating-point conversion
(using atof) is silently terminated at the wrong separator for the locale,
i.e., the fractional part of the number is silently dropped.  This is
obviously not ideal, but on the other hand there are relatively few
floating-point command-line options for PLplot, and we also expect those who
use the -locale option to specifically ask for a given separator for plots
(e.g., axis labels) will then use it for command-line input of
floating-point values as well.

Certain critical areas of the PLplot library (e.g., our color palette file
reading routines and much of the code in our device drivers) absolutely
require a period for the decimal separator.  We now protect those critical
areas by saving the normal PLplot LC_NUMERIC locale (established with the
above -locale option or by default by whatever is set by external
applications or libraries), setting the LC_NUMERIC "C" locale, executing the
critical code, then restoring back to the normal PLplot LC_NUMERIC locale.
Previous versions of PLplot did not have this protection of the critical
areas so were vulnerable to default LC_NUMERIC settings of external
applications that resulted in a comma decimal separator that did not work
correctly for the critical areas.

2.37 Linear gradients have been implemented

The new plgradient routine draws a linear gradient (based on the
current color map 1) at a specified angle with the x axis for a
specified polygon.  Standard examples 25 and 30 now demonstrate use of
plgradient.  Some devices use a software fallback to render the
gradient.  This fallback is implemented with plshades which uses a
series of rectangles to approximate the gradient. Tiny alignment
issues for those rectangles relative to the pixel grid may look
problematic for transparency gradients.  To avoid that issue, we try
to use native gradient capability whenever that is possible for any of
our devices.  Currently, this has been implemented for our svg, qt,
and cairo devices.  The result is nice-looking smooth transparency
gradients for those devices, for, e.g., example 30, page 2.

2.38 Cairo Windows driver implemented

A cairo Windows driver has been implemented. This provides an
interactive cairo driver for Windows similar to xcairo on Linux.
Work to improve its functionality is ongoing.

2.39 Custom axis labelling implemented

Axis text labels can now be customized using the new plslabelfunc function.
This allows a user to specify what text should be draw at a given position
along a plot axis.  Example 19 has been updated to illustrate this function's
use through labelling geographic coordinates in degrees North, South, East and
West.

2.40 Universal coordinate transform implemented

A custom coordinate transformation function can be set using plstransform.
This transformation function affects all subsequent plot function calls which
work with plot window coordinates.  Testing and refinement of this support is
ongoing.

2.41 Support for arbitrary storage of 2D user data

This improvement courtesy of David MacMahon adds support for arbitrary
storage of 2D user data.  This is very similar to the technique employed
by some existing functions (e.g. plfcont and plfshade) that use "evaluator"
functions to access 2D user data that is stored in an arbitrary format.
The new approach extends the concept of a user-supplied (or predefined)
"evaluator" function to a group of user-supplied (or predefined) "operator"
functions.  The operator functions provide for various operations on the
arbitrarily stored 2D data including: get, set, +=, -=, *=, /=, isnan,
minmax, and f2eval.

To facilitate the passing of an entire family of operator functions (via
function pointers), a plf2ops_t structure is defined to contain a
pointer to each type of operator function.  Predefined operator
functions are defined for several common 2D data storage techniques.
Variables (of type plf2ops_t) containing function pointers for these
operator functions are also defined.

New variants of functions that accept 2D data are created.  The new
variants accept the 2D data as two parameters: a pointer to a plf2ops_t
structure containing (pointers to) suitable operator functions and a
PLPointer to the actual 2D data store.  Existing functions that accept
2D data are modified to simply pass their parameters to the
corresponding new variant of the function, along with a pointer to the
suitable predefined plf2ops_t structure of operator function pointers.

The list of functions for which new variants are created is:
c_plimage, c_plimagefr, c_plmesh, c_plmeshc, c_plot3d, c_plot3dc,
c_plot3dcl, c_plshade1, c_plshades, c_plsurf3d, and c_plsurf3dl, and
c_plgriddata.  The new variants are named the same as their
corresponding existing function except that the "c_" prefix is changed
to "plf" (e.g. the new variant of c_plmesh is called plfmesh).

Adds plfvect declaration to plplot.h and changes the names (and only the
names) of some plfvect arguments to make them slightly clearer.  In
order to maintain backwards API compatibility, this function and the
other existing functions that use "evaluator" functions are NOT changed
to use the new operator functions.

Makes plplot.h and libplplot consistent vis-a-vis pltr0f and pltr2d.
Moves the definitions of pltr2f (already declared in plplot.h) from the
sccont.c files of the FORTRAN 77 and Fortran 95 bindings into plcont.c.
Removes pltr0f declaration from plplot.h.

Changes x08c.c to demonstrate use of new support for arbitrary storage
of 2D data arrays.  Shows how to do surface plots with the following
four types of 2D data arrays:

1) PLFLT z[nx][ny];
2) PLfGrid2 z;
3) PLFLT z[nx*ny]; /* row major order */
4) PLFLT z[nx*ny]; /* column major order */

2.42 Font improvements

We have added the underscore to the Hershey glyphs (thanks to David
MacMahon) and slightly rearranged the ascii index to the Hershey
indices so that plpoin now generates the complete set of printable
ascii characters in the correct order for the Hershey fonts (and therefore
the Type1 and TrueType fonts as well).

We have improved how we access TrueType and Type1 fonts via the Hershey
font index (used by plpoin, plsym, and the Hershey escape sequences in pl*tex
commands).  We have added considerably to the Hershey index to Unicode index
translation table both for the compact and extended Hershey indexing scheme,
and we have adopted the standard Unicode to Type1 index translation tables
from http://unicode.org/Public/MAPPINGS/VENDORS/ADOBE/.

We have also dropped the momentary switch to symbol font that was
implemented in the PLplot core library.  That switch was designed to partially
compensate for the lack of symbol glyphs in the standard Type1 fonts.  That
was a bad design because it affected TrueType font devices as well as
the desired Type1 font devices.  To replace this bad idea we now
change from Type1 standard fonts to the Type1 Symbol font (and vice
versa) whenever there is a glyph lookup failure in the Type1 font
device drivers (ps and pdf).

2.42 Alpha value support for plotting in memory.

The function plsmema() was added to the PLplot API. This allows the user
to supply a RGBA formatted array that PLplot can use to do in memory
plotting with alpha value support. At present only the memcairo device
is capable of using RGBA formatted memory. The mem device, at least
for the time being, only supports RGB formatted memory and will exit
if the user attempts to give it RGBA formatted memory to plot in.

2.43 Add a Qt device for in memory plotting.

A new device called memqt has been added for in memory plotting using
Qt. This device is the Qt equivalent of the memcairo device.

2.44 Add discrete legend capability.

A new routine called pllegend has been added to our core C API.
(N.B. This is an experimental API that may be subject to further
change as we gain more experience with it.)  This routine creates a
discrete plot legend with a plotted box, line, and/or line of symbols
for each annotated legend entry. The arguments of pllegend provide
control over the location and size of the legend within the current
subpage as well as the location and characteristics of the elements
(most of which are optional) within that legend. The resulting legend
is clipped at the boundaries of the current subpage

2.45 Add full bindings and examples for the D language.

As of release 5.9.5 we added full bindings and examples for the D
language.  The results for the D examples are generally consistent
with the corresponding C examples which helps to verify the D
bindings.

Since the release of 5.9.5 it has come to our attention that the
version of gdc supplied with several recent versions of Ubuntu has a
very serious bug on 64-bit systems (see
https://bugs.launchpad.net/ubuntu/+source/gdc-4.2/+bug/235955) which
causes several of the plplot D examples to crash. If this affects you,
you are recommended to disable the d bindings or switch to an
alternative d compiler (the Digital Mars compiler is reported to be
good).

2.46 The plstring and plstring3 functions have been added

The plstring function largely supersedes plpoin and plsym
because many(!) more glyphs are accessible with plstring.  The glyph
is specified with a PLplot user string.  As with plmtex and plptex,
the user string can contain FCI escapes to determine the font, UTF-8
code to determine the glyph or else PLplot escapes for Hershey or
unicode text to determine the glyph.  Standard examples 4 and 26 use
plstring.

The plstring3 function largely supersedes plpoin3 for the same (access
to many more glyphs) reasons.  Standard example 18 uses plstring3.

2.47 The pllegend API has been finalized

The function pllegend allows users to create a discrete plot legend
with a plotted colored box, line, and/or line of symbols for each
annotated legend entry.  The pllegend function was first made
available for 5.9.7. Due to feedback from early adopters of pllegend,
we have now added substantially to the pllegend capabilities. and we
now believe pllegend is ready for prime time.  The pllegend
capabilities are documented in our DocBook documentation and
demonstrated in standard examples 4, 26, and 33.

N.B. The current set of changes required a backwards-incompatible
change to the pllegend API.  This requires users who tried this new
functionality for 5.9.7 to reprogramme their pllegend calls.  Since
the pllegend API was labelled experimental for 5.9.7, we will not be
bumping the soversions of the affected PLplot libraries.

2.48 Octave bindings now implemented with swig

Octave is a powerful platform that demands a first-class PLplot
solution, but we were finding it difficult to realize that goal
because we were running up against limitations of the previous
matwrap-generated Octave bindings.  Accordingly, a swig-generated
version of the Octave bindings has now been implemented that builds on
the prior matwrapped bindings effort but also extends it with, e.g.,
bindings for plstring, plstring3, pllegend, and plcolorbar.  These new
octave bindings (which now completely replace the prior matwrapped
bindings) make it possible to run examples 4, 18, 26, and 33 (all of
which have now have been updated to use those functions) and get
consistent results with the corresponding C examples.

Like the matwrapped bindings before it, the new swig-generated octave
bindings currently do not have a number of the PLplot functions
wrapped (e.g., "plmap") that are needed by standard example 19.
However, because of the power of swig we now have some confidence we
can solve this issue in the future.

2.49 Documentation redone for our swig-generated Python and Octave bindings

Through the docstring %feature, swig can generate documentation
strings for certain of the languages it supports (currently Python,
Octave, and Ruby).  We have now removed all such hand-crafted swig
documentation data from bindings/swig-support/plplotcapi.i and
replaced it with generated documentation in the file
bindings/swig-support/swig_documentation.i.  That file is generated
from doc/docbook/src/api.xml using the perl script
doc/docbook/bin/api2swigdoc.pl.  The build system Unix target
"check_swig_documentation" now runs that script and compares results
with bindings/swig-support/swig_documentation.i in the source tree to
make sure that latter file is consistent with any changes that might
have occurred in doc/docbook/src/api.xml.

The resulting Octave and Python user-documentation (obtained by 'help
<PLplot_command_name>' in Octave and 'print ("%s" %
<PLplot_command_name>.__doc__)' in Python is much more detailed than
what was available before using the hand-crafted documentation.  If we
ever decided to generate PLplot bindings for Ruby with swig, this
high-quality user-documentation would be available for that language
as well.

2.50 Support large polygons

Previous releases had an implicit limitation with respect to the
number of vertices in a polygon. This was due to the use of statically
defined arrays (to avoid allocating and freeing memory for each polygon
to be drawn). José Luis García Pallero found this limitation and
provided patches to eliminate this limitation. The strategy is
that for small polygons, the original statically defined arrays
are used and for large polygons new arrays are allocated and freed.
This strategy has been applied to all relevant source files.

2.51 Complete set of PLplot parameters now available for Fortran

The #defines in bindings/swig-support/plplotcapi.i (which are
consistent with those in include/plplot.h) define the complete set of
important PLplot constants (whose names typically start with "PL_").
We have implemented automatic methods of transforming that complete
set of #defines into Fortran parameters that can be used from either
Fortran 77 or Fortran 95.

For Fortran 77, the user must insert an

      include 'plplot_parameters.h'

statement in every function/subroutine/main programme where he expects
to use PLplot constants (whose names typically start with "PL_".  (See
examples/f77/*.fm4 for examples of this method).  When compiling he
must also insert the appropriate -I option to find this file (in
bindings/f77/ in the source tree and currently in
$prefix/lib/fortran/include/plplot$version in the install tree
although that install location may be subject to change).  Note, the
above method does not interfere with existing apps which have
necessarily been forced to define the needed PLplot constants for
themselves.  But for future f77 use, the above statement is
more convenient and much less subject to error than a whole bunch of
parameter statements for the required constants.

For Fortran 95, the complete set of parameters are made available as
part of the plplot module.  So access to this complete set of
parameters is automatic wherever the "use plplot" statement is used.
This is extremely convenient for new Fortran 95 apps that use PLplot,
but, in general, changes will have to be made for existing apps. (See
announcement XX above for the details).

2.52 The plarc function has been added

The plarc function allows drawing filled and outlined arcs in PLplot.
Standard example 3 uses plarc.

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

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

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

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

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

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

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

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

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

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

2.63 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/

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

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

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


PLplot Release 5.9.9
~~~~~~~~~~~~~~~~~~~~
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 bugtracker, then please send bug reports to PLplot
developers via the mailing lists at
http://sourceforge.net/mail/?group_id=2915 (preferred) or on our bugtracker
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.9

1. Changes relative to PLplot 5.9.8 (the previous development release)

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

OFFICIAL NOTICES FOR USERS

(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 colours 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 colours) 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

-1. Important changes we should have mentioned in previous release announcements.

-1.1 Add full bindings and examples for the D language.

As of release 5.9.5 we added full bindings and examples for the D
language.  The results for the D examples are generally consistent
with the corresponding C examples which helps to verify the D
bindings.

Since the release of 5.9.5 it has come to our attention that the
version of gdc supplied with several recent versions of Ubuntu has a
very serious bug on 64-bit systems (see
https://bugs.launchpad.net/ubuntu/+source/gdc-4.2/+bug/235955) which
causes several of the plplot D examples to crash. If this affects you,
you are recommended to disable the d bindings or switch to an
alternative d compiler (the Digital Mars compiler is reported to be
good).


0. Tests made for release 5.9.9

* (Alan W. Irwin) The scripts/comprehensive_test.sh script was run for
  a fully loaded (all Linux bindings other than PDL, all Linux device
  drivers including our qt and cairo device drivers) Debian Squeeze
  Linux platform with no obvious build-time or run-time issues being
  found.  This script runs 7 major tests for each of our three
  principal build configurations (shared library/dynamic device
  drivers, shared libraries/nondynamic device drivers, static
  libraries/nondynamic device drivers). Those 7 tests are ctest and
  the test_noninteractive and test_interactive targets in the build
  tree, the test_noninteractive and test_interactive targets
  configured with CMake in the installed examples tree, and the
  traditional (MakeFile + pkg-config) test_noninteractive and
  test_interactive targets in the installed examples tree.

  These tests were done with OCaml disabled because of a segfault and
  a series of bad valgrind test results that occurred for OCaml
  3.11.2.  We have tentatively ascribed this issue to issues with the
  OCaml stack on that platform since this bad OCaml result contrasts
  with good OCaml results on other reported platforms.  

  In addition to the scripts/comprehensive_test.sh result,
  comprehensive valgrind results were clean for all C examples for
  both -dev psc and -dev epsqt for the build-tree/shared
  library/dynamic device drivers case.  The first result verifies
  there are no core memory management issues for our C library and C
  examples for one of our simpler devices that has no external
  dependencies.  The second result shows in addition that there are no
  memory management issues for our epsqt device and the part of the
  Qt4 version 4.6.3 stack that it uses on this platform.

* (Andrew Ross) For one Ubuntu platform the test_noninteractive and
  test_interactive targets for the shared libraries and dynamic
  drivers case gave good results.  This was for a fully loaded
  platform including our qt and cairo device drivers.

* (Hezekiah M. Carty) scripts/comprehensive_test.sh failed on a Ubuntu
  Linux platform because of segfaults in the qt devices.  We
  have tentatively ascribed this issue to issues with the Qt4 stack of
  libraries on that platform since this bad qt result contrasts with
  the good qt result on the previous two Linux platforms.  When qt devices
  were ignored, clean valgrind results were obtained for OCaml-3.12.1 and
  OCaml-3.11.2 (in contrast to the results seen for OCaml-3.11.2 above).
  Testing with the comprehensive_test.sh script and qt devices disabled
  completed with good results.

* (Arjen Markus) MinGW/MSYS installed on a lightly loaded (at least
  compared to Linux tests) Windows XP system gives good results for
  the test_noninteractive target in the build tree for the shared
  library/dynamic device drivers case.

* (Arjen Markus) The combination of Microsoft Visual C/C++ version 9.0
  and Intel Fortran compilers installed on a lightly loaded Windows XP
  system gives good results for the "all" target for the shared
  library/dynamic device drivers case.  That target just builds the
  software.  In addition, some run-time testing was done by hand with
  no sign of any run-time trouble.

* (Jerry Bauck) Mac OS X 10.6.8 (Snow Leopard) platform with Ada
  bindings and good coverage of devices (e.g., qt and cairo) but
  lightly loaded with regard to non-Ada bindings give fairly good
  results for ctest and the test_noninteractive target for the shared
  library/dynamic device drivers case.  All tests passed including qt
  and cairo device driver tests, but when looking at detailed results
  some missing circular symbol issues were discovered for the pscairo
  results.  We don't understand this issue because the cairo devices
  give both superb and reliable results on our Linux platforms.  The
  cairo device driver depends on a subset (e.g., pango and cairo) of
  the GTK+ stack of libraries.  These results were obtained for GTK+
  version 2.18.5.

* (Werner Smekal) Mac OS X 10.7.1, XCode 4.1 platform that is lightly
  loaded (e.g., GTK+ but no Qt4) gave mixed results for ctest and the
  test_noninteractive target for the shared library/dynamic device
  drivers case.  The build worked without issues, and also everything
  but cairo devices at run time.  However, all cairo device results
  had major run-time errors (e.g., segfaults).  In this case the GTK+
  library was newer than we have tested before (version 2.24 from the
  Homebrew packaging effort as compared to 2.21 that gives such good
  results on Linux) so there may be a mismatch between our cairo
  device driver and this newer version of GTK+ that needs to be sorted
  out.

1. Changes relative to PLplot 5.9.8 (the previous development release)

No notable new features.  This is a bug fix release.  See the above
announcements.

2. Changes relative to PLplot 5.8.0 (the previous stable release)

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 antialized 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 rigourous 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 locale is
chosen depending on applications and libraries external to PLplot (see
comments above), and (b) setting an environment variable (LC_ALL,
LC_NUMERIC, or LANG on Linux, for example) to some locale that has been
installed on your system.  On Linux, to find what locales are installed, use
the "locale -a" option. The "C" locale is always installed, but usually
there is also a principal locale that works on a platform such as
en_US.UTF8, nl_NL.UTF8, etc.  Furthermore, it is straightforward to build
and install any additional locale you desire.  (For example, on Debian Linux
you do that by running "dpkg-reconfigure locales".)

Normally, users will not use the -locale option since the period
decimal separator that you get for the normal LC_NUMERIC default "C"
locale used by external applications and libraries is fine for their needs.
However, if the resulting decimal separator is not what the user
wants, then they would do something like the following to (a) use a period
decimal separator for command-line input and plots:

LC_ALL=C examples/c/x09c -locale -dev psc -o test.psc -ori 0.5

or (b) use a comma decimal separator for command-line input and plots:

LC_ALL=nl_NL.UTF8 examples/c/x09c -locale -dev psc -o test.psc -ori 0,5

N.B. in either case if the wrong separator is used for input (e.g., -ori 0,5
in the first case or -ori 0.5 in the second) the floating-point conversion
(using atof) is silently terminated at the wrong separator for the locale,
i.e., the fractional part of the number is silently dropped.  This is
obviously not ideal, but on the other hand there are relatively few
floating-point command-line options for PLplot, and we also expect those who
use the -locale option to specifically ask for a given separator for plots
(e.g., axis labels) will then use it for command-line input of
floating-point values as well.

Certain critical areas of the PLplot library (e.g., our colour palette file
reading routines and much of the code in our device drivers) absolutely
require a period for the decimal separator.  We now protect those critical
areas by saving the normal PLplot LC_NUMERIC locale (established with the
above -locale option or by default by whatever is set by external
applications or libraries), setting the LC_NUMERIC "C" locale, executing the
critical code, then restoring back to the normal PLplot LC_NUMERIC locale.
Previous versions of PLplot did not have this protection of the critical
areas so were vulnerable to default LC_NUMERIC settings of external
applications that resulted in a comma decimal separator that did not work
correctly for the critical areas.

2.37 Linear gradients have been implemented

The new plgradient routine draws a linear gradient (based on the
current colour map 1) at a specified angle with the x axis for a
specified polygon.  Standard examples 25 and 30 now demonstrate use of
plgradient.  Some devices use a software fallback to render the
gradient.  This fallback is implemented with plshades which uses a
series of rectangles to approximate the gradient. Tiny alignment
issues for those rectangles relative to the pixel grid may look
problematic for transparency gradients.  To avoid that issue, we try
to use native gradient capability whenever that is possible for any of
our devices.  Currently, this has been implemented for our svg, qt,
and cairo devices.  The result is nice-looking smooth transparency
gradients for those devices, for, e.g., example 30, page 2.

2.38 Cairo Windows driver implemented

A cairo Windows driver has been implemented. This provides an
interactive cairo driver for Windows similar to xcairo on Linux.
Work to improve its functionality is ongoing.

2.39 Custom axis labeling implemented

Axis text labels can now be customized using the new plslabelfunc function.
This allows a user to specify what text should be draw at a given position
along a plot axis.  Example 19 has been updated to illustrate this function's
use through labeling geographic coordinates in degrees North, South, East and
West.

2.40 Universal coordinate transform implemented

A custom coordinate transformation function can be set using plstransform.
This transformation function affects all subsequent plot function calls which
work with plot window coordinates.  Testing and refinement of this support is
ongoing.

2.41 Support for arbitrary storage of 2D user data

This improvement courtesy of David MacMahon adds support for arbitrary
storage of 2D user data.  This is very similar to the technique employed
by some existing functions (e.g. plfcont and plfshade) that use "evaluator"
functions to access 2D user data that is stored in an arbitrary format.
The new approach extends the concept of a user-supplied (or predefined)
"evaluator" function to a group of user-supplied (or predefined) "operator"
functions.  The operator functions provide for various operations on the
arbitrarily stored 2D data including: get, set, +=, -=, *=, /=, isnan,
minmax, and f2eval.

To facilitate the passing of an entire family of operator functions (via
function pointers), a plf2ops_t structure is defined to contain a
pointer to each type of operator function.  Predefined operator
functions are defined for several common 2D data storage techniques.
Variables (of type plf2ops_t) containing function pointers for these
operator functions are also defined.

New variants of functions that accept 2D data are created.  The new
variants accept the 2D data as two parameters: a pointer to a plf2ops_t
structure containing (pointers to) suitable operator functions and a
PLPointer to the actual 2D data store.  Existing functions that accept
2D data are modified to simply pass their parameters to the
corresponding new variant of the function, along with a pointer to the
suitable predefined plf2ops_t structure of operator function pointers.

The list of functions for which new variants are created is:
c_plimage, c_plimagefr, c_plmesh, c_plmeshc, c_plot3d, c_plot3dc,
c_plot3dcl, c_plshade1, c_plshades, c_plsurf3d, and c_plsurf3dl, and
c_plgriddata.  The new variants are named the same as their
corresponding existing function except that the "c_" prefix is changed
to "plf" (e.g. the new variant of c_plmesh is called plfmesh).

Adds plfvect declaration to plplot.h and changes the names (and only the
names) of some plfvect arguments to make them slightly clearer.  In
order to maintain backwards API compatibility, this function and the
other existing functions that use "evaluator" functions are NOT changed
to use the new operator functions.

Makes plplot.h and libplplot consistent vis-a-vis pltr0f and pltr2d.
Moves the definitions of pltr2f (already declared in plplot.h) from the
sccont.c files of the FORTRAN 77 and Fortran 95 bindings into plcont.c.
Removes pltr0f declaration from plplot.h.

Changes x08c.c to demonstrate use of new support for arbitrary storage
of 2D data arrays.  Shows how to do surface plots with the following
four types of 2D data arrays:

1) PLFLT z[nx][ny];
2) PLfGrid2 z;
3) PLFLT z[nx*ny]; /* row major order */
4) PLFLT z[nx*ny]; /* column major order */

2.42 Font improvements

We have added the underscore to the Hershey glyphs (thanks to David
MacMahon) and slightly rearranged the ascii index to the Hershey
indices so that plpoin now generates the complete set of printable
ascii characters in the correct order for the Hershey fonts (and therefore
the Type1 and TrueType fonts as well).

We have improved how we access TrueType and Type1 fonts via the Hershey
font index (used by plpoin, plsym, and the Hershey escape sequences in pl*tex
commands).  We have added considerably to the Hershey index to Unicode index
translation table both for the compact and extended Hershey indexing scheme,
and we have adopted the standard Unicode to Type1 index translation tables
from http://unicode.org/Public/MAPPINGS/VENDORS/ADOBE/.

We have also dropped the momentary switch to symbol font that was
implemented in the PLplot core library.  That switch was designed to partially
compensate for the lack of symbol glyphs in the standard Type1 fonts.  That
was a bad design because it affected TrueType font devices as well as
the desired Type1 font devices.  To replace this bad idea we now
change from Type1 standard fonts to the Type1 Symbol font (and vice
versa) whenever there is a glyph lookup failure in the Type1 font
device drivers (ps and pdf).

2.42 Alpha value support for plotting in memory.

The function plsmema() was added to the PLplot API. This allows the user
to supply a RGBA formatted array that PLplot can use to do in memory
plotting with alpha value support. At present only the memcairo device
is capable of using RGBA formatted memory. The mem device, at least
for the time being, only supports RGB formatted memory and will exit
if the user attempts to give it RGBA formatted memory to plot in.

2.43 Add a Qt device for in memory plotting.

A new device called memqt has been added for in memory plotting using
Qt. This device is the Qt equivalent of the memcairo device.

2.44 Add discrete legend capability.

A new routine called pllegend has been added to our core C API.
(N.B. This is an experimental API that may be subject to further
change as we gain more experience with it.)  This routine creates a
discrete plot legend with a plotted box, line, and/or line of symbols
for each annotated legend entry. The arguments of pllegend provide
control over the location and size of the legend within the current
subpage as well as the location and characteristics of the elements
(most of which are optional) within that legend. The resulting legend
is clipped at the boundaries of the current subpage


2.45 Add full bindings and examples for the D language.

As of release 5.9.5 we added full bindings and examples for the D
language.  The results for the D examples are generally consistent
with the corresponding C examples which helps to verify the D
bindings.

Since the release of 5.9.5 it has come to our attention that the
version of gdc supplied with several recent versions of Ubuntu has a
very serious bug on 64-bit systems (see
https://bugs.launchpad.net/ubuntu/+source/gdc-4.2/+bug/235955) which
causes several of the plplot D examples to crash. If this affects you,
you are recommended to disable the d bindings or switch to an
alternative d compiler (the Digital Mars compiler is reported to be
good).

2.46 The plstring and plstring3 functions have been added

The plstring function largely supersedes plpoin and plsym
because many(!) more glyphs are accessible with plstring.  The glyph
is specified with a PLplot user string.  As with plmtex and plptex,
the user string can contain FCI escapes to determine the font, UTF-8
code to determine the glyph or else PLplot escapes for Hershey or
unicode text to determine the glyph.  Standard examples 4 and 26 use
plstring.

The plstring3 function largely supersedes plpoin3 for the same (access
to many more glyphs) reasons.  Standard example 18 uses plstring3.

2.47 The pllegend API has been finalized

The function pllegend allows users to create a discrete plot legend
with a plotted colored box, line, and/or line of symbols for each
annotated legend entry.  The pllegend function was first made
available for 5.9.7. Due to feedback from early adopters of pllegend,
we have now added substantially to the pllegend capabilities. and we
now believe pllegend is ready for prime time.  The pllegend
capabilities are documented in our DocBook documentation and
demonstrated in standard examples 4, 26, and 33.  

N.B. The current set of changes required a backwards-incompatible
change to the pllegend API.  This requires users who tried this new
functionality for 5.9.7 to reprogramme their pllegend calls.  Since
the pllegend API was labelled experimental for 5.9.7, we will not be
bumping the soversions of the affected PLplot libraries.

2.48 Octave bindings now implemented with swig

Octave is a powerful platform that demands a first-class PLplot
solution, but we were finding it difficult to realize that goal
because we were running up against limitations of the previous
matwrap-generated Octave bindings.  Accordingly, a swig-generated
version of the Octave bindings has now been implemented that builds on
the prior matwrapped bindings effort but also extends it with, e.g.,
bindings for plstring, plstring3, pllegend, and plcolorbar.  These new
octave bindings (which now completely replace the prior matwrapped
bindings) make it possible to run examples 4, 18, 26, and 33 (all of
which have now have been updated to use those functions) and get
consistent results with the corresponding C examples.

Like the matwrapped bindings before it, the new swig-generated octave
bindings currently do not have a number of the PLplot functions
wrapped (e.g., "plmap") that are needed by standard example 19.
However, because of the power of swig we now have some confidence we
can solve this issue in the future.

2.49 Documentation redone for our swig-generated Python and Octave bindings

Through the docstring %feature, swig can generate documentation
strings for certain of the languages it supports (currently Python,
Octave, and Ruby).  We have now removed all such hand-crafted swig
documentation data from bindings/swig-support/plplotcapi.i and
replaced it with generated documentation in the file
bindings/swig-support/swig_documentation.i.  That file is generated
from doc/docbook/src/api.xml using the perl script
doc/docbook/bin/api2swigdoc.pl.  The build system Unix target
"check_swig_documentation" now runs that script and compares results
with bindings/swig-support/swig_documentation.i in the source tree to
make sure that latter file is consistent with any changes that might
have occurred in doc/docbook/src/api.xml.

The resulting Octave and Python user-documentation (obtained by 'help
<PLplot_command_name>' in Octave and 'print ("%s" %
<PLplot_command_name>.__doc__)' in Python is much more detailed than
what was available before using the hand-crafted documentation.  If we
ever decided to generate PLplot bindings for Ruby with swig, this
high-quality user-documentation would be available for that language
as well.

2.50 Support large polygons

Previous releases had an implicit limitation with respect to the
number of vertices in a polygon. This was due to the use of statically
defined arrays (to avoid allocating and freeing memory for each polygon
to be drawn). Jos Luis Garca Pallero found this limitation and
provided patches to eliminate this limitation. The strategy is
that for small polygons, the original statically defined arrays
are used and for large polygons new arrays are allocated and freed.
This strategy has been applied to all relevant source files.

2.51 Complete set of PLplot parameters now available for Fortran

The #defines in bindings/swig-support/plplotcapi.i (which are
consistent with those in include/plplot.h) define the complete set of
important PLplot constants (whose names typically start with "PL_").
We have implemented automatic methods of transforming that complete
set of #defines into Fortran parameters that can be used from either
Fortran 77 or Fortran 95.

For Fortran 77, the user must insert an

      include 'plplot_parameters.h'

statement in every function/subroutine/main programme where he expects
to use PLplot constants (whose names typically start with "PL_".  (See
examples/f77/*.fm4 for examples of this method).  When compiling he
must also insert the appropriate -I option to find this file (in
bindings/f77/ in the source tree and currently in
$prefix/lib/fortran/include/plplot$version in the install tree
although that install location may be subject to change).  Note, the
above method does not interfere with existing apps which have
necessarily been forced to define the needed PLplot constants for
themselves.  But for future f77 use, the above statement is
more convenient and much less subject to error than a whole bunch of
parameter statements for the required constants.

For Fortran 95, the complete set of parameters are made available as
part of the plplot module.  So access to this complete set of
parameters is automatic wherever the "use plplot" statement is used.
This is extremely convenient for new Fortran 95 apps that use PLplot,
but, in general, changes will have to be made for existing apps. (See
announcement XX above for the details).

2.52 The plarc function has been added

The plarc function allows drawing filled and outlined arcs in PLplot.
Standard example 3 uses plarc.


PLplot Release 5.9.8
~~~~~~~~~~~~~~~~~~~~
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 bugtracker, then please send bug reports to PLplot
developers via the mailing lists at
http://sourceforge.net/mail/?group_id=2915 (preferred) or on our bugtracker
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.

Official Notices for Users.

(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 colours 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 colours) 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.

INDEX

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

1. Changes relative to PLplot 5.9.7 (the previous development release)

1.1 The plstring and plstring3 functions have been added
1.2 The pllegend API has been finalized
1.3 Octave bindings now implemented with swig
1.4 Documentation redone for our swig-generated Python and Octave bindings
1.5 Support large polygons
1.6 Complete set of PLplot parameters now available for Fortran

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

-1. Important changes we should have mentioned in previous release announcements.

-1.1 Add full bindings and examples for the D language.

As of release 5.9.5 we added full bindings and examples for the D
language.  The results for the D examples are generally consistent
with the corresponding C examples which helps to verify the D
bindings.

Since the release of 5.9.5 it has come to our attention that the
version of gdc supplied with several recent versions of Ubuntu has a
very serious bug on 64-bit systems (see
https://bugs.launchpad.net/ubuntu/+source/gdc-4.2/+bug/235955) which
causes several of the plplot D examples to crash. If this affects you,
you are recommended to disable the d bindings or switch to an
alternative d compiler (the Digital Mars compiler is reported to be
good).


0. Tests made for release 5.9.8

See
http://www.miscdebris.net/plplot_wiki/index.php?title=Testing_PLplot#Testing_Reports
for a summary table of all testing done for PLplot-5.9.8.


1. Changes relative to PLplot 5.9.7 (the previous development release)

1.1 The plstring and plstring3 functions have been added

The plstring function largely supersedes plpoin and plsym
because many(!) more glyphs are accessible with plstring.  The glyph
is specified with a PLplot user string.  As with plmtex and plptex,
the user string can contain FCI escapes to determine the font, UTF-8
code to determine the glyph or else PLplot escapes for Hershey or
unicode text to determine the glyph.  Standard examples 4 and 26 use
plstring.

The plstring3 function largely supersedes plpoin3 for the same (access
to many more glyphs) reasons.  Standard example 18 uses plstring3.

1.2 The pllegend API has been finalized

The function pllegend allows users to create a discrete plot legend
with a plotted colored box, line, and/or line of symbols for each
annotated legend entry.  The pllegend function was first made
available for 5.9.7. Due to feedback from early adopters of pllegend,
we have now added substantially to the pllegend capabilities. and we
now believe pllegend is ready for prime time.  The pllegend
capabilities are documented in our docbook documentation and
demonstrated in standard examples 4, 26, and 33.  

N.B. The current set of changes required a backwards-incompatible
change to the pllegend API.  This requires users who tried this new
functionality for 5.9.7 to reprogramme their pllegend calls.  Since
the pllegend API was labelled experimental for 5.9.7, we will not be
bumping the soversions of the affected PLplot libraries.

1.3 Octave bindings now implemented with swig

Octave is a powerful platform that demands a first-class PLplot
solution, but we were finding it difficult to realize that goal
because we were running up against limitations of the previous
matwrap-generated Octave bindings.  Accordingly, a swig-generated
version of the Octave bindings has now been implemented that builds on
the prior matwrapped bindings effort but also extends it with, e.g.,
bindings for plstring, plstring3, pllegend, and plcolorbar.  These new
octave bindings (which now completely replace the prior matwrapped
bindings) make it possible to run examples 4, 18, 26, and 33 (all of
which have now have been updated to use those functions) and get
consistent results with the corresponding C examples.

Like the matwrapped bindings before it, the new swig-generated octave
bindings currently do not have a number of the PLplot functions
wrapped (e.g., "plmap") that are needed by standard example 19.
However, because of the power of swig we now have some confidence we
can solve this issue in the future.

1.4 Documentation redone for our swig-generated Python and Octave bindings

Through the docstring %feature, swig can generate documentation
strings for certain of the languages it supports (currently Python,
Octave, and Ruby).  We have now removed all such hand-crafted swig
documentation data from bindings/swig-support/plplotcapi.i and
replaced it with generated documentation in the file
bindings/swig-support/swig_documentation.i.  That file is generated
from doc/docbook/src/api.xml using the perl script
doc/docbook/bin/api2swigdoc.pl.  The build system Unix target
"check_swig_documentation" now runs that script and compares results
with bindings/swig-support/swig_documentation.i in the source tree to
make sure that latter file is consistent with any changes that might
have occurred in doc/docbook/src/api.xml.

The resulting Octave and Python user-documentation (obtained by 'help
<PLplot_command_name>' in Octave and 'print ("%s" %
<PLplot_command_name>.__doc__)' in Python is much more detailed than
what was available before using the hand-crafted documentation.  If we
ever decided to generate PLplot bindings for Ruby with swig, this
high-quality user-documentation would be available for that language
as well.

1.5 Support large polygons

Previous releases had an implicit limitation with respect to the
number of vertices in a polygon. This was due to the use of statically
defined arrays (to avoid allocating and freeing memory for each polygon
to be drawn). Jos Luis Garca Pallero found this limitation and
provided patches to eliminate this limitation. The strategy is
that for small polygons, the original statically defined arrays
are used and for large polygons new arrays are allocated and freed.
This strategy has been applied to all relevant source files.

1.6 Complete set of PLplot parameters now available for Fortran

The #defines in bindings/swig-support/plplotcapi.i (which are
consistent with those in include/plplot.h) define the complete set of
important PLplot constants (whose names typically start with "PL_").
We have implemented automatic methods of transforming that complete
set of #defines into Fortran parameters that can be used from either
Fortran 77 or Fortran 95.

For Fortran 77, the user must insert an

      include 'plplot_parameters.h'

statement in every function/subroutine/main programme where he expects
to use PLplot constants (whose names typically start with "PL_".  (See
examples/f77/*.fm4 for examples of this method).  When compiling he
must also insert the appropriate -I option to find this file (in
bindings/f77/ in the source tree and currently in
$prefix/lib/fortran/include/plplot$version in the install tree
although that install location may be subject to change).  Note, the
above method does not interfere with existing apps which have
necessarily been forced to define the needed PLplot constants for
themselves.  But for future f77 use, the above statement is
more convenient and much less subject to error than a whole bunch of
parameter statements for the required constants.

For Fortran 95, the complete set of parameters are made available as
part of the plplot module.  So access to this complete set of
parameters is automatic wherever the "use plplot" statement is used.
This is extremely convenient for new Fortran 95 apps that use PLplot,
but, in general, changes will have to be made for existing apps. (See
announcement XX above for the details).

2. Changes relative to PLplot 5.8.0 (the previous stable release)

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 antialized 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 rigourous 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 locale is
chosen depending on applications and libraries external to PLplot (see
comments above), and (b) setting an environment variable (LC_ALL,
LC_NUMERIC, or LANG on Linux, for example) to some locale that has been
installed on your system.  On Linux, to find what locales are installed, use
the "locale -a" option. The "C" locale is always installed, but usually
there is also a principal locale that works on a platform such as
en_US.UTF8, nl_NL.UTF8, etc.  Furthermore, it is straightforward to build
and install any additional locale you desire.  (For example, on Debian Linux
you do that by running "dpkg-reconfigure locales".)

Normally, users will not use the -locale option since the period
decimal separator that you get for the normal LC_NUMERIC default "C"
locale used by external applications and libraries is fine for their needs.
However, if the resulting decimal separator is not what the user
wants, then they would do something like the following to (a) use a period
decimal separator for command-line input and plots:

LC_ALL=C examples/c/x09c -locale -dev psc -o test.psc -ori 0.5

or (b) use a comma decimal separator for command-line input and plots:

LC_ALL=nl_NL.UTF8 examples/c/x09c -locale -dev psc -o test.psc -ori 0,5

N.B. in either case if the wrong separator is used for input (e.g., -ori 0,5
in the first case or -ori 0.5 in the second) the floating-point conversion
(using atof) is silently terminated at the wrong separator for the locale,
i.e., the fractional part of the number is silently dropped.  This is
obviously not ideal, but on the other hand there are relatively few
floating-point command-line options for PLplot, and we also expect those who
use the -locale option to specifically ask for a given separator for plots
(e.g., axis labels) will then use it for command-line input of
floating-point values as well.

Certain critical areas of the PLplot library (e.g., our colour palette file
reading routines and much of the code in our device drivers) absolutely
require a period for the decimal separator.  We now protect those critical
areas by saving the normal PLplot LC_NUMERIC locale (established with the
above -locale option or by default by whatever is set by external
applications or libraries), setting the LC_NUMERIC "C" locale, executing the
critical code, then restoring back to the normal PLplot LC_NUMERIC locale.
Previous versions of PLplot did not have this protection of the critical
areas so were vulnerable to default LC_NUMERIC settings of external
applications that resulted in a comma decimal separator that did not work
correctly for the critical areas.

2.37 Linear gradients have been implemented

The new plgradient routine draws a linear gradient (based on the
current colour map 1) at a specified angle with the x axis for a
specified polygon.  Standard examples 25 and 30 now demonstrate use of
plgradient.  Some devices use a software fallback to render the
gradient.  This fallback is implemented with plshades which uses a
series of rectangles to approximate the gradient. Tiny alignment
issues for those rectangles relative to the pixel grid may look
problematic for transparency gradients.  To avoid that issue, we try
to use native gradient capability whenever that is possible for any of
our devices.  Currently, this has been implemented for our svg, qt,
and cairo devices.  The result is nice-looking smooth transparency
gradients for those devices, for, e.g., example 30, page 2.

2.38 Cairo Windows driver implemented

A cairo Windows driver has been implemented. This provides an
interactive cairo driver for Windows similar to xcairo on Linux.
Work to improve its functionality is ongoing.

2.39 Custom axis labeling implemented

Axis text labels can now be customized using the new plslabelfunc function.
This allows a user to specify what text should be draw at a given position
along a plot axis.  Example 19 has been updated to illustrate this function's
use through labeling geographic coordinates in degrees North, South, East and
West.

2.40 Universal coordinate transform implemented

A custom coordinate transformation function can be set using plstransform.
This transformation function affects all subsequent plot function calls which
work with plot window coordinates.  Testing and refinement of this support is
ongoing.

2.41 Support for arbitrary storage of 2D user data

This improvement courtesy of David MacMahon adds support for arbitrary
storage of 2D user data.  This is very similar to the technique employed
by some existing functions (e.g. plfcont and plfshade) that use "evaluator"
functions to access 2D user data that is stored in an arbtrary format.
The new approach extends the concept of a user-supplied (or predefined)
"evaluator" function to a group of user-supplied (or predefined) "operator"
functions.  The operator functions provide for various operations on the
arbitrarily stored 2D data including: get, set, +=, -=, *=, /=, isnan,
minmax, and f2eval.

To facilitate the passing of an entire family of operator functions (via
function pointers), a plf2ops_t structure is defined to contain a
pointer to each type of operator function.  Predefined operator
functions are defined for several common 2D data storage techniques.
Variables (of type plf2ops_t) containing function pointers for these
operator functions are also defined.

New variants of functions that accept 2D data are created.  The new
variants accept the 2D data as two parameters: a pointer to a plf2ops_t
structure containing (pointers to) suitable operator functions and a
PLPointer to the actual 2D data store.  Existing functions that accept
2D data are modified to simply pass their parameters to the
corresponding new variant of the function, along with a pointer to the
suitable predefined plf2ops_t stucture of operator function pointers.

The list of functions for which new variants are created is:
c_plimage, c_plimagefr, c_plmesh, c_plmeshc, c_plot3d, c_plot3dc,
c_plot3dcl, c_plshade1, c_plshades, c_plsurf3d, and c_plsurf3dl, and
c_plgriddata.  The new variants are named the same as their
corresponding existing function except that the "c_" prefix is changed
to "plf" (e.g. the new variant of c_plmesh is called plfmesh).

Adds plfvect declaration to plplot.h and changes the names (and only the
names) of some plfvect arguments to make them slightly clearer.  In
order to maintain backwards API compatibility, this function and the
other existing functions that use "evaluator" functions are NOT changed
to use the new operator functions.

Makes plplot.h and libplplot consistent vis-a-vis pltr0f and pltr2d.
Moves the definitions of pltr2f (already declared in plplot.h) from the
sccont.c files of the FORTRAN 77 and Fortran 95 bindings into plcont.c.
Removes pltr0f declaration from plplot.h.

Changes x08c.c to demonstrate use of new support for arbitrary storage
of 2D data arrays.  Shows how to do surface plots with the following
four types of 2D data arrays:

1) PLFLT z[nx][ny];
2) PLfGrid2 z;
3) PLFLT z[nx*ny]; /* row major order */
4) PLFLT z[nx*ny]; /* column major order */

2.42 Font improvements

We have added the underscore to the Hershey glyphs (thanks to David
MacMahon) and slightly rearranged the ascii index to the Hershey
indices so that plpoin now generates the complete set of printable
ascii characters in the correct order for the Hershey fonts (and therefore
the Type1 and TrueType fonts as well).

We have improved how we access TrueType and Type1 fonts via the Hershey
font index (used by plpoin, plsym, and the Hershey escape sequences in pl*tex
commands).  We have added considerably to the Hershey index to Unicode index
translation table both for the compact and extended Hershey indexing scheme,
and we have adopted the standard Unicode to Type1 index translation tables
from http://unicode.org/Public/MAPPINGS/VENDORS/ADOBE/.

We have also dropped the momentary switch to symbol font that was
implemented in the PLplot core library.  That switch was designed to partially
compensate for the lack of symbol glyphs in the standard Type1 fonts.  That
was a bad design because it affected TrueType font devices as well as
the desired Type1 font devices.  To replace this bad idea we now
change from Type1 standard fonts to the Type1 Symbol font (and vice
versa) whenever there is a glyph lookup failure in the Type1 font
device drivers (ps and pdf).

2.42 Alpha value support for plotting in memory.

The function plsmema() was added to the PLplot API. This allows the user
to supply a RGBA formatted array that PLplot can use to do in memory
plotting with alpha value support. At present only the memcairo device
is capable of using RGBA formatted memory. The mem device, at least
for the time being, only supports RGB formatted memory and will exit
if the user attempts to give it RGBA formatted memory to plot in.

2.43 Add a Qt device for in memory plotting.

A new device called memqt has been added for in memory plotting using
Qt. This device is the Qt equivalent of the memcairo device.

2.44 Add discrete legend capability.

A new routine called pllegend has been added to our core C API.
(N.B. This is an experimental API that may be subject to further
change as we gain more experience with it.)  This routine creates a
discrete plot legend with a plotted box, line, and/or line of symbols
for each annotated legend entry. The arguments of pllegend provide
control over the location and size of the legend within the current
subpage as well as the location and characteristics of the elements
(most of which are optional) within that legend. The resulting legend
is clipped at the boundaries of the current subpage


2.45 Add full bindings and examples for the D language.

As of release 5.9.5 we added full bindings and examples for the D
language.  The results for the D examples are generally consistent
with the corresponding C examples which helps to verify the D
bindings.

Since the release of 5.9.5 it has come to our attention that the
version of gdc supplied with several recent versions of Ubuntu has a
very serious bug on 64-bit systems (see
https://bugs.launchpad.net/ubuntu/+source/gdc-4.2/+bug/235955) which
causes several of the plplot D examples to crash. If this affects you,
you are recommended to disable the d bindings or switch to an
alternative d compiler (the Digital Mars compiler is reported to be
good).

2.46 The plstring and plstring3 functions have been added

The plstring function largely supersedes plpoin and plsym
because many(!) more glyphs are accessible with plstring.  The glyph
is specified with a PLplot user string.  As with plmtex and plptex,
the user string can contain FCI escapes to determine the font, UTF-8
code to determine the glyph or else PLplot escapes for Hershey or
unicode text to determine the glyph.  Standard examples 4 and 26 use
plstring.

The plstring3 function largely supersedes plpoin3 for the same (access
to many more glyphs) reasons.  Standard example 18 uses plstring3.

2.47 The pllegend API has been finalized

The function pllegend allows users to create a discrete plot legend
with a plotted colored box, line, and/or line of symbols for each
annotated legend entry.  The pllegend function was first made
available for 5.9.7. Due to feedback from early adopters of pllegend,
we have now added substantially to the pllegend capabilities. and we
now believe pllegend is ready for prime time.  The pllegend
capabilities are documented in our docbook documentation and
demonstrated in standard examples 4, 26, and 33.  

N.B. The current set of changes required a backwards-incompatible
change to the pllegend API.  This requires users who tried this new
functionality for 5.9.7 to reprogramme their pllegend calls.  Since
the pllegend API was labelled experimental for 5.9.7, we will not be
bumping the soversions of the affected PLplot libraries.

2.48 Octave bindings now implemented with swig

Octave is a powerful platform that demands a first-class PLplot
solution, but we were finding it difficult to realize that goal
because we were running up against limitations of the previous
matwrap-generated Octave bindings.  Accordingly, a swig-generated
version of the Octave bindings has now been implemented that builds on
the prior matwrapped bindings effort but also extends it with, e.g.,
bindings for plstring, plstring3, pllegend, and plcolorbar.  These new
octave bindings (which now completely replace the prior matwrapped
bindings) make it possible to run examples 4, 18, 26, and 33 (all of
which have now have been updated to use those functions) and get
consistent results with the corresponding C examples.

Like the matwrapped bindings before it, the new swig-generated octave
bindings currently do not have a number of the PLplot functions
wrapped (e.g., "plmap") that are needed by standard example 19.
However, because of the power of swig we now have some confidence we
can solve this issue in the future.

2.49 Documentation redone for our swig-generated Python and Octave bindings

Through the docstring %feature, swig can generate documentation
strings for certain of the languages it supports (currently Python,
Octave, and Ruby).  We have now removed all such hand-crafted swig
documentation data from bindings/swig-support/plplotcapi.i and
replaced it with generated documentation in the file
bindings/swig-support/swig_documentation.i.  That file is generated
from doc/docbook/src/api.xml using the perl script
doc/docbook/bin/api2swigdoc.pl.  The build system Unix target
"check_swig_documentation" now runs that script and compares results
with bindings/swig-support/swig_documentation.i in the source tree to
make sure that latter file is consistent with any changes that might
have occurred in doc/docbook/src/api.xml.

The resulting Octave and Python user-documentation (obtained by 'help
<PLplot_command_name>' in Octave and 'print ("%s" %
<PLplot_command_name>.__doc__)' in Python is much more detailed than
what was available before using the hand-crafted documentation.  If we
ever decided to generate PLplot bindings for Ruby with swig, this
high-quality user-documentation would be available for that language
as well.

2.50 Support large polygons

Previous releases had an implicit limitation with respect to the
number of vertices in a polygon. This was due to the use of statically
defined arrays (to avoid allocating and freeing memory for each polygon
to be drawn). Jos Luis Garca Pallero found this limitation and
provided patches to eliminate this limitation. The strategy is
that for small polygons, the original statically defined arrays
are used and for large polygons new arrays are allocated and freed.
This strategy has been applied to all relevant source files.

2.51 Complete set of PLplot parameters now available for Fortran

The #defines in bindings/swig-support/plplotcapi.i (which are
consistent with those in include/plplot.h) define the complete set of
important PLplot constants (whose names typically start with "PL_").
We have implemented automatic methods of transforming that complete
set of #defines into Fortran parameters that can be used from either
Fortran 77 or Fortran 95.

For Fortran 77, the user must insert an

      include 'plplot_parameters.h'

statement in every function/subroutine/main programme where he expects
to use PLplot constants (whose names typically start with "PL_".  (See
examples/f77/*.fm4 for examples of this method).  When compiling he
must also insert the appropriate -I option to find this file (in
bindings/f77/ in the source tree and currently in
$prefix/lib/fortran/include/plplot$version in the install tree
although that install location may be subject to change).  Note, the
above method does not interfere with existing apps which have
necessarily been forced to define the needed PLplot constants for
themselves.  But for future f77 use, the above statement is
more convenient and much less subject to error than a whole bunch of
parameter statements for the required constants.

For Fortran 95, the complete set of parameters are made available as
part of the plplot module.  So access to this complete set of
parameters is automatic wherever the "use plplot" statement is used.
This is extremely convenient for new Fortran 95 apps that use PLplot,
but, in general, changes will have to be made for existing apps. (See
announcement XX above for the details).

2.52 The plarc function has been added

The plarc function allows drawing filled and outlined arcs in PLplot.
Standard example 3 uses plarc.


PLplot Release 5.9.7
~~~~~~~~~~~~~~~~~~~~
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 bugtracker, then please send bug reports to PLplot
developers via the mailing lists at
http://sourceforge.net/mail/?group_id=2915 (preferred) or on our bugtracker
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.

Official Notices for Users.

I. As of release 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.

II. As of release 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.

III. As of release 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.

IV. As of release 5.9.2 we have set HAVE_PTHREAD to ON by default for all
platforms other than Darwin.  Darwin will follow later once it appears the
Apple version of X supports it.

V. As of release 5.9.3 our build system requires CMake version 2.6.0 or
higher.

VI. As of release 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.
N.B. This announcement has been superseded by the subsequent retirement
of gcw, gnome2, and pygcw, see announcement XVII.

VII. As of release 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.

VIII. As of release 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.

IX. As of release 5.9.4 we have deprecated the pbm device driver (containing
the pbm device) because glibc detects a catastrophic double free.

X. As of release 5.9.5 we have removed pyqt3 access to PLplot and
replaced it by pyqt4 access to PLplot (see details below).

XI. As of release 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.

XII. As of release 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.

XIII. As of release 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 colours 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.

XIV. As of release 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 colours) which has never been
fixed indicating nobody is interested in maintaining this device.

XV. As of release 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.

XVI. As of release 5.9.6 plpoin results for ascii codes 92, 94, and 95
are changed 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 "°".

XVII. As of release 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.

XVIII. As of release 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.

XVIV. It has come to our attention that the version of gdc supplied with 
several recent versions of Ubuntu has a very serious bug on 64-bit 
systems (see https://bugs.launchpad.net/ubuntu/+source/gdc-4.2/+bug/235955)
which causes several of the plplot D examples to crash. If this
affects you, you are recommended to disable the d bindings or switch to
an alternative d compiler (the Digital Mars compiler is reported to
be good).

INDEX

0. Tests made for release 5.9.7

1. Changes relative to PLplot 5.9.6 (the previous development release)

1.1 Alpha value support for plotting in memory.
1.2 Add a Qt device for in memory plotting.
1.3 Add discrete legend capability.


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


0. Tests made for release 5.9.7

See 
http://www.miscdebris.net/plplot_wiki/index.php?title=Testing_PLplot#Testing_Reports
for a summary table of all testing done for PLplot-5.9.7.

1. Changes relative to PLplot 5.9.6 (the previous development release)

1.1 Alpha value support for plotting in memory.

The function plsmema() was added to the PLplot API. This allows the user
to supply a RGBA formatted array that PLplot can use to do in memory
plotting with alpha value support. At present only the memcairo device
is capable of using RGBA formatted memory. The mem device, at least
for the time being, only supports RGB formatted memory and will exit
if the user attempts to give it RGBA formatted memory to plot in.

1.2 Add a Qt device for in memory plotting.

A new device called memqt has been added for in memory plotting using
Qt. This device is the Qt equivalent of the memcairo device.

1.3 Add discrete legend capability.

A new routine called pllegend has been added to our core C API.
(N.B. This is an experimental API that may be subject to further
change as we gain more experience with it.)  This routine creates a
discrete plot legend with a plotted box, line, and/or line of symbols
for each annotated legend entry. The arguments of pllegend provide
control over the location and size of the legend within the current
subpage as well as the location and characteristics of the elements
(most of which are optional) within that legend. The resulting legend
is clipped at the boundaries of the current subpage

2. Changes relative to PLplot 5.8.0 (the previous stable release)

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 antialized 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 rigourous 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 locale is
chosen depending on applications and libraries external to PLplot (see
comments above), and (b) setting an environment variable (LC_ALL,
LC_NUMERIC, or LANG on Linux, for example) to some locale that has been
installed on your system.  On Linux, to find what locales are installed, use
the "locale -a" option. The "C" locale is always installed, but usually
there is also a principal locale that works on a platform such as
en_US.UTF8, nl_NL.UTF8, etc.  Furthermore, it is straightforward to build
and install any additional locale you desire.  (For example, on Debian Linux
you do that by running "dpkg-reconfigure locales".)

Normally, users will not use the -locale option since the period
decimal separator that you get for the normal LC_NUMERIC default "C"
locale used by external applications and libraries is fine for their needs.
However, if the resulting decimal separator is not what the user
wants, then they would do something like the following to (a) use a period
decimal separator for command-line input and plots:

LC_ALL=C examples/c/x09c -locale -dev psc -o test.psc -ori 0.5

or (b) use a comma decimal separator for command-line input and plots:

LC_ALL=nl_NL.UTF8 examples/c/x09c -locale -dev psc -o test.psc -ori 0,5

N.B. in either case if the wrong separator is used for input (e.g., -ori 0,5
in the first case or -ori 0.5 in the second) the floating-point conversion
(using atof) is silently terminated at the wrong separator for the locale,
i.e., the fractional part of the number is silently dropped.  This is
obviously not ideal, but on the other hand there are relatively few
floating-point command-line options for PLplot, and we also expect those who
use the -locale option to specifically ask for a given separator for plots
(e.g., axis labels) will then use it for command-line input of
floating-point values as well.

Certain critical areas of the PLplot library (e.g., our colour palette file
reading routines and much of the code in our device drivers) absolutely
require a period for the decimal separator.  We now protect those critical
areas by saving the normal PLplot LC_NUMERIC locale (established with the
above -locale option or by default by whatever is set by external
applications or libraries), setting the LC_NUMERIC "C" locale, executing the
critical code, then restoring back to the normal PLplot LC_NUMERIC locale.
Previous versions of PLplot did not have this protection of the critical
areas so were vulnerable to default LC_NUMERIC settings of external
applications that resulted in a comma decimal separator that did not work
correctly for the critical areas.

2.37 Linear gradients have been implemented

The new plgradient routine draws a linear gradient (based on the
current colour map 1) at a specified angle with the x axis for a
specified polygon.  Standard examples 25 and 30 now demonstrate use of
plgradient.  Some devices use a software fallback to render the
gradient.  This fallback is implemented with plshades which uses a
series of rectangles to approximate the gradient. Tiny alignment
issues for those rectangles relative to the pixel grid may look
problematic for transparency gradients.  To avoid that issue, we try
to use native gradient capability whenever that is possible for any of
our devices.  Currently, this has been implemented for our svg, qt,
and cairo devices.  The result is nice-looking smooth transparency
gradients for those devices, for, e.g., example 30, page 2.

2.38 Cairo Windows driver implemented

A cairo Windows driver has been implemented. This provides an
interactive cairo driver for Windows similar to xcairo on Linux.
Work to improve its functionality is ongoing.

2.39 Custom axis labeling implemented

Axis text labels can now be customized using the new plslabelfunc function.
This allows a user to specify what text should be draw at a given position
along a plot axis.  Example 19 has been updated to illustrate this function's
use through labeling geographic coordinates in degrees North, South, East and
West.

2.40 Universal coordinate transform implemented

A custom coordinate transformation function can be set using plstransform.
This transformation function affects all subsequent plot function calls which
work with plot window coordinates.  Testing and refinement of this support is
ongoing.

2.41 Support for arbitrary storage of 2D user data

This improvement courtesy of David MacMahon adds support for arbitrary 
storage of 2D user data.  This is very similar to the technique employed 
by some existing functions (e.g. plfcont and plfshade) that use "evaluator" 
functions to access 2D user data that is stored in an arbtrary format.  
The new approach extends the concept of a user-supplied (or predefined) 
"evaluator" function to a group of user-supplied (or predefined) "operator" 
functions.  The operator functions provide for various operations on the 
arbitrarily stored 2D data including: get, set, +=, -=, *=, /=, isnan, 
minmax, and f2eval.

To facilitate the passing of an entire family of operator functions (via
function pointers), a plf2ops_t structure is defined to contain a
pointer to each type of operator function.  Predefined operator
functions are defined for several common 2D data storage techniques.
Variables (of type plf2ops_t) containing function pointers for these
operator functions are also defined.

New variants of functions that accept 2D data are created.  The new
variants accept the 2D data as two parameters: a pointer to a plf2ops_t
structure containing (pointers to) suitable operator functions and a
PLPointer to the actual 2D data store.  Existing functions that accept
2D data are modified to simply pass their parameters to the
corresponding new variant of the function, along with a pointer to the
suitable predefined plf2ops_t stucture of operator function pointers.

The list of functions for which new variants are created is:
c_plimage, c_plimagefr, c_plmesh, c_plmeshc, c_plot3d, c_plot3dc,
c_plot3dcl, c_plshade1, c_plshades, c_plsurf3d, and c_plsurf3dl, and
c_plgriddata.  The new variants are named the same as their
corresponding existing function except that the "c_" prefix is changed
to "plf" (e.g. the new variant of c_plmesh is called plfmesh).

Adds plfvect declaration to plplot.h and changes the names (and only the
names) of some plfvect arguments to make them slightly clearer.  In
order to maintain backwards API compatibility, this function and the
other existing functions that use "evaluator" functions are NOT changed
to use the new operator functions.

Makes plplot.h and libplplot consistent vis-a-vis pltr0f and pltr2d.
Moves the definitions of pltr2f (already declared in plplot.h) from the
sccont.c files of the FORTRAN 77 and Fortran 95 bindings into plcont.c.
Removes pltr0f declaration from plplot.h.

Changes x08c.c to demonstrate use of new support for arbitrary storage
of 2D data arrays.  Shows how to do surface plots with the following
four types of 2D data arrays:

1) PLFLT z[nx][ny];
2) PLfGrid2 z;
3) PLFLT z[nx*ny]; /* row major order */
4) PLFLT z[nx*ny]; /* column major order */

2.42 Font improvements

We have added the underscore to the Hershey glyphs (thanks to David
MacMahon) and slightly rearranged the ascii index to the Hershey
indices so that plpoin now generates the complete set of printable
ascii characters in the correct order for the Hershey fonts (and therefore
the Type1 and TrueType fonts as well).

We have improved how we access TrueType and Type1 fonts via the Hershey
font index (used by plpoin, plsym, and the Hershey escape sequences in pl*tex
commands).  We have added considerably to the Hershey index to Unicode index
translation table both for the compact and extended Hershey indexing scheme,
and we have adopted the standard Unicode to Type1 index translation tables
from http://unicode.org/Public/MAPPINGS/VENDORS/ADOBE/.

We have also dropped the momentary switch to symbol font that was
implemented in the PLplot core library.  That switch was designed to partially
compensate for the lack of symbol glyphs in the standard Type1 fonts.  That
was a bad design because it affected TrueType font devices as well as
the desired Type1 font devices.  To replace this bad idea we now
change from Type1 standard fonts to the Type1 Symbol font (and vice
versa) whenever there is a glyph lookup failure in the Type1 font
device drivers (ps and pdf).

2.42 Alpha value support for plotting in memory.

The function plsmema() was added to the PLplot API. This allows the user
to supply a RGBA formatted array that PLplot can use to do in memory
plotting with alpha value support. At present only the memcairo device
is capable of using RGBA formatted memory. The mem device, at least
for the time being, only supports RGB formatted memory and will exit
if the user attempts to give it RGBA formatted memory to plot in.

2.43 Add a Qt device for in memory plotting.

A new device called memqt has been added for in memory plotting using
Qt. This device is the Qt equivalent of the memcairo device.

2.44 Add discrete legend capability.

A new routine called pllegend has been added to our core C API.
(N.B. This is an experimental API that may be subject to further
change as we gain more experience with it.)  This routine creates a
discrete plot legend with a plotted box, line, and/or line of symbols
for each annotated legend entry. The arguments of pllegend provide
control over the location and size of the legend within the current
subpage as well as the location and characteristics of the elements
(most of which are optional) within that legend. The resulting legend
is clipped at the boundaries of the current subpage


PLplot Release 5.9.6
~~~~~~~~~~~~~~~~~~~~
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 bugtracker, then please send bug reports to PLplot
developers via the mailing lists at
http://sourceforge.net/mail/?group_id=2915 (preferred) or on our bugtracker
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.

Official Notices for Users.

I. As of release 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.

II. As of release 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.

III. As of release 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.

IV. As of release 5.9.2 we have set HAVE_PTHREAD to ON by default for all
platforms other than Darwin.  Darwin will follow later once it appears the
Apple version of X supports it.

V. As of release 5.9.3 our build system requires CMake version 2.6.0 or
higher.

VI. As of release 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.
N.B. This announcement has been superseded by the subsequent retirement
of gcw, gnome2, and pygcw, see announcement XVII.

VII. As of release 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.

VIII. As of release 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.

IX. As of release 5.9.4 we have deprecated the pbm device driver (containing
the pbm device) because glibc detects a catastrophic double free.

X. As of release 5.9.5 we have removed pyqt3 access to PLplot and
replaced it by pyqt4 access to PLplot (see details below).

XI. As of release 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.

XII. As of release 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.

XIII. As of release 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 colours 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.

XIV. As of release 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 colours) which has never been
fixed indicating nobody is interested in maintaining this device.

XV. As of release 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.

XVI. As of release 5.9.6 plpoin results for ascii codes 92, 94, and 95
are changed 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 "°".

XVII. As of release 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.

XVIII. As of release 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.

XVIV. It has come to our attention that the version of gdc supplied with 
several recent versions of Ubuntu has a very serious bug on 64-bit 
systems (see https://bugs.launchpad.net/ubuntu/+source/gdc-4.2/+bug/235955)
which causes several of the plplot D examples to crash. If this
affects you, you are recommended to disable the d bindings or switch to
an alternative d compiler (the Digital Mars compiler is reported to
be good).

INDEX

0. Tests made for release 5.9.6

1. Changes relative to PLplot 5.9.5 (the previous development release)

1.1 Make PLplot aware of LC_NUMERIC locale
1.2 Linear gradients have been implemented
1.3 Cairo Windows driver implemented
1.4 Custom axis labeling implemented
1.5 Universal coordinate transform implemented
1.6 Support for arbitrary storage of 2D user data
1.7 Font improvements


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 labeling implemented
2.40 Universal coordinate transform implemented
2.41 Support for arbitrary storage of 2D user data
2.42 Font improvements


0. Tests made for release 5.9.6

See 
http://www.miscdebris.net/plplot_wiki/index.php?title=Testing_PLplot#Testing_Reports
for a summary table of all testing done for PLplot-5.9.6.

1. Changes relative to PLplot 5.9.5 (the previous development release)

1.1 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 locale is
chosen depending on applications and libraries external to PLplot (see
comments above), and (b) setting an environment variable (LC_ALL,
LC_NUMERIC, or LANG on Linux, for example) to some locale that has been
installed on your system.  On Linux, to find what locales are installed, use
the "locale -a" option. The "C" locale is always installed, but usually
there is also a principal locale that works on a platform such as
en_US.UTF8, nl_NL.UTF8, etc.  Furthermore, it is straightforward to build
and install any additional locale you desire.  (For example, on Debian Linux
you do that by running "dpkg-reconfigure locales".)

Normally, users will not use the -locale option since the period
decimal separator that you get for the normal LC_NUMERIC default "C"
locale used by external applications and libraries is fine for their needs.
However, if the resulting decimal separator is not what the user
wants, then they would do something like the following to (a) use a period
decimal separator for command-line input and plots:

LC_ALL=C examples/c/x09c -locale -dev psc -o test.psc -ori 0.5

or (b) use a comma decimal separator for command-line input and plots:

LC_ALL=nl_NL.UTF8 examples/c/x09c -locale -dev psc -o test.psc -ori 0,5

N.B. in either case if the wrong separator is used for input (e.g., -ori 0,5
in the first case or -ori 0.5 in the second) the floating-point conversion
(using atof) is silently terminated at the wrong separator for the locale,
i.e., the fractional part of the number is silently dropped.  This is
obviously not ideal, but on the other hand there are relatively few
floating-point command-line options for PLplot, and we also expect those who
use the -locale option to specifically ask for a given separator for plots
(e.g., axis labels) will then use it for command-line input of
floating-point values as well.

Certain critical areas of the PLplot library (e.g., our colour palette file
reading routines and much of the code in our device drivers) absolutely
require a period for the decimal separator.  We now protect those critical
areas by saving the normal PLplot LC_NUMERIC locale (established with the
above -locale option or by default by whatever is set by external
applications or libraries), setting the LC_NUMERIC "C" locale, executing the
critical code, then restoring back to the normal PLplot LC_NUMERIC locale.
Previous versions of PLplot did not have this protection of the critical
areas so were vulnerable to default LC_NUMERIC settings of external
applications that resulted in a comma decimal separator that did not work
correctly for the critical areas.

1.2 Linear gradients have been implemented

The new plgradient routine draws a linear gradient (based on the
current colour map 1) at a specified angle with the x axis for a
specified polygon.  Standard examples 25 and 30 now demonstrate use of
plgradient.  Some devices use a software fallback to render the
gradient.  This fallback is implemented with plshades which uses a
series of rectangles to approximate the gradient. Tiny alignment
issues for those rectangles relative to the pixel grid may look
problematic for transparency gradients.  To avoid that issue, we try
to use native gradient capability whenever that is possible for any of
our devices.  Currently, this has been implemented for our svg, qt,
and cairo devices.  The result is nice-looking smooth transparency
gradients for those devices, for, e.g., example 30, page 2.

1.3 Cairo Windows driver implemented

A cairo Windows driver has been implemented. This provides an
interactive cairo driver for Windows similar to xcairo on Linux.
Work to improve its functionality is ongoing.

1.4 Custom axis labeling implemented

Axis text labels can now be customized using the new plslabelfunc function.
This allows a user to specify what text should be draw at a given position
along a plot axis.  Example 19 has been updated to illustrate this function's
use through labeling geographic coordinates in degrees North, South, East and
West.

1.5 Universal coordinate transform implemented

A custom coordinate transformation function can be set using plstransform.
This transformation function affects all subsequent plot function calls which
work with plot window coordinates.  Testing and refinement of this support is
ongoing.

1.6 Support for arbitrary storage of 2D user data

This improvement courtesy of David MacMahon adds support for arbitrary 
storage of 2D user data.  This is very similar to the technique employed 
by some existing functions (e.g. plfcont and plfshade) that use "evaluator" 
functions to access 2D user data that is stored in an arbtrary format.  
The new approach extends the concept of a user-supplied (or predefined) 
"evaluator" function to a group of user-supplied (or predefined) "operator" 
functions.  The operator functions provide for various operations on the 
arbitrarily stored 2D data including: get, set, +=, -=, *=, /=, isnan, 
minmax, and f2eval.

To facilitate the passing of an entire family of operator functions (via
function pointers), a plf2ops_t structure is defined to contain a
pointer to each type of operator function.  Predefined operator
functions are defined for several common 2D data storage techniques.
Variables (of type plf2ops_t) containing function pointers for these
operator functions are also defined.

New variants of functions that accept 2D data are created.  The new
variants accept the 2D data as two parameters: a pointer to a plf2ops_t
structure containing (pointers to) suitable operator functions and a
PLPointer to the actual 2D data store.  Existing functions that accept
2D data are modified to simply pass their parameters to the
corresponding new variant of the function, along with a pointer to the
suitable predefined plf2ops_t stucture of operator function pointers.

The list of functions for which new variants are created is:
c_plimage, c_plimagefr, c_plmesh, c_plmeshc, c_plot3d, c_plot3dc,
c_plot3dcl, c_plshade1, c_plshades, c_plsurf3d, and c_plsurf3dl, and
c_plgriddata.  The new variants are named the same as their
corresponding existing function except that the "c_" prefix is changed
to "plf" (e.g. the new variant of c_plmesh is called plfmesh).

Adds plfvect declaration to plplot.h and changes the names (and only the
names) of some plfvect arguments to make them slightly clearer.  In
order to maintain backwards API compatibility, this function and the
other existing functions that use "evaluator" functions are NOT changed
to use the new operator functions.

Makes plplot.h and libplplot consistent vis-a-vis pltr0f and pltr2d.
Moves the definitions of pltr2f (already declared in plplot.h) from the
sccont.c files of the FORTRAN 77 and Fortran 95 bindings into plcont.c.
Removes pltr0f declaration from plplot.h.

Changes x08c.c to demonstrate use of new support for arbitrary storage
of 2D data arrays.  Shows how to do surface plots with the following
four types of 2D data arrays:

1) PLFLT z[nx][ny];
2) PLfGrid2 z;
3) PLFLT z[nx*ny]; /* row major order */
4) PLFLT z[nx*ny]; /* column major order */

1.7 Font improvements

We have added the underscore to the Hershey glyphs (thanks to David
MacMahon) and slightly rearranged the ascii index to the Hershey
indices so that plpoin now generates the complete set of printable
ascii characters in the correct order for the Hershey fonts (and therefore
the Type1 and TrueType fonts as well).

We have improved how we access TrueType and Type1 fonts via the Hershey
font index (used by plpoin, plsym, and the Hershey escape sequences in pl*tex
commands).  We have added considerably to the Hershey index to Unicode index
translation table both for the compact and extended Hershey indexing scheme,
and we have adopted the standard Unicode to Type1 index translation tables
from http://unicode.org/Public/MAPPINGS/VENDORS/ADOBE/.

We have also dropped the momentary switch to symbol font that was
implemented in the PLplot core library.  That switch was designed to partially
compensate for the lack of symbol glyphs in the standard Type1 fonts.  That
was a bad design because it affected TrueType font devices as well as
the desired Type1 font devices.  To replace this bad idea we now
change from Type1 standard fonts to the Type1 Symbol font (and vice
versa) whenever there is a glyph lookup failure in the Type1 font
device drivers (ps and pdf).

2. Changes relative to PLplot 5.8.0 (the previous stable release)

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 antialized 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 rigourous 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 locale is
chosen depending on applications and libraries external to PLplot (see
comments above), and (b) setting an environment variable (LC_ALL,
LC_NUMERIC, or LANG on Linux, for example) to some locale that has been
installed on your system.  On Linux, to find what locales are installed, use
the "locale -a" option. The "C" locale is always installed, but usually
there is also a principal locale that works on a platform such as
en_US.UTF8, nl_NL.UTF8, etc.  Furthermore, it is straightforward to build
and install any additional locale you desire.  (For example, on Debian Linux
you do that by running "dpkg-reconfigure locales".)

Normally, users will not use the -locale option since the period
decimal separator that you get for the normal LC_NUMERIC default "C"
locale used by external applications and libraries is fine for their needs.
However, if the resulting decimal separator is not what the user
wants, then they would do something like the following to (a) use a period
decimal separator for command-line input and plots:

LC_ALL=C examples/c/x09c -locale -dev psc -o test.psc -ori 0.5

or (b) use a comma decimal separator for command-line input and plots:

LC_ALL=nl_NL.UTF8 examples/c/x09c -locale -dev psc -o test.psc -ori 0,5

N.B. in either case if the wrong separator is used for input (e.g., -ori 0,5
in the first case or -ori 0.5 in the second) the floating-point conversion
(using atof) is silently terminated at the wrong separator for the locale,
i.e., the fractional part of the number is silently dropped.  This is
obviously not ideal, but on the other hand there are relatively few
floating-point command-line options for PLplot, and we also expect those who
use the -locale option to specifically ask for a given separator for plots
(e.g., axis labels) will then use it for command-line input of
floating-point values as well.

Certain critical areas of the PLplot library (e.g., our colour palette file
reading routines and much of the code in our device drivers) absolutely
require a period for the decimal separator.  We now protect those critical
areas by saving the normal PLplot LC_NUMERIC locale (established with the
above -locale option or by default by whatever is set by external
applications or libraries), setting the LC_NUMERIC "C" locale, executing the
critical code, then restoring back to the normal PLplot LC_NUMERIC locale.
Previous versions of PLplot did not have this protection of the critical
areas so were vulnerable to default LC_NUMERIC settings of external
applications that resulted in a comma decimal separator that did not work
correctly for the critical areas.

2.37 Linear gradients have been implemented

The new plgradient routine draws a linear gradient (based on the
current colour map 1) at a specified angle with the x axis for a
specified polygon.  Standard examples 25 and 30 now demonstrate use of
plgradient.  Some devices use a software fallback to render the
gradient.  This fallback is implemented with plshades which uses a
series of rectangles to approximate the gradient. Tiny alignment
issues for those rectangles relative to the pixel grid may look
problematic for transparency gradients.  To avoid that issue, we try
to use native gradient capability whenever that is possible for any of
our devices.  Currently, this has been implemented for our svg, qt,
and cairo devices.  The result is nice-looking smooth transparency
gradients for those devices, for, e.g., example 30, page 2.

2.38 Cairo Windows driver implemented

A cairo Windows driver has been implemented. This provides an
interactive cairo driver for Windows similar to xcairo on Linux.
Work to improve its functionality is ongoing.

2.39 Custom axis labeling implemented

Axis text labels can now be customized using the new plslabelfunc function.
This allows a user to specify what text should be draw at a given position
along a plot axis.  Example 19 has been updated to illustrate this function's
use through labeling geographic coordinates in degrees North, South, East and
West.

2.40 Universal coordinate transform implemented

A custom coordinate transformation function can be set using plstransform.
This transformation function affects all subsequent plot function calls which
work with plot window coordinates.  Testing and refinement of this support is
ongoing.

2.41 Support for arbitrary storage of 2D user data

This improvement courtesy of David MacMahon adds support for arbitrary 
storage of 2D user data.  This is very similar to the technique employed 
by some existing functions (e.g. plfcont and plfshade) that use "evaluator" 
functions to access 2D user data that is stored in an arbtrary format.  
The new approach extends the concept of a user-supplied (or predefined) 
"evaluator" function to a group of user-supplied (or predefined) "operator" 
functions.  The operator functions provide for various operations on the 
arbitrarily stored 2D data including: get, set, +=, -=, *=, /=, isnan, 
minmax, and f2eval.

To facilitate the passing of an entire family of operator functions (via
function pointers), a plf2ops_t structure is defined to contain a
pointer to each type of operator function.  Predefined operator
functions are defined for several common 2D data storage techniques.
Variables (of type plf2ops_t) containing function pointers for these
operator functions are also defined.

New variants of functions that accept 2D data are created.  The new
variants accept the 2D data as two parameters: a pointer to a plf2ops_t
structure containing (pointers to) suitable operator functions and a
PLPointer to the actual 2D data store.  Existing functions that accept
2D data are modified to simply pass their parameters to the
corresponding new variant of the function, along with a pointer to the
suitable predefined plf2ops_t stucture of operator function pointers.

The list of functions for which new variants are created is:
c_plimage, c_plimagefr, c_plmesh, c_plmeshc, c_plot3d, c_plot3dc,
c_plot3dcl, c_plshade1, c_plshades, c_plsurf3d, and c_plsurf3dl, and
c_plgriddata.  The new variants are named the same as their
corresponding existing function except that the "c_" prefix is changed
to "plf" (e.g. the new variant of c_plmesh is called plfmesh).

Adds plfvect declaration to plplot.h and changes the names (and only the
names) of some plfvect arguments to make them slightly clearer.  In
order to maintain backwards API compatibility, this function and the
other existing functions that use "evaluator" functions are NOT changed
to use the new operator functions.

Makes plplot.h and libplplot consistent vis-a-vis pltr0f and pltr2d.
Moves the definitions of pltr2f (already declared in plplot.h) from the
sccont.c files of the FORTRAN 77 and Fortran 95 bindings into plcont.c.
Removes pltr0f declaration from plplot.h.

Changes x08c.c to demonstrate use of new support for arbitrary storage
of 2D data arrays.  Shows how to do surface plots with the following
four types of 2D data arrays:

1) PLFLT z[nx][ny];
2) PLfGrid2 z;
3) PLFLT z[nx*ny]; /* row major order */
4) PLFLT z[nx*ny]; /* column major order */

2.42 Font improvements

We have added the underscore to the Hershey glyphs (thanks to David
MacMahon) and slightly rearranged the ascii index to the Hershey
indices so that plpoin now generates the complete set of printable
ascii characters in the correct order for the Hershey fonts (and therefore
the Type1 and TrueType fonts as well).

We have improved how we access TrueType and Type1 fonts via the Hershey
font index (used by plpoin, plsym, and the Hershey escape sequences in pl*tex
commands).  We have added considerably to the Hershey index to Unicode index
translation table both for the compact and extended Hershey indexing scheme,
and we have adopted the standard Unicode to Type1 index translation tables
from http://unicode.org/Public/MAPPINGS/VENDORS/ADOBE/.

We have also dropped the momentary switch to symbol font that was
implemented in the PLplot core library.  That switch was designed to partially
compensate for the lack of symbol glyphs in the standard Type1 fonts.  That
was a bad design because it affected TrueType font devices as well as
the desired Type1 font devices.  To replace this bad idea we now
change from Type1 standard fonts to the Type1 Symbol font (and vice
versa) whenever there is a glyph lookup failure in the Type1 font
device drivers (ps and pdf).


PLplot Release 5.9.5
~~~~~~~~~~~~~~~~~~~~
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, then please send bug reports to PLplot developers via the
mailing lists at http://sourceforge.net/mail/?group_id=2915 .

     Please see the license under which this software is distributed
(LGPL), and the disclaimer of all warranties, given in the COPYING.LIB
file.


Official Notices for Users.

I. As of release 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.

II. As of release 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.

III. As of release 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.

IV. As of release 5.9.2 we have set HAVE_PTHREAD to ON by default for all
platforms other than Darwin.  Darwin will follow later once it appears the
Apple version of X supports it.

V. As of release 5.9.3 our build system requires CMake version 2.6.0 or
higher.

VI. As of release 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.

VII. As of release 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.

VIII. As of release 5.9.3 we have reenabled 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.

IX. As of release 5.9.4 we have deprecated the pbm device driver (containing
the pbm device) because glibc detects a catastrophic double free.

X. As of release 5.9.5 we have removed pyqt3 access to PLplot and
replaced it by pyqt4 access to PLplot (see details below).

XI. As of release 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 reimplementation for details.

XII. As of release 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.

INDEX

1. Changes relative to PLplot 5.9.4 (the previous development release)

1.1 PyQt changes
1.2 Color Palettes
1.3 Reimplementation of a "soft landing" when a bad/missing compiler is
detected

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

1.2 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 PLplots color table 0. The commands cmap1 /
plspal1 are used to load cmap1 type files which specify PLplots 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).

1.3 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. 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 Reimplementation of a "soft landing" when a bad/missing compiler is
detected.


2. Changes relative to PLplot 5.8.0 (the previous stable release)

2.1 All autotools-related files have now been removed

CMake (with the exception of a special build script for the DJGPP platform)
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 antialized 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 availale 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 offical 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 rigourous 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 PLplots color table 0. The commands cmap1 /
plspal1 are used to load cmap1 type files which specify PLplots 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.



PLplot Release 5.9.4
~~~~~~~~~~~~~~~~~~~~
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, then please send bug reports to PLplot developers via the
mailing lists at http://sourceforge.net/mail/?group_id=2915 .

     Please see the license under which this software is distributed
(LGPL), and the disclaimer of all warranties, given in the COPYING.LIB
file.


Notices for Users.

I. This is the official notice that our deprecated autotools-based build
system has been removed as of release 5.9.1.  Instead, use the CMake-based
build system following the directions in the INSTALL file.

II. This is official notice that we (as of 5.9.1) 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.

III. This is official notice that the PLplot team have decided (as of release
5.9.1) 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.

IV. This is official notice that (as of release 5.9.2) we have set
HAVE_PTHREAD to ON by default for all platforms other than Darwin.  Darwin
will follow later once it appears the Apple version of X supports it.

V. This is official notice that (as of release 5.9.3) our  build system
requires CMake version 2.6.0 or higher.

VI. This is official notice that (as of release 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.

VII. This is official notice that (as of release 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.

VIII. This is official notice that the tk, itk, and itcl components of
PLplot have been reenabled again by default (as of release 5.9.3) after
being 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.

INDEX

1. Changes relative to PLplot 5.9.3 (the previous development release)

1.1 Various bug fixes
1.2 Cairo driver improvements


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

1. Changes relative to PLplot 5.9.3 (the previous development release)

1.1 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

1.2 Cairo driver improvements

Improvements to the cairo driver to give better results for bitmap 
formats when used with anti-aliasing file viewers.

2. Changes relative to PLplot 5.8.0 (the previous stable release)

2.1 All autotools-related files have now been removed

CMake (with the exception of a special build script for the DJGPP platform)
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 antialized 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 availale 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 offical 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 rigourous 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.


PLplot Release 5.9.3
~~~~~~~~~~~~~~~~~~~~
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, then please send bug reports to PLplot developers via the
mailing lists at http://sourceforge.net/mail/?group_id=2915 .

     Please see the license under which this software is distributed
(LGPL), and the disclaimer of all warranties, given in the COPYING.LIB
file.


Notices for Users.

I. This is the official notice that our deprecated autotools-based build
system has been removed as of release 5.9.1.  Instead, use the CMake-based
build system following the directions in the INSTALL file.

II. This is official notice that we (as of 5.9.1) 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.

III. This is official notice that the PLplot team have decided (as of release
5.9.1) 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.

IV. This is official notice that (as of release 5.9.2) we have set
HAVE_PTHREAD to ON by default for all platforms other than Darwin.  Darwin
will follow later once it appears the Apple version of X supports it.

V. This is official notice that (as of release 5.9.3) our  build system
requires CMake version 2.6.0 or higher.

VI. This is official notice that (as of release 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.

VII. This is official notice that (as of release 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.

VIII. This is official notice that the tk, itk, and itcl components of
PLplot have been reenabled again by default (as of release 5.9.3) after
being 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.

INDEX

1. Changes relative to PLplot 5.9.2 (the previous development release)

1.1 libnistcd (a.k.a. libcd) now built internally for -dev cgm
1.2 get-drv-info now changed to test-drv-info
1.3 Text clipping now enabled by default for the cairo devices
1.4 A powerful qt device driver has been implemented
1.5 The PLplot API is now accessible from Qt GUI applications
1.6 NaN / Inf support for some PLplot functions

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

1. Changes relative to PLplot 5.9.2 (the previous development release)

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

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

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

1.4 A powerful qt device driver has been implemented

Thanks to the efforts of Alban Rochel of the QSAS team, we now have a 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 to control
paging.  The qtwidget overall size is expressed in pixels. bmpqt, jpgqt,
pngqt, ppmqt, and tiffqt are file devices whose overal 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 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.  Qt-4.5 is the version we have used for
most of our testing, but limited testing for Qt-4.4 indicates that version
should be fine for qt devices other than svgqt.

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

1.6 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. Changes relative to PLplot 5.8.0 (the previous stable release)

2.1 All autotools-related files have now been removed

CMake (with the exception of a special build script for the DJGPP platform)
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 antialized 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 availale 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 offical 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 rigourous 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 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 to control
paging.  The qtwidget overall size is expressed in pixels. bmpqt, jpgqt,
pngqt, ppmqt, and tiffqt are file devices whose overal 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 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.  Qt-4.5 is the version we have used for
most of our testing, but limited testing for Qt-4.4 indicates that version
should be fine for qt devices other than svgqt.

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.


PLplot Release 5.9.2
~~~~~~~~~~~~~~~~~~~~
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, then please send bug reports to PLplot developers via the
mailing lists at http://sourceforge.net/mail/?group_id=2915 .

     Please see the license under which this software is distributed
(LGPL), and the disclaimer of all warranties, given in the COPYING.LIB
file.


Notices for Users.

I. This is the official notice that our deprecated autotools-based build
system has been removed as of release 5.9.1.  Instead, use the CMake-based
build system following the directions in the INSTALL file.

II. This is official notice that the tk, itk, and itcl components of PLplot
have been disabled by default as of 5.9.1.  We reluctantly took this step
for these venerable PLplot components because we found segfaults with most
of our Tk-related interactive tests for this release which we have been, as
yet, unable to address. For now, if you want to try these components of
PLplot to help us debug the problem, you must specifically use the cmake
options -DENABLE_tk=ON -DENABLE_itk=ON -DENABLE_itcl=ON to build and install
these components.

III. This is official notice that we (as of 5.9.1) 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.

IV.  This is official notice that the PLplot team have decided (as of
release 5.9.1) 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.

INDEX

1. Changes relative to PLplot 5.9.1 (the previous development release)

1.1 Extension of our test framework

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


1. Changes relative to PLplot 5.9.1 (the previous development release)

1.1 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 rigourous 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. Changes relative to PLplot 5.8.0 (the previous stable release)

2.1 All autotools-related files have now been removed

CMake (with the exception of a special build script for the DJGPP platform)
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, 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 antialized 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 availale 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 offical 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 rigourous 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.


PLplot Release 5.9.1
~~~~~~~~~~~~~~~~~~~~
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, then please send bug reports to PLplot developers via the
mailing lists at http://sourceforge.net/mail/?group_id=2915 .

     Please see the license under which this software is distributed
(LGPL), and the disclaimer of all warranties, given in the COPYING.LIB
file.

Notices for Users.

I. This is the official notice that our deprecated autotools-based build
system has now been removed.  Instead, use the CMake-based build system
following the directions in the INSTALL file.

II. This is official notice that the tk, itk, and itcl components of PLplot
have been disabled by default for this release.  We reluctantly take this
step for these venerable PLplot components because we found segfaults with
most of our Tk-related interactive tests for this release.  We hope these
issues are addressed before our next release so that the tk, itk, and itcl
components of PLplot can be enabled by default again.  For now, if you want
to try these components of PLplot to help us debug the problem, you must
specifically use the cmake options -DENABLE_tk=ON -DENABLE_itk=ON
-DENABLE_itcl=ON to build and install these components.

III. This is official notice that the python version of gnome2 has been
temporarily disabled by default until we can figure out a

RuntimeError: maximum recursion depth exceeded

error that has been introduced for it (e.g., when running
plplotcanvas_animation.py in the installed examples/python directory).  If
you wish to experiment with this component of PLplot use the
-DENABLE_pygcw=ON option.  

examples/c/plplotcanvas_animation (when built in the install tree for the
default ENABLE_gnome2=ON case) works fine.  So do all the standard examples
in the installed examples/python tree.  So this issue appears to be confined
just to the python version of gnome2.

IV. This is official notice that 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.

V.  This is official notice that the PLplot team 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.

INDEX

1. Changes relative to PLplot 5.9.0 (the previous development release)
1.1 New PLplot functions
1.2 Improvements to the cairo driver family.
1.3 wxWidgets driver improvements
1.4 pdf driver improvements
1.5 svg driver improvements
1.6 Ada language support
1.7 OCaml language support
1.8 Perl/PDL language support
1.9 Update to various language bindings
1.10 Update to various examples
1.11 Rename test subdirectory to plplot_test
1.12 Website support files updated
1.13 Internal changes to function visibility
1.14 Dynamic driver support in Windows
1.15 Documentation updates

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 Rename test subdirectory to plplot_test
2.20 Website support files updated
2.21 Internal changes to function visibility
2.22 Dynamic driver support in Windows
2.23 Documentation updates

1. Changes relative to PLplot 5.9.0 (the previous development release)

1.1 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 (based
on the original Mersenne Twister 1997 code) 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.

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

1.3 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 antialized 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 availale in the xwin and tk driver) was
   implemented, where graphics input events are processed and translated
   to world coordinates

1.4 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)
 
1.5 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.

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

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

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

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

1.10 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 (example 1-30 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. The standard test suite for PLplot using ctest now carries out a
comparison of the postscript output for different languages as a check. 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.

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

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

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

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

1.15 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. Changes relative to PLplot 5.8.0 (the previous stable release)

2.1 All autotools-related files have now been removed

CMake (with the exception of a special build script for the DJGPP platform)
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, 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 antialized 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 availale 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 offical 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 (example 1-30 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. The standard test suite for PLplot using ctest now carries out a
comparison of the postscript output for different languages as a check. 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 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.20 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.21 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.22 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.23 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.



PLplot Release 5.9.0
~~~~~~~~~~~~~~~~~~~~
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, then please send bug reports to PLplot developers via the
mailing lists at http://sourceforge.net/mail/?group_id=2915 .

     Please see the license under which this software is distributed
(LGPL), and the disclaimer of all warrantees, given in the COPYING.LIB
file.

N.B. This is the official notice that our deprecated autotools-based build
system has now been removed.  Instead, use the CMake-based build system
following the directions in the INSTALL file.

INDEX

1. Changes relative to PLplot 5.8.0 (the previous stable release)

1.1 All autotools-related files have now been removed
1.2 Date / time labels for axes
1.3 Code cleanup 
1.4 Bug fixes
1.5 Alpha value support
1.6 Build system improvements
1.7 Implement build-system infrastructure for installed Ada bindings and 
examples
1.8 WxWidgets driver improvements
1.9 External libLASi library improvements affecting our psttf device.


1.1 All autotools-related files have now been removed

CMake (with the exception of a special build script for the DJGPP platform)
is now the only supported build system. It has been tested on Linux / Unix,
Mac OS-X and Windows platforms.

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

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

1.4 Bug fixes

Various fixes including:

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.

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

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

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

1.8 WxWidgets driver improvements

A number of small bug fixes. New functionality includes menu options to 
save the current plot in different formats.

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


PLplot Release 5.8.0
~~~~~~~~~~~~~~~~~~~~

This is a stable 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, then please send bug reports to PLplot developers via the
mailing lists at http://sourceforge.net/mail/?group_id=2915 .

     Please see the license under which this software is distributed
(LGPL), and the disclaimer of all warranties, given in the COPYING.LIB
file.

N.B. This is the official notice that our deprecated autotools-based build
system is scheduled for removal starting with the 5.9.0 release.  The reason
for this decision is the PLplot developers and users are happy with our
CMake-based build system (see below), and nobody has been willing to spend
time maintaining our old autotools-based build system.

Note for Windows users:
The same holds for the old Windows build system in sys/win32/msdev. This
build system is much less flexible than the CMake-based system. It also
lacks a larger number of important features - freetype text, language
bindings and so on. With the 5.9.0 release the source distribution will
no longer contain this directory. Hence you should switch to the new
build system described below.

Note for gfortran users of our f95 bindings: gfortran version 4.2.1 or later
is a requirement, see fortran 95 bindings remarks below.

Note for OS-X users:
The Octave bindings no longer work for Octave 2.1.73. Work is ongoing to
try and solve this problem.


INDEX

1. Changes relative to PLplot 5.7.4
  1.1 Drivers
    1.1.1 cairo devices
    1.1.2 plmeta/plrender
  1.2 Fortran 95 bindings
  1.3 plmtex3/plptex3
  1.4 Octave 2.9
  
2. Changes relative to PLplot 5.6.1
  2.1 CVS to Subversion conversion
  2.2 CMake build system
  2.3 Plot Buffering
  2.4 Updated INSTALL/README
  2.5 malloc/calloc clean up
  2.6 Documentation
  2.7 Additions to the PLplot API
  2.8 Language bindings
    2.8.1 ADA language binding
    2.8.2 wxwidgets applications bindings
    2.8.3 Python bindings
    2.8.4 Fortran 95 bindings
    2.8.5 Octave 2.9
  2.9 Updated examples
  2.10 Drivers
    2.10.1 psttf
    2.10.2 svg
    2.10.3 wxwidgets
    2.10.4 pdf
    2.10.5 gd, wingcc (freetype)
    2.10.6 cairo
    2.10.7 pstex
    2.10.8 plmeta (and plrender application to render plmeta results).


1. Changes relative to PLplot 5.7.4 (the previous development release)

1.1 Drivers
   1.1.1 cairo devices
     The xwinttf driver has been renamed xcairo. In addition most of the
     other devices that are theoretically possible with Cairo have been
     implemented. These are a PostScript device (pscairo), a PNG device
     (pngcairo), a PDF device (pdfcairo), an SVG device (svgcairo), and a
     memory device (memcairo). The cairo device driver is still considered
     experimental as a whole. Known issues include improper text rendering
     with svgcairo and memcairo not working at all so those two devices are
     disabled by default.  The pngcairo, pscairo, and xcairo devices appear
     to work without problems and also give outstanding-looking antialiased
     and hinted results so are enabled by default. The pdfcairo device
     appears to work reasonably well so is enabled by default although it is
     not as mature as the other Cairo devices that are enabled.

   1.1.2 plmeta/plrender
     The combination of the plmeta device and the plrender application
     that renders plmeta results is unmaintained and has some known issues
     with strings, aspect ratio changes, and fonts.  Therefore, the plmeta
     device is now not enabled by default, and must be specifically enabled
     by the user using the -DPLD_plmeta=ON cmake option.  Furthermore,
     plrender is not built or installed and the plrender man page is not
     installed unless the plmeta device is specifically enabled.

1.2 Fortran 95 bindings

    Equivalance statements in our F95 bindings were causing problems for
    one fortran 95 compiler so we have dropped those equivalence statements
    and use the transfer intrinsic instead.  However, for gfortran that
    intrinsic was only implemented for version 4.2.1 so that is the
    minimum version requirement for gfortran now if you attempt to build
    the f95 bindings.  Note, earlier versions of gfortran build the f77
    bindings with no problems.

1.3  plmtex3/plptex3

    These two functions, which were added in release 5.7.3, had a number
    of bugs. These have hopefully been cleaned up. Example 28 demonstrates
    how to use these functions. The functions and the example have now been
    implemented for most language bindings.

1.4 Octave 2.9
  
    Octave 2.9 has a number of significant differences from version 2.1. 
    The octave language bindings have been updated to work with this new 
    version since the latest 2.9.x release is now the "recommended" choice 
    by the octave developers. Note that all the low-level plplot functions 
    work as expected. The higher level functions which replace the default
    octave / gnuplot plotting commands mostly work as for version 2.1. They 
    do not (yet) replicate the new and more Matlab-like functionality in 
    the latest 2.9.x releases of Octave.

    Note: As a result of the compatibilty code for octave 2.1 and lower the
    octave bindings will generate spurious warnings about obsolete built-in 
    variables when using octave 2.9. These can be silenced using the command
        warning("off","Octave:built-in-variable-assignment");
    before using the plplot bindings. This is not enabled by default as it 
    would also turn off genuine warnings in your own code which you might 
    want to fix. 


2. Changes relative to PLplot 5.6.1 (the previous stable release)

2.1 CVS to Subversion conversion

   PLplot now uses the Subversion (svn) version control system. Records of
all the changes and release tags have been preserved from the CVS repository.

2.2 CMake build system

   PLplot now uses the CMake build system (www.cmake.org) and the older
autotools build system has been deprecated and is scheduled for removal as
of the 5.9.0 release. The switch to CMake was made due its superior support
for Windows platforms and its relative simplicity compared to autotools on
Unix. To use CMake to configure and build PLplot follow the directions at
http://www.miscdebris.net/plplot_wiki/.

2.3 Plot Buffering

   PLplot core has been modified to buffer plot commands in memory rather than
via a unix pipe or temporary file. Testing has shown that there is 20-30%
improvement in plotting performance (i.e. speed). This is likely to be system
dependent and some may see a much larger benefit. This also resolves a problem
with some windows platforms where the temporary files were not getting deleted.

2.4 Updated INSTALL/README

   The INSTALL and README files have been updated. They now include detailed
instructions for building plplot using the new CMake build system on Linux
and Windows.

2.5 malloc/calloc clean up

   Checks have been added to many (all?) of the calls to calloc and malloc in
the PLplot core. The purpose of the check is to verify that the memory
requested was actually allocated prior to attempting to use it.

2.6 Documentation

   The API section has been expanded to include information about how to call
the functions from Fortran95, Java, Perl/PDL and Python. Since array dimension
information is typically redundant in these languages it is dropped in many
of the relevant function. Additionally, some of the Perl/PDL function calls
have a different argument order than their C equivalent. This section has also
been expanded to include a list of which examples each function is used in
(if any).

   The Fortran95 documentation has been updated.

2.7 Additions to the PLplot API

   The functions plptex3 and plmtex3 have been added to the PLplot API. These
allow the user to draw text in "3D" on the 3D plots. plptex3 is the 3D
equivalent of plptex and plmtex3 is the 3D equivalent of plmtex. Their
use is demonstrated by example 28.

2.8 Language bindings
  2.8.1 ADA
       Jerry Bauck has donated bindings to the ADA programming language.
    These bindings have been included into the CMake build system,
    and should be generated automatically if you have an ADA compiler and
    you specify the cmake option -DENABLE_ada=ON. The ADA bindings are now
    considered complete and the current focus is on implementing all of the
    examples in ADA to help test the bindings.  Until that work is completed
    these bindings should be considered experimental.

  2.8.2 wxwidgets applications bindings
       The wxWidgets bindings provide an interface to the PLplot API and a
    simple widget to be used in a wxWidgets application. The class
    'wxPLplotstream' inherited from the PLplot class 'plstream' allows access
    to the complete PLplot API. 'wxPLplotWindow' is a simple wxWidget which
    takes care of some preparatory work for convenient use of the PLplot
    Library within a wxWidgets application.

  2.8.3 Python bindings
    The Python bindings have been updated to use numpy rather than the now
    deprecated Numeric python numeric library.

  2.8.4 Fortran 95 bindings
    Equivalance statements in our F95 bindings were causing problems for
    one fortran 95 compiler so we have dropped those equivalence statements
    and use the transfer intrinsic instead.  However, for gfortran that
    intrinsic was only implemented for version 4.1.2 so that is the
    minimum version requirement for gfortran now if you attempt to build
    the f95 bindings.  Note, earlier versions of gfortran build the f77
    bindings with no problems.
  
  2.8.5 Octave 2.9
    Octave 2.9 has a number of significant differences from version 2.1. 
    The octave language bindings have been updated to work with this new 
    version since the latest 2.9.x release is now the "recommended" choice 
    by the octave developers. Note that all the low-level plplot functions 
    work as expected. The higher level functions which replace the default
    octave / gnuplot plotting commands mostly work as for version 2.1. They 
    do not (yet) replicate the new and more Matlab-like functionality in 
    the latest 2.9.x releases of Octave.

    Note: As a result of the compatibilty code for octave 2.1 and lower the
    octave bindings will generate spurious warnings about obsolete built-in 
    variables when using octave 2.9. These can be silenced using the command
        warning("off","Octave:built-in-variable-assignment");
    before using the plplot bindings. This is not enabled by default as it 
    would also turn off genuine warnings in your own code which you might 
    want to fix. 

2.9 Updated examples

   The examples have been checked over to make sure that they all work
and to make them more consistent across different programming languages.

2.10 Drivers
  2.10.1 psttf
    This device driver now requires LASi version 1.0.6 or 1.0.5pl.  See
    http://www.unifont.org/lasi/ for instructions (depending on installed
    version of FreeType library) on which to choose.

  2.10.2 svg
    This is a new device driver that creates Scalable Vector Graphics files
    (http://www.w3.org/Graphics/SVG/). SVG is a XML language describing
    graphics that is supported directly or via plug-ins in most modern web
    browsers. The driver is off by default as its text handling has not been
    perfected.

  2.10.3 wxwidgets
    This driver has been updated a great deal. The most important improvements
    have been to the antialiasing part of the driver. It is now about 4 times
    faster than it was, and is nearly comparable in speed to the driver
    with the antialiasing turned off. In addition the antialiasing code can
    now handle filled polygons and window resizing.

  2.10.4 pdf
    A basic version of a pdf driver was added to the latest PLplot release.
    This driver is based on the libharu library
    (http://libharu.sourceforge.net/). At present only the Hershey fonts are
    used and there is no support for pdf or TrueType fonts. Compression of the 
    pdf output is not enabled and the paper size can't be chosen. All these 
    issues will be addressed in later releases.

  2.10.5 gd, wingcc (freetype)
    Improved anti-aliasing routines have been added to PLplot's freetype
    font rendering engine. The gd and wingcc drivers have been modified in
    turn to take advantage of these new routines, leading to improved text
    rendering.

  2.10.6 cairo
    This is a family of drivers that use the Cairo graphics library to
    render text and graphics. The graphics and the text are both
    anti-aliased which yields some outstanding-looking results. This driver
    is unicode enabled, and Truetype fonts are used by default. Most of the
    devices that are theoretically possible with Cairo have been
    implemented. These are an X device (xcairo), a PostScript device
    (pscairo), a PNG device (pngcairo, a PDF device (pdfcairo), an SVG
    device (svgcairo), and a memory device (memcairo). The cairo device
    driver is still considered experimental as a whole. Known issues include
    improper text rendering with svgcairo and memcairo not working at all so
    those two devices are disabled by default.  The pngcairo, pscairo, and
    xcairo devices appear to work without problems and also give
    outstanding-looking antialiased and hinted results so are enabled by
    default. The pdfcairo device appears to work reasonable well so is
    enabled by default although it is not as mature as the other three cairo
    devices that are enabled.

  2.10.7 pstex driver
       This Latex driver has now been resurrected from years of neglect and
    aside from bounding box issues seems to be working well.  Should be
    useful for Latex enthusiasts.

  2.10.8 plmeta driver
    The combination of the plmeta device and the plrender application that
    renders plmeta results is unmaintained and has some known issues with
    strings, aspect ratio changes, and fonts.  Therefore, the plmeta device
    is now not enabled by default, and must be specifically enabled by the
    user using the -DPLD_plmeta=ON cmake option. Furthermore, plrender is
    not built or installed and the plrender man page is not installed unless
    the plmeta device is specifically enabled.


PLplot Release 5.8.0-RC1
~~~~~~~~~~~~~~~~~~~~~~~~

This is a stable 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, then please send bug reports to PLplot developers via the
mailing lists at http://sourceforge.net/mail/?group_id=2915 .

     Please see the license under which this software is distributed
(LGPL), and the disclaimer of all warranties, given in the COPYING.LIB
file.

N.B. This is the official notice that our deprecated autotools-based build
system is scheduled for removal starting with the 5.9.0 release.  The reason
for this decision is the PLplot developers and users are happy with our
CMake-based build system (see below), and nobody has been willing to spend
time maintaining our old autotools-based build system.

Note for Windows users:
The same holds for the old Windows build system in sys/win32/msdev. This
build system is much less flexible than the CMake-based system. It also
lacks a larger number of important features - freetype text, language
bindings and so on. With the 5.9.0 release the source distribution will
no longer contain this directory. Hence you should switch to the new
build system described below.

Note for gfortran users of our f95 bindings: gfortran version 4.1.2 or later
is a requirement, see fortran 95 bindings remarks below.

INDEX

1. Changes relative to PLplot 5.7.4
  1.1 Drivers
    1.1.1 cairo devices
    1.1.2 plmeta/plrender
  1.2 Fortran 95 bindings
  1.3 plmtex3/plptex3
  1.4 Octave 2.9
  
2. Changes relative to PLplot 5.6.1
  2.1 CVS to Subversion conversion
  2.2 CMake build system
  2.3 Plot Buffering
  2.4 Updated INSTALL/README
  2.5 malloc/calloc clean up
  2.6 Documentation
  2.7 Additions to the PLplot API
  2.8 Language bindings
    2.8.1 ADA language binding
    2.8.2 wxwidgets applications bindings
    2.8.3 Python bindings
    2.8.4 Fortran 95 bindings
    2.8.5 Octave 2.9
  2.9 Updated examples
  2.10 Drivers
    2.10.1 psttf
    2.10.2 svg
    2.10.3 wxwidgets
    2.10.4 pdf
    2.10.5 gd, wingcc (freetype)
    2.10.6 cairo
    2.10.7 pstex
    2.10.8 plmeta (and plrender application to render plmeta results).


1. Changes relative to PLplot 5.7.4 (the previous development release)

1.1 Drivers
   1.1.1 cairo devices
     The xwinttf driver has been renamed xcairo. In addition most of the
     other devices that are theoretically possible with Cairo have been
     implemented. These are a PostScript device (pscairo), a PNG device
     (pngcairo), a PDF device (pdfcairo), an SVG device (svgcairo), and a
     memory device (memcairo). The cairo device driver is still considered
     experimental as a whole. Known issues include improper text rendering
     with svgcairo and memcairo not working at all so those two devices are
     disabled by default.  The pngcairo, pscairo, and xcairo devices appear
     to work without problems and also give outstanding-looking antialiased
     and hinted results so are enabled by default. The pdfcairo device
     appears to work reasonably well so is enabled by default although it is
     not as mature as the other Cairo devices that are enabled.

   1.1.2 plmeta/plrender
     The combination of the plmeta device and the plrender application
     that renders plmeta results is unmaintained and has some known issues
     with strings, aspect ratio changes, and fonts.  Therefore, the plmeta
     device is now not enabled by default, and must be specifically enabled
     by the user using the -DPLD_plmeta=ON cmake option.  Furthermore,
     plrender is not built or installed and the plrender man page is not
     installed unless the plmeta device is specifically enabled.

1.2 Fortran 95 bindings

    Equivalance statements in our F95 bindings were causing problems for
    one fortran 95 compiler so we have dropped those equivalence statements
    and use the transfer intrinsic instead.  However, for gfortran that
    intrinsic was only implemented for version 4.1.2 so that is the
    minimum version requirement for gfortran now if you attempt to build
    the f95 bindings.  Note, earlier versions of gfortran build the f77
    bindings with no problems.

1.3  plmtex3/plptex3

    These two functions, which were added in release 5.7.3, had a number
    of bugs. These have hopefully been cleaned up. Example 28 demonstrates
    how to use these functions. The functions and the example have now been
    implemented for most language bindings.

1.4 Octave 2.9
  
    Octave 2.9 has a number of significant differences from version 2.1. 
    The octave language bindings have been updated to work with this new 
    version since the latest 2.9.x release is now the "recommended" choice 
    by the octave developers. Note that all the low-level plplot functions 
    work as expected. The higher level functions which replace the default
    octave / gnuplot plotting commands mostly work as for version 2.1. They 
    do not (yet) replicate the new and more Matlab-like functionality in 
    the latest 2.9.x releases of Octave.

    Note: As a result of the compatibilty code for octave 2.1 and lower the
    octave bindings will generate spurious warnings about obsolete built-in 
    variables when using octave 2.9. These can be silenced using the command
        warning("off","Octave:built-in-variable-assignment");
    before using the plplot bindings. This is not enabled by default as it 
    would also turn off genuine warnings in your own code which you might 
    want to fix. 


2. Changes relative to PLplot 5.6.1 (the previous stable release)

2.1 CVS to Subversion conversion

   PLplot now uses the Subversion (svn) version control system. Records of
all the changes and release tags have been preserved from the CVS repository.

2.2 CMake build system

   PLplot now uses the CMake build system (www.cmake.org) and the older
autotools build system has been deprecated and is scheduled for removal as
of the 5.9.0 release. The switch to CMake was made due its superior support
for Windows platforms and its relative simplicity compared to autotools on
Unix. To use CMake to configure and build PLplot follow the directions at
http://www.miscdebris.net/plplot_wiki/.

2.3 Plot Buffering

   PLplot core has been modified to buffer plot commands in memory rather than
via a unix pipe or temporary file. Testing has shown that there is 20-30%
improvement in plotting performance (i.e. speed). This is likely to be system
dependent and some may see a much larger benefit. This also resolves a problem
with some windows platforms where the temporary files were not getting deleted.

2.4 Updated INSTALL/README

   The INSTALL and README files have been updated. They now include detailed
instructions for building plplot using the new CMake build system on Linux
and Windows.

2.5 malloc/calloc clean up

   Checks have been added to many (all?) of the calls to calloc and malloc in
the PLplot core. The purpose of the check is to verify that the memory
requested was actually allocated prior to attempting to use it.

2.6 Documentation

   The API section has been expanded to include information about how to call
the functions from Fortran95, Java, Perl/PDL and Python. Since array dimension
information is typically redundant in these languages it is dropped in many
of the relevant function. Additionally, some of the Perl/PDL function calls
have a different argument order than their C equivalent. This section has also
been expanded to include a list of which examples each function is used in
(if any).

   The Fortran95 documentation has been updated.

2.7 Additions to the PLplot API

   The functions plptex3 and plmtex3 have been added to the PLplot API. These
allow the user to draw text in "3D" on the 3D plots. plptex3 is the 3D
equivalent of plptex and plmtex3 is the 3D equivalent of plmtex. Their
use is demonstrated by example 28.

2.8 Language bindings
  2.8.1 ADA
       Jerry Bauck has donated bindings to the ADA programming language.
    These bindings have been included into the CMake build system,
    and should be generated automatically if you have an ADA compiler and
    you specify the cmake option -DENABLE_ada=ON. The ADA bindings are now
    considered complete and the current focus is on implementing all of the
    examples in ADA to help test the bindings.  Until that work is completed
    these bindings should be considered experimental.

  2.8.2 wxwidgets applications bindings
       The wxWidgets bindings provide an interface to the PLplot API and a
    simple widget to be used in a wxWidgets application. The class
    'wxPLplotstream' inherited from the PLplot class 'plstream' allows access
    to the complete PLplot API. 'wxPLplotWindow' is a simple wxWidget which
    takes care of some preparatory work for convenient use of the PLplot
    Library within a wxWidgets application.

  2.8.3 Python bindings
    The Python bindings have been updated to use numpy rather than the now
    deprecated Numeric python numeric library.

  2.8.4 Fortran 95 bindings
    Equivalance statements in our F95 bindings were causing problems for
    one fortran 95 compiler so we have dropped those equivalence statements
    and use the transfer intrinsic instead.  However, for gfortran that
    intrinsic was only implemented for version 4.1.2 so that is the
    minimum version requirement for gfortran now if you attempt to build
    the f95 bindings.  Note, earlier versions of gfortran build the f77
    bindings with no problems.
  
  2.8.5 Octave 2.9
    Octave 2.9 has a number of significant differences from version 2.1. 
    The octave language bindings have been updated to work with this new 
    version since the latest 2.9.x release is now the "recommended" choice 
    by the octave developers. Note that all the low-level plplot functions 
    work as expected. The higher level functions which replace the default
    octave / gnuplot plotting commands mostly work as for version 2.1. They 
    do not (yet) replicate the new and more Matlab-like functionality in 
    the latest 2.9.x releases of Octave.

    Note: As a result of the compatibilty code for octave 2.1 and lower the
    octave bindings will generate spurious warnings about obsolete built-in 
    variables when using octave 2.9. These can be silenced using the command
        warning("off","Octave:built-in-variable-assignment");
    before using the plplot bindings. This is not enabled by default as it 
    would also turn off genuine warnings in your own code which you might 
    want to fix. 

2.9 Updated examples

   The examples have been checked over to make sure that they all work
and to make them more consistent across different programming languages.

2.10 Drivers
  2.10.1 psttf
    This device driver now requires LASi version 1.0.6 or 1.0.5pl.  See
    http://www.unifont.org/lasi/ for instructions (depending on installed
    version of FreeType library) on which to choose.

  2.10.2 svg
    This is a new device driver that creates Scalable Vector Graphics files
    (http://www.w3.org/Graphics/SVG/). SVG is a XML language describing
    graphics that is supported directly or via plug-ins in most modern web
    browsers. The driver is off by default as its text handling has not been
    perfected.

  2.10.3 wxwidgets
    This driver has been updated a great deal. The most important improvements
    have been to the antialiasing part of the driver. It is now about 4 times
    faster than it was, and is nearly comparable in speed to the driver
    with the antialiasing turned off. In addition the antialiasing code can
    now handle filled polygons and window resizing.

  2.10.4 pdf
    A basic version of a pdf driver was added to the latest PLplot release.
    This driver is based on the libharu library
    (http://libharu.sourceforge.net/). At present only the Hershey fonts are
    used and there is no support for pdf or TrueType fonts. Compression of the 
    pdf output is not enabled and the paper size can't be chosen. All these 
    issues will be addressed in later releases.

  2.10.5 gd, wingcc (freetype)
    Improved anti-aliasing routines have been added to PLplot's freetype
    font rendering engine. The gd and wingcc drivers have been modified in
    turn to take advantage of these new routines, leading to improved text
    rendering.

  2.10.6 cairo
    This is a family of drivers that use the Cairo graphics library to
    render text and graphics. The graphics and the text are both
    anti-aliased which yields some outstanding-looking results. This driver
    is unicode enabled, and Truetype fonts are used by default. Most of the
    devices that are theoretically possible with Cairo have been
    implemented. These are an X device (xcairo), a PostScript device
    (pscairo), a PNG device (pngcairo, a PDF device (pdfcairo), an SVG
    device (svgcairo), and a memory device (memcairo). The cairo device
    driver is still considered experimental as a whole. Known issues include
    improper text rendering with svgcairo and memcairo not working at all so
    those two devices are disabled by default.  The pngcairo, pscairo, and
    xcairo devices appear to work without problems and also give
    outstanding-looking antialiased and hinted results so are enabled by
    default. The pdfcairo device appears to work reasonable well so is
    enabled by default although it is not as mature as the other three cairo
    devices that are enabled.

  2.10.7 pstex driver
       This Latex driver has now been resurrected from years of neglect and
    aside from bounding box issues seems to be working well.  Should be
    useful for Latex enthusiasts.

  2.10.8 plmeta driver
    The combination of the plmeta device and the plrender application that
    renders plmeta results is unmaintained and has some known issues with
    strings, aspect ratio changes, and fonts.  Therefore, the plmeta device
    is now not enabled by default, and must be specifically enabled by the
    user using the -DPLD_plmeta=ON cmake option. Furthermore, plrender is
    not built or installed and the plrender man page is not installed unless
    the plmeta device is specifically enabled.


PLplot Release 5.7.4
~~~~~~~~~~~~~~~~~~~~

This is a routine development release of PLplot. It represents the ongoing 
efforts of the community to improve the PLplot plotting package. Development 
releases in the 5.7.x series will be available every few months. The next 
stable release will be 5.8.0.

     If you encounter a problem that is not already documented in the
PROBLEMS file, then please send bug reports to PLplot developers via the
mailing lists at http://sourceforge.net/mail/?group_id=2915 .

     Please see the license under which this software is distributed
(LGPL), and the disclaimer of all warrantees, given in the COPYING.LIB
file.


INDEX

1. Changes relative to PLplot 5.7.3
  1.1 CVS to Subversion conversion
  1.2 Drivers
    1.2.1 xwinttf -> xcairo
  1.3 Ada bindings
  1.4 Python bindings
  1.5 Fortran95 Documentation
  
2. Changes relative to PLplot 5.6.1
  2.1 CVS to Subversion conversion
  2.2 CMake build system
  2.3 Plot Buffering
  2.4 Updated INSTALL/README
  2.5 malloc/calloc clean up
  2.6 Documentation
  2.7 Additions to the PLplot API
  2.8 Language bindings
    2.8.1 Experimental ADA language binding
    2.8.2 wxwidgets applications bindings
  2.9 Updated examples
  2.10 Drivers
    2.10.1 psttf
    2.10.2 svg
    2.10.3 wxwidgets
    2.10.4 pdf
    2.10.5 gd, wingcc (freetype)
    2.10.6 cairo
    2.10.7 pstex
  2.11 Python bindings
  2.12 Fortran95 Documentation


1. Changes relative to PLplot 5.7.3 (the previous development release)

1.1 CVS to Subversion conversion

   PLplot now uses the Subversion (svn) version control system. Records of
all the changes and release tags have been preserved from the CVS repository.

1.2 Drivers
   1.2.1 xwinttf -> xcairo
        The xwinttf driver has been renamed xcairo. In addition most of the
     the other output devices that Cairo supports are now supported. These
     include a postscript driver (pscairo), a PDF driver (pdfcairo), a
     SVG driver (svgcairo), a PNG driver (pngcairo) and a memory driver
     (memcairo). This driver is still considered experimental. Known issues 
     include improper text rendering with the SVG driver and the memory 
     driver does not work at all.

1.3 Ada bindings

    The ADA bindings are now considered complete and the current focus is on
implementing all of the examples in ADA.

1.4 Python bindings

    The Python bindings have been updated to use numpy rather than the now
deprecated Numeric python numeric library. If you need to revert to the old
Numeric support, then you should specify the cmake option -DHAVE_NUMPY=OFF.

1.5 Fortran95 documentation

    The Fortran95 documentation has been updated.


2. Changes relative to PLplot 5.6.1 (the previous stable release)

2.1 CVS to Subversion conversion

   PLplot now uses the Subversion (svn) version control system. Records of
all the changes and release tags have been preserved from the CVS repository.

2.2 CMake build system

   PLplot now uses the CMake build system (www.cmake.org) and the older
autotools build system has been deprecated. The switch to CMake was made due
its superior support for Windows platforms and its relative simplicity
compared to autotools. CMake 2.4.5 is the minimum required version of cmake.
Finding swig has been improved such that it should now be found as long as
it is in your path.

2.3 Plot Buffering

   PLplot core has been modified to buffer plot commands in memory rather than
via a unix pipe or temporary file. Testing has shown that there is 20-30%
improvement in plotting performance (i.e. speed). This is likely to be system
dependent and some may see a much larger benefit. This also resolves a problem 
with some windows platforms where the temporary files were not getting deleted.

2.4 Updated INSTALL/README

   The INSTALL and README files have been updated. They now include detailed
instructions for building plplot using the new CMake build system on linux
and windows.

2.5 malloc/calloc clean up

   Checks have been added to many (all?) of the calls to calloc and malloc in
the PLplot core. The purpose of the check is to verify that the memory 
requested was actually allocated prior to attempting to use it.

2.6 Documentation

   The API section has been expanded to include information about how to call
the functions from Fortran95, Java, Perl/PDL and Python. Since array dimension
information is typically redundant in these languages it is dropped in many
of the relevant function. Additionally, some of the Perl/PDL function calls 
have a different argument order than their C equivalent. This section has also 
been expanded to include a list of which examples each function is used in 
(if any).

2.7 Additions to the PLplot API

   The functions plptex3 and plmtex3 have been added to the PLplot API. These
allow the user to draw text in "3D" on the 3D plots. plptex3 is the 3D
equivalent of plptex and plmtex3 is the 3D equivalent of plmtex.
 
2.8 Language bindings
  2.8.1 ADA
       Jerry Bauck has donated bindings to the ADA programming language. 
    These are considered experimental in nature and the API is subject to
    change.  These bindings have been included into the CMake build system,
    and should be generated automatically if you have an ADA compiler and
    you specify the cmake option -DENABLE_ada=ON.  Four standard examples
    have been completed and work on a complete set of examples is ongoing.

  2.8.2 wxwidgets applications bindings
       The wxWidgets bindings provide an interface to the PLplot API and a 
    simple widget to be used in a wxWidgets application. The class 
    'wxPLplotstream' inherited from the PLplot class 'plstream' allows access
    to the complete PLplot API. 'wxPLplotWindow' is a simple wxWidget which
    takes care of some preparational work for convenient use of the PLplot
    Library within a wxWidgets application.
 
2.9 Updated examples

   The examples have been checked over to make sure that they all work
and to make them more consistent across different programming languages.   

2.10 Drivers
  2.10.1 psttf
    This device driver now requires LASi version 1.0.6 or 1.0.5pl.  See
    http://www.unifont.org/lasi/ for instructions (depending on installed
    version of FreeType library) on which to choose.

  2.10.2 svg
    This is a new device driver that creates Scalable Vector Graphics files 
    (http://www.w3.org/Graphics/SVG/). SVG is a XML language describing
    graphics that is supported directly or via plug-ins in most modern web
    browsers. The driver is off by default as its text handling has not been
    perfected.

  2.10.3 wxwidgets
    This driver has been updated a great deal. The most important improvements
    have been to the antializing part of the driver. It is now about 4 times
    faster than it was, and is nearly comparable in speed to the driver
    with the antializing turned off. In addition the antializing code can
    now handle filled polygons and window resizing.

  2.10.4 pdf
    A basic version of a pdf driver was added to the latest PLplot release. 
    This driver is based on the libharu library 
    (http://libharu.sourceforge.net/). At present only the hershey fonts are 
    used and there is no support for pdf or ttf fonts. Compression of the pdf 
    output is not enabled and the paper size can't be chosen. All these issues 
    will be addressed in later releases.

  2.10.5 gd, wingcc (freetype)
    Improved anti-aliasing routines have been added to plplot's freetype
    font rendering engine. The gd and wingcc drivers have been modified in 
    turn to take advantage of these new routines, leading to improved text
    rendering.

  2.10.6 cairo 
       This is a family of drivers that use the Cairo graphics library to
    render text and graphics. The graphics and the text are both
    anti-aliased. It is unicode enabled and Truetype fonts are used by 
    default. Most of the the output devices that Cairo supports are 
    supported. These include a X windows driver (xcairo), a postscript 
    driver (pscairo), a PDF driver (pdfcairo), a SVG driver (svgcairo), a 
    PNG driver (pngcairo) and a memory driver (memcairo). This driver is 
    still considered experimental. Known issues include improper text 
    rendering with the SVG driver and the memory driver does not work at 
    all.

  2.10.7 pstex driver
       This Latex driver has now been resurrected from years of neglect and
    aside from bounding box issues seems to be working well.  Should be
    useful for Latex enthusiasts.

1.4 Python bindings

    The Python bindings have been updated to use numpy rather than the now
deprecated Numeric python numeric library.

1.5 Fortran95 documentation

    The Fortran95 documentation has been updated.


PLplot Release 5.7.3
~~~~~~~~~~~~~~~~~~~~

This is a routine development release of PLplot. It represents the ongoing 
efforts of the community to improve the PLplot plotting package. Development 
releases in the 5.7.x series will be available every few months. The next 
stable release will be 5.8.0.

     If you encounter a problem that is not already documented in the
PROBLEMS file, then please send bug reports to PLplot developers via the
mailing lists at http://sourceforge.net/mail/?group_id=2915 .

     Please see the license under which this software is distributed
(LGPL), and the disclaimer of all warrantees, given in the COPYING.LIB
file.


INDEX

1. Changes relative to PLplot 5.7.2
  1.1 CMake build system
  1.2 malloc/calloc clean up
  1.3 Documentation
  1.4 Additions to the PLplot API
  1.5 Language bindings
    1.5.1 Experimental ADA language binding
    1.5.2 wxwidgets applications bindings
  1.6 Drivers
    1.6.1 xwinttf
    1.6.2 pstex

2. Changes relative to PLplot 5.6.1
  2.1 CMake build system
  2.2 Plot Buffering
  2.3 Updated INSTALL/README
  2.4 malloc/calloc clean up
  2.5 Documentation
  2.6 Additions to the PLplot API
  2.7 Language bindings
    2.7.1 Experimental ADA language binding
    2.7.2 wxwidgets applications bindings
  2.8 Updated examples
  2.9 Drivers
    2.9.1 psttf
    2.9.2 svg
    2.9.3 wxwidgets
    2.9.4 pdf
    2.9.5 gd, wingcc (freetype)
    2.9.6 xwinttf
    2.9.7 pstex


1. Changes relative to PLplot 5.7.2 (the previous development release)

1.1 CMake build system

   Finding swig has been improved such that it should now be found as long
as it is in your path.

1.2 malloc/calloc clean up

   Checks have been added to many (all?) of the calls to calloc and malloc in
the PLplot core. The purpose of the check is to verify that the memory 
requested was actually allocated prior to attempting to use it.

1.3 Documentation

   The API section has been expanded to include information about how to call
the functions from Fortran95, Java, Perl/PDL and Python. Since array dimension
information is typically redundant in these languages it is dropped in many
of the relevant function. Additionally, some of the Perl/PDL function calls 
have a different argument order than their C equivalent. This section has also 
been expanded to include a list of which examples each function is used in 
(if any).

1.4 Additions to the PLplot API

   The functions plptex3 and plmtex3 have been added to the PLplot API. These
allow the user to draw text in "3D" on the 3D plots. plptex3 is the 3D
equivalent of plptex and plmtex3 is the 3D equivalent of plmtex.
 
1.5 Language bindings
  1.5.1 ADA
       Jerry Bauck has donated bindings to the ADA programming language. 
    These are considered experimental in nature and the API is subject to
    change.  These bindings have been included into the CMake build system,
    and should be generated automatically if you have an ADA compiler and
    you specify the cmake option -DENABLE_ada=ON.  Four standard examples
    have been completed and work on a complete set of examples is ongoing.

  1.5.2 wxwidgets applications bindings
       The wxWidgets bindings provide an interface to the PLplot API and a 
    simple widget to be used in a wxWidgets application. The class 
    'wxPLplotstream' inherited from the PLplot class 'plstream' allows access
    to the complete PLplot API. 'wxPLplotWindow' is a simple wxWidget which
    takes care of some preparational work for convenient use of the PLplot
    Library within a wxWidgets application.
 
1.6 Drivers
 
  1.6.1 xwinttf driver
       This is a new driver for X Windows that uses Cairo for rendering
    graphics and Pango for rendering text. The graphics and the text are both
    anti-aliased. It is unicode enabled and Truetype fonts are used by 
    default.

  1.6.2 pstex driver
       This Latex driver has now been resurrected from years of neglect and
    aside from bounding box issues seems to be working well.  Should be
    useful for Latex enthusiasts.

2. Changes relative to PLplot 5.6.1 (the previous stable release)

2.1 CMake build system

   PLplot now uses the CMake build system (www.cmake.org) and the older
autotools build system has been deprecated. The switch to CMake was made due
its superior support for Windows platforms and its relative simplicity
compared to autotools. CMake 2.4.5 is the minimum required version of cmake.
Finding swig has been improved such that it should now be found as long as
it is in your path.

2.2 Plot Buffering

   PLplot core has been modified to buffer plot commands in memory rather than
via a unix pipe or temporary file. Testing has shown that there is 20-30%
improvement in plotting performance (i.e. speed). This is likely to be system
dependent and some may see a much larger benefit. This also resolves a problem 
with some windows platforms where the temporary files were not getting deleted.

2.3 Updated INSTALL/README

   The INSTALL and README files have been updated. They now include detailed
instructions for building plplot using the new CMake build system on linux
and windows.

2.4 malloc/calloc clean up

   Checks have been added to many (all?) of the calls to calloc and malloc in
the PLplot core. The purpose of the check is to verify that the memory 
requested was actually allocated prior to attempting to use it.

2.5 Documentation

   The API section has been expanded to include information about how to call
the functions from Fortran95, Java, Perl/PDL and Python. Since array dimension
information is typically redundant in these languages it is dropped in many
of the relevant function. Additionally, some of the Perl/PDL function calls 
have a different argument order than their C equivalent. This section has also 
been expanded to include a list of which examples each function is used in 
(if any).

2.6 Additions to the PLplot API

   The functions plptex3 and plmtex3 have been added to the PLplot API. These
allow the user to draw text in "3D" on the 3D plots. plptex3 is the 3D
equivalent of plptex and plmtex3 is the 3D equivalent of plmtex.
 
2.7 Language bindings
  2.7.1 ADA
       Jerry Bauck has donated bindings to the ADA programming language. 
    These are considered experimental in nature and the API is subject to
    change.  These bindings have been included into the CMake build system,
    and should be generated automatically if you have an ADA compiler and
    you specify the cmake option -DENABLE_ada=ON.  Four standard examples
    have been completed and work on a complete set of examples is ongoing.

  2.7.2 wxwidgets applications bindings
       The wxWidgets bindings provide an interface to the PLplot API and a 
    simple widget to be used in a wxWidgets application. The class 
    'wxPLplotstream' inherited from the PLplot class 'plstream' allows access
    to the complete PLplot API. 'wxPLplotWindow' is a simple wxWidget which
    takes care of some preparational work for convenient use of the PLplot
    Library within a wxWidgets application.
 
2.8 Updated examples

   The examples have been checked over to make sure that they all work
and to make them more consistent across different programming languages.   

2.9 Drivers
  2.9.1 psttf
    This device driver now requires LASi version 1.0.6 or 1.0.5pl.  See
    http://www.unifont.org/lasi/ for instructions (depending on installed
    version of FreeType library) on which to choose.

  2.9.2 svg
    This is a new device driver that creates Scalable Vector Graphics files 
    (http://www.w3.org/Graphics/SVG/). SVG is a XML language describing
    graphics that is supported directly or via plug-ins in most modern web
    browsers. The driver is off by default as its text handling has not been
    perfected.

  2.9.3 wxwidgets
    This driver has been updated a great deal. The most important improvements
    have been to the antializing part of the driver. It is now about 4 times
    faster than it was, and is nearly comparable in speed to the driver
    with the antializing turned off. In addition the antializing code can
    now handle filled polygons and window resizing.

  2.9.4 pdf
    A basic version of a pdf driver was added to the latest PLplot release. 
    This driver is based on the libharu library 
    (http://libharu.sourceforge.net/). At present only the hershey fonts are 
    used and there is no support for pdf or ttf fonts. Compression of the pdf 
    output is not enabled and the paper size can't be chosen. All these issues 
    will be addressed in later releases.

  2.9.5 gd, wingcc (freetype)
    Improved anti-aliasing routines have been added to plplot's freetype
    font rendering engine. The gd and wingcc drivers have been modified in 
    turn to take advantage of these new routines, leading to improved text
    rendering.

  2.9.6 xwinttf driver
       This is a new driver for X Windows that uses Cairo for rendering
    graphics and Pango for rendering text. The graphics and the text are both
    anti-aliased. It is unicode enabled and Truetype fonts are used by 
    default.

  2.9.7 pstex driver
       This Latex driver has now been resurrected from years of neglect and
    aside from bounding box issues seems to be working well.  Should be
    useful for Latex enthusiasts.


PLplot Release 5.7.2
~~~~~~~~~~~~~~~~~~~~

This is a routine development release of PLplot. It represents the ongoing 
efforts of the community to improve the PLplot plotting package. Development 
releases in the 5.7.x series will be available every few months. The next full 
release will be 5.8.0.

     If you encounter a problem that is not already documented in the
PROBLEMS file, then please send bug reports to PLplot developers via the
mailing lists at http://sourceforge.net/mail/?group_id=2915 .

     Please see the license under which this software is distributed
(LGPL), and the disclaimer of all warrantees, given in the COPYING.LIB
file.


INDEX

1. Changes relative to PLplot 5.7.1
  1.1 CMake build system
  1.2 Updated INSTALL/README
  1.3 Updated examples
  1.4 Drivers
    1.4.1 pdf
    1.4.2 gd, wingcc (freetype)

2. Changes relative to PLplot 5.6.1
  2.1 CMake build system
  2.2 Plot Buffering 
  2.3 Drivers
    2.3.1 psttf
    2.3.2 svg
    2.3.3 wxwidgets

1. Changes relative to PLplot 5.7.1 (the previous development release)

1.1 CMake build system

   CMake 2.4.5 is the now minimum required version of cmake. A lot of work
has been done to improve this build system, particularly for Windows 
platforms.  

1.2 Updated INSTALL/README

   The INSTALL and README files have been updated. They now include detailed
instructions for building plplot using the new CMake build system on linux
and windows.

1.3 Updated examples

   The examples have been checked over to make sure that they all work
and to make them more consistent across different programming languages.   

1.4 Drivers
  1.4.1 pdf
    A basic version of a pdf driver was added to the latest PLplot release. 
    This driver is based on the libharu library 
    (http://libharu.sourceforge.net/). At present only the hershey fonts are 
    used and there is no support for pdf or ttf fonts. Compression of the pdf 
    output is not enabled and the paper size can't be chosen. All these issues 
    will be addressed in later releases.

  1.4.2 gd, wingcc (freetype)
    Improved anti-aliasing routines have been added to plplot's freetype
    font rendering engine. The gd and wingcc drivers have been modified in 
    turn to take advantage of these new routines, leading to improved text
    rendering.


2. Changes relative to PLplot 5.6.1 (the previous stable release)

2.1 CMake build system

   PLplot now uses the CMake build system (www.cmake.org) and the older
autotools build system has been deprecated. The switch to CMake was made due
its superior support for Windows platforms and its relative simplicity
compared to autotools. 

2.2 Plot Buffering

   PLplot core has been modified to buffer plot commands in memory rather than
via a unix pipe or temporary file. Testing has shown that there is 20-30%
improvement in plotting performance (i.e. speed). This is likely to be system
dependent and some may see a much larger benefit. This also resolves a problem 
with some windows platforms where the temporary files were not getting deleted.

2.3 Drivers
  2.3.1 psttf
    This device driver now requires LASi version 1.0.6 or 1.0.5pl.  See
    http://www.unifont.org/lasi/ for instructions (depending on installed
    version of FreeType library) on which to choose.

  2.3.2 svg
    This is a new device driver that creates Scalable Vector Graphics files 
    (http://www.w3.org/Graphics/SVG/). SVG is a XML language describing
    graphics that is supported directly or via plug-ins in most modern web
    browsers. The driver is off by default as its text handling has not been
    perfected.

  2.3.3 wxwidgets
    This driver has been updated a great deal. The most important improvements
    have been to the antializing part of the driver. It is now about 4 times
    faster than it was, and is nearly comparable in speed to the driver
    with the antializing turned off. In addition the antializing code can
    now handle filled polygons and window resizing.


PLplot Release 5.7.1
~~~~~~~~~~~~~~~~~~~~

This is a routine development release of PLplot. It represents the ongoing 
efforts of the community to improve the PLplot plotting package. Development 
releases in the 5.7.x series will be available every few months. The next full 
release will be 5.8.0.

     If you encounter a problem that is not already documented in the
PROBLEMS file, then please send bug reports to PLplot developers via the
mailing lists at http://sourceforge.net/mail/?group_id=2915 .

     Please see the license under which this software is distributed
(LGPL), and the disclaimer of all warrantees, given in the COPYING.LIB
file.


INDEX

1. Changes relative to PLplot 5.6.1
  1.1 CMake build system
  1.2 Plot Buffering 
  1.3 Drivers
    1.3.1 psttf
    1.3.2 svg
    1.3.3 wxwidgets


1. Changes relative to PLplot 5.6.1 (the previous stable release)

1.1 CMake build system

   PLplot now uses the CMake build system (www.cmake.org) and the older
autotools build system has been deprecated. The switch to CMake was made due
its superior support for Windows platforms and its relative simplicity
compared to autotools. 

1.2 Plot Buffering

   PLplot core has been modified to buffer plot commands in memory rather than
via a unix pipe or temporary file. Testing has shown that there is 20-30%
improvement in plotting performance (i.e. speed). This is likely to be system
dependent and some may see a much larger benefit. This also resolves a problem 
with some windows platforms where the temporary files were not getting deleted.

1.3 Drivers
  1.3.1 psttf
    This device driver now requires LASi version 1.0.6 or 1.0.5pl.  See
    http://www.unifont.org/lasi/ for instructions (depending on installed
    version of FreeType library) on which to choose.

  1.3.2 svg
    This is a new device driver that creates Scalable Vector Graphics files 
    (http://www.w3.org/Graphics/SVG/). SVG is a XML language describing
    graphics that is supported directly or via plug-ins in most modern web
    browsers. The driver is off by default as its text handling has not been
    perfected.

  1.3.3 wxwidgets
    This driver has been updated a great deal. The most important improvements
    have been to the antializing part of the driver. It is now about 4 times
    faster than it was, and is nearly comparable in speed to the driver
    with the antializing turned off. In addition the antializing code can
    now handle filled polygons and window resizing.



PLplot Bug Fix Release 5.6.1
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

This release corrects a number of outstanding issues with plplot that were
discovered subsequent to the 5.6.0 release. It represents the ongoing efforts 
of the community to improve the PLplot plotting package. Development releases 
in the 5.7.x series will be available every few months. The next full release 
will be 5.8.0.

     If you encounter a problem that is not already documented in the
PROBLEMS file, then please send bug reports to PLplot developers via the
mailing lists at http://sourceforge.net/mail/?group_id=2915 .

     Please see the license under which this software is distributed
(LGPL), and the disclaimer of all warrantees, given in the COPYING.LIB
file.


INDEX

1. Changes relative to PLplot 5.6.0
  1.1 API
    1.1.1 f95
  1.2 Drivers
    1.2.1 psttf
    1.2.2 pstex


1. Changes relative to PLplot 5.6.0 (the previous stable release)

1.1 Fortran 95

A lot of work was done to correct a number of outstanding issues with
Fortran 95 interface. All of plplot API is now available to f95 users and
a complete set of examples was created to demonstrate how to use plplot with 
a f95. In its current form it is known to work with gfortran compiler. Due
to limitations in the current version of libtool it not possible to use both
a f77 and a f95 compiler to build plplot. If you desire both interfaces the
recommended approach is to compile the f77 interface with your f95 compiler,
which can be done by setting the FC and F77 environment variables at the
configuration stage.

- The API is defined via a module, so that the compiler can now check
  the argument types.
- It is now possible to pass arrays as assumed-shape arrays. This
  means: less arguments and less chances for interface errors.
- The module also defines specific parameters to describe PLplot
  options. This way, you can use symbolic names instead of
  numbers.
- The floating-point type PLFLT is now available as a KIND parameter,
  making it possible to use the same code for single and double
  precision applications - simply declare all real variables
  using the KIND facility and link with the corresponding version of
  the PLplot library.

More information is found in bindings/f95/readme_f95.txt


1.2 Drivers

1.2.1 psttf

This is a postscript driver that supports TrueType fonts. This allows access 
to a far greater range of fonts and characters than is possible using Type 1
postscript fonts. 

The driver requires the LASi (v1.0.5), pango and pangoft2 libraries to work.
The pango and pangoft2 libraries are widely distributed with most Linux
distributions and give the psttf driver full complex text layout (CTL)
capability (see http://plplot.sourceforge.net/examples/demo24.php for an
example of this capability).  The LASi library is not part of most
distributions at this time. The source code can be downloaded from
http://www.unifont.org/lasi/. The library is small and easy to build and
install.  Make sure you use LASi-1.0.5.  The psttf device driver uses new
capabilities in this version of LASi and no longer works with LASi-1.0.4.

This driver is now enabled by default. 

1.2.2 pstex

Permanently disable the autotools build of pstex.  Other PostScript devices
(either ps or psttf) appear to give better solutions so there doesn't seem
to be much purpose in maintaining this currently broken device.



PLplot Development Release 5.6.0
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

This is a stable release of PLplot. It represents the ongoing efforts of the
community to improve the PLplot plotting package. Development releases in the
5.7.x series will be available every few months. The next full release will
be 5.8.0.

     If you encounter a problem that is not already documented in the
PROBLEMS file, then please send bug reports to PLplot developers via the
mailing lists at http://sourceforge.net/mail/?group_id=2915 .

     Please see the license under which this software is distributed
(LGPL), and the disclaimer of all warrantees, given in the COPYING.LIB
file.


INDEX

1. Build Instructions
2. Changes relative to PLplot 5.5.3
  2.1 API
    2.1.1 PLBOOL
  2.2 Drivers
    2.2.1 psttf
    2.2.2 wingcc
    2.2.3 wxwidgets
3. Changes relative to PLplot 5.3.1
  3.1 API
    3.1.1 Deprecated functions
    3.1.2 Unicode
    3.1.3 Extended cmap0 support
    3.1.4 The PlplotCanvas Widget for Gnome/GTK Applications
  3.2 Drivers
    3.2.1 PostScript
    3.2.2 psttf
    3.2.3 GD (png, jpeg, gif)
    3.2.4 GCW (Gnome 2)
    3.2.5 AquaTerm (Mac OS X)
    3.2.6 Tk
    3.2.7 wxwidgets
4. Notes on Autotools
  4.1 Autotools versions
  4.2 cf/bootstrap.sh output

1. Build Instructions

For detailed instructions on how to build and install PLplot from this
tarball, please read the INSTALL file.  The basic procedure is to execute
the following commands:

  ./configure
  make
  make install

     There are a variety of configuration options, and these are explained
in the INSTALL document, and below as required.  In particular, if you
want to install the PLplot Programmer's Reference Manual, please use:

  ./configure --with-prebuiltdoc

Note that it is often helpful to use the --with-pkg-config option if your
system has the pkg-config program (typically *nix systems).


2. Changes relative to PLplot 5.5.3 (the previous development release)


2.1 API


2.1.1 PLBOOL

The java interface was reworked to use the PLBOOL type.

2.1.2 Fortran 95

The language bindings have been extended to Fortran 95. While it is
possible to use the F77 bindings in a program that uses the Fortran 95
features (as Fortran 95 is almost 100% compatible with FORTRAN 77),
there are a few aspects specific to this newer standard that made
it worthwhile to support Fortran 95 explicitly:

- The API is defined via a module, so that the compiler can now check
  the argument types.
- It is now possible to pass arrays as assumed-shape arrays. This
  means: less arguments and less chances for interface errors.
- The module also defines specific parameters to describe PLplot
  options. This way, you can use symbolic names instead of
  numbers.
- The floating-point type PLFLT is now available as a KIND parameter,
  making it possible to use the same code for single and double
  precision applications - simply declare all real variables
  using the KIND facility and link with the corresponding version of
  the PLplot library.

More information is found in bindings/f95/readme_f95.txt


2.2 Drivers


2.2.1 psttf

Initial version of a postscript driver that supports TrueType fonts. 
This allows access to a far greater range of fonts and characters than 
is possible using purely postscript fonts. 

The driver requires the LASi, pango and pangoft2 libraries to work. 
The pango and pangoft2 libraries are widely distributed with most 
Linux distributions at least. The LASi library is not part of most 
distributions at this time. The source code can be downloaded from 
http://eyegene.ophthy.med.umich.edu/lasi/. The library is small and 
easy to build and install.

This driver is disabled by default. To try it you will need to add 
the --enable-psttf --enable-psttfc options when running configure.

2.2.2 wingcc

Performance improvements have been implemented.

2.2.3 wxwidgets

Major upgrade that eliminated a number of bugs and added support for unicode
fonts.

2.2.4 win32

Support for UNICODE and anti-aliasing fonts added


3. Changes Relative to PLplot 5.3.1 (the previous stable release)


3.1 API


3.1.1 Deprecated functions

plParseOpts, plHLS_RGB, and plRGB_HLS are now deprecated and will eventually
be removed from the API.  Use plparseopts, plhlsrgb, and plrgbhls instead
for all language interfaces.


3.1.2 Unicode

PLplot now supports unicode text.  The escape sequence for unicode
characters is

     #[nnn]

where nnn can be decimal or hexadecimal.  Escape sequences are also defined
to change fonts mid-string.

     There are known bugs for our unicode font implementation that are
listed in a special section of the PROBLEMS file, but the current
implementation is good enough so we turn on unicode support by default
for the psc, ps, png, gif, jpeg, and gcw devices.  Although all examples
look better with unicode fonts, the new PLplot unicode capabilities are
especially demonstrated in examples x23 and x24.  (The latter example
requires special fonts to be installed and at run time environment
variables have to be set to access them;  see the self-documentation of
the example 24 source code).


3.1.3 Extended cmap0 support.

There have been many updates to cmap0 handling in the effort to wipe away
all vestiges of the old 16 color limit.  The theoretical limit should now
be 2^15 colors, since the metafile and tk drivers use a short for
communication of the cmap0 index.  Should be *plenty* for the given
application, i.e. fixing colors for lines, points, labels, and such.

     Since both the metafile & tk data stream formats have changed due to
the change from U_CHAR -> short for cmap0 index representation, the format
versions have been upgraded.  If you see something like this:

  $ x02c -dev tk
  Error: incapable of reading output of version 2005a.
  plr_init: Please obtain a newer copy of plserver.
  Command code: 1, byte count: 14
  plr_process1: Unrecognized command code 0
  ...

then you know it's using the wrong version of plserver (in which case
either you didn't install or your path is wrong).

     The second example program (multiple bindings available) contains
a demo of the expanded cmap0 capability.


3.1.4 The PlplotCanvas Widget for Gnome/GTK Applications

PlplotCanvas is a widget for use in Gnome/GTK applications, and
is contained in the libplplotgnome2d library.  A specialzed API is
provided, and bindings are included for the C and Python programming
languages.  Special example programs that demonstrate the use of
PlplotCanvas in Gnome/GTK applications are given for each language
binding.


3.2 Drivers

Some of the drivers have undergone important revisions in order to provide
unicode support.  Several now present TrueType or PostScript fonts by
default, which produces higher-quality output than in the past: see the
examples from the GD (png) driver on the PLplot Web site at
http://plplot.sourceforge.net/examples/index.html .


3.2.1 PostScript

The PostScript driver produces "publication quality" output files.  It
is unicode-enabled, and Type 1 PostScript fonts are used by default.
Although the Type 1 symbol fonts have a significant number of
mathemetical symbols available, some key special symbols (squares,
triangles) are missing.  Thus, by default, Hershey fonts are used to
produce the symbols generated by calls to "plpoin" and "plsym", while
PostScript fonts are used for calls to PLplot routines that plot text
strings (e.g., "plmtex").  If you prefer a pure Hershey font environment,
specify -drvopt text=0, and if you prefer a pure Postscript font
environment, specify -drvopt hrshsym=0.


3.2.2 psttf

An initial version of a new PostScript driver that has all the functionality
of the current postscript driver and also handles TrueType fonts.


3.2.2 GD (png, jpeg, gif)

The GD driver is used to produce png, jpeg, and gif files.  It is
unicode-enabled, and uses TrueType fonts by default.  The examples on
the PLplot Web site at
http://plplot.sourceforge.net/examples/index.html were produced using
this driver.


3.2.3 GCW (Gnome 2)

GCW is a new driver for Gnome 2 that displays plots in a tabbed window.
The driver is unicode-enabled, and uses TrueType fonts.  The GCW user
interface supports zooming, and saves to a variety of output file
formats (ps, psc, png, jpg, gif).  All of the relevant command-line
options for PLplot are supported.

     A specialized API, which allows interaction with the driver,
is provided in libplplotgnome2d.  Bindings are provided for the C and
Python programming languages.


3.2.4 AquaTerm (Mac OS X)

AquaTerm is a new driver for Mac OS X that provides PLplot output in
the AquaTerm graphics terminal program.  Aquaterm is a native Cocoa
graphics terminal program for Mac OS X that provides a familiar look and
feel to Mac users.  More details about AquaTerm and how to install it can
be found at http://aquaterm.sourceforge.net/. The driver is unicode-enabled
and uses default OS X fonts.


3.2.5 Tk

The plframe widget (and by extension, the Tk driver) now saves a plot using
the correct aspect ratio, as represented by the actual window size.  For
complicit output drivers only, e.g. png.


3.2.6 wxwidgets

This is a device driver that runs on the wxWidgets cross-platform GUI (see
http://www.wxwidgets.org/) that has been donated by Werner Smekal. The driver
is unicode-enabled. It currently provides a limited GUI but additional
capabilities are being developed.


4. Note on the Autotools that were used for this release

4.1 Autotools versions

autoconf (GNU Autoconf) 2.59
Written by David J. MacKenzie and Akim Demaille.

automake (GNU automake) 1.9.6
Written by Tom Tromey <tromey@redhat.com>.

ltmain.sh (GNU libtool) 1.5.22 (1.1220.2.365 2005/12/18 22:14:06)

4.2 cf/bootstrap.sh output

Running aclocal (GNU automake) 1.9.6... done
Running autoheader (GNU Autoconf) 2.59... done
Running libtoolize (GNU libtool) 1.5.22... done
Running automake (GNU automake) 1.9.6... done
Running autoconf (GNU Autoconf) 2.59... done
Regenerating libltdl/aclocal+configure... done



PLplot Development Release 5.5.4
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

This is a routine development release of PLplot, and represents the 
ongoing efforts of the community to improve the PLplot plotting 
package.  Development releases represent a "work in progress", and 
we expect to provide installments in the 5.5.x series every few weeks.  
The next full release will be 5.6.0.

     If you encounter a problem that is not already documented in the 
PROBLEMS file, then please send bug reports to PLplot developers via the 
mailing lists at http://sourceforge.net/mail/?group_id=2915 .

     Please see the license under which this software is distributed
(LGPL), and the disclaimer of all warrantees, given in the COPYING.LIB 
file.


INDEX

1. Build Instructions
2. Changes relative to PLplot 5.5.3
  2.1 API
    2.1.1 PlplotCanvas
    2.1.2 FCI
  2.2 Drivers
    2.2.1 GCW (Gnome 2)
    2.2.2 wxwidgets
3. Changes relative to PLplot 5.3.1
  3.1 API
    3.1.1 Deprecated functions
    3.1.2 Unicode
    3.1.3 Extended cmap0 support
    3.1.4 The PlplotCanvas Widget for Gnome/GTK Applications
  3.2 Drivers
    3.2.1 PostScript
    3.2.2 GD (png, jpeg, gif)
    3.2.3 GCW (Gnome 2)
    3.2.4 AquaTerm (Mac OS X)
    3.2.5 Tk
    3.2.6 wxwidgets


1. Build Instructions

For detailed instructions on how to build and install PLplot from this
tarball, please read the INSTALL file.  The basic procedure is to execute
the following commands:

  ./configure
  make
  make install

     There are a variety of configuration options, and these are explained 
in the INSTALL document, and below as required.  In particular, if you 
want to install the PLplot Programmer's Reference Manual, please use:

  ./configure --with-prebuiltdoc

Note that it is often helpful to use the --with-pkg-config option if your
system has the pkg-config program (typically *nix systems).


2. Changes relative to PLplot 5.5.3 (the previous development release)


2.1 API


2.1.1 PlplotCanvas

PlplotCanvas method wrappers for PLplot functions have dropped
the prefix "pl" from the function name.  For example, the
method plplot_canvas_plline is now plplot_canvas_line.


2.1.2 FCI

Backwards incompatible API change (with respect to 5.5.3, but not with
respect to 5.3.1 since this involves a new feature within the 5.5.x
development releases).  PL_FCI_MARK changed from 0x10000000 to 0x80000000.
This should only affect users who have been inserting absolute FCI (font
characterization integer) changes within their strings to change the font in
mid-string.

2.2 Drivers


2.2.1 GCW (Gnome 2)

Performance improvements have been implemented.

2.2.2 wxwidgets

Initial version of a device to run on the wxWidgets cross-platform GUI (see
http://www.wxwidgets.org/) has been donated by Werner Smekal.  Most examples
work out of the box, but some (e.g., a segfault for example 8) currently
have problems.  More development of this immature device driver is planned.

3. Changes Relative to PLplot 5.3.1 (the previous stable release)


3.1 API


3.1.1 Deprecated functions

plParseOpts, plHLS_RGB, and plRGB_HLS are now deprecated and will eventually
be removed from the API.  Use plparseopts, plhlsrgb, and plrgbhls instead
for all language interfaces.


3.1.2 Unicode

PLplot now supports unicode text.  The escape sequence for unicode
characters is

     #[nnn]

where nnn can be decimal or hexadecimal.  Escape sequences are also defined
to change fonts mid-string.

     There are known bugs for our unicode font implementation that are 
listed in a special section of the PROBLEMS file, but the current 
implementation is good enough so we turn on unicode support by default 
for the psc, ps, png, gif, jpeg, and gcw devices.  Although all examples 
look better with unicode fonts, the new PLplot unicode capabilities are 
especially demonstrated in examples x23 and x24.  (The latter example 
requires special fonts to be installed and at run time environment 
variables have to be set to access them;  see the self-documentation of 
the example 24 source code).  


3.1.3 Extended cmap0 support.

There have been many updates to cmap0 handling in the effort to wipe away 
all vestiges of the old 16 color limit.  The theoretical limit should now 
be 2^15 colors, since the metafile and tk drivers use a short for 
communication of the cmap0 index.  Should be *plenty* for the given 
application, i.e. fixing colors for lines, points, labels, and such.
 
     Since both the metafile & tk data stream formats have changed due to 
the change from U_CHAR -> short for cmap0 index representation, the format
versions have been upgraded.  If you see something like this:
 
  $ x02c -dev tk 
  Error: incapable of reading output of version 2005a. 
  plr_init: Please obtain a newer copy of plserver. 
  Command code: 1, byte count: 14 
  plr_process1: Unrecognized command code 0 
  ... 
 
then you know it's using the wrong version of plserver (in which case 
either you didn't install or your path is wrong). 

     The second example program (multiple bindings available) contains 
a demo of the expanded cmap0 capability.


3.1.4 The PlplotCanvas Widget for Gnome/GTK Applications

PlplotCanvas is a widget for use in Gnome/GTK applications, and
is contained in the libplplotgnome2d library.  A specialzed API is
provided, and bindings are included for the C and Python programming 
languages.  Special example programs that demonstrate the use of 
PlplotCanvas in Gnome/GTK applications are given for each language 
binding.


3.2 Drivers

Some of the drivers have undergone important revisions in order to provide
unicode support.  Several now present TrueType or PostScript fonts by
default, which produces higher-quality output than in the past: see the
examples from the GD (png) driver on the PLplot Web site at
http://plplot.sourceforge.net/examples/index.html .


3.2.1 PostScript

The PostScript driver produces "publication quality" output files.  It
is unicode-enabled, and Type 1 PostScript fonts are used by default.  
Although the Type 1 symbol fonts have a significant number of 
mathemetical symbols available, some key special symbols (squares,
triangles) are missing.  Thus, by default, Hershey fonts are used to 
produce the symbols generated by calls to "plpoin" and "plsym", while 
PostScript fonts are used for calls to PLplot routines that plot text 
strings (e.g., "plmtex").  If you prefer a pure Hershey font environment, 
specify -drvopt text=0, and if you prefer a pure Postscript font 
environment, specify -drvopt hrshsym=0.


3.2.2 GD (png, jpeg, gif)

The GD driver is used to produce png, jpeg, and gif files.  It is 
unicode-enabled, and uses TrueType fonts by default.  The examples on 
the PLplot Web site at
http://plplot.sourceforge.net/examples/index.html were produced using 
this driver.


3.2.3 GCW (Gnome 2)

GCW is a new driver for Gnome 2 that displays plots in a tabbed window.  
The driver is unicode-enabled, and uses TrueType fonts.  The GCW user 
interface supports zooming, and saves to a variety of output file 
formats (ps, psc, png, jpg, gif).  All of the relevant command-line 
options for PLplot are supported.

     A specialized API, which allows interaction with the driver,
is provided in libplplotgnome2d.  Bindings are provided for the C and 
Python programming languages.


3.2.4 AquaTerm (Mac OS X)

AquaTerm is a new driver for Mac OS X that provides PLplot output in 
the AquaTerm graphics terminal program.  Aquaterm is a native Cocoa 
graphics terminal program for Mac OS X that provides a familiar look and 
feel to Mac users.  More details about AquaTerm and how to install it can 
be found at http://aquaterm.sourceforge.net/.

     The driver is unicode-enabled and uses default OS X fonts.

     To install the AquaTerm driver, use the options "--disable-dyndrivers" 
and "--disable-f77" during the configure step of the install process.
 

3.2.5 Tk

The plframe widget (and by extension, the Tk driver) now saves a plot using 
the correct aspect ratio, as represented by the actual window size.  For 
complicit output drivers only, e.g. png.

3.2.6 wxwidgets

Initial version of a device to run on the wxWidgets cross-platform GUI (see
http://www.wxwidgets.org/) has been donated by Werner Smekal.  Most examples
work out of the box, but some (e.g., a segfault for example 8) currently
have problems.  More development of this immature device driver is planned.




PLplot Development Release 5.5.2
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

This is a routine development release of PLplot, and represents the 
ongoing efforts of the community to improve the PLplot plotting 
package.  Development releases represent a "work in progress", and 
we expect to provide installments in the 5.5.x series every few weeks.  
The next full release will be 5.6.0.

If you encounter a problem that is not already documented in the PROBLEMS
file then please send bug reports to PLplot developers via the mailing lists
at http://sourceforge.net/mail/?group_id=2915 .

Please see the license under which this software is distributed, and the
disclaimer of all warrantees, given in the COPYING.LIB file.


INDEX

1. Build Instructions
2. Changes Relative to PLplot 5.5.1
  2.1 API
  2.2 Drivers
3. Changes Relative to PLplot 5.3.1
  3.1 API
    3.1.1 Unicode
    3.1.2 Extended cmap0 support
  3.2 Drivers
    3.2.1 PostScript
    3.2.2 GD (png, jpeg, gif)
    3.2.3 GCW "Gnome Canvas Widget"
    3.2.4 AquaTerm (Mac OS X)
    3.2.5 Tk


1. Build Instructions

For detailed instructions on how to build and install PLplot from this
tarball, please read the INSTALL file.  The basic procedure is to execute
the following commands:

     ./configure
     make
     make install

There are a variety of configuration options, and these are explained in the
INSTALL document, and below as required.  In particular, if you want to
install the PLplot Programmer's Reference Manual (which is required for
documentation on any new feature since PLplot 5.3.1), you must use:

     ./configure --with-prebuiltdoc

Note that it is often helpful to use the --with-pkg-config option if your
system has the pkg-config program (typically *nix systems).


2. Changes Relative to our last development release, PLplot 5.5.1

Progress toward our next major release with documentation improvements and a
substantial number of minor tweaks and bug fixes.

2.1 API

No change.


2.2 Drivers

No change.


3. Changes Relative to our last stable release, PLplot 5.3.1


3.1 API


3.1.1 Unicode

PLplot now allows unicode text, and this is detailed in the PLplot
Programmers Reference Manual in the section on "Setting Character
Attributes".  The escape sequence for unicode characters is

     #[nnn]

where nnn can be decimal or hexadecimal.  Escape sequences are also defined
to change fonts mid-string.

There are known bugs for our unicode font implementation that are listed in
a special section of the PROBLEMS file, but the current implementation is
good enough so we turn on unicode support by default for the psc, ps, png,
gif, jpeg, and gcw devices. Although all examples look better with unicode
fonts, the new PLplot unicode capabilities are especially demonstrated in
examples x23 and x24.  (The latter example requires special fonts to be
installed and at run time environment variables have to be set to access
them, see the self-documentation of the example 24 source code).  


3.1.2 Extended cmap0 support.

There have been many updates to cmap0 handling in the effort to wipe away all
vestiges of the old 16 color limit.  The theoretical limit should now be 2^15
colors, since the metafile and tk drivers use a short for communication of the
cmap0 index.  Should be *plenty* for the given application, i.e. fixing colors
for lines, points, labels, and such.
 
Since both the metafile & tk data stream formats have changed due to the
change from U_CHAR -> short for cmap0 index representation, the format
versions have been upgraded.  If you see something like this:
 
$ x02c -dev tk 
Error: incapable of reading output of version 2005a. 
plr_init: Please obtain a newer copy of plserver. 
Command code: 1, byte count: 14 
plr_process1: Unrecognized command code 0 
... 
 
then you know it's using the wrong version of plserver (in which case either 
you didn't install or your path is wrong). 

The second example program (multiple bindings available) contains a demo of
the expanded cmap0 capability.


3.2 Drivers

Some of the drivers have undergone important revisions in order to provide
unicode support.  Several now present TrueType or PostScript fonts by
default, which produces higher-quality output than in the past: see the
examples from the GD (png) driver on the PLplot Web site at
http://plplot.sourceforge.net/examples/index.html .


3.2.1 PostScript

The PostScript driver is unicode-enabled, and Type 1 PostScript fonts are
used by default.  Although the Type 1 symbol fonts do have a significant
number of mathemetical symbols available some key special symbols (squares,
triangles) are missing so that by default Hershey fonts are used to produce
the symbols generated by calls to "plpoin" and "plsym" while PostScript
fonts are used for calls to PLplot routines that plot text strings (e.g.,
"plmtex").  If you prefer a pure Hershey font environment, specify -drvopt
text=0, and if you prefer a pure Postscript font environment, specify
-drvopt hrshsym=0.

Tranforms to the text (i.e., rotations, shears)
have been dramatically improved, and the PostScript driver now produces
"publication quality" output with the default PostScript fonts for text
and Hershey fonts for special symbols.


3.2.2 GD (png, jpeg, gif)

The GD driver is unicode-enabled, and uses TrueType fonts by default.  The
examples on the PLplot Web site at
http://plplot.sourceforge.net/examples/index.html were produced using this
driver.


3.2.3 GCW "Gnome Canvas Widget"

The GCW "Gnome Canvas Widget" is a new driver that provides PLplot output in
a tabbed Gnome window.  It can alternatively be used to drive a special
widget called the PlplotCanvas that can be embedded in Gnome applications.
The driver, associated widget, and specialized API are fully documented in
the PLplot Programmer's Reference Manual in the sections titled "The GCW
Driver" and "Embedding Plots in Gnome/GTK Applications", respectively.

The GCW driver is unicode-enabled, and uses TrueType fonts by default.

Special examples that demonstrate the use of the PlplotCanvas are provided
for both the C and Python programming languages.

To install the GCW driver, use the "--enable-gcw" option during the
configure step of the install process.

For more information on GTK, see http://www.gtk.org/ .


3.2.4 AquaTerm (Mac OS X)

AquaTerm is a new driver that provides PLplot output in the AquaTerm
graphics terminal program. Aquaterm is a native Cocoa graphics terminal 
program for Mac OS X that provides a familiar look and feel to Mac users. 
More details about AquaTerm and how to install it can be found at 
http://aquaterm.sourceforge.net/.

The driver is unicode-enabled, however it currently only supports the 
default OS X fonts which are not TrueType.

To install the AquaTerm driver, use the options "--disable-dyndrivers" and
"--disable-f77" during the configure step of the install process.
 

3.2.5 Tk

The plframe widget (and by extension, the Tk driver) now saves a plot using the
correct aspect ratio, as represented by the actual window size.  For complicit
output drivers only, e.g. png.




PLplot Development Release 5.5.1
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

This is a routine development release of PLplot, and represents the 
ongoing efforts of the community to improve the PLplot plotting 
package.  Development releases represent a "work in progress", and 
we expect to provide installments in the 5.5.x series every few weeks.  
The next full release will be 5.6.0.

Feedback on this development release can be communicated to PLplot
developers via the mailing lists at 
http://sourceforge.net/mail/?group_id=2915 .

Please see the license under which this software is distributed, and the
disclaimer of all warrantees, given in the COPYING.LIB file.


INDEX

1. Build Instructions
  1.1 Tcl
2. Changes
  2.1 API
  2.2 Drivers


1. Build Instructions

For detailed instructions on how to build and install PLplot from this
tarball, please read the INSTALL file.  The basic procedure is to execute
the following commands:

     ./configure
     make
     make install

There are a variety of configuration options, and these are explained in the
INSTALL document, and below as required.  In particular, if you want to
install the PLplot Programmer's Reference Manual (which is required for
documentation on any new feature since PLplot 5.3.1), you must use:

     ./configure --with-prebuiltdoc

Note that it is often helpful to use the --with-pkg-config option if your
system has the pkg-config program (typically *nix).


1.1 Tcl

Due to unresolved problems in the build process, tcl has been temporarily
disabled for this release.

If you must have tcl, here are the instrutions.  DO NOT ATTEMPT THIS
UNLESS YOU ARE SURE YOU KNOW WHAT YOU ARE DOING.

  1) Move all plplot files in /usr/lib and /usr/local/lib into a
     temporary directory.

  2) Use the --enable-tcl and --enable-itcl options during configure.


2. Changes


2.1 API


2.2 Drivers




PLplot Development Release 5.5.0
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

This is a routine development release of PLplot, and represents the ongoing efforts of the community to improve the PLplot plotting package.  The next full release will be 5.6.0.


INDEX

1. Build Instructions
2. Changes
  2.1 API
    2.1.1 Unicode
  2.2 Drivers
    2.2.1 Postscript
    2.2.2 GD (png, jpeg, gif)
    2.2.3 GCW "Gnome Canvas Widget"


1. Build Instructions

For detailed instructions on how to build and install PLplot from this tarball, please read the INSTALL file.  The basic procedure is to execute the following commands:

     ./configure
     make
     make install

There are a variety of configuration options, and these are explained in the INSTALL document, and below as required.  In particular, if you want to build and install the PLplot Programmer's Reference Manual (which is required for documentation on any new feature since PLplot 5.3.1), you must use:

     ./configure --enable-builddoc

Detailed instructions on building the documentation, including the packages that you will need for a successful build, are provided in this tarball under doc/docbook/README.developers.


2. Changes


2.1 API


2.1.1 Unicode

PLplot now allows unicode text, and this is detailed in the PLplot Programmers Reference Manual in the section on "Setting Character Attributes".  The escape sequence for unicode characters is

     #[nnn]

where nnn can be decimal or hexdecimal.  Escape sequences are also defined to change fonts mid-string.

The new unicode capabilities are demonstrated in example x23.


2.2 Drivers

Some of the drivers have undergone important revisions in order to provide unicode support.  Several now present truetype or postscript fonts by default, which produces higher-quality output than in the past: see the examples from the GD (png) driver on the PLplot Web site at http://plplot.sourceforge.net/examples/index.html.


2.2.1 PostScript

The PostScript driver is unicode-enabled, and Type 1 PostScript fonts are used by default.  Because many symbols are missing from the Type 1 PostScript fonts, Hershey fonts are used for calls to "plpoin".  Tranforms to the text (i.e., rotations, shears) have been dramatically improved, and the PostScript driver now produces "publication quality" output.


2.2.2 GD (png, jpeg, gif)

The GD driver is unicode-enabled, and uses truetype fonts by default.  The examples on the PLplot Web site at http://plplot.sourceforge.net/examples/index.html were produced using this driver.


2.2.3 GCW "Gnome Canvas Widget"

The GCW "Gnome Canvas Widget" is a new driver that provides PLplot output in a tabbed Gnome window.  It can alternatively be used to drive a special widget called the PlplotCanvas that can be embedded in Gnome applications.  The driver, associated widget, and specialized API are fully documented in the PLplot Programmer's Reference Manual in the sections titled "The GCW Driver" and "Embedding Plots in Gnome/GTK Applications", respectively.

The GCW driver is unicode-enabled, and uses truetype fonts by default.

Special examples that demonstrate the use of the PlplotCanvas are provided for both the C and Python programming languages.

To install the GCW driver, use the "--enable-gcw" option during the configure step of the install process.