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

bug in 5.4rc2 X11 terminal

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

Hello,

Something goes wrong with fonts or character encodings on the x11 terminal.
See the attached which is the result of simply  
  plot 1e6
The vertical labels have a few unintended characters instead of multiplication
signs (crosses).

Debian's stock gnuplot 5.2pl6 version displays the multiplication sign
correctly on the x11 terminal, as does 5.4rc2 with the Qt terminal.

Any idea what this could be? Any test I could do to help debug it?

Regards,
  Pieter-Tjerk

Re: set nonlinear for secondary axis

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

Ethan A Merritt writes:
> Good idea.  Done.

Thank you very much.


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

Waldorf MIDI Implementation & additional documentation:
http://Synth.Stromeko.net/Downloads.html#WaldorfDocs

Re: Bug in 5.4.rc2

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

Dima Kogan <gn...@di...> writes:

> I finished a patch just as you wrote this.

So I just played with the patched code a bit more, and it's plotting the
circles as circles even if the aspect ratio is not square. So it's
clearly insufficient. Hmm

Re: Bug in 5.4.rc2

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

I finished a patch just as you wrote this. The patch is attached. I
tried several operations, and it appears to do what I want, and not
break anything. The code has a lot of confusion about the meaning of
xlow/xhigh/ylow/yhigh in arguments to store2d_point() and again, in the
*cp structure this function fills. The previous code was passing the x,y
extents to store2d_point(), but if you do that, you run out of
arguments, and can't pass the y extents even if you wanted to. This
patch computes the extents inside store2d_point(), so there are
arguments left over. This patch also documents the meanings of
xlow/xhigh/ylow/yhigh.



Ethan A Merritt <me...@uw...> writes:

> On Monday, 22 June 2020 23:11:41 PDT Dima Kogan wrote:
>
> Autoscaling on y for "with circles" is not a well-defined operation.
> The whole point of the style is that the circle radius depends only on
> x. It will accommodate any yrange by adjusting the extent on y taking
> into account the aspect ratio of the plot.

Maybe I'm abusing the intent of the style here, but in my intended
usage, the meaning is well-defined, and the existing behavior highly
surprising. I want a circle in the x and y coordinates of the plot. If
the aspect ratio is square, it will look like a circle. If the aspect
ratio isn't square, it will look like an ellipse. Is "with circles" not
the proper style? Do I want "with ellipses"? I do see that what you're
saying is spelled-out in the "with circles" documentation; I guess I
thought the meaning of "circle" was clear-enough such that I didn't need
to read that page :)

And regardless of the answer to that question, the user expectation is
that the autoscaling would cause everything in the plot to be visible.
So given that, we shouldn't be cutting off any of the plotted circle.

Thanks

Re: Bug in 5.4.rc2

[Ethan A M. <me...@uw...>]

On Monday, 22 June 2020 23:11:41 PDT Dima Kogan wrote:
> I just hit a bug in 5.4.rc2. I'm guessing this isn't a new bug, but it'd
> be nice to fix it before the release. To reproduce:
> 
>   set size ratio -1
>   plot '-'   using 1:2:3 notitle with circles lw 2
>   0 0 2.5
>   e
> 
> It looks like when "with circles" data is used for autoscaling, the
> edges of the circles are used for the x-axis autoscaling, but only the
> centers for the y-axis autoscaling. So in the plot above, most of the
> one circle gets cut off.

Autoscaling on y for "with circles" is not a well-defined operation.
The whole point of the style is that the circle radius depends only on x.
It will accommodate any yrange by adjusting the extent on y taking
into account the aspect ratio of the plot.

	Ethan  


> 
> I can debug and come up with a patch, but some of you can do that MUCH
> faster than me.
> 
> If yall are busy, let me know, and I can produce a patch.
> 
> Thanks!

Bug in 5.4.rc2

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

I just hit a bug in 5.4.rc2. I'm guessing this isn't a new bug, but it'd
be nice to fix it before the release. To reproduce:

  set size ratio -1
  plot '-'   using 1:2:3 notitle with circles lw 2
  0 0 2.5
  e

It looks like when "with circles" data is used for autoscaling, the
edges of the circles are used for the x-axis autoscaling, but only the
centers for the y-axis autoscaling. So in the plot above, most of the
one circle gets cut off.

I can debug and come up with a patch, but some of you can do that MUCH
faster than me.

If yall are busy, let me know, and I can produce a patch.

Thanks!

Re: set nonlinear for secondary axis

[Ethan A M. <me...@uw...>]

On Monday, 22 June 2020 11:32:27 PDT Achim Gratz wrote:
> 
> I've recently started using "set nonlinear" more and more and finally
> got to the point where I wanted to have both the primary and secondary
> axis nonlinear.  I promptly fell into the trap that the axis is now
> called x2 (or y2 or z2), but the dummy variable still needs to be given
> as plain x, y, z for the dummy variable in the function setup.  Could
> the documentation be augmented to have at least one example of using a
> secondary axis so that this becomes more clear?
> 
> Regards,
> Achim.

Good idea.  Done.

	Ethan

set nonlinear for secondary axis

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

I've recently started using "set nonlinear" more and more and finally
got to the point where I wanted to have both the primary and secondary
axis nonlinear.  I promptly fell into the trap that the axis is now
called x2 (or y2 or z2), but the dummy variable still needs to be given
as plain x, y, z for the dummy variable in the function setup.  Could
the documentation be augmented to have at least one example of using a
secondary axis so that this becomes more clear?


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

SD adaptation for Waldorf Blofeld V1.15B11:
http://Synth.Stromeko.net/Downloads.html#WaldorfSDada

Re: palette plus extra color?

[Allin C. <cot...@wf...>]

On Sat, 13 Jun 2020, Ethan Merritt wrote:

> On Saturday, 13 June 2020 12:07:02 PDT Ethan A Merritt wrote:
>> On Saturday, 13 June 2020 11:25:46 PDT Allin Cottrell wrote:
>>> The following doesn't work (not surprising) but I'm wondering if
>>> there's any real gnuplot syntax that'll do what it's trying to do:
>>>
>>> plot for [i=0:*] 'polygons.dat' index i with filledcurves \
>>>   fc ($3 < 0 ? 'gray' : palette)
>>>
>>> The datafile contains several datasets representing polygons; the
>>> first 2 columns hold the coordinates of vertices and the third a
>>> value to be colorized (if >= 0) or shown as missing (gray) if
>>> negative.
>>
>> Define the palette such that cb=0 is gray, the rest whatever you want.
>>
>>      set palette defined (-0.001 "gray",   0 "first palette color", ..., 1 "last palette color")
>>      set cbrange [0:*]
>
> Ah, sorry. I missed the normal color for ( >= 0) requirement.
>         set cbrange [-0.001:*]

Thanks, Ethan. I'd actually tried "set palette defined" plus "set 
cbrange" but I failed to get it right.

Allin

Re: palette plus extra color?

[Ethan M. <eam...@gm...>]

On Saturday, 13 June 2020 12:07:02 PDT Ethan A Merritt wrote:
> On Saturday, 13 June 2020 11:25:46 PDT Allin Cottrell wrote:
> > The following doesn't work (not surprising) but I'm wondering if 
> > there's any real gnuplot syntax that'll do what it's trying to do:
> > 
> > plot for [i=0:*] 'polygons.dat' index i with filledcurves \
> >   fc ($3 < 0 ? 'gray' : palette)
> > 
> > The datafile contains several datasets representing polygons; the 
> > first 2 columns hold the coordinates of vertices and the third a 
> > value to be colorized (if >= 0) or shown as missing (gray) if 
> > negative.
> 
> Define the palette such that cb=0 is gray, the rest whatever you want.
> 
>      set palette defined (-0.001 "gray",   0 "first palette color", ..., 1 "last palette color")
>      set cbrange [0:*]

Ah, sorry. I missed the normal color for ( >= 0) requirement.
         set cbrange [-0.001:*]

	Ethan

Re: palette plus extra color?

[Ethan A M. <me...@uw...>]

On Saturday, 13 June 2020 11:25:46 PDT Allin Cottrell wrote:
> The following doesn't work (not surprising) but I'm wondering if 
> there's any real gnuplot syntax that'll do what it's trying to do:
> 
> plot for [i=0:*] 'polygons.dat' index i with filledcurves \
>   fc ($3 < 0 ? 'gray' : palette)
> 
> The datafile contains several datasets representing polygons; the 
> first 2 columns hold the coordinates of vertices and the third a 
> value to be colorized (if >= 0) or shown as missing (gray) if 
> negative.

Define the palette such that cb=0 is gray, the rest whatever you want.

     set palette defined (-0.001 "gray",   0 "first palette color", ..., 1 "last palette color")
     set cbrange [0:*]
 

	Ethan

palette plus extra color?

[Allin C. <cot...@wf...>]

The following doesn't work (not surprising) but I'm wondering if 
there's any real gnuplot syntax that'll do what it's trying to do:

plot for [i=0:*] 'polygons.dat' index i with filledcurves \
  fc ($3 < 0 ? 'gray' : palette)

The datafile contains several datasets representing polygons; the 
first 2 columns hold the coordinates of vertices and the third a 
value to be colorized (if >= 0) or shown as missing (gray) if 
negative.

-- 
Allin Cottrell
Department of Economics
Wake Forest University

Re: 5.4.rc2 second release candidate for gnuplot version 5.4

[Tait <gnu...@t4...>]

I ran gp54rc1-win64-mingw.exe downloaded from SF.

The wxt, qt, libgd-png, and libcairo-png terminal output is not
affected by the text display scaling in my test. The 100% and
225% plots are identical to each other. The mouse coordinate
display and the Window title -- where it says "Gnuplot (window
id : 0)" do change based on text display scaling. Perhaps it's
an optional configuration in cairo's build? On one of the two
machines I tested (but not the other) there is a significant
difference in the default text size between pngcairo and
(gd)png.

As an aside, the gnuplot console text is unaffected, although
the menus, etc. are affected. That will make gnuplot difficult
to use (i.e. tiny) on high-resolution displays.

There are at least two other scaling options available in
Windows that I did not adjust (Scale and Layout in Display, Text
Display in Ease-of-Access, and Make Everything Bigger in
Ease-of-Access). I'm running this in Windows Sandbox to ensure a
pristine default install, and Sandbox won't let me adjust those
other settings.

I wanted to try the Windows terminal, too, but it hangs for a
few seconds and then crashes, seemingly no matter what I try to
plot.


Ethan A Merritt <me...@uw...> said (on 2020/06/06):
> I have placed a tarball for 5.4.rc2 on SourceForge
>    https://sourceforge.net/projects/gnuplot/files/gnuplot/testing/gnuplot-5.4.rc2.tar.gz/download
> 
>  Release Notes date: 04-Jun-2020
> ...
> Can someone comment on this issue - is it reproducible?
>     Bug #2261 Text Size Depends on Windows Scale and Layout Setting
>     https://sourceforge.net/p/gnuplot/bugs/2261/
> 
> Any other known issues?

Re: Cygwin + Qt and/or wxt [was Re: OK to put out an -rc2 for version 5.4?]

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

Ethan A Merritt writes:
> If you can spare the time...

I'll see if I get to it on the weekend or so…

> Here is a small diagnostic patch for the qt terminal.
> It tests the hypothesis that qt connection failure on Cygwin is due to
> horribly slow font initialization.  With the patch in place font handling
> is disabled until the first plot has completed.

Font initialization _is_ slow, I usually even get a warning that tells
me exactly that.


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: Cygwin + Qt and/or wxt [was Re: OK to put out an -rc2 for version 5.4?]

[Ethan A M. <me...@uw...>]

On Sunday, 7 June 2020 00:48:14 PDT Achim Gratz wrote:
> 
> The thing is that the call _should_ work and since this is deep inside a
> Qt library that is happily used by other Qt applications without any
> reported problems indicates that there is some other condition that
> makes it not work work for gnuplot_qt specifically (an initialization
> that's missing or something like that).
> 
> Regards,
> Achim.

If you can spare the time...

Here is a small diagnostic patch for the qt terminal.
It tests the hypothesis that qt connection failure on Cygwin is due to
horribly slow font initialization.  With the patch in place font handling
is disabled until the first plot has completed.

This is guaranteed to mess up layout of the first plot, but if it makes
the connection succeed we can sort out font initialization later.

	Ethan

Re: 5.4.rc2 second release candidate for gnuplot version 5.4

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

Hi Ethan,

Just to report that compilation of 5.4.rc2 on OS X works fine. Note that I
use the x11 terminal (and in addition to the standard terminals I also
include the pdf, gif, jpg, and png terminals), as described here
https://csml-wiki.northwestern.edu/index.php/Binary_versions_of_Gnuplot_for_OS_X
(one
day I will find time for cairo, but x11 serves my purposes).

Best,

Erik


On Sat, Jun 6, 2020 at 12:16 AM Ethan A Merritt <me...@uw...> wrote:

> I have placed a tarball for 5.4.rc2 on SourceForge
>
>
> https://sourceforge.net/projects/gnuplot/files/gnuplot/testing/gnuplot-5.4.rc2.tar.gz/download
>
>  Release Notes date: 04-Jun-2020
>
> * Changes between -rc1 and -rc2
>         o faster response to piped input on Windows (Bug #2204)
>         o "splot with boxes" failed to recognize "fc palette" in -rc1
>         o repair several problems with parallel axis plots (Bug #2294)
>         o minor changes to dumb.trm, pixmap handling
>         o -rc1 failed to act on "with labels rotate by <ang>" (Bug #2264)
>         o \n _not_ stripped from string returned by backquoted shell
> command
>         o fix autoscaling of boxplots
>         o new function palette(z) returns packed RGB representation
>         o lua/tikz terminal applies alpha channel to point symbols
>
> Can someone comment on this issue - is it reproducible?
>     Bug #2261 Text Size Depends on Windows Scale and Layout Setting
>     https://sourceforge.net/p/gnuplot/bugs/2261/
>
> Any other known issues?
>
>         Ethan
>
>
>
>
>
>
>
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> Membership management via:
> https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
>

Re: Cygwin + Qt and/or wxt [was Re: OK to put out an -rc2 for version 5.4?]

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

Ethan A Merritt writes:
> I suppose. But the work involved to disentangle the code in
> wxt_gui.cpp from the core to make it a loadable module would be pretty
> much the same work needed to make it an outboard driver.

Probably yes.  I was thinking that once this has been done for one
driver iot would providew an easier model to follow for others and then
allow the "expensive" drivers (in terms of dependencies) split out into
their own modules (Cairo/Pango, etc. pp.).

> Honestly I think it would be less work to get the Qt terminal
> working.

I think we'll get there eventually, it's just that the Cygwin devs don't
have a small enough reproducer yet.

> But I have never worked on Windows at all and have no particular
> desire to start now.  So I can't really debug or try much myself, only make
> suggestions and point to possible problem points.   
> Is the problem with O_NONBLOCK absolute, i.e. Cygwin will never
> accept such a call, or is it just that making this particular connection
> non-blocking reveals an unacceptable latency in the initialization?
> The former I can't do much about, but the latter we could maybe
> work around by having gnuplot_qt return SUCCESS immediately
> even though initialization is not complete.

The thing is that the call _should_ work and since this is deep inside a
Qt library that is happily used by other Qt applications without any
reported problems indicates that there is some other condition that
makes it not work work for gnuplot_qt specifically (an initialization
that's missing or something like that).


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

Cygwin + Qt and/or wxt [was Re: OK to put out an -rc2 for version 5.4?]

[Ethan A M. <me...@uw...>]

On Saturday, 6 June 2020 23:11:30 PDT Achim Gratz wrote:
> Ethan A Merritt writes:
 
> > No, sorry.  There is not a gnuplot variant that uses wxWidgets as an outboard
> > driver.   About 10 years ago there was some work to create one because at the
> > time the inboard driver did not work on OSX, but it never reached completion
> > and also I think the OSX problem resolved itself.
> >    https://sourceforge.net/p/gnuplot/patches/380/
>
> [snip]
> 
> Instead of having outboard drivers running a s a separate process as you
> use for X11 and Qt may driver modules could work?  The problem for
> packagers really is that e.g. wx pulls in about half of the GNOME stack
> as a dependency and it's linked to the executable.  Having that
> dependency chain in a separate library that could be dynlinked if and
> when the driver was actually used would alleviate that problem.

I suppose. But the work involved to disentangle the code in  wxt_gui.cpp
from the core to make it a loadable module would be pretty
much  the same work needed to make it an outboard driver.

Honestly I think it would be less work to get the Qt terminal working. 
But I have never worked on Windows at all and have no particular
desire to start now.  So I can't really debug or try much myself, only make
suggestions and point to possible problem points.   
Is the problem with O_NONBLOCK absolute, i.e. Cygwin will never
accept such a call, or is it just that making this particular connection
non-blocking reveals an unacceptable latency in the initialization?
The former I can't do much about, but the latter we could maybe
work around by having gnuplot_qt return SUCCESS immediately
even though initialization is not complete.

	Ethan

> 
> 
> Regards,
> Achim.

Re: OK to put out an -rc2 for version 5.4?

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

Ethan A Merritt writes:
>> I'm the maintainer for gnuplot on Cygwin and as long as the Qt/Cygwin
>> problem isn't properly solved 
>
> Thank you for reminding me of that problem.
> I reviewed the original report and the trail of issues filed with the
> Cygwin and Qt upstreams.  It seems that nothing came of either after
> the first flurry of investigation.

It sort of got stalled, yes.  The consensus was that the patch proposed
would probably have unintended side-effects and that the bug was likely
within Cygwin itself.

> However one point was raised which you might know more of.
> As I understand it, the original diagnosis was that Cygwin was using
> named pipes to emulate unix sockets. But that was corrected by 
> Corinna Vinschen, who said that Cygwin was moving towards using
> named pipes but was [at that time] using  loopback IPv4 sockets to 
> implement AF_UNIX sockets.  That was more than a year ago.
> Has the situation changed?  If switching to named pipes would
> resolve this problem and the work is planned anyhow, perhaps it is worth
> prodding to see how close to completion it might be?

Since then there was a lot of work done on pipes which is still not
complete (and I think at least two bugfixes for the socket code), but
unfortuntaley it didn't remove the bug that's the problem for gnuplot so
far.

> No, sorry.  There is not a gnuplot variant that uses wxWidgets as an outboard
> driver.   About 10 years ago there was some work to create one because at the
> time the inboard driver did not work on OSX, but it never reached completion
> and also I think the OSX problem resolved itself.
>    https://sourceforge.net/p/gnuplot/patches/380/

OK, that's a bit disappointing even though semi-expected.  I have
resolved for now to building gnuplot five times with different
configuration options (which fortunately is fast enough on my new build
machine), package the various bits and pieces separately so that users
can mix and match and then using alternatives to select the correct
executables.

Instead of having outboard drivers running a s a separate process as you
use for X11 and Qt may driver modules could work?  The problem for
packagers really is that e.g. wx pulls in about half of the GNOME stack
as a dependency and it's linked to the executable.  Having that
dependency chain in a separate library that could be dynlinked if and
when the driver was actually used would alleviate that problem.


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

Wavetables for the Terratec KOMPLEXER:
http://Synth.Stromeko.net/Downloads.html#KomplexerWaves

Re: OK to put out an -rc2 for version 5.4?

[Ethan A M. <me...@uw...>]

On Saturday, 6 June 2020 00:26:27 PDT ASSI wrote:
> Ethan A Merritt writes:
> > There have been no major changes since -rc1, but a few of them touch
> > the build + packaging pathway so it would be good to test them.
> 
> FWIW, I have seen no problems with RC1 on Cygwin.
> 
> I'm the maintainer for gnuplot on Cygwin and as long as the Qt/Cygwin
> problem isn't properly solved 

Thank you for reminding me of that problem.
I reviewed the original report and the trail of issues filed with the
Cygwin and Qt upstreams.  It seems that nothing came of either after
the first flurry of investigation.
   
However one point was raised which you might know more of.
As I understand it, the original diagnosis was that Cygwin was using
named pipes to emulate unix sockets. But that was corrected by 
Corinna Vinschen, who said that Cygwin was moving towards using
named pipes but was [at that time] using  loopback IPv4 sockets to 
implement AF_UNIX sockets.  That was more than a year ago.
Has the situation changed?  If switching to named pipes would
resolve this problem and the work is planned anyhow, perhaps it is worth
prodding to see how close to completion it might be?

> I'd thought I should maybe package wxt
> instead (which I recently got working).  However, wxt doesn't produce
> its own executable and pulls in an enormous amount of libraries that
> many people don't want installed.  Is there some build option that I may
> have missed to separate the wxt terminal out (like qt and X11) so it can
> be put in its own package and the non-GUI gnuplot can remain as lean as
> it used to be?

No, sorry.  There is not a gnuplot variant that uses wxWidgets as an outboard
driver.   About 10 years ago there was some work to create one because at the
time the inboard driver did not work on OSX, but it never reached completion
and also I think the OSX problem resolved itself.
   https://sourceforge.net/p/gnuplot/patches/380/

The thing is, even if you resurrected that patch series to create an outboard
wxt terminal I worry that you would run into exactly the same problem that
is hitting the outboard Qt driver:  you need an inter-process communication
socket, and that seems to be where the Cygwin options are shaky.

Nevertheless, if you want to organize or delegate someone to work on
an outboard wxt terminal driver I'd be happy to kibbutz from the sidelines.

	best,

		Ethan

> Regards
> Achim.
> 

Re: OK to put out an -rc2 for version 5.4?

[ASSI <Str...@ne...>]

Ethan A Merritt writes:
> There have been no major changes since -rc1, but a few of them touch
> the build + packaging pathway so it would be good to test them.

FWIW, I have seen no problems with RC1 on Cygwin.

I'm the maintainer for gnuplot on Cygwin and as long as the Qt/Cygwin
problem isn't properly solved I'd thought I should maybe package wxt
instead (which I recently got working).  However, wxt doesn't produce
its own executable and pulls in an enormous amount of libraries that
many people don't want installed.  Is there some build option that I may
have missed to separate the wxt terminal out (like qt and X11) so it can
be put in its own package and the non-GUI gnuplot can remain as lean as
it used to be?


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

Wavetables for the Terratec KOMPLEXER:
http://Synth.Stromeko.net/Downloads.html#KomplexerWaves

5.4.rc2 second release candidate for gnuplot version 5.4

[Ethan A M. <me...@uw...>]

I have placed a tarball for 5.4.rc2 on SourceForge

   https://sourceforge.net/projects/gnuplot/files/gnuplot/testing/gnuplot-5.4.rc2.tar.gz/download

 Release Notes date: 04-Jun-2020

* Changes between -rc1 and -rc2
        o faster response to piped input on Windows (Bug #2204)
        o "splot with boxes" failed to recognize "fc palette" in -rc1
        o repair several problems with parallel axis plots (Bug #2294)
        o minor changes to dumb.trm, pixmap handling
        o -rc1 failed to act on "with labels rotate by <ang>" (Bug #2264)
        o \n _not_ stripped from string returned by backquoted shell command
        o fix autoscaling of boxplots
        o new function palette(z) returns packed RGB representation
        o lua/tikz terminal applies alpha channel to point symbols

Can someone comment on this issue - is it reproducible?
    Bug #2261 Text Size Depends on Windows Scale and Layout Setting
    https://sourceforge.net/p/gnuplot/bugs/2261/

Any other known issues?

	Ethan

Re: GPVAL_TERM_XSIZE behavior?

[Allin C. <cot...@wf...>]

On Fri, 5 Jun 2020, Ethan A Merritt wrote:

> On Friday, 5 June 2020 13:25:18 PDT Allin Cottrell wrote:
>> On Fri, 5 Jun 2020, Ethan A Merritt wrote:
>>
>>> On Friday, 5 June 2020 09:47:49 PDT Allin Cottrell wrote:
>>>> I'm seeing something that puzzles me. I create a plot using this
>>>> term line:
>>>>
>>>> set term pngcairo size 762,600
>>>>
>>>> Now I'm interested in retrieving the size of the PNG (which the
>>>> venerable xv tells me really is 762 x 600). Using gnuplot 5.0.6 I
>>>> get
>>>>
>>>> GPVAL_TERM_XSIZE = 15240
>>>> GPVAL_TERM_YSIZE = 12000
>>>> GPVAL_TERM_SCALE = 20
>>>>
>>>> and on division by 20 I get the size back OK. But using 5.2.8 I get
>>>>
>>>> GPVAL_TERM_XSIZE = 15220
>>>> GPVAL_TERM_YSIZE = 11980
>>>> GPVAL_TERM_SCALE = 20
>>>>
>>>> giving 761 x 599 on division by 20.
>>>>
>>>> Is this inadvertant or is there a reason for the difference?
>>>
>>> 600 pixels on y numbered from 0 to 599.
>>> 762 pixels on x numbered from 0 to 761.
>>>
>>> The internal variables are
>>>  term->xmax
>>>  term->ymax
>>>
>>> It is perhaps unfortunate that the exported versions are named
>>> "size" rather than "max".  This change fixed a long history of bug
>>> reports of asymmetry in the left/right top/bottom borders of
>>> pixel-based output plots.
>>>
>>> %%%%%%%%%%%%%%%%%%%%%%%%%%%%
>>> commit 6abd6679ae4757fbff54d4cbbb50b12ec35792d3
>>> Author: Ethan A Merritt <merritt@u.washington.edu>
>>> Date:   Fri Jun 8 10:42:22 2018 -0700
>>>
>>>    Reconcile cairo terminal pixel coordinates and floating point coordinates.
>>>
>>>    The floating point coordinate space used internally by the terminal
>>>    is [0:size*oversample] but in terms of screen pixels it is [0:size-1].
>>>    Simply casting to (int) produces a bottom-of-screen y coordinate that
>>>    is one too large and hence is not drawn.  Similarly the right-of-screen
>>>    maximum x coordinate. Now we report one pixel smaller dimensions back
>>>    to the core code via term->xmax and term->ymax while retaining the full
>>>    canvas size internally to retain the oversampling boost in precision.
>>>    This affects all the cairo terminal variants including wxt.
>>>
>>> %%%%%%%%%%%%%%%%%%%%%%%%%%%%%
>>
>> Thanks, Ethan. Not crucial, but do you know what was the first
>> release to incorporate this change? (I tried to figure this out
>> myself but failed.)
>>
>> Allin
>
> First appeared in 5.2.8, although it had been active in the 
> development version for 18 months at that point.

Thanks again! Good to know for sure.

Allin Cottrell

Re: GPVAL_TERM_XSIZE behavior?

[Ethan A M. <me...@uw...>]

On Friday, 5 June 2020 13:25:18 PDT Allin Cottrell wrote:
> On Fri, 5 Jun 2020, Ethan A Merritt wrote:
> 
> > On Friday, 5 June 2020 09:47:49 PDT Allin Cottrell wrote:
> >> I'm seeing something that puzzles me. I create a plot using this
> >> term line:
> >>
> >> set term pngcairo size 762,600
> >>
> >> Now I'm interested in retrieving the size of the PNG (which the
> >> venerable xv tells me really is 762 x 600). Using gnuplot 5.0.6 I
> >> get
> >>
> >> GPVAL_TERM_XSIZE = 15240
> >> GPVAL_TERM_YSIZE = 12000
> >> GPVAL_TERM_SCALE = 20
> >>
> >> and on division by 20 I get the size back OK. But using 5.2.8 I get
> >>
> >> GPVAL_TERM_XSIZE = 15220
> >> GPVAL_TERM_YSIZE = 11980
> >> GPVAL_TERM_SCALE = 20
> >>
> >> giving 761 x 599 on division by 20.
> >>
> >> Is this inadvertant or is there a reason for the difference?
> >
> > 600 pixels on y numbered from 0 to 599.
> > 762 pixels on x numbered from 0 to 761.
> >
> > The internal variables are
> >  term->xmax
> >  term->ymax
> >
> > It is perhaps unfortunate that the exported versions are named
> > "size" rather than "max".  This change fixed a long history of bug
> > reports of asymmetry in the left/right top/bottom borders of
> > pixel-based output plots.
> >
> > %%%%%%%%%%%%%%%%%%%%%%%%%%%%
> > commit 6abd6679ae4757fbff54d4cbbb50b12ec35792d3
> > Author: Ethan A Merritt <merritt@u.washington.edu>
> > Date:   Fri Jun 8 10:42:22 2018 -0700
> >
> >    Reconcile cairo terminal pixel coordinates and floating point coordinates.
> >
> >    The floating point coordinate space used internally by the terminal
> >    is [0:size*oversample] but in terms of screen pixels it is [0:size-1].
> >    Simply casting to (int) produces a bottom-of-screen y coordinate that
> >    is one too large and hence is not drawn.  Similarly the right-of-screen
> >    maximum x coordinate. Now we report one pixel smaller dimensions back
> >    to the core code via term->xmax and term->ymax while retaining the full
> >    canvas size internally to retain the oversampling boost in precision.
> >    This affects all the cairo terminal variants including wxt.
> >
> > %%%%%%%%%%%%%%%%%%%%%%%%%%%%%
> 
> Thanks, Ethan. Not crucial, but do you know what was the first 
> release to incorporate this change? (I tried to figure this out 
> myself but failed.)
> 
> Allin

First appeared in 5.2.8, although it had been active in the development version
for 18 months at that point.

	Ethan

Re: GPVAL_TERM_XSIZE behavior?

[Allin C. <cot...@wf...>]

On Fri, 5 Jun 2020, Ethan A Merritt wrote:

> On Friday, 5 June 2020 09:47:49 PDT Allin Cottrell wrote:
>> I'm seeing something that puzzles me. I create a plot using this
>> term line:
>>
>> set term pngcairo size 762,600
>>
>> Now I'm interested in retrieving the size of the PNG (which the
>> venerable xv tells me really is 762 x 600). Using gnuplot 5.0.6 I
>> get
>>
>> GPVAL_TERM_XSIZE = 15240
>> GPVAL_TERM_YSIZE = 12000
>> GPVAL_TERM_SCALE = 20
>>
>> and on division by 20 I get the size back OK. But using 5.2.8 I get
>>
>> GPVAL_TERM_XSIZE = 15220
>> GPVAL_TERM_YSIZE = 11980
>> GPVAL_TERM_SCALE = 20
>>
>> giving 761 x 599 on division by 20.
>>
>> Is this inadvertant or is there a reason for the difference?
>
> 600 pixels on y numbered from 0 to 599.
> 762 pixels on x numbered from 0 to 761.
>
> The internal variables are
>  term->xmax
>  term->ymax
>
> It is perhaps unfortunate that the exported versions are named
> "size" rather than "max".  This change fixed a long history of bug
> reports of asymmetry in the left/right top/bottom borders of
> pixel-based output plots.
>
> %%%%%%%%%%%%%%%%%%%%%%%%%%%%
> commit 6abd6679ae4757fbff54d4cbbb50b12ec35792d3
> Author: Ethan A Merritt <merritt@u.washington.edu>
> Date:   Fri Jun 8 10:42:22 2018 -0700
>
>    Reconcile cairo terminal pixel coordinates and floating point coordinates.
>
>    The floating point coordinate space used internally by the terminal
>    is [0:size*oversample] but in terms of screen pixels it is [0:size-1].
>    Simply casting to (int) produces a bottom-of-screen y coordinate that
>    is one too large and hence is not drawn.  Similarly the right-of-screen
>    maximum x coordinate. Now we report one pixel smaller dimensions back
>    to the core code via term->xmax and term->ymax while retaining the full
>    canvas size internally to retain the oversampling boost in precision.
>    This affects all the cairo terminal variants including wxt.
>
> %%%%%%%%%%%%%%%%%%%%%%%%%%%%%

Thanks, Ethan. Not crucial, but do you know what was the first 
release to incorporate this change? (I tried to figure this out 
myself but failed.)

Allin