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