gnuplot-beta

07-May-2014 Update on version 5 progress

[Ethan A M. <sf...@us...>]

I think that we are close to putting out a first release candidate
for version 5.   

Here is a summary of progress on the big items.
IMHO all are in an acceptable state for a release candidate.

Bold/Italic markup in enhanced text mode
==============================
- some terminal-specific bugs reported and fixed
- not yet implemented for x11, aqua, ...
- Try it out: "test" command,  bolditalic.dem
	http://gnuplot.sourceforge.net/demo_svg_5.0/enhanced_utf8.html

Dash patterns under user control
========================
- generic fallback to version 4 "linetype" dash patterns seems to work
- custom dash patterns not yet implemented for latex terminals, win, ...
- very little testing, so there are probably bugs
- Try it out: dashtypes.dem
	http://gnuplot.sourceforge.net/demo_canvas_5.0/dashtypes.html

Default line color sequence
====================
- Three sequences are built in as "set colors {default|classic|podo}"
- As in version 4.6 this can be further customized via "set linetype"
- Should there be a built-in "monochrome" sequence that uses
  defined dash patterns and line widths instead of colors?
- Try it out: "test" command, any of the demos

Known issues (not serious enough to block release)
=====================================
- wxt and qt terminals don't work as nicely on OSX as on linux or windows
- the output from "set table' could use thorough revision
- the built-in sequence of dash patterns is not consistent across terminals

Unresolved
========
- Back in 2004 STORE_WITH_LOG_AND_UPDATE_RANGE was changed
  to not store NaN or Inf values read from the input file.
  Furthermore no other data values on that same line are stored.
  This produces garbage output from "set table" and limits
  what changes you can make before issuing a "refresh" command. 
  See thread "what is the use of "u" in tabulated output?".

  Does anyone recall whether there was a specific problem in 2004 that
  led to this change?   Can we safely change [back] to storing x/y/z/etc
  data values even if the point is marked "undefined" because one of the
  values is NaN or Inf?

  My feeling is that it would be OK to make this change for 5.0-rc1 with the
  option of reverting it if unresolvable problems show up.

		Ethan

Re: 07-May-2014 Update on version 5 progress

[Tatsuro M. <tma...@ya...>]

--- On Thu, 2014/5/8, Ethan A Merritt  wrote:

> I think that we are close to putting out a first release candidate
> for version 5.   
> 
> Here is a summary of progress on the big items.
> IMHO all are in an acceptable state for a release candidate.
> 
> Bold/Italic markup in enhanced text mode
> ==============================
> - some terminal-specific bugs reported and fixed
> - not yet implemented for x11, aqua, ...
> - Try it out: "test" command,  bolditalic.dem
>     http://gnuplot.sourceforge.net/demo_svg_5.0/enhanced_utf8.html
> 
> Dash patterns under user control
> ========================
> - generic fallback to version 4 "linetype" dash patterns seems to work
> - custom dash patterns not yet implemented for latex terminals, win, ...
> - very little testing, so there are probably bugs
> - Try it out: dashtypes.dem
>     http://gnuplot.sourceforge.net/demo_canvas_5.0/dashtypes.html
> 
> Default line color sequence
> ====================
> - Three sequences are built in as "set colors {default|classic|podo}"
> - As in version 4.6 this can be further customized via "set linetype"
> - Should there be a built-in "monochrome" sequence that uses
>   defined dash patterns and line widths instead of colors?
> - Try it out: "test" command, any of the demos
> 
> Known issues (not serious enough to block release)
> =====================================
> - wxt and qt terminals don't work as nicely on OSX as on linux or windows
> - the output from "set table' could use thorough revision
> - the built-in sequence of dash patterns is not consistent across terminals
> 
> Unresolved
> ========
> - Back in 2004 STORE_WITH_LOG_AND_UPDATE_RANGE was changed
>   to not store NaN or Inf values read from the input file.
>   Furthermore no other data values on that same line are stored.
>   This produces garbage output from "set table" and limits
>   what changes you can make before issuing a "refresh" command. 
>   See thread "what is the use of "u" in tabulated output?".
> 
>   Does anyone recall whether there was a specific problem in 2004 that
>   led to this change?   Can we safely change [back] to storing x/y/z/etc
>   data values even if the point is marked "undefined" because one of the
>   values is NaN or Inf?
> 
>   My feeling is that it would be OK to make this change for 5.0-rc1 with the
>   option of reverting it if unresolvable problems show up.
> 
>         Ethan

Very Nice! 

> Known issues (not serious enough to block release)
> =====================================
> - wxt and qt terminals don't work as nicely on OSX as on linux or windows

For mingw build, there is no way to build gnuplot with qt terminals.
The config/mingw/Makefile should be modified.

qt terminal also does not work on the Cygwin
http://sourceforge.net/p/gnuplot/bugs/1346/
On the Cygwin-64 qt terminal also does not work.

Re: 07-May-2014 Update on version 5 progress

[Tatsuro M. <tma...@ya...>]

--- On Thu, 2014/5/8, Tatsuro MATSUOKA wrote:

> --- On Thu, 2014/5/8, Ethan A Merritt  wrote:
> 
> > I think that we are close to putting out a first release candidate
> > for version 5.   
> > 
> > Here is a summary of progress on the big items.
> > IMHO all are in an acceptable state for a release candidate.
> > 
> > Bold/Italic markup in enhanced text mode
> > ==============================
> > - some terminal-specific bugs reported and fixed
> > - not yet implemented for x11, aqua, ...
> > - Try it out: "test" command,  bolditalic.dem
> >     http://gnuplot.sourceforge.net/demo_svg_5.0/enhanced_utf8.html
> > 
> > Dash patterns under user control
> > ========================
> > - generic fallback to version 4 "linetype" dash patterns seems to work
> > - custom dash patterns not yet implemented for latex terminals, win, ...
> > - very little testing, so there are probably bugs
> > - Try it out: dashtypes.dem
> >     http://gnuplot.sourceforge.net/demo_canvas_5.0/dashtypes.html
> > 
> > Default line color sequence
> > ====================
> > - Three sequences are built in as "set colors {default|classic|podo}"
> > - As in version 4.6 this can be further customized via "set linetype"
> > - Should there be a built-in "monochrome" sequence that uses
> >   defined dash patterns and line widths instead of colors?
> > - Try it out: "test" command, any of the demos
> > 
> > Known issues (not serious enough to block release)
> > =====================================
> > - wxt and qt terminals don't work as nicely on OSX as on linux or windows
> > - the output from "set table' could use thorough revision
> > - the built-in sequence of dash patterns is not consistent across terminals
> > 
> > Unresolved
> > ========
> > - Back in 2004 STORE_WITH_LOG_AND_UPDATE_RANGE was changed
> >   to not store NaN or Inf values read from the input file.
> >   Furthermore no other data values on that same line are stored.
> >   This produces garbage output from "set table" and limits
> >   what changes you can make before issuing a "refresh" command. 
> >   See thread "what is the use of "u" in tabulated output?".
> > 
> >   Does anyone recall whether there was a specific problem in 2004 that
> >   led to this change?   Can we safely change [back] to storing x/y/z/etc
> >   data values even if the point is marked "undefined" because one of the
> >   values is NaN or Inf?
> > 
> >   My feeling is that it would be OK to make this change for 5.0-rc1 with the
> >   option of reverting it if unresolvable problems show up.
> > 
> >         Ethan
> 
> Very Nice! 
> 
> > Known issues (not serious enough to block release)
> > =====================================
> > - wxt and qt terminals don't work as nicely on OSX as on linux or windows
> 
> For mingw build, there is no way to build gnuplot with qt terminals.
> The config/mingw/Makefile should be modified.
> 

I found description for qt terminal in config/msvc/Makefile.
This is a good example.
The octave-3.8.1 ships qt-4 toolkit on MinGW.  I will try to modify config/mingw/Makefile for qt terminal build on MinGW platform if I will find time to do so.

Tatsuro

Re: 18-August-2014 Update on version 5 progress

[Ethan A M. <sf...@us...>]

I plan to package a second release candidate for gnuplot version 5
next weekend, unless of course someone points out an important
bug or mis-feature in the currect CVS source that is easily fixable.

The plan is to create a new version 5.0 branch of the CVS source tree.
It will initially hold 5.0-rc2 and will essentially freeze the source for 5.0
except for bug fixes turned up by testing of -rc2.
Development will continue in the main CVS tree, which will be labeled
5.1.   Bug fixes should be applied to both the 5.0 and 5.1 source.
New features added to 5.1 may not appear in the final release package
for 5.0.

Thanks to everyone who test the first release candidate and reported
problems or suggestions for improvement. Many of the issues identified
were immediately fixable and hopefully have been resolved in the
upcoming -rc2 release. 

None of this will affect the planned release of 4.6.6 in September/October,
which will probably be the last release in the 4.6 series.

Changes between 5.0 -rc1 and -rc2
=============================

* NEW grey out key entries when corresponding plot is toggled off
* NEW allow parenthesized expressions as call parameters
* NEW command "set margins <left>, <right>, <top>, <bottom>"
* NEW command "set trange [theta_min:theta_max] filters polar mode input data
* NEW command "set mouse zoomfactors <xfact>,<yfact>"
* NEW matrix keywords for text data: "columnheaders" and "rowheaders"
* CHANGE apply "set key {no}enhanced}" to the key title
* CHANGE scale dashlength with line width (not yet done for all terminals)
* CHANGE apply default rectangle style during "set obj" rather than when drawn
* FIX width adjustment for long key title in multicolumn keys
* FIX treat data value read as "NaN" the same as we would "1/0"
* FIX pointtype PT_CHARACTER in 3D plots
* FIX do not store long strings (e.g. epslatex_header) in terminal options
* FIX extra resize of initial qt window may fix problems on OSX, Debian
* FIX handling of events triggered by closing the qt plot window
* FIX refresh of plot with log-scaled color box
* FIX MSWin pipe issues
* FIX if terminal is in "monochrome" mode, convert color requests to black
* FIX various bugs related to the new dashtype code (there are surely more!)


Unresolved issues
=================

- The wxt terminal does not work with wxWidgets 3.0 (wxgtk3).
  No fix is known and so far as I know no one is working on it.
  The problem is made worse for Debian/Ubuntu users because Debian
  plans to drop support for wxWidgets 2.8.

- Initialization and resizing of the qt terminal may still have
  problems on OSX (and other platforms?).

- The lua terminal does not accepts ARGB color specifiers
  (alpha is ignored).

- There is general agreement that the "dashlength" property of
  dashed lines should scale with the linewidth.  Not all terminals
  have yet been modified to act this way. 

- Version 5 terminals default to enhanced text mode.  This change
  broke some scripts.  While "set termoption noenhanced" restores the
  Version 4 default, this command is not persistent.  I.e. it is lost
  whenever you do another "set term" command.  Should there be
  a new command like "set {no}enhanced" that would apply for an
  entire gnuplot session?  Maybe it could offer finer control:
    set {no}enhanced {titles} {tics} {labels} {key}

- A similar issue exists for terminals with a "monochrome" mode.
  Should there be a global "set monochrome {some options}" command?
  Would this clobber all current linetype definitions, or would 
  there be a separate parallel set of monochrome linetypes, or what?

- The <space> (raise console) and <q> (close plot window) hot keys
  do not work consistently for different terminal types.  It would
  be preferable to move this functionality into the core mouse.c
  code and get rid of the special-case code in the individual 
  terminal drivers.  This is not a release-blocker, however, and may
  have to wait until after the final version 5.0 release.

		Ethan Merritt (sf...@us...)

Re: 18-August-2014 Update on version 5 progress

[Pieter-Tjerk de B. <p.t...@ut...>]

Back in June this year, there was some discussion about the fit command,
and in a mail to this list on June 15, I provided a patch to resolve
some issues with it.
I don't see 'fit' mentioned here either as a change or as an unresolved
issue, so I guess this was overlooked?

Regards,
  Pieter-Tjerk


On Mon, Aug 18, 2014 at 11:56:33AM -0700, Ethan A Merritt wrote:
> I plan to package a second release candidate for gnuplot version 5
> next weekend, unless of course someone points out an important
> bug or mis-feature in the currect CVS source that is easily fixable.
> 
> The plan is to create a new version 5.0 branch of the CVS source tree.
> It will initially hold 5.0-rc2 and will essentially freeze the source for 5.0
> except for bug fixes turned up by testing of -rc2.
> Development will continue in the main CVS tree, which will be labeled
> 5.1.   Bug fixes should be applied to both the 5.0 and 5.1 source.
> New features added to 5.1 may not appear in the final release package
> for 5.0.
> 
> Thanks to everyone who test the first release candidate and reported
> problems or suggestions for improvement. Many of the issues identified
> were immediately fixable and hopefully have been resolved in the
> upcoming -rc2 release. 
> 
> None of this will affect the planned release of 4.6.6 in September/October,
> which will probably be the last release in the 4.6 series.
> 
> Changes between 5.0 -rc1 and -rc2
> =============================
> 
> * NEW grey out key entries when corresponding plot is toggled off
> * NEW allow parenthesized expressions as call parameters
> * NEW command "set margins <left>, <right>, <top>, <bottom>"
> * NEW command "set trange [theta_min:theta_max] filters polar mode input data
> * NEW command "set mouse zoomfactors <xfact>,<yfact>"
> * NEW matrix keywords for text data: "columnheaders" and "rowheaders"
> * CHANGE apply "set key {no}enhanced}" to the key title
> * CHANGE scale dashlength with line width (not yet done for all terminals)
> * CHANGE apply default rectangle style during "set obj" rather than when drawn
> * FIX width adjustment for long key title in multicolumn keys
> * FIX treat data value read as "NaN" the same as we would "1/0"
> * FIX pointtype PT_CHARACTER in 3D plots
> * FIX do not store long strings (e.g. epslatex_header) in terminal options
> * FIX extra resize of initial qt window may fix problems on OSX, Debian
> * FIX handling of events triggered by closing the qt plot window
> * FIX refresh of plot with log-scaled color box
> * FIX MSWin pipe issues
> * FIX if terminal is in "monochrome" mode, convert color requests to black
> * FIX various bugs related to the new dashtype code (there are surely more!)
> 
> 
> Unresolved issues
> =================
> 
> - The wxt terminal does not work with wxWidgets 3.0 (wxgtk3).
>   No fix is known and so far as I know no one is working on it.
>   The problem is made worse for Debian/Ubuntu users because Debian
>   plans to drop support for wxWidgets 2.8.
> 
> - Initialization and resizing of the qt terminal may still have
>   problems on OSX (and other platforms?).
> 
> - The lua terminal does not accepts ARGB color specifiers
>   (alpha is ignored).
> 
> - There is general agreement that the "dashlength" property of
>   dashed lines should scale with the linewidth.  Not all terminals
>   have yet been modified to act this way. 
> 
> - Version 5 terminals default to enhanced text mode.  This change
>   broke some scripts.  While "set termoption noenhanced" restores the
>   Version 4 default, this command is not persistent.  I.e. it is lost
>   whenever you do another "set term" command.  Should there be
>   a new command like "set {no}enhanced" that would apply for an
>   entire gnuplot session?  Maybe it could offer finer control:
>     set {no}enhanced {titles} {tics} {labels} {key}
> 
> - A similar issue exists for terminals with a "monochrome" mode.
>   Should there be a global "set monochrome {some options}" command?
>   Would this clobber all current linetype definitions, or would 
>   there be a separate parallel set of monochrome linetypes, or what?
> 
> - The <space> (raise console) and <q> (close plot window) hot keys
>   do not work consistently for different terminal types.  It would
>   be preferable to move this functionality into the core mouse.c
>   code and get rid of the special-case code in the individual 
>   terminal drivers.  This is not a release-blocker, however, and may
>   have to wait until after the final version 5.0 release.
> 
> 		Ethan Merritt (sf...@us...)
> 
> ------------------------------------------------------------------------------
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> Membership management via: https://lists.sourceforge.net/lists/listinfo/gnuplot-beta

Re: 18-August-2014 Update on version 5 progress

[sfeam <sf...@us...>]

On Friday, 22 August 2014 12:03:45 PM Pieter-Tjerk de Boer wrote:
> 
> Back in June this year, there was some discussion about the fit command,
> and in a mail to this list on June 15, I provided a patch to resolve
> some issues with it.
> I don't see 'fit' mentioned here either as a change or as an unresolved
> issue, so I guess this was overlooked?

Patches sent to the mailing list tend to get lost.  Please upload
it to the Patches section of the web site:

   https://sourceforge.net/p/gnuplot/patches/

I discovered yesterday that the new fit keyword "errors" does not
work. I don't suppose your patch happens to fix that?

Also there is no documentation for that keyword or the other new
error-related keywords.  So indeed there are some issues remaining with
fit that will hopefully be fixed during -rc2 testing and before the final
release of version 5.  

	Ethan


> 
> Regards,
>   Pieter-Tjerk
> 
> 
> On Mon, Aug 18, 2014 at 11:56:33AM -0700, Ethan A Merritt wrote:
> > I plan to package a second release candidate for gnuplot version 5
> > next weekend, unless of course someone points out an important
> > bug or mis-feature in the currect CVS source that is easily fixable.
> > 
> > The plan is to create a new version 5.0 branch of the CVS source tree.
> > It will initially hold 5.0-rc2 and will essentially freeze the source for 5.0
> > except for bug fixes turned up by testing of -rc2.
> > Development will continue in the main CVS tree, which will be labeled
> > 5.1.   Bug fixes should be applied to both the 5.0 and 5.1 source.
> > New features added to 5.1 may not appear in the final release package
> > for 5.0.
> > 
> > Thanks to everyone who test the first release candidate and reported
> > problems or suggestions for improvement. Many of the issues identified
> > were immediately fixable and hopefully have been resolved in the
> > upcoming -rc2 release. 
> > 
> > None of this will affect the planned release of 4.6.6 in September/October,
> > which will probably be the last release in the 4.6 series.
> > 
> > Changes between 5.0 -rc1 and -rc2
> > =============================
> > 
> > * NEW grey out key entries when corresponding plot is toggled off
> > * NEW allow parenthesized expressions as call parameters
> > * NEW command "set margins <left>, <right>, <top>, <bottom>"
> > * NEW command "set trange [theta_min:theta_max] filters polar mode input data
> > * NEW command "set mouse zoomfactors <xfact>,<yfact>"
> > * NEW matrix keywords for text data: "columnheaders" and "rowheaders"
> > * CHANGE apply "set key {no}enhanced}" to the key title
> > * CHANGE scale dashlength with line width (not yet done for all terminals)
> > * CHANGE apply default rectangle style during "set obj" rather than when drawn
> > * FIX width adjustment for long key title in multicolumn keys
> > * FIX treat data value read as "NaN" the same as we would "1/0"
> > * FIX pointtype PT_CHARACTER in 3D plots
> > * FIX do not store long strings (e.g. epslatex_header) in terminal options
> > * FIX extra resize of initial qt window may fix problems on OSX, Debian
> > * FIX handling of events triggered by closing the qt plot window
> > * FIX refresh of plot with log-scaled color box
> > * FIX MSWin pipe issues
> > * FIX if terminal is in "monochrome" mode, convert color requests to black
> > * FIX various bugs related to the new dashtype code (there are surely more!)
> > 
> > 
> > Unresolved issues
> > =================
> > 
> > - The wxt terminal does not work with wxWidgets 3.0 (wxgtk3).
> >   No fix is known and so far as I know no one is working on it.
> >   The problem is made worse for Debian/Ubuntu users because Debian
> >   plans to drop support for wxWidgets 2.8.
> > 
> > - Initialization and resizing of the qt terminal may still have
> >   problems on OSX (and other platforms?).
> > 
> > - The lua terminal does not accepts ARGB color specifiers
> >   (alpha is ignored).
> > 
> > - There is general agreement that the "dashlength" property of
> >   dashed lines should scale with the linewidth.  Not all terminals
> >   have yet been modified to act this way. 
> > 
> > - Version 5 terminals default to enhanced text mode.  This change
> >   broke some scripts.  While "set termoption noenhanced" restores the
> >   Version 4 default, this command is not persistent.  I.e. it is lost
> >   whenever you do another "set term" command.  Should there be
> >   a new command like "set {no}enhanced" that would apply for an
> >   entire gnuplot session?  Maybe it could offer finer control:
> >     set {no}enhanced {titles} {tics} {labels} {key}
> > 
> > - A similar issue exists for terminals with a "monochrome" mode.
> >   Should there be a global "set monochrome {some options}" command?
> >   Would this clobber all current linetype definitions, or would 
> >   there be a separate parallel set of monochrome linetypes, or what?
> > 
> > - The <space> (raise console) and <q> (close plot window) hot keys
> >   do not work consistently for different terminal types.  It would
> >   be preferable to move this functionality into the core mouse.c
> >   code and get rid of the special-case code in the individual 
> >   terminal drivers.  This is not a release-blocker, however, and may
> >   have to wait until after the final version 5.0 release.
> > 
> > 		Ethan Merritt (sf...@us...)
> > 
> > ------------------------------------------------------------------------------
> > _______________________________________________
> > gnuplot-beta mailing list
> > gnu...@li...
> > Membership management via: https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
> 
> ------------------------------------------------------------------------------
> Slashdot TV.  
> Video for Nerds.  Stuff that matters.
> http://tv.slashdot.org/
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> Membership management via: https://lists.sourceforge.net/lists/listinfo/gnuplot-beta

Re: 18-August-2014 Update on version 5 progress

[Tatsuro M. <tma...@ya...>]

----- Original Message -----

> From: sfeam 
> To: gnu...@li...
> Cc: Pieter-Tjerk de Boer 
> Date: 2014/8/23, Sat 00:18
> Subject: Re: 18-August-2014 Update on version 5 progress
> 
> On Friday, 22 August 2014 12:03:45 PM Pieter-Tjerk de Boer wrote:
>> 
>>  Back in June this year, there was some discussion about the fit command,
>>  and in a mail to this list on June 15, I provided a patch to resolve
>>  some issues with it.
>>  I don't see 'fit' mentioned here either as a change or as an 
> unresolved
>>  issue, so I guess this was overlooked?
> 
> Patches sent to the mailing list tend to get lost.  Please upload
> it to the Patches section of the web site:
> 
>   https://sourceforge.net/p/gnuplot/patches/
> 
> I discovered yesterday that the new fit keyword "errors" does not
> work. I don't suppose your patch happens to fix that?
> 
> Also there is no documentation for that keyword or the other new
> error-related keywords.  So indeed there are some issues remaining with
> fit that will hopefully be fixed during -rc2 testing and before the final
> release of version 5.  
> 
>     Ethan
> 
> 
>> 
>>  Regards,
>>    Pieter-Tjerk
>> 
>> 
>>  On Mon, Aug 18, 2014 at 11:56:33AM -0700, Ethan A Merritt wrote:
>>  > I plan to package a second release candidate for gnuplot version 5
>>  > next weekend, unless of course someone points out an important
>>  > bug or mis-feature in the currect CVS source that is easily fixable.
>>  > 
>>  > The plan is to create a new version 5.0 branch of the CVS source tree.
>>  > It will initially hold 5.0-rc2 and will essentially freeze the source 
> for 5.0
>>  > except for bug fixes turned up by testing of -rc2.
>>  > Development will continue in the main CVS tree, which will be labeled
>>  > 5.1.   Bug fixes should be applied to both the 5.0 and 5.1 source.
>>  > New features added to 5.1 may not appear in the final release package
>>  > for 5.0.
>>  > 
>>  > Thanks to everyone who test the first release candidate and reported
>>  > problems or suggestions for improvement. Many of the issues identified
>>  > were immediately fixable and hopefully have been resolved in the
>>  > upcoming -rc2 release. 
>>  > 
>>  > None of this will affect the planned release of 4.6.6 in 
> September/October,
>>  > which will probably be the last release in the 4.6 series.
>>  > 
>>  > Changes between 5.0 -rc1 and -rc2
>>  > =============================
>>  > 
>>  > * NEW grey out key entries when corresponding plot is toggled off
>>  > * NEW allow parenthesized expressions as call parameters
>>  > * NEW command "set margins <left>, <right>, 
> <top>, <bottom>"
>>  > * NEW command "set trange [theta_min:theta_max] filters polar 
> mode input data
>>  > * NEW command "set mouse zoomfactors 
> <xfact>,<yfact>"
>>  > * NEW matrix keywords for text data: "columnheaders" and 
> "rowheaders"
>>  > * CHANGE apply "set key {no}enhanced}" to the key title
>>  > * CHANGE scale dashlength with line width (not yet done for all 
> terminals)
>>  > * CHANGE apply default rectangle style during "set obj" 
> rather than when drawn
>>  > * FIX width adjustment for long key title in multicolumn keys
>>  > * FIX treat data value read as "NaN" the same as we would 
> "1/0"
>>  > * FIX pointtype PT_CHARACTER in 3D plots
>>  > * FIX do not store long strings (e.g. epslatex_header) in terminal 
> options
>>  > * FIX extra resize of initial qt window may fix problems on OSX, 
> Debian
>>  > * FIX handling of events triggered by closing the qt plot window
>>  > * FIX refresh of plot with log-scaled color box
>>  > * FIX MSWin pipe issues
>>  > * FIX if terminal is in "monochrome" mode, convert color 
> requests to black
>>  > * FIX various bugs related to the new dashtype code (there are surely 
> more!)
>>  > 
>>  > 
>>  > Unresolved issues
>>  > =================
>>  > 
>>  > - The wxt terminal does not work with wxWidgets 3.0 (wxgtk3).
>>  >   No fix is known and so far as I know no one is working on it.
>>  >   The problem is made worse for Debian/Ubuntu users because Debian
>>  >   plans to drop support for wxWidgets 2.8.
>>  > 
>>  > - Initialization and resizing of the qt terminal may still have
>>  >   problems on OSX (and other platforms?).
>>  > 
>>  > - The lua terminal does not accepts ARGB color specifiers
>>  >   (alpha is ignored).
>>  > 
>>  > - There is general agreement that the "dashlength" property 
> of
>>  >   dashed lines should scale with the linewidth.  Not all terminals
>>  >   have yet been modified to act this way. 
>>  > 
>>  > - Version 5 terminals default to enhanced text mode.  This change
>>  >   broke some scripts.  While "set termoption noenhanced" 
> restores the
>>  >   Version 4 default, this command is not persistent.  I.e. it is lost
>>  >   whenever you do another "set term" command.  Should there 
> be
>>  >   a new command like "set {no}enhanced" that would apply for 
> an
>>  >   entire gnuplot session?  Maybe it could offer finer control:
>>  >     set {no}enhanced {titles} {tics} {labels} {key}
>>  > 
>>  > - A similar issue exists for terminals with a "monochrome" 
> mode.
>>  >   Should there be a global "set monochrome {some options}" 
> command?
>>  >   Would this clobber all current linetype definitions, or would 
>>  >   there be a separate parallel set of monochrome linetypes, or what?
>>  > 
>>  > - The <space> (raise console) and <q> (close plot window) 
> hot keys
>>  >   do not work consistently for different terminal types.  It would
>>  >   be preferable to move this functionality into the core mouse.c
>>  >   code and get rid of the special-case code in the individual 
>>  >   terminal drivers.  This is not a release-blocker, however, and may
>>  >   have to wait until after the final version 5.0 release.
>>  > 
>>  >         Ethan Merritt (sf...@us...)
>>  > 
>>  > 



The patch was attached at this thread:
http://gnuplot.10905.n7.nabble.com/Gnuplot-version-5-release-candidate-td18424.html#a18519



Tatsuro

Nov 2014 Update on version 5 progress: -rc3 available

[Ethan A M. <sf...@us...>]

I have placed a source tarball on SourceForge for the
3rd (final) version 5.0 release candidate.

I do not expect much to change between -rc3  and the final 5.0 release,
but if your valuable testing uncovers a problem there is still time to fix it.

The user-visible changes since -rc2 are
=============================

- revised "fit" command 
 + syntax:
       fit {<ranges>} <expression>
           '<datafile>' {datafile-modifiers}
           {{unitweights} | {y|xy|z}error | errors <var1>{,<var2>,...}}
           via '<parameter file>' | <var1>{,<var2>,...}
  + this is a CHANGE from -rc1 and -rc2
  + most version 4 "fit" syntax is detected and emulated even though
     the command options have changed. Also there is now an explicit
     command "set fit {v4|v5}" to force ambiguous commands to be
     interpreted as they were in version 4.

- completion of time/date format changes begun in -rc1 and -rc2
 + formats used for input and output are now distinct
 + fime format used to read input data or range/position commands
    is specified by 'set timefmt' or  timecolumn(column,"timeformat')
 + timecolumn(column) uses default from 'set timefmt' as in version 4
 + time format used to output axis tic labels is specified by
    set {xyz}tics {timedate|geographic|numeric} format "..."
 + new format modifier "t" distinguishes a time interval from a date

- wxt terminal has an Export-to-File widget on the toolbar

- various bug fixes (see NEWS and ChangeLog)

Known issues (no resolution expected before 5.0)
====================================

- the wxt terminal emits runtime warnings and errors if gnuplot is 
  built using wxWidgets 3.0 rather than 2.8


	thanks for all the testing and feedback on -rc1 and -rc2

			Ethan