Menu
▾
▴
gnuplot-beta
|
From: sfeam <sf...@us...> - 2014-05-15 05:57:44
|
Today I have updated the version info in the CVS source to version 5.0.rc1
A 5.0.rc1 tarball a a draft set of Release Notes are now on SourceForge
in a "staging area" of the Files section.
(I'm not quite sure how that works, but I think for the first
3 days it is only visible if you are on some list of developers.
Unfortunately I don't know exactly where that list is so I don't
know how many of you are on it.)
On Saturday either the tarball will automagically become visible to
everyone or I will manually move it if that fails.
Next Monday, if nothing has gone wrong, I will send announcements
to various places.
If you have any last minute issues/requests/additions
please send them by the end of the week. If you have
suggestions where to send announcements, send those too.
I append a copy of the draft Release Notes.
happy gnuplotting!
Ethan
GNUPLOT VERSION 5.0.rc1 RELEASE NOTES
=====================================
We are happy to announce a release candidate for gnuplot version 5.
Version 5 will be a major release with significant new capabilities
and enhancements compared to previous gnuplot versions.
MAJOR NEW FEATURES
==================
* The dot/dash pattern of a line can now be controlled independently
from other properties using the keyword "dashtype".
* Text markup now supports bold and italic font settings in addition to
the subscript, superscript, font size and other options previously
provided by the "enhanced text" mode. This mode is now the default.
* Command scripts may place in-line data in a named data block for
repeated plotting.
* RGB colors can include an alpha-channel for transparency.
E.g. SEETHRUBLU = (0xDD << 24) + (0x0 << 16) + (0x0 << 8) + (0xFF)
set linetype N linecolor rgb SEETHRUBLU
* Bit shift operators << and >> (used in above example)
* Secondary axes (x2, y2) can be locked to the primary axis via a mapping
function. In the simplest case this guarantees that the primary and
secondary axis ranges are identical. In the general case it allows you
to define a non-linear axis, something that previously was only possible
for the special case of log scaling.
* The "import" command attaches a user-defined function name to a
function provided by an extenal shared object (i.e. a plugin).
* Previous commands in the history list of an interactive session can be
reexecuted by number. For example "history !5" will reexecute the
command numbered 5 in the list reported by "history".
* New plot styles "with parallelaxes", labeled contours.
* New coordinate system (Degrees, Minutes, Seconds) "set xdata geographic".
* Hypertext labels in the interactive terminals including web display
using the HTML canvas or svg terminals.
Many other additions are described in the "New Features" section of the
documentation.
CHANGES
=======
Gnuplot development assigns very high priority to backward compatibility
with earlier versions. For example any command script that worked in
version 4.0 is expected to continue to work for all version 4 releases
including the most recent one (4.6.5). However changes introduced in
version 5 can affect the operation of some version 4 scripts.
A brief summary of potentially incompatible changes is given here.
* Earlier versions of gnuplot used the keyword "linetype" to mean both
the color and the solid/dot/dash pattern of a line. Version 5 has
separate keywords "linecolor" and "dashtype". You can assign any
desired color and a dash pattern to any linetype. The program now
uses a default set of 8 linetypes, all solid. You can change these
or add new linetypes as you please, or include the desired color or
dash pattern directly in a plot command. You do not need to change
the current terminal or terminal mode in order to used dashed lines.
* The handling of input data containing NaN, Inf, inconsistent number of
data columns, or other unexpected content has changed. See documentation
under "missing" for examples and figures.
* Time coordinates are stored internally as the number of seconds relative
to the standard unix epoch 1-Jan-1970. Earlier versions of gnuplot used
a different epoch internally (1-Jan-2000). This change resolves
inconsistencies introduced when time in seconds was generated externally.
The epoch convention used by a particular gnuplot installation can be
determined using the command `print strftime("%F",0)`.
Time is now stored to at least millisecond precision.
* The "reverse" keyword (e.g. "set xrange [*:*] reverse") now affects only
autoscaling. It has no effect on explicit ranges.
"set xrange [0:1] reverse" is _not_ the same as "set xrange [1:0]".
* Options to the "fit" command are now given by "set fit ..." rather than
by setting environmental variables. Fit can handle up to MAX_NUM_VAR
independent variables (currently 12). Variables other than the first
two (x, y) have been dissociated from axis names.
E.g. "set urange [U1:U2]" has no effect on fitting. Use the command
"set dummy ..." to assign names to fit variables 3 ... 12.
* The function `timecolumn(N,"timeformat")` now has 2 parameters.
Because the required second parameter is not associated with a particular
data axis, this allows using the `timecolumn` function to read time data
for reasons other than specifying the x or y coordinate.
* The `call` command is implemented by providing a set of variables ARGC,
ARG0, ..., ARG9. ARG0 holds the name of the script file being executed.
ARG1 to ARG9 are string variables and thus may either be referenced directly
or expanded as macros, e.g. @ARG1. The older convention for referencing
call parameters as tokens $0 ... $9 is deprecated.
* "unset xrange" (and other axis ranges) restores the default range.
* "unset terminal" restores the original terminal of the current session.
NOTES TO PACKAGERS AND TESTERS
===============================
Configuration options for interactive use
-----------------------------------------
The 5.0 source code supports three primary cross-platform output modes
in addition to several platform-specific modes.
1) Qt
The qt terminal supports interactive display with menu-driven
output to png, svg or pdf. The final 5.0 release may also support
scripted output to these same file formats but this is not present
in rc1. If either Qt4 or Qt5 is detected by the configure script,
this will be the default terminal. It is now the fastest and most
full-featured interactive terminal option.
To disable this terminal:
./configure --without-qt
To force use of Qt4 even if Qt5 is present:
./configure --with-qt=qt4
2) Cairo/pango/wxWidgets
This set of terminals includes
- pngcairo, pdfcairo, epscairo, and cairolatex for output to a file
- wxt for interactive display
All of these will be built by default if the configuration script finds
the required libcairo, libpango, libcairo, libwxgtk, and related
support libraries
To disable these terminals:
./configure --without-cairo
./configure --with-cairo --disable-wxt
3) X11 (the "classic" interactive interface)
This used to be the preferred interactive interface, but the newer
wxt and qt terminals offer nicer output and a wider range of features.
Options for output to files
---------------------------
Of course the terminals (output modes) present in previous gnuplot versions
are also still available. These include, among many more obscure options:
- png/jpeg/gif output via libgd
- PostScript
- Many flavors of TeX/LaTeX output, including TikZ and ConTeXt
- Bitmapped output to support many older devices (e.g. HP deskjet, epson,
seiko printers, pbm bitmapped graphics files) is available if needed
but is no longer configured in by default.
./configure --with-bitmap-terminals
Options for generating interactive plots for web display
--------------------------------------------------------
- Mouseable output for display on the web can be created using either
the canvas terminal (HTML5 2D canvas element) or the svg terminal.
Both allow zooming, toggling plot elements on/off, and user-scriptable
hot keys.
Online demo plots
-----------------
Demo plots illustrating new and old features are online at
http://gnuplot.sourceforge.net/demo_5.0/
OTHER NOTES
===============================
Installation
------------
You can download a source tarball for gnuplot version 5.0.rc1 from the
gnuplot development site on SourceForge.
http://sourceforge.net/project/showfiles.php?group_id=2055
Installation instructions are available in the source itself; the short
version for linux/unix-like systems is to unpack the tarball and then
build it:
cd gnuplot-5.0.rc1 ; ./configure ; make
test it:
make check
install it:
make install
Pay careful attention to the output of the ./configure script.
It may indicate that some output drivers have been omitted because the
necessary support libraries were not found. In general you need to have
previously installed the "*-devel-*" versions of these libraries.
Known issues
------------
- Mac OSX ships with a terminal input library that appears to be GNU
libreadline, but isn't really. The program tries to cope with this, but
you may get better results by configuring gnuplot to use either its own
built-in readline routines or the real GNU libreadline.
- The gnuplot build system is not very good at figuring out where to find
or install LaTeX-related files. This can affect use of the new lua/tikz
and ConTeXt terminals.
- You can configure support for both wxt and qt into the same gnuplot
executable, but only one of these two output modes can be used in any
given gnuplot session.
Support
-------
Please report all bugs and installation problems to the bug tracker
on SourceForge:
http://sourceforge.net/tracker/?group_id=2055&atid=102055
There is also an gnuplot discussion forum on usenet group
comp.graphics.apps.gnuplot
Development
-----------
Gnuplot development is quite active. The development branch on SourceForge
contains preliminary implementations of many new features. Following the
release of gnuplot 5.0, the development branch will be identified as
version 5.1. Feedback and contributions of code are very welcome.
|
|
From: Christoph B. <us...@be...> - 2014-05-17 08:39:30
|
Thanks for the RC! Zitat von sfeam <sf...@us...>: > > If you have any last minute issues/requests/additions > please send them by the end of the week. If you have > suggestions where to send announcements, send those too. What happend to the `dashed` option of e.g. the cairo terminals? I don't see, how currently the default linetypes can be switched between dashed and solid-only. That would be like the `color` and `monochrome` options of the terminals. You can change the *default* linetypes to be dashed or only solid, but you could in any case use `dashtype` to use dashed lines even if the terminal option is set to `solid`. Second, I would like to see a 'linetype variable' which, opposed to `lc var`, changes all line properties: linecolor, dashtype and pointtype. But that could also be added later. > CHANGES > ======= > Here is missing, that `set style increment user` was removed. I think, we should also organize a section on the homepage with 'Migrating to 5.0', which contains simple examples showing how to change and adapt old scripts. Christoph |
|
From: Ethan A M. <sf...@us...> - 2014-05-19 19:56:22
|
A source tarball for the version 5.0-rc1 release candidate
is now publically accessible on SourceForge:
http://sourceforge.net/projects/gnuplot/files/gnuplot/5.0.rc1/
Release Notes are here
http://gnuplot.sourceforge.net/RELEASE_NOTES_5_0_rc1.text
Demos are here
http://gnuplot.sourceforge.net/demo_5.0/
http://gnuplot.sourceforge.net/demo_svg_5.0/
http://gnuplot.sourceforge.net/demo_canvas_5.0/
Ethan
On Wednesday, 14 May, 2014 22:44:25 sfeam wrote:
>
> A 5.0.rc1 tarball a a draft set of Release Notes are now on SourceForge
> in a "staging area" of the Files section.
> (I'm not quite sure how that works, but I think for the first
> 3 days it is only visible if you are on some list of developers.
> Unfortunately I don't know exactly where that list is so I don't
> know how many of you are on it.)
>
> On Saturday either the tarball will automagically become visible to
> everyone or I will manually move it if that fails.
>
> Next Monday, if nothing has gone wrong, I will send announcements
> to various places.
|
|
From: Tait <gnu...@t4...> - 2014-05-20 16:15:10
|
I don't see the windows binaries on SourceForge, but I did pull them
from Tatsuro's site, and the default wxt terminal behaves oddly, now.
When I load a script containing "set contour" and a plot or splot, the
plot window does not appear until after I move the mouse. Without the
"set contour", without the (s)plot, or when not from within a script,
the plot displays immediately.
To try it out, create a script:
reset
set contour
plot x
then 'load "thatscript.gps"' from within gnuplot, without touching the
mouse. No plot or plot window is displayed. As soon as the mouse
moves, the window appears, with the plot as expected. The behavior is
repeatable, for me. Does anybody else see this as well?
Ethan A Merritt <sf...@us...> said (on 2014/05/19):
> A source tarball for the version 5.0-rc1 release candidate
> is now publically accessible on SourceForge:...
|
|
From: Tatsuro M. <tma...@ya...> - 2014-05-21 13:52:43
|
--- On Wed, 2014/5/21, Tait wrote: > I don't see the windows binaries on SourceForge, but I did pull them > from Tatsuro's site, and the default wxt terminal behaves oddly, now. > When I load a script containing "set contour" and a plot or splot, the > plot window does not appear until after I move the mouse. Without the > "set contour", without the (s)plot, or when not from within a script, > the plot displays immediately. > > To try it out, create a script: > reset > set contour > plot x > > then 'load "thatscript.gps"' from within gnuplot, without touching the > mouse. No plot or plot window is displayed. As soon as the mouse > moves, the window appears, with the plot as expected. The behavior is > repeatable, for me. Does anybody else see this as well? > > > Ethan A Merritt <sf...@us...> said (on 2014/05/19): > > A source tarball for the version 5.0-rc1 release candidate > > is now publically accessible on SourceForge:... Tait. Please confirm whether your operation works well on windows terminal. I suspect that the change on 2014-01-04 is related to that you pointed out. I have aware the phenomenon that all .dem on wxt terminal on windows does not work correctly. Shigeharu Takeno also pointed out that point in the private mail to me. The change below perhaps related to the phenomena that you have met. ************************************************************************* 2014-01-04 Bastian Maerkisch <bma...@we...> * src/win/wcommon.h src/win/wgdiplus.cpp|h src/win/wgnuplib.h src/win/wgraph.c src/win/resourc.h term/win.trm: New (optional) variant of the windows terminal backend which draws using the GDI+ API whenever possible. This is much faster in some cases than the old backend which switches between GDI and GDI+ to support antialiasing and RGBA colors. Images are drawn using GDI since GDI+ always uses some sort of interpolation when scaling images. Enhanced text is currently still drawn using GDI. Adjacent polygons of the same color are merged in order to avoid "seams" between them caused by antialiasing. See also Bug #1096. * src/term_api.h src/graphics (plot_image_or_update_axes): Wrap the fallback image output with term->layer() commands using TERM_LAYER_BEGIN_IMAGE and TERM_LAYER_END_IMAGE. This can be used by terminals to optimize output. * src/win/wgraph.c (drawgraph): Move GDI image drawing code from drawgraph() to a new routine draw_image(). * src/command.c src/fit.c|h src/plot.c|h src/term.c src/win/wgraph.c src/win/winmain.c src/win/wtext.c term/win.trm: Handle Ctrl-C asynchronously on Windows (GUI and console mode). This is done by setting ctrlc_flag and testing it in check_for_mouse_event(). Thus, scripts etc. can now finally be interrupted by pressing Ctrl-C in console mode gnuplot or Ctrl-Break in wgnuplot. * src/win/winmain.c (ConsoleGetch): Remap Shift-Tab key-code in console mode, too. *********************************************************************** The above change solves the CTRL+C issue on gnuplot on windows for a long term. The change seems to be well on windows terminal but not be well on wxt terminal. To confirm my assumption, I have to downgrade the cvs source but I have not tried yet. Please give me a little bit time to confirm that the change above is an origin of the fault on the wxt terminal. Regards Tatsuro |
|
From: Tatsuro M. <tma...@ya...> - 2014-05-22 03:19:26
|
--- On Wed, 2014/5/21, Tatsuro MATSUOKA wrote: > --- On Wed, 2014/5/21, Tait wrote: > > I don't see the windows binaries on SourceForge, but I did pull them > > from Tatsuro's site, and the default wxt terminal behaves oddly, now. > > When I load a script containing "set contour" and a plot or splot, the > > plot window does not appear until after I move the mouse. Without the > > "set contour", without the (s)plot, or when not from within a script, > > the plot displays immediately. > > > > To try it out, create a script: > > reset > > set contour > > plot x > > > > then 'load "thatscript.gps"' from within gnuplot, without touching the > > mouse. No plot or plot window is displayed. As soon as the mouse > > moves, the window appears, with the plot as expected. The behavior is > > repeatable, for me. Does anybody else see this as well? > > > > > > Ethan A Merritt <sf...@us...> said (on 2014/05/19): > > > A source tarball for the version 5.0-rc1 release candidate > > > is now publically accessible on SourceForge:... > > Tait. Please confirm whether your operation works well on windows terminal. > > I suspect that the change on 2014-01-04 is related to that you pointed out. > I have aware the phenomenon that all .dem on wxt terminal on windows does not work correctly. Shigeharu Takeno also pointed out that point in the private mail to me. > > The change below perhaps related to the phenomena that you have met. > ************************************************************************* > 2014-01-04 Bastian Maerkisch <bma...@we...> > > * src/win/wcommon.h src/win/wgdiplus.cpp|h src/win/wgnuplib.h > src/win/wgraph.c src/win/resourc.h term/win.trm: New (optional) > variant of the windows terminal backend which draws using the GDI+ API > whenever possible. This is much faster in some cases than the old > backend which switches between GDI and GDI+ to support antialiasing > and RGBA colors. Images are drawn using GDI since GDI+ always uses some > sort of interpolation when scaling images. Enhanced text is currently > still drawn using GDI. Adjacent polygons of the same color are merged > in order to avoid "seams" between them caused by antialiasing. See also > Bug #1096. > > * src/term_api.h src/graphics (plot_image_or_update_axes): Wrap > the fallback image output with term->layer() commands using > TERM_LAYER_BEGIN_IMAGE and TERM_LAYER_END_IMAGE. This can be > used by terminals to optimize output. > > * src/win/wgraph.c (drawgraph): Move GDI image drawing code from > drawgraph() to a new routine draw_image(). > > * src/command.c src/fit.c|h src/plot.c|h src/term.c src/win/wgraph.c > src/win/winmain.c src/win/wtext.c term/win.trm: Handle Ctrl-C > asynchronously on Windows (GUI and console mode). This is done by > setting ctrlc_flag and testing it in check_for_mouse_event(). Thus, > scripts etc. can now finally be interrupted by pressing Ctrl-C in > console mode gnuplot or Ctrl-Break in wgnuplot. > > * src/win/winmain.c (ConsoleGetch): Remap Shift-Tab key-code in > console mode, too. > > *********************************************************************** > The above change solves the CTRL+C issue on gnuplot on windows for a long term. > The change seems to be well on windows terminal but not be well on wxt terminal. > > To confirm my assumption, I have to downgrade the cvs source but I have not tried yet. > > Please give me a little bit time to confirm that the change above is an origin of the fault on the wxt terminal. My assumption is wrong. Using the cvs source dated 2014-01-02, the same phenomena occur on the wxt terminal for windows. Perhaps it will take time which change is the origin this fault. Tatsuro |
|
From: Tatsuro M. <tma...@ya...> - 2014-05-26 03:49:13
|
--- On Thu, 2014/5/22, Tatsuro MATSUOKA wrote: > --- On Wed, 2014/5/21, Tatsuro MATSUOKA wrote: > > --- On Wed, 2014/5/21, Tait wrote: > > > I don't see the windows binaries on SourceForge, but I did pull them > > > from Tatsuro's site, and the default wxt terminal behaves oddly, now. > > > When I load a script containing "set contour" and a plot or splot, the > > > plot window does not appear until after I move the mouse. Without the > > > "set contour", without the (s)plot, or when not from within a script, > > > the plot displays immediately. > > > > > > To try it out, create a script: > > > reset > > > set contour > > > plot x > > > > > > then 'load "thatscript.gps"' from within gnuplot, without touching the > > > mouse. No plot or plot window is displayed. As soon as the mouse > > > moves, the window appears, with the plot as expected. The behavior is > > > repeatable, for me. Does anybody else see this as well? > > > > > > > > > Ethan A Merritt <sf...@us...> said (on 2014/05/19): > > > > A source tarball for the version 5.0-rc1 release candidate > > > > is now publically accessible on SourceForge:... > > > > Tait. Please confirm whether your operation works well on windows terminal. > > > > I suspect that the change on 2014-01-04 is related to that you pointed out. > > I have aware the phenomenon that all .dem on wxt terminal on windows does not work correctly. Shigeharu Takeno also pointed out that point in the private mail to me. > > Tait Bastian made a fix ************************************************************* 2014-05-24 Bastian Maerkisch <bma...@we...> * src/wxterminal/wxt_gui.cpp (wxt_waitforinput): Do not wait for an event when only checking for mouse events. Bugfix ************************************************************* and I rebuilt Windows binaries. Please test the fixed binaries solve your problem. Tatsuro |
|
From: Tait <gnu...@t4...> - 2014-05-29 09:52:57
|
I tried the 20140528 binaries and they do not exhibit the same symptoms anymore. The plot window appears immediately, even without moving the mouse. Thanks Tatsuro MATSUOKA <tma...@ya...> said (on 2014/05/26): > Bastian made a fix > ************************************************************* > 2014-05-24 Bastian Maerkisch <bma...@we...> > > * src/wxterminal/wxt_gui.cpp (wxt_waitforinput): Do not wait for an > event when only checking for mouse events. > Bugfix > ************************************************************* > and I rebuilt Windows binaries. > > Please test the fixed binaries solve your problem. > > --- On Thu, 2014/5/22, Tatsuro MATSUOKA wrote: > > --- On Wed, 2014/5/21, Tatsuro MATSUOKA wrote: > > > Tait. Please confirm whether your operation works well on windows terminal. > > > > > > I suspect that the change on 2014-01-04 is related to that you pointed out. > > > I have aware the phenomenon that all .dem on wxt terminal on windows does not work correctly. Shigeharu Takeno also pointed out that point in the private mail to me. > > > > > > --- On Wed, 2014/5/21, Tait wrote: > > > > I don't see the windows binaries on SourceForge, but I did pull them > > > > from Tatsuro's site, and the default wxt terminal behaves oddly, now. > > > > When I load a script containing "set contour" and a plot or splot, the > > > > plot window does not appear until after I move the mouse. Without the > > > > "set contour", without the (s)plot, or when not from within a script, > > > > the plot displays immediately. > > > > > > > > To try it out, create a script: > > > > reset > > > > set contour > > > > plot x > > > > > > > > then 'load "thatscript.gps"' from within gnuplot, without touching the > > > > mouse. No plot or plot window is displayed. As soon as the mouse > > > > moves, the window appears, with the plot as expected. The behavior is > > > > repeatable, for me. Does anybody else see this as well? > > > > > > > > Ethan A Merritt <sf...@us...> said (on 2014/05/19): > > > > > A source tarball for the version 5.0-rc1 release candidate > > > > > is now publically accessible on SourceForge:... |
|
From: Ethan A M. <sf...@us...> - 2014-05-19 20:53:30
|
On Saturday, 17 May, 2014 10:39:07 Christoph Bersch wrote:
> Thanks for the RC!
>
> Zitat von sfeam <sf...@us...>:
> >
> > If you have any last minute issues/requests/additions
> > please send them by the end of the week. If you have
> > suggestions where to send announcements, send those too.
>
> What happend to the `dashed` option of e.g. the cairo terminals?
The dashed/solid terminal options are no longer needed.
> I don't see, how currently the default linetypes can be switched between
> dashed and solid-only.
set for [i=1:N] linetype i solid # set all to solid (this is the default)
set for [i=1:N] linetype i dt i # set each linetype to a different dash pattern
> That would be like the `color` and `monochrome`
> options of the terminals. You can change the *default* linetypes to be
> dashed or only solid, but you could in any case use `dashtype` to use
> dashed lines even if the terminal option is set to `solid`.
Exactly. mono/color is also no longer needed, for much the same reason.
There is a sample monochrome style file in .../share but your
comment reminds me that the new command
set colorsequence {default|classic|podo}
could have a keyword for
set colorsequence mono
that does basically the same thing as the sample script.
> Second, I would like to see a 'linetype variable' which, opposed to
> `lc var`, changes all line properties: linecolor, dashtype and
> pointtype. But that could also be added later.
I agree.
> > CHANGES
> > =======
> >
>
> Here is missing, that `set style increment user` was removed.
>
> I think, we should also organize a section on the homepage with
> 'Migrating to 5.0', which contains simple examples showing how to
> change and adapt old scripts.
There is a small section in the User Manual with examples of
how to replace the deprecated syntax.
It would be nice if someone would volunteer to fix the generation
of HTML documentation from the *.doc or *.tex or whatever.
It has not worked well for a long time. That would make it easier
to provide links to specific online sections of the documentation
rather than pointing to the whole *pdf file.
>
> Christoph
|
|
From: Christoph B. <us...@be...> - 2014-05-20 08:50:51
|
Zitat von Ethan A Merritt <sf...@us...>:
> On Saturday, 17 May, 2014 10:39:07 Christoph Bersch wrote:
>>
> The dashed/solid terminal options are no longer needed.
>
>> I don't see, how currently the default linetypes can be switched between
>> dashed and solid-only.
>
> set for [i=1:N] linetype i solid # set all to solid (this is the default)
> set for [i=1:N] linetype i dt i # set each linetype to a
> different dash pattern
>
>> That would be like the `color` and `monochrome`
>> options of the terminals. You can change the *default* linetypes to be
>> dashed or only solid, but you could in any case use `dashtype` to use
>> dashed lines even if the terminal option is set to `solid`.
>
> Exactly. mono/color is also no longer needed, for much the same reason.
> There is a sample monochrome style file in .../share but your
> comment reminds me that the new command
> set colorsequence {default|classic|podo}
> could have a keyword for
> set colorsequence mono
> that does basically the same thing as the sample script.
Hmm, maybe it would make sense to have a similar option to switch the
default linetypes between dashed and solid. Something like `set
linetype dashed|solid`. Then one could change the line sequences with
e.g.
set linetype dashed
set colorsequence mono
> It would be nice if someone would volunteer to fix the generation
> of HTML documentation from the *.doc or *.tex or whatever.
> It has not worked well for a long time. That would make it easier
> to provide links to specific online sections of the documentation
> rather than pointing to the whole *pdf file.
Good point, I had also thought about this. How was the HTML
documentation of version 4.2 created, which is still online?
I already contacted the maintainer of gnuplotting.org, which has a
very nice version of the 4.6. documentation on
http://www.gnuplotting.org/manpage-gnuplot-4-6/. He sent me some
helpful command line stuff, but it still needs a lot of extra work.
I'll see if I can come up with a good script.
Christoph
|
|
From: sfeam <sf...@us...> - 2014-05-20 15:17:03
|
On Tuesday, 20 May 2014 10:47:50 AM Christoph Bersch wrote: > > It would be nice if someone would volunteer to fix the generation > > of HTML documentation from the *.doc or *.tex or whatever. > > It has not worked well for a long time. That would make it easier > > to provide links to specific online sections of the documentation > > rather than pointing to the whole *pdf file. > > Good point, I had also thought about this. How was the HTML > documentation of version 4.2 created, which is still online? It was generated with an external tool called latex2html. But that tool ceased to be developed or supported, so far as I can tell, and no longer works with current LaTeX installations. Furthermore it didn't handle figures, or at least the commands in gnuplot's Makefile didn't handle figures. I have tried several possible replacements. The most promising seems to be htlatex. Supposedly it should do what we want, but the default mode is not very satisfactory. > I already contacted the maintainer of gnuplotting.org, which has a > very nice version of the 4.6. documentation on > http://www.gnuplotting.org/manpage-gnuplot-4-6/. He sent me some > helpful command line stuff, but it still needs a lot of extra work. > I'll see if I can come up with a good script. That site does look nicer than I get out of a default run of htlatex. It would be nicer yet if the index ran down the side in a separate panel so that you can browse the index without losing your current place. Ethan > > Christoph > > |
|
From: Christoph B. <us...@be...> - 2014-05-21 20:39:19
|
Zitat von sfeam <sf...@us...>: > On Tuesday, 20 May 2014 10:47:50 AM Christoph Bersch wrote: >> How was the HTML >> documentation of version 4.2 created, which is still online? > > It was generated with an external tool called latex2html. > But that tool ceased to be developed or supported, so far as I > can tell, and no longer works with current LaTeX installations. > Furthermore it didn't handle figures, or at least the commands > in gnuplot's Makefile didn't handle figures. > > I have tried several possible replacements. The most promising > seems to be htlatex. Supposedly it should do what we want, but > the default mode is not very satisfactory. I've written a Python script doc2html.py which does the conversion directly from the gnuplot.doc file. It is working already, but needs some more tweaking. I'll upload a patch next week to sourceforge, so we can discuss about the formatting details. Christoph |
|
From: Pieter-Tjerk de B. <p.t...@ut...> - 2014-06-06 09:40:02
|
Hello, I've given the 5.0-rc1 release candidate a try, and a few minor things caught my attention: * The .tgz source tarball doesn't seem to contain the release notes. * The section in the release notes on potentially backward-incompatible changes does not mention the change of the default colorsequence on many terminals. This change doesn't stop old scripts from working, but the output produced is different, which can be an issue in case of non-interactive use (e.g., automatic plots on a website, with surrounding text referring to colours in the plot). * The fit command in some cases interprets one column as errors, for compatibility with pre-5.0 versions, according to `help fit`. Perhaps it's an idea to change this, making 'noerror' the default, since 5.0 isn't supposed to be fully compatible anyway? That seems more systematic: then the error column is only there when explicitly indicated, and it makes the 'using' specification in case of 2 independent variables similar to what the user expects from splot. Regards, Pieter-Tjerk |
|
From: Ethan A M. <sf...@us...> - 2014-06-06 18:04:30
|
On Friday, 06 June, 2014 11:39:53 Pieter-Tjerk de Boer wrote:
> Hello,
>
> I've given the 5.0-rc1 release candidate a try, and a few minor things
> caught my attention:
>
> * The .tgz source tarball doesn't seem to contain the release notes.
Yeah, the packaging script failed to include it.
I've fixed the script so that subsequent packages will include the release notes.
> * The section in the release notes on potentially backward-incompatible
> changes does not mention the change of the default colorsequence on
> many terminals.
> This change doesn't stop old scripts from working, but the output
> produced is different, which can be an issue in case of non-interactive
> use (e.g., automatic plots on a website, with surrounding text referring
> to colours in the plot).
FYI the old behavior is available via "set colors classic".
> * The fit command in some cases interprets one column as errors, for
> compatibility with pre-5.0 versions, according to `help fit`.
> Perhaps it's an idea to change this, making 'noerror' the default,
> since 5.0 isn't supposed to be fully compatible anyway?
> That seems more systematic: then the error column is only there when
> explicitly indicated, and it makes the 'using' specification in case
> of 2 independent variables similar to what the user expects from splot.
I find myself somewhat by the new keywords also.
The v5 docs appear contradictory.
First it says:
If specified using the `errors` or `zerrors` keyword, the last column `s` is
interpreted as the standard deviation of the corresponding z value and is
used to compute a weight for the datum, 1/s**2. Otherwise, all data points
are weighted equally, with a weight of one.
That appears to say that "noerror" is the default.
But then later it says
[...] this means that you always have to supply z-errors s in a fit with two
independent variables x, y if you do not specify the `{no}error` keyword.
which appears to say that "noerror" is _not_ the default, at least for the 3D
case. Hence my confusion. Do the keywords mean different things in
the 2D, 3D, and ND cases?
For me the most useful statement in the v5 docs was that the "yerror"
keyword made fit work analogously to "plot with yerrorbars".
Perhaps either the documentation or the keywords themselves could
be made to match better with "plot/splot" commands?
> Regards,
> Pieter-Tjerk
Thanks for the feedback.
Ethan
|
|
From: Pieter-Tjerk de B. <p.t...@ut...> - 2014-06-15 19:18:30
Attachments:
fit-doc-and-noerrors.diff
|
On Fri, Jun 06, 2014 at 11:03:52AM -0700, Ethan A Merritt wrote:
> > * The fit command in some cases interprets one column as errors, for
> > compatibility with pre-5.0 versions, according to `help fit`.
> > Perhaps it's an idea to change this, making 'noerror' the default,
> > since 5.0 isn't supposed to be fully compatible anyway?
> > That seems more systematic: then the error column is only there when
> > explicitly indicated, and it makes the 'using' specification in case
> > of 2 independent variables similar to what the user expects from splot.
>
> I find myself somewhat by the new keywords also.
> The v5 docs appear contradictory.
Hmm, indeed.
And there's more: it doesn't even describe the new `errors` keyword,
nor the new possibilities it offers (namely giving error estimates not
only for the dependent but also for the independent variables). The
rest of the text seems a bit confused; one sentence actually appears
twice in two different paragraphs ("there must be two more `using`
... one variable").
> which appears to say that "noerror" is _not_ the default, at least for the 3D
> case. Hence my confusion. Do the keywords mean different things in
> the 2D, 3D, and ND cases?
As far as I could find out, they mean the same.
Actually, "xerror", "yerror" and "zerror" are effectively all the same
as "errors z", only for different cases.
> For me the most useful statement in the v5 docs was that the "yerror"
> keyword made fit work analogously to "plot with yerrorbars".
Same for "xyerror" and "with xyerrorbars"; but "xerror" is _not_
analogous to "with xerrorbars".
In fact, I wonder whether it wouldn't be better to remove "xerror",
since it doesn't seem to have much purpose, and may be confusing.
While playing around with this, I also ran into a few bugs that
were due to variables not being properly reinitialized:
- repeatedly giving a command like:
fit a*x+b 'tt.dat' u 1:2:3 errors x,z via a,b
gives different error messages each time;
- the command:
fit a*x+b 'tt.dat' u 1:2:3 errors x via a,b
complains (rightfully) that z errors need to be given, but doesn't
complain about it if one previously issued a fit command that _did_
have z errors.
> Perhaps either the documentation or the keywords themselves could
> be made to match better with "plot/splot" commands?
Attached is a patch which makes the following changes:
- proper initialization of err_cols and num_errors;
- noerror is now the default; this is incompatible with pre-5.0, but
makes things more systematic (and match better with the splot command
in case of 3D-fits);
- rewrite of the `fit` documentation, to match the new default meaning
of the data columns, to explain the new errors options, and also to
improve clarity on a few other aspects.
But of course, I don't know whether there is consensus about breaking
compatibility with pre-5.0 this way.
Regards,
Pieter-Tjerk
|
