Looking for the latest version? Download plplot-5.11.1.tar.gz (15.4 MB)
Home / plplot / 5.9.11 Source
Name Modified Size Downloads / Week Status
Parent folder
Totals: 3 Items   14.9 MB 7
README.release 2013-12-22 294.3 kB 11 weekly downloads
plplot-5.9.11.tar.gz 2013-12-22 14.6 MB 55 weekly downloads
plplot-5.9.11.tar.gz.asc 2013-12-22 490 Bytes 11 weekly downloads
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 comm
Source: README.release, updated 2013-12-22