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

SourceForge Headquarters 1320 Columbia Street Suite 310 San Diego, CA 92101 +1 (858) 422-6466

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

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

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

--- trunk/OLD-README.release	2013-09-30 23:24:39 UTC (rev 12560)
+++ trunk/OLD-README.release	2013-10-01 06:22:48 UTC (rev 12561)
@@ -1,3 +1,1648 @@
+PLplot Release 5.9.10
+~~~~~~~~~~~~~~~~~~~~
+This is a development release of PLplot. It represents the ongoing efforts
+of the community to improve the PLplot plotting package. Development
+releases in the 5.9.x series will be available every few months. The next
+stable release will be 5.10.0.
+
+     If you encounter a problem that is not already documented in the
+PROBLEMS file or on our bug tracker, then please send bug reports to PLplot
+developers via the mailing lists at
+http://sourceforge.net/mail/?group_id=2915 (preferred) or on our bug tracker
+at http://sourceforge.net/tracker/?group_id=2915&atid=102915.
+
+     Please see the license under which this software is distributed
+(LGPL), and the disclaimer of all warranties, given in the COPYING.LIB
+file.
+
+INDEX
+
+OFFICIAL NOTICES FOR USERS
+
+CHANGES
+
+-1. Important changes we should have mentioned in previous release announcements.
+
+-1.1 Add full bindings and examples for the D language.
+
+0. Tests made for release 5.9.10
+
+1. Changes relative to PLplot 5.9.9 (the previous development release)
+
+1.1 The format for map data used by plmap has changed
+1.2 Python support for Numeric has been dropped
+1.3 Backwards-incompatible API change to non-integer line widths
+1.4 Improvements to the build system for the Cygwin case
+1.5 The plcolorbar API has been finalized
+1.6 Documentation of the new legend and color bar capabilities of PLplot
+1.7 The D bindings and examples have been converted from the
+old version of D (D1) to the new version of D (D2)
+1.8 The DocBook documentation for PLplot is now generated using modern
+XML/XSL backend tools for DocBook
+1.9 Implement experimental build_projects sub-project
+1.10 Implement extremely simple "00" example
+1.11 Convert to using the Allura form of SourceForge software
+1.12 Use NON_TRANSITIVE linking by default for the shared libraries case for
+all non-windows systems
+1.13 Update f95 examples to take larger advantage of Fortran 95 capabilities
+1.14 Substantial additions to the doxygen documentation
+
+2. Changes relative to PLplot 5.8.0 (the previous stable release)
+
+2.1 All autotools-related files have now been removed
+2.2 Build system bug fixes
+2.3 Build system improvements
+2.4 Implement build-system infrastructure for installed Ada bindings and
+examples
+2.5 Code cleanup
+2.6 Date / time labels for axes
+2.7 Alpha value support
+2.8 New PLplot functions
+2.9 External libLASi library improvements affecting our psttf device
+2.10 Improvements to the cairo driver family
+2.11 wxWidgets driver improvements
+2.12 pdf driver improvements
+2.13 svg driver improvements
+2.14 Ada language support
+2.15 OCaml language support
+2.16 Perl/PDL language support
+2.17 Update to various language bindings
+2.18 Update to various examples
+2.19 Extension of our test framework
+2.20 Rename test subdirectory to plplot_test
+2.21 Website support files updated
+2.22 Internal changes to function visibility
+2.23 Dynamic driver support in Windows
+2.24 Documentation updates
+2.25 libnistcd (a.k.a. libcd) now built internally for -dev cgm
+2.26 get-drv-info now changed to test-drv-info
+2.27 Text clipping now enabled by default for the cairo devices
+2.28 A powerful qt device driver has been implemented
+2.29 The PLplot API is now accessible from Qt GUI applications
+2.30 NaN / Inf support for some PLplot functions
+2.31 Various bug fixes
+2.32 Cairo driver improvements
+2.33 PyQt changes
+2.34 Color Palettes
+2.35 Re-implementation of a "soft landing" when a bad/missing compiler is
+detected
+2.36 Make PLplot aware of LC_NUMERIC locale
+2.37 Linear gradients have been implemented
+2.38 Cairo Windows driver implemented
+2.39 Custom axis labelling implemented
+2.40 Universal coordinate transform implemented
+2.41 Support for arbitrary storage of 2D user data
+2.42 Font improvements
+2.42 Alpha value support for plotting in memory.
+2.43 Add a Qt device for in memory plotting.
+2.44 Add discrete legend capability.
+2.45 Add full bindings and examples for the D language.
+2.46 The plstring and plstring3 functions have been added
+2.47 The pllegend API has been finalized
+2.48 Octave bindings now implemented with swig
+2.49 Documentation redone for our swig-generated Python and Octave bindings
+2.50 Support large polygons
+2.51 Complete set of PLplot parameters now available for Fortran
+2.52 The plarc function has been added
+2.53 The format for map data used by plmap has changed
+2.54 Python support for Numeric has been dropped
+2.55 Backwards-incompatible API change to non-integer line widths
+2.56 Improvements to the build system for the Cygwin case
+2.57 The plcolorbar API has been finalized
+2.58 Documentation of the new legend and color bar capabilities of PLplot
+2.59 The D bindings and examples have been converted from the
+old version of D (D1) to the new version of D (D2)
+2.60 The DocBook documentation for PLplot is now generated using modern
+XML/XSL backend tools for DocBook
+2.61 Implement experimental build_projects sub-project
+2.62 Implement extremely simple "00" example
+2.63 Convert to using the Allura form of SourceForge software
+2.64 Use NON_TRANSITIVE linking by default for the shared libraries case for
+all non-windows systems
+2.65 Update f95 examples to take larger advantage of Fortran 95 capabilities
+2.66 Substantial additions to the doxygen documentation
+
+
+OFFICIAL NOTICES FOR USERS
+
+(5.9.10) The minimum version of CMake has been bumped to 2.8.9.  This
+change allows our build system to take advantage of CMake features
+introduced in later versions of CMake.  Even more importantly it also
+updates user's builds to the CMake policy conventions (important
+backwards-incompatible changes in CMake behaviour introduced in later
+versions of CMake) to the default CMake policy used for 2.8.9.
+
+(5.9.10) The long deprecated support for the python Numeric package has been
+dropped. This is no longer supported and is superseded by numpy. Support for
+numpy has been the default in PLplot for a number of years so most users
+should notice no difference.
+
+(5.9.10) The current format for maps used by plmap has been deprecated in
+favour of using shapefiles (a standard format widely used for GIS and with
+suitable free data sources available). This requires the shapelib library
+to be installed. If this library is not installed then by default no map
+support will be available. Support for the old binary format is still
+available by setting the cmake variable PL_DEPRECATED, however this
+support will be removed in a future release of PLplot.
+
+(5.9.10) Those who use the Python version of plgriddata will have to
+change their use of this function for this release as follows (see
+examples/xw21.py)
+
+# old version (which overwrites preexisting zg in place):
+zg = reshape(zeros(xp*yp),(xp,yp))
+plgriddata(x, y, z, xg, yg, zg, alg, opt[alg-1])
+
+# new version (which uses a properly returned newly created NumPy array
+# as per the normal Python expectations):
+
+zg = plgriddata(x, y, z, xg, yg, alg, opt[alg-1])
+
+(5.9.10) Significant efforts have been made to ensure the PLplot code
+is standards compliant and free from warnings. Compliance has been
+tested using the gcc compiler suite -std, -pedantic and -W  flags. The
+language standards adopted are
+C: ISO C99 with POSIX.1-2001 base specification (required for a number
+of C library calls)
+C++: ISO C++ 1998 standard plus amendments
+F95: Fortran 95 standard
+
+Specifically, the following gcc / g++ / gfortran flags were used
+
+CFLAGS='-O3 -std=c99 -pedantic -D_POSIX_C_SOURCE=200112L -Wall  \
+-Wextra -Wmissing-prototypes -Wstrict-prototypes -Wnested-externs \
+-Wconversion -Wshadow -Wcast-qual -Wcast-align -Wwrite-strings'
+
+CXXFLAGS='-O3 -fvisibility=hidden -std=c++98 -pedantic -Wall -Wextra '
+
+FFLAGS='-std=f95 -O3 -fall-intrinsics -fvisibility=hidden -pedantic \
+-Wall -Wextra '
+
+Note that the code is not yet quite standards compliant or warning free,
+but this is our aim. We know that a number of common compilers do not
+support these standards "out of the box", so we will continue to develop
+and support workarounds to ensure that PLplot remains easily built on
+a variety of platforms and compilers. Standards compliance should make
+it easier to port to new systems in the future. Using aggressive
+warnings flags will help to detect and eliminate errors or problems in
+the libraries.
+
+The gfortran -fall-intrinsics flag is required for a couple of
+non-standard intrinsics which are used in the code. In the future
+adopting the fortran 2003 or 2008 standard should allow this to be
+removed.
+
+Note: currently this code cleanup does not apply to code generated by
+swig (octave, python, java, lua bindings) which gives a large number of
+code warnings.
+
+(5.9.10) For some years now we have had both FORTRAN 77 and Fortran 95
+bindings, but to the best of our knowledge, there are no longer
+any maintained FORTRAN 77 compilers left that do not also support
+Fortran 95. (g77 for instance has not been maintained for several
+years now. Its successor gfortran supports Fortran 95 and later standards
+as well all g77's legacy features).
+
+An important consequence is that we can not test the implementation for
+compliance to the FORTRAN 77 standard.
+Furthermore, we would prefer to concentrate all our Fortran
+development effort on our f95 bindings and strongly encourage all our
+Fortran users to use those bindings if they haven't switched from the
+f77 version already. Therefore, as of this release we are deprecating
+the f77 bindings and examples and plan no further support for them.
+We signal this deprecation by disabling f77 by default (although our
+users can still get access to these unsupported bindings and examples
+for now by specifying the -DENABLE_f77=ON cmake option).
+
+We plan to completely remove the f77 bindings and examples
+two releases after this one.
+
+(5.9.10) We have found that some distributions of the Windows
+MinGW/gfortran compiler (i.e., MinGW/gfortran 4.6.1 and 4.6.2 from
+http://www.equation.com) may cause a link error due to duplicate
+symbols like __gfortran_setarg_. These errors can be suppressed by
+adding the flag -Wl,--allow-multiple-define. It is very likely that
+this is a bug in these distributions.
+
+As building the libraries and the examples succeeds without any problem
+if you use most other distributions of Windows MinGW/gfortran,
+we have decided not to include this flag in our build system.
+
+Distributions that are known to work:
+- MinGW/gfortran-4.5 from http://www.equation.com,
+- MinGW/gfortran-4.5.2-1 that is installed using the latest
+  mingw-get-inst-20110802 automatic installer available at
+  http://sourceforge.net/projects/mingw/files/Installer/mingw-get-inst
+- MinGW/gfortran-4.6.2 from tdm-gcc.tdragon.net
+
+(Therefore it is not the 4.5.x versus 4.6.x version of MinGW/gfortran
+as such that causes this problem.)
+
+(5.9.9) This is a quick release to deal with two broken build issues
+that were recently discovered for our Windows platform.  Windows users should
+avoid 5.9.8 because of these problems for that release, and instead use
+5.9.9 which has been heavily tested on a number of platforms including
+Windows, see "Tests made for release 5.9.9" below.
+
+(5.9.8) For unicode-aware devices we now follow what is done for the
+Hershey font case for epsilon, theta, and phi.  This means the #ge,
+#gh, and #gf escapes now give users the Greek lunate epsilon, the
+ordinary Greek lower case theta, and the Greek symbol phi for Unicode
+fonts just like has occurred since the dawn of PLplot history for the
+Hershey font case.  Previously these legacy escapes were assigned to
+ordinary Greek lower-case epsilon, the Greek symbol theta (= script
+theta), and the ordinary Greek lower case phi for unicode fonts
+inconsistently with what occurred for Hershey fonts.  This change gets
+rid of this inconsistency, that is the #g escapes should give the best
+unicode approximation to the Hershey glyph result that is possible for
+unicode-aware devices.
+
+In general we encourage users of unicode-aware devices who might
+dislike the Greek glyph Hershey-lookalike choices they get with the
+legacy #g escapes to use instead either PLplot unicode escapes (e.g.,
+"#[0x03b5]" for ordinary Greek lower-case epsilon, see page 3 of
+example 23) or better yet, UTF-8 strings (e.g., "ε") to specify
+exactly what unicode glyph they want.
+
+(5.9.8) The full set of PLplot constants have been made available to
+our Fortran 95 users as part of the plplot module.  This means those
+users will have to remove any parameter statements where they have
+previously defined the PLplot constants (whose names typically start
+with "PL_" for themselves.  For a complete list of the affected
+constants, see the #defines in swig-support/plplotcapi.i which are
+used internally to help generate the plplot module.  See also Index
+item 2.51 below.
+
+(5.9.8) There has been widespread const modifier changes in the API
+for libplplotd and libplplotcxxd.  Those backwards-incompatible API
+changes are indicated in the usual way by a soversion bump in those
+two libraries which will force all apps and libraries that depend on
+those two libraries to be rebuilt.
+
+Specifically, we have changed the following arguments in the C library
+(libplplotd) case
+
+type * name1 ==> const type * name1
+type * name2 ==> const type ** name2
+
+and the following arguments in the C++ library (libplplotcxxd) case
+
+type * name1 ==> const type * name1
+type * name1 ==> const type * const * name2
+
+where name1 is the name of a singly dimensioned array whose values are
+not changed internally by the PLplot libraries and name2 is the name
+of a doubly dimensioned array whose values are not changed internally
+by the PLplot libraries.
+
+The general documentation and safety justification for such const
+modifier changes to our API is given in
+http://www.cprogramming.com/tutorial/const_correctness.html.
+Essentially, the above const modifier changes constitute our guarantee
+that the associated arrays are not changed internally by the PLplot
+libraries.
+
+Although it is necessary to rebuild all apps and libraries that depend
+on libplplotd and/or libplplotcxxd, that rebuild should be possible
+with unchanged source code without build errors in all cases.  For C
+apps and libraries (depending on libplplotd) there will be additional
+build warnings due to a limitation in the C standard discussed at
+http://c-faq.com/ansi/constmismatch.html unless all doubly dimensioned
+arrays (but not singly dimensioned) are explicitly cast to (const type
+**).  However, such source code changes will not be necessary to avoid
+warning messages for the C++ (libplplotcxxd) change because of the
+double use of const in the above "const type * const * name2" change.
+
+(5.9.8) The plarc API has changed in release 5.9.8.  The plarc API now
+has a rotation parameter which will eventually allow for rotated arcs.
+PLplot does not currently support rotated arcs, but the plarc function
+signature has been modified to avoid changing the API when this
+functionality is added.
+
+(5.9.6) We have retired the pbm driver containing the pbm (actually
+portable pixmap) file device. This device is quite primitive and
+poorly maintained. It ignores unicode fonts (i.e., uses the Hershey
+font fallback), falls back to ugly software fills, doesn't support
+alpha transparency, etc.  It also has a serious run-time issue with
+example 2 (double free detected by glibc) which probably indicates
+some fundamental issue with the 100 colors in cmap0 for that
+example. For those who really need portable pixmap results, we suggest
+using the ImageMagick convert programme, e.g., "convert
+examples/x24c01.pngqt test.ppm" or "convert examples/x24c01.pngcairo
+test.ppm" to produce good-looking portable pixmap results from our
+best png device results.
+
+(5.9.6) We have retired the linuxvga driver containing the linuxvga
+interactive device.  This device is quite primitive, difficult to
+test, and poorly maintained. It ignores unicode fonts (i.e., uses the
+Hershey font fallback), falls back to ugly software fills, doesn't
+support alpha transparency, etc.  It is Linux only, can only be run as
+root, and svgalib (the library used by linuxsvga) is not supported by
+some mainstream (e.g., Intel) chipsets.  All of these characteristics
+make it difficult to even test this device much less use it for
+anything serious.  Finally, it has had a well-known issue for years
+(incorrect colors) which has never been fixed indicating nobody is
+interested in maintaining this device.
+
+(5.9.6) We have retired our platform support of djgpp that used to
+reside in sys/dos/djgpp.  The developer (Andrew Roach) who used to
+maintain those support files for djgpp feels that the djgpp platform
+is no longer actively developed, and he no longer uses djgpp himself.
+
+(5.9.6) We have changed plpoin results for ascii codes 92, 94, and 95
+from centred dot, degree symbol, and centred dot glyphs to the correct
+backslash, caret, and underscore glyphs that are associated with those
+ascii indices.  This change is consistent with the documentation of
+plpoin and solves a long-standing issue with backslash, caret, and
+underscore ascii characters in character strings used for example by
+pl[mp]tex.  Those who need access to a centred dot with plpoin should
+use index 1.  The degree symbol is no longer accessible with plpoin,
+but it is available in ordinary text input to PLplot as Hershey escape
+"#(718)", where 718 is the Hershey index of the degree symbol, unicode
+escape "#[0x00B0]" where 0x00B0 is the unicode index for the degree
+symbol or direct UTF8 unicode string "°".
+
+(5.9.6) We have retired the gcw device driver and the related gnome2
+and pygcw bindings since these are unmaintained and there are good
+replacements.  These components of PLplot were deprecated as of
+release 5.9.3.  A good replacement for the gcw device is either the
+xcairo or qtwidget device.  A good replacement for the gnome2 bindings
+is the externally supplied XDrawable or Cairo context associated with
+the xcairo device and the extcairo device (see
+examples/c/README.cairo).  A good replacement for pygcw is our new
+pyqt4 bindings for PLplot.
+
+(5.9.6) We have deprecated support for the python Numeric array
+extensions. Numeric is no longer maintained and users of Numeric are
+advised to migrate to numpy. Numpy has been the standard for PLplot
+for some time. If numpy is not present PLplot will now disable python
+by default. If you still require Numeric support in the short term
+then set USE_NUMERIC to ON in cmake. The PLplot support for Numeric
+will be dropped in a future release.
+
+(5.9.5) We have removed pyqt3 access to PLplot and replaced it by
+pyqt4 access to PLplot (see details below).
+
+(5.9.5) The only method of specifying a non-default compiler (and
+associated compiler options) that we support is the environment
+variable approach, e.g.,
+
+export CC='gcc -g -fvisibility=hidden'
+export CXX='g++ -g -fvisibility=hidden'
+export FC='gfortran -g -fvisibility=hidden'
+
+All other CMake methods of specifying a non-default compiler and
+associated compiler options will not be supported until CMake bug 9220
+is fixed, see discussion below of the soft-landing re-implementation
+for details.
+
+(5.9.5) We have retired the hpgl driver (containing the hp7470,
+hp7580, and lj_hpgl devices), the impress driver (containing the imp
+device), the ljii driver (containing the ljii and ljiip devices), and
+the tek driver (containing the conex, mskermit, tek4107, tek4107f,
+tek4010, tek4010f, versaterm, vlt, and xterm devices).  Retirement
+means we have removed the build options which would allow these
+devices to build and install.  Recent tests have shown a number of
+run-time issues (hpgl, impress, and ljii) or build-time issues (tek)
+with these devices, and as far as we know there is no more user
+interest in them. Therefore, we have decided to retire these devices
+rather than fix them.
+
+(5.9.4) We have deprecated the pbm device driver (containing the pbm
+device) because glibc detects a catastrophic double free.
+
+(5.9.3) Our build system requires CMake version 2.6.0 or higher.
+
+(5.9.3) We have deprecated the gcw device driver and the related
+gnome2 and pygcw bindings since these are essentially unmaintained.
+For example, the gcw device and associated bindings still depends on
+the plfreetype approach for accessing unicode fonts which has known
+issues (inconsistent text offsets, inconvenient font setting
+capabilities, and incorrect rendering of CTL languages).  To avoid
+these issues we advise using the xcairo device and the externally
+supplied XDrawable or Cairo context associated with the xcairo device
+and the extcairo device (see examples/c/README.cairo) instead. If you
+still absolutely must use -dev gcw or the related gnome2 or pygcw
+bindings despite the known problems, then they can still be accessed
+by setting PLD_gcw, ENABLE_gnome2, and/or ENABLE_pygcw to ON.
+
+(5.9.3) We have deprecated the gd device driver which implements the
+png, jpeg, and gif devices.  This device driver is essentially
+unmaintained. For example, it still depends on the plfreetype approach
+for accessing unicode fonts which has known issues (inconsistent text
+offsets, inconvenient font setting capabilities, and incorrect
+rendering of CTL languages).  To avoid these issues for PNG format, we
+advise using the pngcairo or pngqt devices.  To avoid these issues for
+the JPEG format, we advise using the jpgqt device.  PNG is normally
+considered a better raster format than GIF, but if you absolutely
+require GIF format, we advise using the pngcairo or pngqt devices and
+then downgrading the results to the GIF format using the ImageMagick
+"convert" application.  For those platforms where libgd (the
+dependency of the gd device driver) is accessible while the required
+dependencies of the cairo and/or qt devices are not accessible, you
+can still use these deprecated devices by setting PLD_png, PLD_jpeg,
+or PLD_gif to ON.
+
+(5.9.3) We have re-enabled the tk, itk, and itcl components of PLplot
+by default that were disabled by default as of release 5.9.1 due to
+segfaults.  The cause of the segfaults was a bug (now fixed) in how
+pthread support was implemented for the Tk-related components of
+PLplot.
+
+(5.9.2) We have set HAVE_PTHREAD (now called PL_HAVE_PTHREAD as of
+release 5.9.8) to ON by default for all platforms other than Darwin.
+Darwin will follow later once it appears the Apple version of X
+supports it.
+
+(5.9.1) We have removed our previously deprecated autotools-based
+build system.  Instead, use the CMake-based build system following the
+directions in the INSTALL file.
+
+(5.9.1) We no longer support Octave-2.1.73 which has a variety of
+run-time issues in our tests of the Octave examples on different
+platforms. In contrast our tests show we get good run-time results
+with all our Octave examples for Octave-3.0.1. Also, that is the
+recommended stable version of Octave at
+http://www.gnu.org/software/octave/download.html so that is the only
+version of Octave we support at this time.
+
+(5.9.1) We have decided for consistency sake to change the PLplot
+stream variables plsc->vpwxmi, plsc->vpwxma, plsc->vpwymi, and
+plsc->vpwyma and the results returned by plgvpw to reflect the exact
+window limit values input by users using plwind. Previously to this
+change, the stream variables and the values returned by plgvpw
+reflected the internal slightly expanded range of window limits used
+by PLplot so that the user's specified limits would be on the graph.
+Two users noted this slight difference, and we agree with them it
+should not be there. Note that internally, PLplot still uses the
+expanded ranges so most users results will be identical.  However, you
+may notice some small changes to your plot results if you use these
+stream variables directly (only possible in C/C++) or use plgvpw.
+
+CHANGES
+
+0. Tests made for release 5.9.10
+
+Comprehensive testing that showed no non-zero return codes or other
+obvious run-time issues such as segfaults was done for the Debian
+Wheezy platform.  These tests were done with the
+scripts/comprehensive_test.sh which does 21 major tests.  Those tests
+consist of seven tests (ctest, and "make test_noninteractive" and make
+"test_interactive" results for the build tree, and "make
+test_noninteractive" and make "test_interactive" results for both the
+traditional and CMake-based build systems for the installed examples
+tree) for each of our three major configurations (shared
+libraries/dynamic devices, shared libraries/non-dynamic devices,
+static libraries/non-dynamic devices).
+
+More limited testing that showed no non-zero return codes or other
+obvious run-time issues such as segfaults was done on a large number
+of different platforms including the following:
+
+Fedora with "Unix Makefiles" generator
+Ubuntu with "Unix Makefiles" generator
+Debian unstable with "Unix Makefiles" generator
+Debian wheezy with "Ninja" generator
+Wine version of Windows with "MSYS Makefiles" generator
+Wine version of Windows with "MinGW Makefiles" generator
+Wine version of Windows with "NMake Makefiles JOM" generator
+Microsoft version of Windows with Cygwin and with "Unix Makefiles" generator
+Microsoft version of Windows with "MinGW Makefiles" generator
+Microsoft version of Windows with "MSYS Makefiles" generator
+Microsoft version of Windows with "NMake Makefiles" generator
+
+1. Changes relative to PLplot 5.9.9 (the previous development release)
+
+N.B. This release includes many code cleanups and fixes relative to
+5.9.9 that are not mentioned in the list below.
+
+1.1 The format for map data used by plmap has changed
+
+The format for map data used by plmap is now the shapefile format.
+This is a widely used standard format and there are many sources of data
+in this format. This replaces the custom binary format that PLplot used
+to use. The support for reading shapefiles is provided by the shapelib
+library, which is a new dependency for PLplot. If users do not have this
+installed then, by default, they will not get any map capabilities with
+PLplot. Support for the old format can still be enabled by setting the
+PL_DEPRECATED cmake variable, but this support will be removed in a
+subsequent PLplot release.
+
+1.2 Python support for Numeric has been dropped
+
+Support for the python Numeric package has been dropped. This has been
+deprecated since 5.9.6. Numeric is no longer supported and is superseded
+by numpy. Support for numpy has been the default in plplot for a number
+of years so most users should notice no difference.
+
+1.3 Backwards-incompatible API change to non-integer line widths
+
+All functions which take line width arguments (plwidth, plshade*,
+pllegend) now use PLFLT values for the line width. This allows device
+drivers which are based on modern graphics libraries such as Qt4 and
+pango/cairo to make full use (e.g., extremely fine line widths) of the
+floating-point line width capabilities of those libraries.  The
+replacement of plwid by plwidth, and the change in argument lists for
+plshade* and pllegend constitute a backwards incompatible API change
+from previous releases and the soname of libraries has been bumped
+accordingly (which forces users to recompile PLplot).
+
+1.4 Improvements to the build system for the Cygwin case
+
+The Cygwin platform provides a full-featured Unix environment on
+Windows.  CMake has recently been changed (at the request of Cygwin
+developers) to emphasize the Unix aspects of the Cygwin platform and
+deemphasize the Windows aspects of that platform.  It was argued this
+change would tend to make CMake builds of software much more reliable
+on Cygwin, and after some small but important changes to our
+CMake-based build system to adjust for these recent CMake changes for
+Cygwin, we have indeed confirmed that prediction for the PLplot case.
+There are still some Cygwin platform issues left which are being
+discussed on our Wiki at http://www.miscdebris.net/plplot_wiki/index.php?title=Setup_cygwin,
+but some fundamental breakthroughs have also been made for the Cygwin case
+that should interest all our Windows users.  For example, for the
+first time ever we have been able to build our cairo and qt device
+drivers on the Cygwin platform giving our Windows users convenient
+access to the many high-quality PLplot devices that are available with
+these two different device drivers.
+
+1.5 The plcolorbar API has been finalized
+
+The function plcolorbar allows users to create a color bar (an
+annotated subplot representing a continuous range of colors within the
+main plot and typically identifying certain colors with certain
+numerical values using an axis).  The plcolorbar capabilities are
+documented in our DocBook (and doxygen) documentation and demonstrated
+in standard examples 16 and 33.
+
+N.B. The previous two releases (5.9.8 and 5.9.9) contained
+unadvertised experimental versions of plcolorbar.  Any PLplot user who
+found and tried those capabilities will have to reprogramme their
+plcolorbar calls to be compatible with the argument list of the latest
+version.
+
+1.6 Documentation of the new legend and color bar capabilities of PLplot
+
+The pllegend and plcolorbar API has been documented in both doxygen
+and DocBook forms.  In addition, the "advanced use" chapter of the
+DocBook form of documentation now contains a section giving an
+overview of pllegend and plcolorbar.
+
+N.B. Although we feel the pllegend and plcolorbar API has now been
+finalized with regard to the PLplot core developers ow...
 
[truncated message content]

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

Cross-platform, scientific graphics plotting library

plplot-cvs