gnuplot-beta — Developers and beta testers of new gnuplot code

Re: Request to rename version.h

[Ethan M. (UW) <me...@uw...>]

On Sunday, 03 November 2019 18:56:09 Ethan Merritt wrote:
> > /opt/local/libexec/llvm-9.0/bin/../include/c++/v1/cstddef:37:
> > ../version:1:1: error: expected unqualified-id
> > 5.2
> > ^
> > 
> > > And frankly, I cannot believe any tool vendor nor standardization body
> > > would be so daft as to assume that <version.h> is a suitable name for a
> > > new standard header.  There must be roughly several million pre-existing
> > > user header files by that name out there that this would trample on.
> > 
> > Well ... the fact is that the build breaks when using the latest clang
> > compiler. And on old OS versions this is now the default behaviour in
> > MacPorts, so gnuplot build is currently broken for many of our users.
>  
> I can build from current git head using clang 9.0.0 without any problem.
> My wxgtk version is 3.1
>  
> On my system cstddef.h does not refer to VERSION anywhere.
> However that file came from gcc, not from llvm.
> I don't know where that gets us in debugging your problem,
> but it seems not to be a problem with clang per se.
>  
> Note that the syntax
>    #include <FILENAME>
> should only look in "a standard list of system directories".
> I do not know where that standard list is defined, but in any
> case it should not include the current working directory.
> So a local file named VERSION would not conflict.
>  
> 	Ethan
>  
>  
> > 
> > It hardly makes sense to start pointing fingers about who was supposed
> > to figure out that VERSION would be loaded first when one of the
> > compiler's own files says "#include <version>" ...
> > 
> > Mojca

Upon further reflection...
Your error message cannot be coming from a filename.
It is the VERSION symbol itself that may be an issue.
Can you compile a junk program?

    clang -o helloworld -DVERSION="6.7" helloworld.cpp

If defining VERSION breaks your compile chain that is clearly
a problem, but it has nothing to do with gnuplot file names.

	Ethan

-- 
Ethan A Merritt, Dept of Biochemistry
Biomolecular Structure Center,  K-428 Health Sciences Bldg
MS 357742,   University of Washington, Seattle 98195-7742

Re: Request to rename version.h

[Ethan M. (UW) <me...@uw...>]

On Sunday, 03 November 2019 22:57:19 Mojca Miklavec wrote:
> On Sun, 3 Nov 2019 at 22:33, Hans-Bernhard Bröker wrote:
> > Am 03.11.2019 um 21:48 schrieb Mojca Miklavec:
> > > Dear developers,
> > >
> > > I would like to request renaming the file version.h (and potentially
> > > version.c) to something else, for example gnuplot_version.h.
> > >
> > > The problem is that C++20 introduced a standard header version.h:
> > >     https://en.cppreference.com/w/cpp/header/version
> >
> > That's not actually what that reference says.  That header is called
> > <version>, not <version.h>.
> 
> I'm sorry, I misread the error report.
> 
> The problem is in fact not with version.h, but with VERSION (please
> note that files are case insensitive on macOS).
> 
> I tried to reproduce the problem locally, and here's what I get:
> 
> /opt/local/bin/clang-mp-9.0  -pipe -Os -F/opt/local/Library/Frameworks
> -arch x86_64 -ObjC  -L/opt/local/lib -Wl,-rpath -Wl,/opt/local/lib
> -L/opt/local/lib -Wl,-headerpad_max_install_names
> -F/opt/local/Library/Frameworks -arch x86_64 -L/opt/local/lib -lcerf
> -framework Foundation -framework AquaTerm -L/opt/local/lib
> -L/opt/local/lib -Wl,-headerpad_max_install_names -L/opt/local/lib -o
> bf_test bf_test.o -lm
> In file included from wxterminal/wxt_gui.cpp:93:
> In file included from wxterminal/wxt_gui.h:75:
> In file included from
> /opt/local/Library/Frameworks/wxWidgets.framework/Versions/wxWidgets/3.0/include/wx-3.0/wx/wxprec.h:12:
> In file included from
> /opt/local/Library/Frameworks/wxWidgets.framework/Versions/wxWidgets/3.0/include/wx-3.0/wx/defs.h:734:
> In file included from
> /opt/local/Library/Frameworks/wxWidgets.framework/Versions/wxWidgets/3.0/include/wx-3.0/wx/debug.h:14:
> In file included from /usr/include/assert.h:44:
> In file included from
> /opt/local/libexec/llvm-9.0/bin/../include/c++/v1/stdlib.h:100:
> In file included from
> /opt/local/libexec/llvm-9.0/bin/../include/c++/v1/math.h:337:
> In file included from
> /opt/local/libexec/llvm-9.0/bin/../include/c++/v1/type_traits:417:
> In file included from
> /opt/local/libexec/llvm-9.0/bin/../include/c++/v1/cstddef:37:
> ../version:1:1: error: expected unqualified-id
> 5.2
> ^
> 
> > And frankly, I cannot believe any tool vendor nor standardization body
> > would be so daft as to assume that <version.h> is a suitable name for a
> > new standard header.  There must be roughly several million pre-existing
> > user header files by that name out there that this would trample on.
> 
> Well ... the fact is that the build breaks when using the latest clang
> compiler. And on old OS versions this is now the default behaviour in
> MacPorts, so gnuplot build is currently broken for many of our users.

I can build from current git head using clang 9.0.0 without any problem.
My wxgtk version is 3.1

On my system cstddef.h does not refer to VERSION anywhere.
However that file came from gcc, not from llvm.
I don't know where that gets us in debugging your problem,
but it seems not to be a problem with clang per se.

Note that the syntax
   #include <FILENAME>
should only look in "a standard list of system directories".
I do not know where that standard list is defined, but in any
case it should not include the current working directory.
So a local file named VERSION would not conflict.

	Ethan


> 
> It hardly makes sense to start pointing fingers about who was supposed
> to figure out that VERSION would be loaded first when one of the
> compiler's own files says "#include <version>" ...
> 
> Mojca
> 
> 
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> Membership management via: https://lists.sourceforge.net/lists/listinfo/gnuplot-beta

-- 
Ethan A Merritt, Dept of Biochemistry
Biomolecular Structure Center,  K-428 Health Sciences Bldg
MS 357742,   University of Washington, Seattle 98195-7742

Re: Request to rename version.h

[Mojca M. <moj...@gm...>]

On Sun, 3 Nov 2019 at 22:33, Hans-Bernhard Bröker wrote:
> Am 03.11.2019 um 21:48 schrieb Mojca Miklavec:
> > Dear developers,
> >
> > I would like to request renaming the file version.h (and potentially
> > version.c) to something else, for example gnuplot_version.h.
> >
> > The problem is that C++20 introduced a standard header version.h:
> >     https://en.cppreference.com/w/cpp/header/version
>
> That's not actually what that reference says.  That header is called
> <version>, not <version.h>.

I'm sorry, I misread the error report.

The problem is in fact not with version.h, but with VERSION (please
note that files are case insensitive on macOS).

I tried to reproduce the problem locally, and here's what I get:

/opt/local/bin/clang-mp-9.0  -pipe -Os -F/opt/local/Library/Frameworks
-arch x86_64 -ObjC  -L/opt/local/lib -Wl,-rpath -Wl,/opt/local/lib
-L/opt/local/lib -Wl,-headerpad_max_install_names
-F/opt/local/Library/Frameworks -arch x86_64 -L/opt/local/lib -lcerf
-framework Foundation -framework AquaTerm -L/opt/local/lib
-L/opt/local/lib -Wl,-headerpad_max_install_names -L/opt/local/lib -o
bf_test bf_test.o -lm
In file included from wxterminal/wxt_gui.cpp:93:
In file included from wxterminal/wxt_gui.h:75:
In file included from
/opt/local/Library/Frameworks/wxWidgets.framework/Versions/wxWidgets/3.0/include/wx-3.0/wx/wxprec.h:12:
In file included from
/opt/local/Library/Frameworks/wxWidgets.framework/Versions/wxWidgets/3.0/include/wx-3.0/wx/defs.h:734:
In file included from
/opt/local/Library/Frameworks/wxWidgets.framework/Versions/wxWidgets/3.0/include/wx-3.0/wx/debug.h:14:
In file included from /usr/include/assert.h:44:
In file included from
/opt/local/libexec/llvm-9.0/bin/../include/c++/v1/stdlib.h:100:
In file included from
/opt/local/libexec/llvm-9.0/bin/../include/c++/v1/math.h:337:
In file included from
/opt/local/libexec/llvm-9.0/bin/../include/c++/v1/type_traits:417:
In file included from
/opt/local/libexec/llvm-9.0/bin/../include/c++/v1/cstddef:37:
../version:1:1: error: expected unqualified-id
5.2
^

> And frankly, I cannot believe any tool vendor nor standardization body
> would be so daft as to assume that <version.h> is a suitable name for a
> new standard header.  There must be roughly several million pre-existing
> user header files by that name out there that this would trample on.

Well ... the fact is that the build breaks when using the latest clang
compiler. And on old OS versions this is now the default behaviour in
MacPorts, so gnuplot build is currently broken for many of our users.

It hardly makes sense to start pointing fingers about who was supposed
to figure out that VERSION would be loaded first when one of the
compiler's own files says "#include <version>" ...

Mojca

Re: Request to rename version.h

[Hans-Bernhard B. <HBB...@t-...>]

Am 03.11.2019 um 21:48 schrieb Mojca Miklavec:
> Dear developers,
> 
> I would like to request renaming the file version.h (and potentially
> version.c) to something else, for example gnuplot_version.h.
> 
> The problem is that C++20 introduced a standard header version.h:
>     https://en.cppreference.com/w/cpp/header/version

That's not actually what that reference says.  That header is called
<version>, not <version.h>.

And frankly, I cannot believe any tool vendor nor standardization body
would be so daft as to assume that <version.h> is a suitable name for a
new standard header.  There must be roughly several million pre-existing
user header files by that name out there that this would trample on.

Request to rename version.h

[Mojca M. <moj...@gm...>]

Dear developers,

I would like to request renaming the file version.h (and potentially
version.c) to something else, for example gnuplot_version.h.

The problem is that C++20 introduced a standard header version.h:
    https://en.cppreference.com/w/cpp/header/version
which is now causing issues when using a C++20-compliant compiler for gnuplot.

We need to patch gnuplot we ship inside a package manager as soon as
possible, but ideally I would like to use the same patch as upstream.

Thank you very much,
    Mojca

Re: Decoupling contours and zrange

[Ethan M. (UW) <me...@uw...>]

On Wednesday, 18 September 2019 12:06:09 Dima Kogan wrote:
> Thanks for the comments. Notes inline
> 
> Ethan Merritt (UW) <me...@uw...> writes:
> 
> > On Wednesday, 18 September 2019 10:37:15 Dima Kogan wrote:
> >
> > Are you saying that you have two sets of data, each with its own range
> > on z? That is a separate problem I will come back to at the end [*].
> > For now I assume the two data sets are on the same scale.
> 
> Yes, they're different: the z used for the contours is unrelated in what
> I want plotted on the z.
> 
> What I'm REALLY trying to do is to visualize a 4D function that maps
> (x,y,a) -> b. There's no clear "right" way to do this in any plotting
> tool. I'd like to do this with several stacked contours, at some preset
> values of a: a0,a1,a2, .... So in each a = a* slice I'd have a 3D
> function (x,y) -> b. And for each such slice I want to generate a
> contour on the xy plane, rendering the contour at z = a*. Multiplot is
> needed for the multiple contours, but that's a whole other issue. As you
> can see, the contours are generated by looking at the value of b, while
> the plot shows values of a on the z axis. Any other suggestions for
> visualizing such 4D functions welcome.

That sounds very close to the new voxel-based options in 5.3.
One such visualization is the animation in "voxel.dem"
The on-line collection has a static image of the end point, but
if you run the demo locally you'll see that it steps through the
volumne one plane at a time.
    http://gnuplot.sourceforge.net/demo_5.3/voxel.html

Your description sounds like the same thing with contours rather
than a heatmap.

I would do it by precalculating the contour slices one by one and
then either stepping through them or superimposing them.
Something like this:
    set contour
    set cntrparam levels increment -1, .1, 1
    unset surface
    f1(x,y) = sin(x)*cos(y)
    f2(x,y) = sin(x+.1)*cos(y-.1)
    f3(x,y) = sin(x+.2)*cos(y-.2)
    set table $slice1
    splot [-5:5][-5:5] '++' using 1:2:(f1($1,$2)) with lines
    set table $slice2
    splot [-5:5][-5:5] '++' using 1:2:(f2($1,$2)) with lines
    set table $slice3
    splot [-5:5][-5:5] '++' using 1:2:(f3($1,$2)) with lines
    unset table

    unset contour
    set surface
    splot $slice1 using 1:2:(0.0):3 with lines lc palette, \
          $slice2 using 1:2:(0.1):3 with lines lc palette, \
          $slice3 using 1:2:(0.2):3 with lines lc palette


There's something odd about one of those contours but you get the idea.


> > The contour plot is generated by contouring the data. If you restrict
> > the data to the subset in a particular range then you get contours of
> > only that subset.
> 
> Yes. But the expectation was that zrange restricts the visualization,
> not the data. So the full set of data would be used in the contouring,
> and the zrange would only control how stuff is drawn.

[shrug] I guess it depends on how you think about it.
Consider the 9th plot (3rd from the end) in this demo:
    http://gnuplot.sourceforge.net/demo_5.2/sampling.html
    
Limiting the axis range of each plot controls which data is plotted
where, but the overall axis ranges on x y z for the plot as a whole
encompass all the pieces.

	Ethan

Re: Decoupling contours and zrange

[Dima K. <gn...@di...>]

Thanks for the comments. Notes inline

Ethan Merritt (UW) <me...@uw...> writes:

> On Wednesday, 18 September 2019 10:37:15 Dima Kogan wrote:
>
> Are you saying that you have two sets of data, each with its own range
> on z? That is a separate problem I will come back to at the end [*].
> For now I assume the two data sets are on the same scale.

Yes, they're different: the z used for the contours is unrelated in what
I want plotted on the z.

What I'm REALLY trying to do is to visualize a 4D function that maps
(x,y,a) -> b. There's no clear "right" way to do this in any plotting
tool. I'd like to do this with several stacked contours, at some preset
values of a: a0,a1,a2, .... So in each a = a* slice I'd have a 3D
function (x,y) -> b. And for each such slice I want to generate a
contour on the xy plane, rendering the contour at z = a*. Multiplot is
needed for the multiple contours, but that's a whole other issue. As you
can see, the contours are generated by looking at the value of b, while
the plot shows values of a on the z axis. Any other suggestions for
visualizing such 4D functions welcome.


> The contour plot is generated by contouring the data. If you restrict
> the data to the subset in a particular range then you get contours of
> only that subset.

Yes. But the expectation was that zrange restricts the visualization,
not the data. So the full set of data would be used in the contouring,
and the zrange would only control how stuff is drawn.


> [*] If the two data sets are not on the same scale then a different
> approach is needed.  Gnuplot does not currently have a separate z2
> axis analogous to x2 or y2.  You can, however, introduce a scaling
> function into the plot command:
>
>   splot $data1 using 1:2:3 with lines nosurface title "contours", \
>         $data2 using 1:2:(scale($3)) with points nocontour
>
> However the commands as shown would leave you with the wrong labels
> along z.  If you apply the scale to the contoured data instead then
> the z axis labels would be correct but the contour labels would be
> wrong.  Either way you would have to manually correct the values in
> the labels.
>
> Modifying gnuplot to support a z2 axis would be possible, but we'd
> have to agree on the desired representation.  x2 and y2 are drawn
> on the opposite side of the plot from x1 and y1 respectively.
> Would z2 be drawn on a separate [new] vertical line from z1?
> Or would z2 consist only of a second set of z-axis tic labels,
> presumably in a distinct color?

Hmmm. A separate z2 axis would solve this, and maybe supporting that
eventually would be nice, but for THIS particular issue it feels like a
workaround.

Presumably in the gnuplot guts we have some for of this logic:

1. ingest data
2. throw away all data outside the xrange, yrange, zrange
3. make contours
4. draw

Can it be updated to

1. ingest data
2. make contours
3. throw away all data outside the xrange, yrange, zrange
4. draw

Or maybe

1.   ingest data
1.5. throw away all data outside the xrange, yrange
2.   make contours
3.   throw away all data outside the zrange
4.   draw

Here when looking at contours in step 3, we'd use the z of where the
contours are drawn, not the data used to generate them. So for contours
on the xyplane we'd use the z coordinate of the xyplane.

It's very possible that I'm oversimplifying everything here, and that
there're lots of details that make such a change impossible. But it
feels a lot more like what I (as a user) thinks zrange should do: act on
what I see rendered against the z axis.

Thanks

Re: Decoupling contours and zrange

[Ethan M. (UW) <me...@uw...>]

On Wednesday, 18 September 2019 10:37:15 Dima Kogan wrote:
> Hi. I'm trying to make a plot that's not working because I'm running
> into some assumptions gnuplot is making. Help sought.
> 
> I want to make a 3D plot that contains contours on the xyplane AND ALSO
> contains other data (points, say) in the xyz space. The contours are
> rendered on the z=0 plane, so from the plot viewer's perspective this is
> unrelated to the z axis in the plot. So I want the data on the z axis to
> be decoupled from the data used to make the contours.

Are you saying that you have two sets of data, each with its own range on z?
That is a separate problem I will come back to at the end [*].
For now I assume the two data sets are on the same scale.

> 
> Example. I can make contours from a sinusoid:
> 
>   set contour base
>   set cntrparam levels incremental -1,0.1,1
>   set samples 100,100
>   set isosamples 100,100
>   splot [-5:5][-5:5] '++' using 1:2:(sin($1)*cos($2)) with lines nosurface
> 
> This works great. It generates a 3D plot with the contours rendered on
> the z=0 plane only. Let's pretend I have other data plotted also, and
> for whatever reason I also want to
> 
>   set zrange [0:0.5]
> 
> This breaks the contours! It looks like the zrange limit is applied to
> the data before generating the contours, which sounds counter-intuitive
> to me. 

The contour plot is generated by contouring the data.  If you restrict
the data to the subset in a particular range then you get contours of 
only that subset.  

> Any suggestions about how to decouple this? Can we always use
> zrange [*:*] for the purposes of contour generation? Should we?

I do not understand what you are asking for. If you want to contour
all the data then autoscaling z is appropriate.  If you want to contour
a subset of the data then you have two options:

1) restrict the range of the data
	set zrange [min:max]

2) keep the full range of data but restrict the range of contours
    set zrange [*:*]
    set cntrparam levels incremental min, increment, max

If you want to superimpose data points outside the min:max range
then option 1 will not work but option 2 does work.


[*] If the two data sets are not on the same scale then a different
approach is needed.  Gnuplot does not currently have a separate z2
axis analogous to x2 or y2.  You can, however, introduce a scaling
function into the plot command:

  splot $data1 using 1:2:3 with lines nosurface title "contours", \
        $data2 using 1:2:(scale($3)) with points nocontour

However the commands as shown would leave you with the wrong labels
along z.  If you apply the scale to the contoured data instead then
the z axis labels would be correct but the contour labels would be
wrong.  Either way you would have to manually correct the values in
the labels.

Modifying gnuplot to support a z2 axis would be possible, but we'd
have to agree on the desired representation.  x2 and y2 are drawn
on the opposite side of the plot from x1 and y1 respectively.
Would z2 be drawn on a separate [new] vertical line from z1?
Or would z2 consist only of a second set of z-axis tic labels,
presumably in a distinct color?

	Ethan

Decoupling contours and zrange

[Dima K. <gn...@di...>]

Hi. I'm trying to make a plot that's not working because I'm running
into some assumptions gnuplot is making. Help sought.

I want to make a 3D plot that contains contours on the xyplane AND ALSO
contains other data (points, say) in the xyz space. The contours are
rendered on the z=0 plane, so from the plot viewer's perspective this is
unrelated to the z axis in the plot. So I want the data on the z axis to
be decoupled from the data used to make the contours.

Example. I can make contours from a sinusoid:

  set contour base
  set cntrparam levels incremental -1,0.1,1
  set samples 100,100
  set isosamples 100,100
  splot [-5:5][-5:5] '++' using 1:2:(sin($1)*cos($2)) with lines nosurface

This works great. It generates a 3D plot with the contours rendered on
the z=0 plane only. Let's pretend I have other data plotted also, and
for whatever reason I also want to

  set zrange [0:0.5]

This breaks the contours! It looks like the zrange limit is applied to
the data before generating the contours, which sounds counter-intuitive
to me. Any suggestions about how to decouple this? Can we always use
zrange [*:*] for the purposes of contour generation? Should we?

Thanks

Re: How big are points supposed to be?

[Dima K. <gn...@di...>]

Ethan Merritt (UW) <me...@uw...> writes:

> (1) This isn't a new conflict and it isn't the first time that the
> specific issue of point sizes came up.  That's why many (all?) terminals
> accept a "pointsize <scale-factor>" option to "set term".   So one option
> is to experiment in advance with the output formats you are likely to want,
> then adjust and save the corresponding "set term FOO pointsize BAZ"
> commands for future use.
>
> (2) Alternatively, don't use the original fixed sequence of point shapes
> at all. Instead redefine your standard set of line/point/dash properties
> in ~/.gnuplot to use character-based point shapes:
>
> 	set linetype 1 lc rgb "dark-violet" pt "✕"
> 	set linetype 2 lc rgb "#009e73" pt "⚫"
> 	set linetype 3 lc rgb "#56b4e9" pt "⚪"
> 	set linetype 4 lc rgb "#e69f00" pt "☉"
> 	set linetype 5 lc rgb "#f0e442" pt "◐"
> 	set linetype 6 lc rgb "#0072b2" pt "◔"
> 	set linetype 7 lc rgb "#e51e10" pt "□"
> 	set linetype 8 lc rgb "black"   pt "▲"
> 	set linetype 9 lc rgb "gray50"  pt "▽"

Hi. Neither of these are working for me. I'm doing this:

  set terminal pdfcairo noenhanced solid color font ",12" size 11in,8.5in
  set output "/tmp/tst.pdf"
  set grid
  set boxwidth 1
  histbin(x) = 1 * floor(0.5 + x/1)
  set pointsize .13
  set linetype 7 lc rgb "#e51e10" pt "#"
  plot '-'   notitle with points pt 7 ps 2
  1 1
  2 2
  3 3
  4 4
  5 5
  e
  set output

I tried these terminals: pdfcairo, png, postscript, x11. None of these
appear to respond to either 'set pointsize' or 'set linetype'. And
setting the pointsize in the 'set terminal' command looks like it's
generally not supported.

Suggestions? 'set pointsize' sounds like it's what I want.

Thanks.

Re: How big are points supposed to be?

[Ethan M. (UW) <me...@uw...>]

On Saturday, 13 July 2019 10:18:10 Ethan Merritt wrote:
> 
>         set linetype 1 lc rgb "dark-violet" pt "✕"
>         set linetype 2 lc rgb "#009e73" pt "⚫"
>         set linetype 3 lc rgb "#56b4e9" pt "⚪"
>         set linetype 4 lc rgb "#e69f00" pt "☉"
>         set linetype 5 lc rgb "#f0e442" pt "◐"
>         set linetype 6 lc rgb "#0072b2" pt "◔"
>         set linetype 7 lc rgb "#e51e10" pt "□"
>         set linetype 8 lc rgb "black"   pt "▲"
>         set linetype 9 lc rgb "gray50"  pt "▽"
> 

Apologies.  Some of those (pt 2,3,4) don't seem to work currently.
So that's a bug.  I will fix it.

Also the line color is not automatically used as the font color.
Also fixable.

	Ethan

Re: How big are points supposed to be?

[Ethan M. (UW) <me...@uw...>]

On Saturday, 13 July 2019 08:23:34 Dima Kogan wrote:
> Hi.
> 
> I'm observing a specific behavior that probably isn't a bug, but it's
> quite annoying. I'd like a comment.
> 
> Most of my usage of gnuplot is via the feedgnuplot tool:
> https://github.com/dkogan/feedgnuplot
> 
> Usually I'm making interactive plots (x11 terminal) as I explore the
> data. For instance, to plot 5 points with circles:
> 
>   seq 5 | feedgnuplot --with 'points pt 7 ps 2'
> 
> Eventually I'm done, and I want to make a pdf to send out in an email:
> 
>   seq 5 | feedgnuplot --with 'points pt 7 ps 2' --hardcopy whatever.pdf
> 
> This produces the same plot, but targetting a pdf file on a single
> landscape-oriented sheet of letter paper. The terminal is set up like
> this:
> 
>   set terminal pdfcairo noenhanced solid color font ",12" size 11in,8.5in
> 
> This works as expected. But the circles appear much bigger in the pdf
> than they did on the x11-terminal plot. To make the pdf look the same I
> have to manually reduce the size of the points, which is really
> annoying.
> 
> Does anybody know what the logic is governing the size of the points
> gnuplot renders? 

For some older terminals a "point" was just another character.
Introduction of characters as acceptable "point types" in version 5
was in this sense a return to the original idea.  In both old and the
new cases the size of the point scales with the font used to print the
character.

The large middle ground is handled by the generic routine do_point()
in term.c.  This routine constructs the standard sequence of point shapes
using a set of short line segments whose basic length
is taken from term->h_tic.   In other words, it assumes that the
current terminal has provided an appropriate unit size for points
in term->h_tic.

At this point things start to fall apart because different terminals
take different approaches to defining h_tic.  

PostScript, tek, hpgl and some of the other really old terminals set
h_tic to a constant value:
E.g.
	post.h:     #define PS_HTIC (PS_YMAX/80)
	win.trm:    #define WIN_HTIC (WIN_XMAX/160)

Most terminals set it based on the estimated average character width 
in the current font:
E.g.
	svg.trm:    term->h_tic = term->v_char / 2;
	cairo.trm:  term->h_tic = (unsigned int) (term->v_char/2.5);
	qt_term.c:  term->h_tic = (unsigned int) (term->v_char/2.5);
	aquaterm.trm:  term->h_tic = term->v_char / 3;

I have no idea why the ratio of h_tic to v_char varies between 2 and 3,
other than to note that the estimated character width is very empirical
and different terminals vary in how well they can estimate. That is the
purpose of the central block of boxed characters in the middle of the
output from "test" - it shows how good or bad the terminal is doing in
trying to estimate character width.

> It's somewhat arbitrary in this case: in the x11
> terminal the points stay the same size as you zoom, but with pdfcairo,
> naturally everything becomes larger as you zoom in. Is there any
> particular rationale to whatever arbitrary choice we have made to
> control this? If it's completely arbitrary, can we make a specific
> design choice, and then make the terminals agree with each other? I
> think making page-sized hardcopies produce comparable point sizes is a
> reasonable expectation. 

> Thoughts?

As usual there is a conflict between the goal of having uniform 
terminal-independent behaviour and the goal of perfect backward
compatibility.

(1) This isn't a new conflict and it isn't the first time that the 
specific issue of point sizes came up.  That's why many (all?) terminals
accept a "pointsize <scale-factor>" option to "set term".   So one option
is to experiment in advance with the output formats you are likely to want,
then adjust and save the corresponding "set term FOO pointsize BAZ"
commands for future use.

(2) Alternatively, don't use the original fixed sequence of point shapes
at all. Instead redefine your standard set of line/point/dash properties
in ~/.gnuplot to use character-based point shapes:

	set linetype 1 lc rgb "dark-violet" pt "✕"
	set linetype 2 lc rgb "#009e73" pt "⚫"
	set linetype 3 lc rgb "#56b4e9" pt "⚪"
	set linetype 4 lc rgb "#e69f00" pt "☉"
	set linetype 5 lc rgb "#f0e442" pt "◐"
	set linetype 6 lc rgb "#0072b2" pt "◔"
	set linetype 7 lc rgb "#e51e10" pt "□"
	set linetype 8 lc rgb "black"   pt "▲"
	set linetype 9 lc rgb "gray50"  pt "▽"

These will scale with the current font.  I am uncertain whether the
current code is consistent about applying "pointsize <scale>" on top 
of the font size.  That might be worth further investigation.

For normal plotting I would be inclined to go with option 2.
However if you are dealing with huge numbers of points there is a
size/time penalty for drawing each one as text rather than as
line segments.

	Ethan

How big are points supposed to be?

[Dima K. <gn...@di...>]

Hi.

I'm observing a specific behavior that probably isn't a bug, but it's
quite annoying. I'd like a comment.

Most of my usage of gnuplot is via the feedgnuplot tool:
https://github.com/dkogan/feedgnuplot

Usually I'm making interactive plots (x11 terminal) as I explore the
data. For instance, to plot 5 points with circles:

  seq 5 | feedgnuplot --with 'points pt 7 ps 2'

Eventually I'm done, and I want to make a pdf to send out in an email:

  seq 5 | feedgnuplot --with 'points pt 7 ps 2' --hardcopy whatever.pdf

This produces the same plot, but targetting a pdf file on a single
landscape-oriented sheet of letter paper. The terminal is set up like
this:

  set terminal pdfcairo noenhanced solid color font ",12" size 11in,8.5in

This works as expected. But the circles appear much bigger in the pdf
than they did on the x11-terminal plot. To make the pdf look the same I
have to manually reduce the size of the points, which is really
annoying.

Does anybody know what the logic is governing the size of the points
gnuplot renders? It's somewhat arbitrary in this case: in the x11
terminal the points stay the same size as you zoom, but with pdfcairo,
naturally everything becomes larger as you zoom in. Is there any
particular rationale to whatever arbitrary choice we have made to
control this? If it's completely arbitrary, can we make a specific
design choice, and then make the terminals agree with each other? I
think making page-sized hardcopies produce comparable point sizes is a
reasonable expectation. Thoughts?

Re: Release 5.2.7

[Achim G. <Str...@ne...>]

Ethan A Merritt writes:
> I may not understand the required test.

The problem is that I need to filter the data and there may not be any
left after that.  Having no data points unfortunately is fatal to some
of the commands I'm using later, so I need to ensure it doesn't happen
and skip those commands if necessary.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

SD adaptations for KORG EX-800 and Poly-800MkII V0.9:
http://Synth.Stromeko.net/Downloads.html#KorgSDada

Re: Release 5.2.7

[Achim G. <Str...@ne...>]

Achim Gratz writes:
> That no longer works since you're now getting an error (terminating the
> script) at the last line.  Note that you can't do something like
> exist(STATS_record) either like one could reasonably expect to work.
> Any workarounds?

Foundit, thinko on my side.  Correcting the test to

--8<---------------cut here---------------start------------->8---
stats [24*sr:24*sq] data using ($4==10?t($1):1/0):($2) nooutput
TEST=exists("STATS_records")
--8<---------------cut here---------------end--------------->8---

actually works as expected.  I was missing the quotes originally.  Now,
what's still left is to suppress the warning about no valid data points
from the stats invocation.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

SD adaptation for Waldorf rackAttack V1.04R1:
http://Synth.Stromeko.net/Downloads.html#WaldorfSDada

Re: Release 5.2.7

[Ethan A M. <merritt@u.washington.edu>]

On Thursday, June 6, 2019 11:30:40 AM PDT Achim Gratz wrote:
> Ethan Merritt (UW) writes:
> > * CHANGE clear STATS_* variables before performing analysis
> 
> It took me a while to relaize, but that particular change killed on of
> my scripts.  That is using data that doesn't always exist, so I have to
> test for that like this:
> 
> --8<---------------cut here---------------start------------->8---
> STATS_records=0
> stats [24*sr:24*sq] data using ($4==10?t($1):1/0):($2) nooutput
> TEST=STATS_records>0  
> --8<---------------cut here---------------end--------------->8---
> 
> That gives you a warning from stats, but you could then skip additional
> code using the non-existing data (that would error out) based on the
> result in TEST.
> 
> That no longer works since you're now getting an error (terminating the
> script) at the last line.  Note that you can't do something like
> exist(STATS_record) either like one could reasonably expect to work.
> Any workarounds?
> 
> 
> Regards,
> Achim.

I may not understand the required test.  The following works for me:

datafile = "whatever"

 if (exists("STATS_records")) { print 'got it already' }
else { stats datafile }

I would probably use an explicit name rather than STATS:

if (exists("MYDAT_records")) { print 'already did MYDATA' }
else { stats datafile name "MYDAT" }
show var MYDAT

Is the problem that STATS_records might exist for reasons other
than having run a previous STATS command?   That was exactly
the sort of confusion that the change you mention was intended
to prevent.

	Ethan





	Ethan

Re: Release 5.2.7

[Achim G. <Str...@ne...>]

Ethan Merritt (UW) writes:
> * CHANGE clear STATS_* variables before performing analysis

It took me a while to relaize, but that particular change killed on of
my scripts.  That is using data that doesn't always exist, so I have to
test for that like this:

--8<---------------cut here---------------start------------->8---
STATS_records=0
stats [24*sr:24*sq] data using ($4==10?t($1):1/0):($2) nooutput
TEST=STATS_records>0  
--8<---------------cut here---------------end--------------->8---

That gives you a warning from stats, but you could then skip additional
code using the non-existing data (that would error out) based on the
result in TEST.

That no longer works since you're now getting an error (terminating the
script) at the last line.  Note that you can't do something like
exist(STATS_record) either like one could reasonably expect to work.
Any workarounds?


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

SD adaptations for KORG EX-800 and Poly-800MkII V0.9:
http://Synth.Stromeko.net/Downloads.html#KorgSDada

Release 5.2.7

[Ethan M. (UW) <me...@uw...>]

Release 5.2.7 tarball and Windows binaries are ready and can be
downloaded from 

     https://sourceforge.net/projects/gnuplot/files/gnuplot/5.2.7/[1]



		GNUPLOT Version 5.2.7 Release Notes
		===================================

These release notes are for version 5.2 patchlevel 7 (5.2.7).
This release contains bug-fixes, a few changes back-ported from the
development version, and some minor new features.
The largest change is major revision to the fig and pm terminals
bringing them into line with capabilities of other version 5 terminals.

Please see the ChangeLog file for a complete list of changes made during the
course of development from 5.0 to 5.2.

Release Notes date: 29-May-2019

Changes in 5.2.7
================

* NEW "set pm3d noclipcb" will skip drawing quadrangles with color < cbmin
* NEW pm terminal supports utf8, dashed lines, bold/italic text
* NEW imaginary component of array values is available to "using" in column 3
* NEW gnuplot --slow may help use of qt terminal with slow system font server
* CHANGE splot "with points pt 0" acts like "with dots"
* CHANGE (tikz) improved default interpretation of gnuplot arrowhead style
* CHANGE teach hidden3d to handle double-headed vectors (arrowstyle "heads")
* CHANGE "unset title" or "reset" resets all title properties to default
* CHANGE font names passed to enhanced text processing may be in quotes
* CHANGE cairo terminals accept fractional font sizes
* CHANGE "plot with table" does not output trailing field separator
* CHANGE better centering for clustered histograms
* CHANGE clear STATS_* variables before performing analysis
* CHANGE cairo, libgd, and svg terminals handle LT_NODRAW by not drawing at all
* CHANGE svg terminal clickable icons are in-line data rather than external refs
* CHANGE revise space allocated for ylabel; allow text justification for ylabel
* CHANGE reduce overhead, making it feasible to have 10^6 hypertext labels
* FIX "plot with table" unnecessarily limited string column output to 60 chars 
* FIX (windows) make sure graph window is shown even if the program is "hidden"
* FIX hidden3d mode was not correctly dealing with arrowstyle backhead
* FIX sprintf in 'using' spec must not clobber numeric locale
* FIX tikz - request for polygon with 0 vertices could hang terminal
* FIX lua/tikz - do not attempt to ftruncate output being piped through stdout
* FIX tkcanvas - do not attempt to ftruncate output being piped through stdout
* FIX handle NaN values in input stream to "stats FOO matrix"
* FIX prevent extra read past the end of a datablock holding matrix data
* FIX pm - issues in box and polygon fill, (wide) lines, enhanced text, images
* FIX dropped character in piped input stream if plot window is manually closed
* FIX extraneous dots and potential segfault from splot with contour labels
* FIX boxplots - color sequence correctly starts with specified linetype
* FIX incomplete initialization led to segfault from "gnuplot -c foo.gp baz"
* FIX Allow "pm3d depthorder base" to handle 3D quadrangles with logscale z

	happy gnuplotting

		Ethan

--------
[1] https://sourceforge.net/projects/gnuplot/files/gnuplot/5.2.4/gnuplot-5.2.4.tar.gz

Aw: Testing version of Release 5.2.7

[Bastian M. <bma...@we...>]

<html><head></head><body><div style="font-family: Verdana;font-size: 12.0px;"><div>The source successfully builds on OS/2, too.&nbsp; Only the docs/plotstyles_cvt.cmd script</div>

<div>is missing from the tarball.</div>

<div>&nbsp;</div>

<div>I have uploaded a binary package to</div>

<div><a href="https://sourceforge.net/projects/gnuplot/files/gnuplot/testing/" target="_blank">https://sourceforge.net/projects/gnuplot/files/gnuplot/testing/</a></div>

<div>&nbsp;</div>

<div>Please note that this is the first OS/2 binary package since 4.6, so there still might be</div>

<div>some bugs hidden. The binary includes support for the optional gd terminals, lua and</div>

<div>iconv. The pm terminal was considerably updated for this release. The gnuplot.inf help</div>

<div>document now includes graphics. The included README.OS2 gives further details on</div>

<div>known shortcomings of the pm terminal.</div>

<div>&nbsp;</div>

<div>
<div>
<div>&nbsp;&nbsp; Bastian</div>

<div>&nbsp;</div>

<div name="quote" style="margin:10px 5px 5px 10px; padding: 10px 0 10px 10px; border-left:2px solid #C3D9E5; word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;">
<div style="margin:0 0 10px 0;"><b>Gesendet:</b>&nbsp;Dienstag, 21. Mai 2019 um 08:49 Uhr<br/>
<b>Von:</b>&nbsp;&quot;Ethan Merritt (UW)&quot; &lt;me...@uw...&gt;<br/>
<b>An:</b>&nbsp;&quot;gnuplot beta list&quot; &lt;gnu...@li...&gt;<br/>
<b>Betreff:</b>&nbsp;Testing version of Release 5.2.7</div>

<div name="quoted-content"><!--p, li {
}
-->
<div style="font-family: Monospace;font-size: 10.0pt;font-weight: 400;font-style: normal;">
<p style="margin-top: 0.0px;margin-bottom: 0.0px;margin-left: 0.0px;margin-right: 0.0px;text-indent: 0.0px;">&nbsp;</p>

<p style="margin-top: 0.0px;margin-bottom: 0.0px;margin-left: 0.0px;margin-right: 0.0px;text-indent: 0.0px;">I have placed a tarball gnuplot-5.2.7beta.tar.gz in the &quot;testing&quot; folder on SourceForge.</p>

<p style="margin-top: 0.0px;margin-bottom: 0.0px;margin-left: 0.0px;margin-right: 0.0px;text-indent: 0.0px;">&nbsp;</p>

<p style="margin-top: 0.0px;margin-bottom: 0.0px;margin-left: 0.0px;margin-right: 0.0px;text-indent: 0.0px;"><a href="https://sourceforge.net/projects/gnuplot/files/gnuplot/testing/" target="_blank">https://sourceforge.net/projects/gnuplot/files/gnuplot/testing/</a></p>

<p style="margin-top: 0.0px;margin-bottom: 0.0px;margin-left: 0.0px;margin-right: 0.0px;text-indent: 0.0px;">&nbsp;</p>

<p style="margin-top: 0.0px;margin-bottom: 0.0px;margin-left: 0.0px;margin-right: 0.0px;text-indent: 0.0px;">This version identifies as 5.2.7beta and is intended for test-builds on Windows,</p>

<p style="margin-top: 0.0px;margin-bottom: 0.0px;margin-left: 0.0px;margin-right: 0.0px;text-indent: 0.0px;">OSX, etc prior to full release of 5.2.7 at the end of the month.</p>

<p style="margin-top: 0.0px;margin-bottom: 0.0px;margin-left: 0.0px;margin-right: 0.0px;text-indent: 0.0px;">Please report and build problems before then.</p>

<p style="margin-top: 0.0px;margin-bottom: 0.0px;margin-left: 0.0px;margin-right: 0.0px;text-indent: 0.0px;">&nbsp;</p>

<p style="margin-top: 0.0px;margin-bottom: 0.0px;margin-left: 0.0px;margin-right: 0.0px;text-indent: 0.0px;">There are many more changes than is usual for a patchlevel release this late in</p>

<p style="margin-top: 0.0px;margin-bottom: 0.0px;margin-left: 0.0px;margin-right: 0.0px;text-indent: 0.0px;">the series. I do not know why, but perhaps it has taken longer than usual for</p>

<p style="margin-top: 0.0px;margin-bottom: 0.0px;margin-left: 0.0px;margin-right: 0.0px;text-indent: 0.0px;">various linux distributions to include any version of the current major release</p>

<p style="margin-top: 0.0px;margin-bottom: 0.0px;margin-left: 0.0px;margin-right: 0.0px;text-indent: 0.0px;">so end-users only recently switched to 5.2 from 5.0. Maybe.</p>

<p style="margin-top: 0.0px;margin-bottom: 0.0px;margin-left: 0.0px;margin-right: 0.0px;text-indent: 0.0px;">&nbsp;</p>

<p style="margin-top: 0.0px;margin-bottom: 0.0px;margin-left: 0.0px;margin-right: 0.0px;text-indent: 0.0px;">Ethan</p>

<p style="margin-top: 0.0px;margin-bottom: 0.0px;margin-left: 0.0px;margin-right: 0.0px;text-indent: 0.0px;">&nbsp;</p>

<p style="margin-top: 0.0px;margin-bottom: 0.0px;margin-left: 0.0px;margin-right: 0.0px;text-indent: 0.0px;">&nbsp;</p>

<p style="margin-top: 0.0px;margin-bottom: 0.0px;margin-left: 0.0px;margin-right: 0.0px;text-indent: 0.0px;">&nbsp;</p>

<p style="margin-top: 0.0px;margin-bottom: 0.0px;margin-left: 0.0px;margin-right: 0.0px;text-indent: 0.0px;">GNUPLOT Version 5.2.7 Release Notes</p>

<p style="margin-top: 0.0px;margin-bottom: 0.0px;margin-left: 0.0px;margin-right: 0.0px;text-indent: 0.0px;">===================================</p>

<p style="margin-top: 0.0px;margin-bottom: 0.0px;margin-left: 0.0px;margin-right: 0.0px;text-indent: 0.0px;">&nbsp;</p>

<p style="margin-top: 0.0px;margin-bottom: 0.0px;margin-left: 0.0px;margin-right: 0.0px;text-indent: 0.0px;">These release notes are for version 5.2 patchlevel 7 (5.2.7).</p>

<p style="margin-top: 0.0px;margin-bottom: 0.0px;margin-left: 0.0px;margin-right: 0.0px;text-indent: 0.0px;">This release contains bug-fixes, a few changes back-ported from the</p>

<p style="margin-top: 0.0px;margin-bottom: 0.0px;margin-left: 0.0px;margin-right: 0.0px;text-indent: 0.0px;">development version, and some minor new features.</p>

<p style="margin-top: 0.0px;margin-bottom: 0.0px;margin-left: 0.0px;margin-right: 0.0px;text-indent: 0.0px;">The largest change is a revised fig terminal that brings it into line</p>

<p style="margin-top: 0.0px;margin-bottom: 0.0px;margin-left: 0.0px;margin-right: 0.0px;text-indent: 0.0px;">with capabilities of other version 5 terminals.</p>

<p style="margin-top: 0.0px;margin-bottom: 0.0px;margin-left: 0.0px;margin-right: 0.0px;text-indent: 0.0px;">&nbsp;</p>

<p style="margin-top: 0.0px;margin-bottom: 0.0px;margin-left: 0.0px;margin-right: 0.0px;text-indent: 0.0px;">Please see the ChangeLog file for a complete list of changes made during the</p>

<p style="margin-top: 0.0px;margin-bottom: 0.0px;margin-left: 0.0px;margin-right: 0.0px;text-indent: 0.0px;">course of development from 5.0 to 5.2.</p>

<p style="margin-top: 0.0px;margin-bottom: 0.0px;margin-left: 0.0px;margin-right: 0.0px;text-indent: 0.0px;">&nbsp;</p>

<p style="margin-top: 0.0px;margin-bottom: 0.0px;margin-left: 0.0px;margin-right: 0.0px;text-indent: 0.0px;">Release Notes date: 14-May-2019</p>

<p style="margin-top: 0.0px;margin-bottom: 0.0px;margin-left: 0.0px;margin-right: 0.0px;text-indent: 0.0px;">&nbsp;</p>

<p style="margin-top: 0.0px;margin-bottom: 0.0px;margin-left: 0.0px;margin-right: 0.0px;text-indent: 0.0px;">Changes in 5.2.7</p>

<p style="margin-top: 0.0px;margin-bottom: 0.0px;margin-left: 0.0px;margin-right: 0.0px;text-indent: 0.0px;">================</p>

<p style="margin-top: 0.0px;margin-bottom: 0.0px;margin-left: 0.0px;margin-right: 0.0px;text-indent: 0.0px;">&nbsp;</p>

<p style="margin-top: 0.0px;margin-bottom: 0.0px;margin-left: 0.0px;margin-right: 0.0px;text-indent: 0.0px;">* NEW &quot;set pm3d noclipcb&quot; will skip drawing quadrangles with color &lt; cbmin</p>

<p style="margin-top: 0.0px;margin-bottom: 0.0px;margin-left: 0.0px;margin-right: 0.0px;text-indent: 0.0px;">* NEW pm terminal supports utf8, dashed lines, bold/italic text</p>

<p style="margin-top: 0.0px;margin-bottom: 0.0px;margin-left: 0.0px;margin-right: 0.0px;text-indent: 0.0px;">* NEW imaginary component of array values is available to &quot;using&quot; in column 3</p>

<p style="margin-top: 0.0px;margin-bottom: 0.0px;margin-left: 0.0px;margin-right: 0.0px;text-indent: 0.0px;">* NEW gnuplot --slow may help use of qt terminal with slow system font server</p>

<p style="margin-top: 0.0px;margin-bottom: 0.0px;margin-left: 0.0px;margin-right: 0.0px;text-indent: 0.0px;">* CHANGE splot &quot;with points pt 0&quot; acts like &quot;with dots&quot;</p>

<p style="margin-top: 0.0px;margin-bottom: 0.0px;margin-left: 0.0px;margin-right: 0.0px;text-indent: 0.0px;">* CHANGE (tikz) improved default interpretation of gnuplot arrowhead style</p>

<p style="margin-top: 0.0px;margin-bottom: 0.0px;margin-left: 0.0px;margin-right: 0.0px;text-indent: 0.0px;">* CHANGE teach hidden3d to handle double-headed vectors (arrowstyle &quot;heads&quot;)</p>

<p style="margin-top: 0.0px;margin-bottom: 0.0px;margin-left: 0.0px;margin-right: 0.0px;text-indent: 0.0px;">* CHANGE &quot;unset title&quot; or &quot;reset&quot; resets all title properties to default</p>

<p style="margin-top: 0.0px;margin-bottom: 0.0px;margin-left: 0.0px;margin-right: 0.0px;text-indent: 0.0px;">* CHANGE font names passed to enhanced text processing may be in quotes</p>

<p style="margin-top: 0.0px;margin-bottom: 0.0px;margin-left: 0.0px;margin-right: 0.0px;text-indent: 0.0px;">* CHANGE cairo terminals accept fractional font sizes</p>

<p style="margin-top: 0.0px;margin-bottom: 0.0px;margin-left: 0.0px;margin-right: 0.0px;text-indent: 0.0px;">* CHANGE &quot;plot with table&quot; does not output trailing field separator</p>

<p style="margin-top: 0.0px;margin-bottom: 0.0px;margin-left: 0.0px;margin-right: 0.0px;text-indent: 0.0px;">* CHANGE better centering for clustered histograms</p>

<p style="margin-top: 0.0px;margin-bottom: 0.0px;margin-left: 0.0px;margin-right: 0.0px;text-indent: 0.0px;">* CHANGE clear STATS_* variables before performing analysis</p>

<p style="margin-top: 0.0px;margin-bottom: 0.0px;margin-left: 0.0px;margin-right: 0.0px;text-indent: 0.0px;">* CHANGE cairo, libgd, and svg terminals handle LT_NODRAW by not drawing at all</p>

<p style="margin-top: 0.0px;margin-bottom: 0.0px;margin-left: 0.0px;margin-right: 0.0px;text-indent: 0.0px;">* CHANGE svg terminal clickable icons are in-line data rather than external refs</p>

<p style="margin-top: 0.0px;margin-bottom: 0.0px;margin-left: 0.0px;margin-right: 0.0px;text-indent: 0.0px;">* CHANGE revise space allocated for ylabel; allow text justification for ylabel</p>

<p style="margin-top: 0.0px;margin-bottom: 0.0px;margin-left: 0.0px;margin-right: 0.0px;text-indent: 0.0px;">* CHANGE reduce overhead, making it feasible to have 10^6 hypertext labels</p>

<p style="margin-top: 0.0px;margin-bottom: 0.0px;margin-left: 0.0px;margin-right: 0.0px;text-indent: 0.0px;">* FIX &quot;plot with table&quot; unnecessarily limited string column output to 60 chars</p>

<p style="margin-top: 0.0px;margin-bottom: 0.0px;margin-left: 0.0px;margin-right: 0.0px;text-indent: 0.0px;">* FIX (windows) make sure graph window is shown even if the program is &quot;hidden&quot;</p>

<p style="margin-top: 0.0px;margin-bottom: 0.0px;margin-left: 0.0px;margin-right: 0.0px;text-indent: 0.0px;">* FIX hidden3d mode was not correctly dealing with arrowstyle backhead</p>

<p style="margin-top: 0.0px;margin-bottom: 0.0px;margin-left: 0.0px;margin-right: 0.0px;text-indent: 0.0px;">* FIX sprintf in &#39;using&#39; spec must not clobber numeric locale</p>

<p style="margin-top: 0.0px;margin-bottom: 0.0px;margin-left: 0.0px;margin-right: 0.0px;text-indent: 0.0px;">* FIX tikz - request for polygon with 0 vertices could hang terminal</p>

<p style="margin-top: 0.0px;margin-bottom: 0.0px;margin-left: 0.0px;margin-right: 0.0px;text-indent: 0.0px;">* FIX lua/tikz - do not attempt to ftruncate output being piped through stdout</p>

<p style="margin-top: 0.0px;margin-bottom: 0.0px;margin-left: 0.0px;margin-right: 0.0px;text-indent: 0.0px;">* FIX tkcanvas - do not attempt to ftruncate output being piped through stdout</p>

<p style="margin-top: 0.0px;margin-bottom: 0.0px;margin-left: 0.0px;margin-right: 0.0px;text-indent: 0.0px;">* FIX handle NaN values in input stream to &quot;stats FOO matrix&quot;</p>

<p style="margin-top: 0.0px;margin-bottom: 0.0px;margin-left: 0.0px;margin-right: 0.0px;text-indent: 0.0px;">* FIX prevent extra read past the end of a datablock holding matrix data</p>

<p style="margin-top: 0.0px;margin-bottom: 0.0px;margin-left: 0.0px;margin-right: 0.0px;text-indent: 0.0px;">* FIX pm - issues in box and polygon fill, (wide) lines, enhanced text, images</p>

<p style="margin-top: 0.0px;margin-bottom: 0.0px;margin-left: 0.0px;margin-right: 0.0px;text-indent: 0.0px;">* FIX dropped character in piped input stream if plot window is manually closed</p>

<p style="margin-top: 0.0px;margin-bottom: 0.0px;margin-left: 0.0px;margin-right: 0.0px;text-indent: 0.0px;">* FIX extraneous dots and potential segfault from splot with contour labels</p>

<p style="margin-top: 0.0px;margin-bottom: 0.0px;margin-left: 0.0px;margin-right: 0.0px;text-indent: 0.0px;">* FIX boxplots - color sequence correctly starts with specified linetype</p>

<p style="margin-top: 0.0px;margin-bottom: 0.0px;margin-left: 0.0px;margin-right: 0.0px;text-indent: 0.0px;">* FIX incomplete initialization led to segfault from &quot;gnuplot -c foo.gp baz&quot;</p>

<p style="margin-top: 0.0px;margin-bottom: 0.0px;margin-left: 0.0px;margin-right: 0.0px;text-indent: 0.0px;">* FIX Allow &quot;pm3d depthorder base&quot; to handle 3D quadrangles with logscale z</p>

<p style="margin-top: 0.0px;margin-bottom: 0.0px;margin-left: 0.0px;margin-right: 0.0px;text-indent: 0.0px;">&nbsp;</p>

<p style="margin-top: 0.0px;margin-bottom: 0.0px;margin-left: 0.0px;margin-right: 0.0px;text-indent: 0.0px;">&nbsp;</p>
_______________________________________________ gnuplot-beta mailing list gnu...@li... Membership management via: <a href="https://lists.sourceforge.net/lists/listinfo/gnuplot-beta" target="_blank">https://lists.sourceforge.net/lists/listinfo/gnuplot-beta</a></div>
</div>
</div>
</div>
</div></div></body></html>

Windows binary packages for Testing (Re: Testing version of Release 5.2.7)

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

I have uploaded testing windows binary packages gnuplot 5.2.7 beta.

https://sourceforge.net/projects/gnuplot/files/gnuplot/testing/

If you have find problem, please report here.

Tatsuro

----- Original Message -----
>From: Ethan Merritt (UW)
>To: gnuplot beta list 
>Date: 2019/5/21, Tue 15:49
>Subject: Testing version of Release 5.2.7
> 
>
> 
>I have placed a tarball gnuplot-5.2.7beta.tar.gz in the "testing" folder on SourceForge.
> 
>https://sourceforge.net/projects/gnuplot/files/gnuplot/testing/
> 
>This version identifies as 5.2.7beta and is intended for test-builds on Windows,
>OSX, etc prior to full release of 5.2.7 at the end of the month.
>Please report and build problems before then.
> 
>There are many more changes than is usual for a patchlevel release this late in 
>the series.  I do not know why, but perhaps it has taken longer than usual for
>various linux distributions to include any version of the current major release
>so end-users only recently switched to 5.2 from 5.0.  Maybe.
> 
>Ethan
> 
> 
> 
>GNUPLOT Version 5.2.7 Release Notes
>===================================
> 
>These release notes are for version 5.2 patchlevel 7 (5.2.7).
>This release contains bug-fixes, a few changes back-ported from the
>development version, and some minor new features.
>The largest change is a revised fig terminal that brings it into line
>with capabilities of other version 5 terminals.
> 
>Please see the ChangeLog file for a complete list of changes made during the
>course of development from 5.0 to 5.2.
> 
>Release Notes date: 14-May-2019
> 
>Changes in 5.2.7
>================
> 
>* NEW "set pm3d noclipcb" will skip drawing quadrangles with color < cbmin
>* NEW pm terminal supports utf8, dashed lines, bold/italic text
>* NEW imaginary component of array values is available to "using" in column 3
>* NEW gnuplot --slow may help use of qt terminal with slow system font server
>* CHANGE splot "with points pt 0" acts like "with dots"
>* CHANGE (tikz) improved default interpretation of gnuplot arrowhead style
>* CHANGE teach hidden3d to handle double-headed vectors (arrowstyle "heads")
>* CHANGE "unset title" or "reset" resets all title properties to default
>* CHANGE font names passed to enhanced text processing may be in quotes
>* CHANGE cairo terminals accept fractional font sizes
>* CHANGE "plot with table" does not output trailing field separator
>* CHANGE better centering for clustered histograms
>* CHANGE clear STATS_* variables before performing analysis
>* CHANGE cairo, libgd, and svg terminals handle LT_NODRAW by not drawing at all
>* CHANGE svg terminal clickable icons are in-line data rather than external refs
>* CHANGE revise space allocated for ylabel; allow text justification for ylabel
>* CHANGE reduce overhead, making it feasible to have 10^6 hypertext labels
>* FIX "plot with table" unnecessarily limited string column output to 60 chars 
>* FIX (windows) make sure graph window is shown even if the program is "hidden"
>* FIX hidden3d mode was not correctly dealing with arrowstyle backhead
>* FIX sprintf in 'using' spec must not clobber numeric locale
>* FIX tikz - request for polygon with 0 vertices could hang terminal
>* FIX lua/tikz - do not attempt to ftruncate output being piped through stdout
>* FIX tkcanvas - do not attempt to ftruncate output being piped through stdout
>* FIX handle NaN values in input stream to "stats FOO matrix"
>* FIX prevent extra read past the end of a datablock holding matrix data
>* FIX pm - issues in box and polygon fill, (wide) lines, enhanced text, images
>* FIX dropped character in piped input stream if plot window is manually closed
>* FIX extraneous dots and potential segfault from splot with contour labels
>* FIX boxplots - color sequence correctly starts with specified linetype
>* FIX incomplete initialization led to segfault from "gnuplot -c foo.gp baz"
>* FIX Allow "pm3d depthorder base" to handle 3D quadrangles with logscale z
> 
> 
>
>_______________________________________________
>gnuplot-beta mailing list
>gnu...@li...
>Membership management via: https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
>
>
>

Re: Testing version of Release 5.2.7

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

I have built 32 and 64 bit binaries on Windows using Msys2/MinGW64 toolchain.
Build and all.dem went well.

Tatsuro





----- Original Message -----
>From: Ethan Merritt (UW) 
>To: gnuplot beta list
>Date: 2019/5/21, Tue 15:49
>Subject: Testing version of Release 5.2.7
> 
>
> 
>I have placed a tarball gnuplot-5.2.7beta.tar.gz in the "testing" folder on SourceForge.
> 
>https://sourceforge.net/projects/gnuplot/files/gnuplot/testing/
> 
>This version identifies as 5.2.7beta and is intended for test-builds on Windows,
>OSX, etc prior to full release of 5.2.7 at the end of the month.
>Please report and build problems before then.
> 
>There are many more changes than is usual for a patchlevel release this late in 
>the series.  I do not know why, but perhaps it has taken longer than usual for
>various linux distributions to include any version of the current major release
>so end-users only recently switched to 5.2 from 5.0.  Maybe.
> 
>Ethan
> 
> 
> 
>GNUPLOT Version 5.2.7 Release Notes
>===================================
> 
>These release notes are for version 5.2 patchlevel 7 (5.2.7).
>This release contains bug-fixes, a few changes back-ported from the
>development version, and some minor new features.
>The largest change is a revised fig terminal that brings it into line
>with capabilities of other version 5 terminals.
> 
>Please see the ChangeLog file for a complete list of changes made during the
>course of development from 5.0 to 5.2.
> 
>Release Notes date: 14-May-2019
> 
>Changes in 5.2.7
>================
> 
>* NEW "set pm3d noclipcb" will skip drawing quadrangles with color < cbmin
>* NEW pm terminal supports utf8, dashed lines, bold/italic text
>* NEW imaginary component of array values is available to "using" in column 3
>* NEW gnuplot --slow may help use of qt terminal with slow system font server
>* CHANGE splot "with points pt 0" acts like "with dots"
>* CHANGE (tikz) improved default interpretation of gnuplot arrowhead style
>* CHANGE teach hidden3d to handle double-headed vectors (arrowstyle "heads")
>* CHANGE "unset title" or "reset" resets all title properties to default
>* CHANGE font names passed to enhanced text processing may be in quotes
>* CHANGE cairo terminals accept fractional font sizes
>* CHANGE "plot with table" does not output trailing field separator
>* CHANGE better centering for clustered histograms
>* CHANGE clear STATS_* variables before performing analysis
>* CHANGE cairo, libgd, and svg terminals handle LT_NODRAW by not drawing at all
>* CHANGE svg terminal clickable icons are in-line data rather than external refs
>* CHANGE revise space allocated for ylabel; allow text justification for ylabel
>* CHANGE reduce overhead, making it feasible to have 10^6 hypertext labels
>* FIX "plot with table" unnecessarily limited string column output to 60 chars 
>* FIX (windows) make sure graph window is shown even if the program is "hidden"
>* FIX hidden3d mode was not correctly dealing with arrowstyle backhead
>* FIX sprintf in 'using' spec must not clobber numeric locale
>* FIX tikz - request for polygon with 0 vertices could hang terminal
>* FIX lua/tikz - do not attempt to ftruncate output being piped through stdout
>* FIX tkcanvas - do not attempt to ftruncate output being piped through stdout
>* FIX handle NaN values in input stream to "stats FOO matrix"
>* FIX prevent extra read past the end of a datablock holding matrix data
>* FIX pm - issues in box and polygon fill, (wide) lines, enhanced text, images
>* FIX dropped character in piped input stream if plot window is manually closed
>* FIX extraneous dots and potential segfault from splot with contour labels
>* FIX boxplots - color sequence correctly starts with specified linetype
>* FIX incomplete initialization led to segfault from "gnuplot -c foo.gp baz"
>* FIX Allow "pm3d depthorder base" to handle 3D quadrangles with logscale z
> 
> 
>
>_______________________________________________
>gnuplot-beta mailing list
>gnu...@li...
>Membership management via: https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
>
>
>

Re: Testing version of Release 5.2.7

[Erik L. <eri...@gm...>]

P.S. Looking into the changes of the fig terminal, I did "help term fig".
The help text states:

*The fig terminal was significantly revised in gnuplot version 5.3.*

That is evidently a bit confusing.

Erik


On Tue, May 21, 2019 at 12:12 PM Erik Luijten <eri...@gm...>
wrote:

> Dear Ethan,
>
> Version 5.2.7beta compiles without problems on OS X. I have not tested all
> the bugfixes, but in a quick check it appeared to work properly.
>
> Best,
>
> Erik
>
>
> On Tue, May 21, 2019 at 1:52 AM Ethan Merritt (UW) <me...@uw...> wrote:
>
>>
>>
>> I have placed a tarball gnuplot-5.2.7beta.tar.gz in the "testing" folder
>> on SourceForge.
>>
>>
>>
>> https://sourceforge.net/projects/gnuplot/files/gnuplot/testing/
>>
>>
>>
>> This version identifies as 5.2.7beta and is intended for test-builds on
>> Windows,
>>
>> OSX, etc prior to full release of 5.2.7 at the end of the month.
>>
>> Please report and build problems before then.
>>
>>
>>
>> There are many more changes than is usual for a patchlevel release this
>> late in
>>
>> the series. I do not know why, but perhaps it has taken longer than usual
>> for
>>
>> various linux distributions to include any version of the current major
>> release
>>
>> so end-users only recently switched to 5.2 from 5.0. Maybe.
>>
>>
>>
>> Ethan
>>
>>
>>
>>
>>
>>
>>
>> GNUPLOT Version 5.2.7 Release Notes
>>
>> ===================================
>>
>>
>>
>> These release notes are for version 5.2 patchlevel 7 (5.2.7).
>>
>> This release contains bug-fixes, a few changes back-ported from the
>>
>> development version, and some minor new features.
>>
>> The largest change is a revised fig terminal that brings it into line
>>
>> with capabilities of other version 5 terminals.
>>
>>
>>
>> Please see the ChangeLog file for a complete list of changes made during
>> the
>>
>> course of development from 5.0 to 5.2.
>>
>>
>>
>> Release Notes date: 14-May-2019
>>
>>
>>
>> Changes in 5.2.7
>>
>> ================
>>
>>
>>
>> * NEW "set pm3d noclipcb" will skip drawing quadrangles with color < cbmin
>>
>> * NEW pm terminal supports utf8, dashed lines, bold/italic text
>>
>> * NEW imaginary component of array values is available to "using" in
>> column 3
>>
>> * NEW gnuplot --slow may help use of qt terminal with slow system font
>> server
>>
>> * CHANGE splot "with points pt 0" acts like "with dots"
>>
>> * CHANGE (tikz) improved default interpretation of gnuplot arrowhead style
>>
>> * CHANGE teach hidden3d to handle double-headed vectors (arrowstyle
>> "heads")
>>
>> * CHANGE "unset title" or "reset" resets all title properties to default
>>
>> * CHANGE font names passed to enhanced text processing may be in quotes
>>
>> * CHANGE cairo terminals accept fractional font sizes
>>
>> * CHANGE "plot with table" does not output trailing field separator
>>
>> * CHANGE better centering for clustered histograms
>>
>> * CHANGE clear STATS_* variables before performing analysis
>>
>> * CHANGE cairo, libgd, and svg terminals handle LT_NODRAW by not drawing
>> at all
>>
>> * CHANGE svg terminal clickable icons are in-line data rather than
>> external refs
>>
>> * CHANGE revise space allocated for ylabel; allow text justification for
>> ylabel
>>
>> * CHANGE reduce overhead, making it feasible to have 10^6 hypertext labels
>>
>> * FIX "plot with table" unnecessarily limited string column output to 60
>> chars
>>
>> * FIX (windows) make sure graph window is shown even if the program is
>> "hidden"
>>
>> * FIX hidden3d mode was not correctly dealing with arrowstyle backhead
>>
>> * FIX sprintf in 'using' spec must not clobber numeric locale
>>
>> * FIX tikz - request for polygon with 0 vertices could hang terminal
>>
>> * FIX lua/tikz - do not attempt to ftruncate output being piped through
>> stdout
>>
>> * FIX tkcanvas - do not attempt to ftruncate output being piped through
>> stdout
>>
>> * FIX handle NaN values in input stream to "stats FOO matrix"
>>
>> * FIX prevent extra read past the end of a datablock holding matrix data
>>
>> * FIX pm - issues in box and polygon fill, (wide) lines, enhanced text,
>> images
>>
>> * FIX dropped character in piped input stream if plot window is manually
>> closed
>>
>> * FIX extraneous dots and potential segfault from splot with contour
>> labels
>>
>> * FIX boxplots - color sequence correctly starts with specified linetype
>>
>> * FIX incomplete initialization led to segfault from "gnuplot -c foo.gp
>> baz"
>>
>> * FIX Allow "pm3d depthorder base" to handle 3D quadrangles with logscale
>> z
>>
>>
>>
>>
>> _______________________________________________
>> gnuplot-beta mailing list
>> gnu...@li...
>> Membership management via:
>> https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
>>
>

Re: Testing version of Release 5.2.7

[Erik L. <eri...@gm...>]

Dear Ethan,

Version 5.2.7beta compiles without problems on OS X. I have not tested all
the bugfixes, but in a quick check it appeared to work properly.

Best,

Erik


On Tue, May 21, 2019 at 1:52 AM Ethan Merritt (UW) <me...@uw...> wrote:

>
>
> I have placed a tarball gnuplot-5.2.7beta.tar.gz in the "testing" folder
> on SourceForge.
>
>
>
> https://sourceforge.net/projects/gnuplot/files/gnuplot/testing/
>
>
>
> This version identifies as 5.2.7beta and is intended for test-builds on
> Windows,
>
> OSX, etc prior to full release of 5.2.7 at the end of the month.
>
> Please report and build problems before then.
>
>
>
> There are many more changes than is usual for a patchlevel release this
> late in
>
> the series. I do not know why, but perhaps it has taken longer than usual
> for
>
> various linux distributions to include any version of the current major
> release
>
> so end-users only recently switched to 5.2 from 5.0. Maybe.
>
>
>
> Ethan
>
>
>
>
>
>
>
> GNUPLOT Version 5.2.7 Release Notes
>
> ===================================
>
>
>
> These release notes are for version 5.2 patchlevel 7 (5.2.7).
>
> This release contains bug-fixes, a few changes back-ported from the
>
> development version, and some minor new features.
>
> The largest change is a revised fig terminal that brings it into line
>
> with capabilities of other version 5 terminals.
>
>
>
> Please see the ChangeLog file for a complete list of changes made during
> the
>
> course of development from 5.0 to 5.2.
>
>
>
> Release Notes date: 14-May-2019
>
>
>
> Changes in 5.2.7
>
> ================
>
>
>
> * NEW "set pm3d noclipcb" will skip drawing quadrangles with color < cbmin
>
> * NEW pm terminal supports utf8, dashed lines, bold/italic text
>
> * NEW imaginary component of array values is available to "using" in
> column 3
>
> * NEW gnuplot --slow may help use of qt terminal with slow system font
> server
>
> * CHANGE splot "with points pt 0" acts like "with dots"
>
> * CHANGE (tikz) improved default interpretation of gnuplot arrowhead style
>
> * CHANGE teach hidden3d to handle double-headed vectors (arrowstyle
> "heads")
>
> * CHANGE "unset title" or "reset" resets all title properties to default
>
> * CHANGE font names passed to enhanced text processing may be in quotes
>
> * CHANGE cairo terminals accept fractional font sizes
>
> * CHANGE "plot with table" does not output trailing field separator
>
> * CHANGE better centering for clustered histograms
>
> * CHANGE clear STATS_* variables before performing analysis
>
> * CHANGE cairo, libgd, and svg terminals handle LT_NODRAW by not drawing
> at all
>
> * CHANGE svg terminal clickable icons are in-line data rather than
> external refs
>
> * CHANGE revise space allocated for ylabel; allow text justification for
> ylabel
>
> * CHANGE reduce overhead, making it feasible to have 10^6 hypertext labels
>
> * FIX "plot with table" unnecessarily limited string column output to 60
> chars
>
> * FIX (windows) make sure graph window is shown even if the program is
> "hidden"
>
> * FIX hidden3d mode was not correctly dealing with arrowstyle backhead
>
> * FIX sprintf in 'using' spec must not clobber numeric locale
>
> * FIX tikz - request for polygon with 0 vertices could hang terminal
>
> * FIX lua/tikz - do not attempt to ftruncate output being piped through
> stdout
>
> * FIX tkcanvas - do not attempt to ftruncate output being piped through
> stdout
>
> * FIX handle NaN values in input stream to "stats FOO matrix"
>
> * FIX prevent extra read past the end of a datablock holding matrix data
>
> * FIX pm - issues in box and polygon fill, (wide) lines, enhanced text,
> images
>
> * FIX dropped character in piped input stream if plot window is manually
> closed
>
> * FIX extraneous dots and potential segfault from splot with contour labels
>
> * FIX boxplots - color sequence correctly starts with specified linetype
>
> * FIX incomplete initialization led to segfault from "gnuplot -c foo.gp
> baz"
>
> * FIX Allow "pm3d depthorder base" to handle 3D quadrangles with logscale z
>
>
>
>
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> Membership management via:
> https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
>

Testing version of Release 5.2.7

[Ethan M. (UW) <me...@uw...>]

I have placed a tarball gnuplot-5.2.7beta.tar.gz in the "testing" folder on SourceForge.

 https://sourceforge.net/projects/gnuplot/files/gnuplot/testing/

This version identifies as 5.2.7beta and is intended for test-builds on Windows,
OSX, etc prior to full release of 5.2.7 at the end of the month.
Please report and build problems before then.

There are many more changes than is usual for a patchlevel release this late in 
the series.  I do not know why, but perhaps it has taken longer than usual for
various linux distributions to include any version of the current major release
so end-users only recently switched to 5.2 from 5.0.  Maybe.

	Ethan



		GNUPLOT Version 5.2.7 Release Notes
		===================================

These release notes are for version 5.2 patchlevel 7 (5.2.7).
This release contains bug-fixes, a few changes back-ported from the
development version, and some minor new features.
The largest change is a revised fig terminal that brings it into line
with capabilities of other version 5 terminals.

Please see the ChangeLog file for a complete list of changes made during the
course of development from 5.0 to 5.2.

Release Notes date: 14-May-2019

Changes in 5.2.7
================

* NEW "set pm3d noclipcb" will skip drawing quadrangles with color < cbmin
* NEW pm terminal supports utf8, dashed lines, bold/italic text
* NEW imaginary component of array values is available to "using" in column 3
* NEW gnuplot --slow may help use of qt terminal with slow system font server
* CHANGE splot "with points pt 0" acts like "with dots"
* CHANGE (tikz) improved default interpretation of gnuplot arrowhead style
* CHANGE teach hidden3d to handle double-headed vectors (arrowstyle "heads")
* CHANGE "unset title" or "reset" resets all title properties to default
* CHANGE font names passed to enhanced text processing may be in quotes
* CHANGE cairo terminals accept fractional font sizes
* CHANGE "plot with table" does not output trailing field separator
* CHANGE better centering for clustered histograms
* CHANGE clear STATS_* variables before performing analysis
* CHANGE cairo, libgd, and svg terminals handle LT_NODRAW by not drawing at all
* CHANGE svg terminal clickable icons are in-line data rather than external refs
* CHANGE revise space allocated for ylabel; allow text justification for ylabel
* CHANGE reduce overhead, making it feasible to have 10^6 hypertext labels
* FIX "plot with table" unnecessarily limited string column output to 60 chars 
* FIX (windows) make sure graph window is shown even if the program is "hidden"
* FIX hidden3d mode was not correctly dealing with arrowstyle backhead
* FIX sprintf in 'using' spec must not clobber numeric locale
* FIX tikz - request for polygon with 0 vertices could hang terminal
* FIX lua/tikz - do not attempt to ftruncate output being piped through stdout
* FIX tkcanvas - do not attempt to ftruncate output being piped through stdout
* FIX handle NaN values in input stream to "stats FOO matrix"
* FIX prevent extra read past the end of a datablock holding matrix data
* FIX pm - issues in box and polygon fill, (wide) lines, enhanced text, images
* FIX dropped character in piped input stream if plot window is manually closed
* FIX extraneous dots and potential segfault from splot with contour labels
* FIX boxplots - color sequence correctly starts with specified linetype
* FIX incomplete initialization led to segfault from "gnuplot -c foo.gp baz"
* FIX Allow "pm3d depthorder base" to handle 3D quadrangles with logscale z

Re: Aw: Re: Couldn't find `ps.cfg' while processing FAQ.tex on native Windows

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

On my install, mpm seems not to work now.

I re-install the latest version miktex and problem is solved.

Thanks!


Tatsuro  



----- Original Message -----
> From: Bastian Märkisch 
> To: tmacchant3
> Cc: tmacchant3 gnuplot-beta
> Date: 2019/4/26, Fri 03:34
> Subject: Aw: Re: Couldn't find `ps.cfg' while processing FAQ.tex on native Windows
> 
> Dear Tatsuro,
> 
> Please make sure that you have the "times", "mathptmx" and 
> "symbol" packages installed.  This can be easily done using the 
> "MiKTeX Console" (or the package manager if your installation is old). 
> Typically MiKTeX would ask you if it should install packages which are missing 
> during a run of e.g. pdflatex. Why it does not succeed in doing so on your 
> system I do not know.
> 
>   Bastian
> 
>>  Gesendet: Donnerstag, 25. April 2019 um 11:18 Uhr
>>  Von: "Tatsuro MATSUOKA" <tma...@ya...>
>>  An: tma...@ya..., gnu...@li...
>>  Betreff: Re: Couldn't find `ps.cfg' while processing FAQ.tex on 
> native Windows
>> 
>>  I could process the faq.tex on Cygwin using texlive.
>>  I once tried texlive for windows for config/mingw/Makefile build 
>> 
>>  but was in failure.
>> 
>>  I will struggle it.
>>  At the moment I copy faq.pdf generated on Cygwin.
>> 
>> 
>> 
>>  ----- Original Message -----
>>  > From: Tatsuro MATSUOKA 
>>  > To: gnuplot-beta
>>  > Cc: 
>>  > Date: 2019/4/24, Wed 18:32
>>  > Subject: Couldn't find `ps.cfg' while processing FAQ.tex on 
> native Windows
>>  > 
>>  > Commit [bbf941]
>>  > 
>>  > 
>>  > pdflatex ../../faq/faq.tex
>>  > This is pdfTeX, Version 3.14159265-2.6-1.40.16 (MiKTeX 2.9 64-bit)
>>  > entering extended mode
>>  > (../../faq/faq.tex
>>  > LaTeX2e <2015/10/01> patch level 2
>>  > Babel <3.9n> and hyphenation patterns for 69 languages loaded.
>>  > 
> (C:\Programs\MiKTeX_2.9\tex\latex\base\article.cls
>>  > Document Class: article 2014/09/29 v1.4h Standard LaTeX document class
>>  > 
> (C:\Programs\MiKTeX_2.9\tex\latex\base\size11.clo))
>>  > 
> (C:\Programs\MiKTeX_2.9\tex\latex\geometry\geometry.sty
>>  > 
> (C:\Programs\MiKTeX_2.9\tex\latex\graphics\keyval.sty)
>>  > 
> (C:\Programs\MiKTeX_2.9\tex\generic\oberdiek\ifpdf.sty)
>>  > 
> (C:\Programs\MiKTeX_2.9\tex\generic\oberdiek\ifvtex.sty)
>>  > 
> (C:\Programs\MiKTeX_2.9\tex\generic\ifxetex\ifxetex.sty)
>>  > 
> (C:\Programs\MiKTeX_2.9\tex\latex\geometry\geometry.cfg))
>>  > 
> (C:\Programs\MiKTeX_2.9\tex\latex\base\fontenc.sty
>>  > 
> (C:\Programs\MiKTeX_2.9\tex\latex\base\t1enc.def))
>>  > (C:\Programs\MiKTeX_2.9\tex\latex\url\url.sty)
>>  > 
> (C:\Programs\MiKTeX_2.9\tex\latex\psnfss\times.sty)
>>  > 
> (C:\Programs\MiKTeX_2.9\tex\latex\psnfss\mathptmx.sty)
>>  > 
> (C:\Programs\MiKTeX_2.9\tex\latex\hyperref\hyperref.sty
>>  > 
> (C:\Programs\MiKTeX_2.9\tex\generic\oberdiek\hobsub-hyperref.sty
>>  > 
> (C:\Programs\MiKTeX_2.9\tex\generic\oberdiek\hobsub-generic.sty))
>>  > 
> (C:\Programs\MiKTeX_2.9\tex\latex\oberdiek\auxhook.sty)
>>  > 
> (C:\Programs\MiKTeX_2.9\tex\latex\oberdiek\kvoptions.sty)
>>  > 
> (C:\Programs\MiKTeX_2.9\tex\latex\hyperref\pd1enc.def)
>>  > 
> (C:\Programs\MiKTeX_2.9\tex\latex\00miktex\hyperref.cfg))
>>  > 
>>  > Package hyperref Message: Driver (autodetected): hpdftex.
>>  > 
>>  > 
> (C:\Programs\MiKTeX_2.9\tex\latex\hyperref\hpdftex.def
>>  > 
> (C:\Programs\MiKTeX_2.9\tex\latex\oberdiek\rerunfilecheck.sty))
>>  > 
> (C:\Programs\MiKTeX_2.9\tex\latex\graphics\color.sty
>>  > 
> (C:\Programs\MiKTeX_2.9\tex\latex\00miktex\color.cfg)
>>  > 
> (C:\Programs\MiKTeX_2.9\tex\latex\pdftex-def\pdftex.def))
>>  > No file faq.aux.
>>  > 
> (C:\Programs\MiKTeX_2.9\tex\latex\psnfss\t1ptm.fd)
>>  > *geometry* driver: auto-detecting
>>  > *geometry* detected driver: pdftex
>>  > 
> (C:\Programs\MiKTeX_2.9\tex\latex\hyperref\nameref.sty
>>  > 
> (C:\Programs\MiKTeX_2.9\tex\generic\oberdiek\gettitlestring.sty))
>>  > 
> (C:\Programs\MiKTeX_2.9\tex\context\base\supp-pdf.mkii
>>  > [Loading MPS to PDF converter (version 2006.09.02).]
>>  > ) 
> (C:\Programs\MiKTeX_2.9\tex\latex\psnfss\ot1ztmcm.fd)
>>  > 
> (C:\Programs\MiKTeX_2.9\tex\latex\psnfss\omlztmcm.fd)
>>  > 
> (C:\Programs\MiKTeX_2.9\tex\latex\psnfss\omsztmcm.fd)
>>  > 
> (C:\Programs\MiKTeX_2.9\tex\latex\psnfss\omxztmcm.fd)
>>  > 
> (C:\Programs\MiKTeX_2.9\tex\latex\psnfss\ot1ptm.fd) 
>>  > [1{C:/Users/MATSUOKA LAB/Ap
>>  > pData/Local/MiKTeX/2.9/pdftex/config/pdftex.map}]
>>  > 
> (C:\Programs\MiKTeX_2.9\tex\latex\psnfss\t1phv.fd)
>>  > 
> (C:\Programs\MiKTeX_2.9\tex\latex\psnfss\omsptm.fd) [2] 
>>  > [3]
>>  > 
> (C:\Programs\MiKTeX_2.9\tex\latex\psnfss\t1pcr.fd) [4] 
>>  > [5] [6] [7] [8] [9]
>>  > [10] [11] [12
>>  > ======================================================================
>>  > 
>>  > Unfortunately, the package symbol could not be installed.Please check 
> the log 
>>  > file:
>>  > C:/Users/MATSUOKA LAB/AppData/Local/MiKTeX/2.9/miktex/log/pdflatex.log
>>  > ======================================================================
>>  > 
>>  > ======================================================================
>>  > 
>>  > Unfortunately, the package symbol could not be installed.Please check 
> the log 
>>  > file:
>>  > C:/Users/MATSUOKA 
> LAB/AppData/Local/MiKTeX/2.9/miktex/log/miktex-maketfm.log
>>  > ======================================================================
>>  > Running miktex-makemf.exe...
>>  > 
>>  > Sorry, but miktex-makemf did not succeed for the following reason:
>>  > 
>>  >   The psyr source file could not be found.
>>  > 
>>  > The log file hopefully contains the information to get MiKTeX going 
> again:
>>  > 
>>  >   C:/Users/MATSUOKA 
> LAB/AppData/Local/MiKTeX/2.9/miktex/log/miktex-makemf.log
>>  > 
>>  > You may want to visit the MiKTeX project page, if you need help.
>>  > Running hbf2gf.exe...
>>  > 
>>  > hbf2gf (CJK ver. 4.8.4)
>>  > 
>>  > Couldn't find `ps.cfg'
>>  > 
>>  > Sorry, but miktex-maketfm did not succeed for the following reason:
>>  > 
>>  >   No creation rule for font psyr.
>>  > 
>>  > The log file hopefully contains the information to get MiKTeX going 
> again:
>>  > 
>>  >   C:/Users/MATSUOKA 
> LAB/AppData/Local/MiKTeX/2.9/miktex/log/miktex-maketfm.log
>>  > 
>>  > You may want to visit the MiKTeX project page, if you need help.
>>  > 
>>  > ! Font \csname\endcsname=psyr at 10.95pt not loadable: Metric 
> (TFM) file 
>>  > not fo
>>  > und.
>>  > \AtBegShi@Output ...ipout \box \AtBeginShipoutBox
>>  >                                                   \fi \fi
>>  > l.923
>>  > 
>>  > ?
>>  > 
>>  > 
>>  > 
>>  > I seldom use LaTeX. Please give me a hint to overcome the issue.
>>  > 
>>  > Tatsuro
>>  > 
>>  > 
>>  > 
>>  > _______________________________________________
>>  > gnuplot-beta mailing list
>>  > gnu...@li...
>>  > Membership management via: 
>>  > https://lists.sourceforge.net/lists/listinfo/gnuplot-beta 
>>  > 
>> 
>> 
>> 
>>  _______________________________________________
>>  gnuplot-beta mailing list
>>  gnu...@li...
>>  Membership management via: 
> https://lists.sourceforge.net/lists/listinfo/gnuplot-beta 
>> 
>