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

Re: [PATCH] x11 terminal respects the requested aspect ratio

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

On Friday, September 28, 2012 01:35:07 am Dima Kogan wrote:
> > On Thu, 27 Sep 2012 12:00:10 -0700
> > Ethan Merritt <merritt@u.washington.edu> wrote:
 
> > > The problem seems to trigger when YMAX crosses exactly 10000, 
> > > Perhaps it's a formatted field overflow from 4 digits to
> > > 5 in the y coordinate?
> > 
> > I think that must be it.  The coordinates sent from x11.trm to
> > gnuplot_x11 use format statements like PRINT2("V%04d%04d\n", x, y);
> > 
> > It looks like either the field width has to be increased everywhere
> > to 5 digits, or else the new rescaling code needs to rethought
> > (perhaps by adjusting both xsize and ysize rather than only adjusting
> > ysize?)  Increasing the field width has the drawback that more bytes
> > will be sent over the channel regardless of the window size, which
> > can slow down the communication.
> > 
> > What to do?
> > 
> > 		Ethan
> 
> Hi Ethan.
> 
> Good you found the issue. Do you know why field widths are specified at
> all? Why don't we PRINT2("V%d %d\n") and then sscanf("%d %d", ...) on
> the other side? No efficiency is gained by specifying the widths, it
> only builds in limitations and makes the code brittle, as we have just
> observed.

The basic X11 framework was in place long before my involvement, so I do 
not know.  My best guess is that the fixed field width was chosen so as 
to reduce the amount of data sent through the gnuplot->gnuplot_x11 channel.
Adding a space in front of every coordinate pair would increase the
traffic by as much as 25%.

As I recall, when the polygon encoding was switched from formatted to
binary (2004), the advocates of binary encoding/decoding had benchmarks
showing data transfer really was a performance bottleneck, and reducing
the number of bytes sent over the channel resulted in faster plotting.
I do not know if this would still be true on modern machines.

We should benchmark before and after your latest patch.

> I'm attaching a patch that removes hardcoded field sizes from ALL %d
> and %u fields. Some extra care had to be taken in places where a
> numerical field is followed by a string (%s), since the '4' was
> hardcoded in those places too. The bug you described is now gone, and
> the code is more robust.
> 
> I noticed another, very related issue. x11.trm has
> 
>     /* badly outrange labels can overflow into text field */
>     if (x < 10000 && y < 10000) {
> 	PRINT3("T%d %d %s\n", x, y, str);
>     }
> 
> Here we're hardcoding the 10000 again. This has the effect of not
> printing the legend label when the window is skinny (as you were making
> it). This test needs to be adjusted or removed entirely; not sure
> which. CVS says this test was added by lhecking in 1998. This predates
> all of sourceforge. Newsgroup logs go back that far, but I didn't see
> any mention of this issue. Thoughts?

That does look like an early instance of the same problem.
But I wonder how that code ever triggered?

> Finally, in writing the patch, I stumbled on what looks like a bug in
> what looks like dead code. In gplt_x11.c, look at the
> 
>     else if (*buffer == X11_GR_FILLED_POLYGON) {	/* filled
> [snip]
> I suspect the whole block is dead, and this bug is thus
> never hit. If this whole block is truly dead, it should be removed.
> dima

I think it must be left over from when the choice between binary/ascii
polygon encoding was a configuration option.  Since 2009 the ascii 
option no longer exists.  So yeah, that section is dead code.

	Ethan
 

Re: [PATCH] x11 terminal respects the requested aspect ratio

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

> On Thu, 27 Sep 2012 12:00:10 -0700
> Ethan Merritt <merritt@u.washington.edu> wrote:
>
> On Thursday, September 27, 2012 11:41:50 am Ethan A Merritt wrote:
> > On Thursday, September 27, 2012 01:40:18 am Dima Kogan wrote:
> > > > On Tue, 25 Sep 2012 21:31:55 -0700
> > > > "sfeam (Ethan Merritt)" <eam...@gm...> wrote:
> > > >
> > > > On Saturday, 22 September 2012, Dima Kogan
> > > > <gn...@di...> wrote:
> > > > > 
> > > > > I tackled the long-standing issue of the x11 terminal not
> > > > > respecting the requested plot aspect ratio
> > > > <snip>
> > > > 
> > > > Hi Dima.  
> > > > 
> > > > I've applied your patch to CVS in the development branch after
> > > > review and testing. <snip>
> > > 
> > > Hi Ethan. Thanks for applying the patch. Main difference I
> > > noticed so far is that the point sizes appear smaller in the x11
> > > terminal than they were before this patch.
> > 
> > I have found another problem.  I suspect it may be an integer
> > overflow, but if so I can't figure out where.  Here's a simple
> > recipe to show the problem:
> > gnuplot> set term x11
> > gnuplot> set sample 15
> > gnuplot> plot x with points pt 5
> > 
> > 1) Adjust the X-window so that the plot is very tall.
> > 2) Gradually make the plot window narrower and narrower.
> >    At some point the top border of the plot stops being correctly
> > drawn near the top of the window;  instead it is drawn near the
> > bottom.
> > 
> > gnuplot> show var GPVAL_TERM
> >         GPVAL_TERM_XMIN = 473
> >         GPVAL_TERM_XMAX = 3837
> >         GPVAL_TERM_YMIN = 280
> >         GPVAL_TERM_YMAX = 10072
> >         GPVAL_TERM_XSIZE = 4096
> >         GPVAL_TERM_YSIZE = 10245
> > 
> > The problem seems to trigger when YMAX crosses exactly 10000,
> > but I don't see any relevant use of 9999 or 10000 as a constant in
> > the code. Perhaps it's a formatted field overflow from 4 digits to
> > 5 in the y coordinate?
> 
> I think that must be it.  The coordinates sent from x11.trm to
> gnuplot_x11 use format statements like PRINT2("V%04d%04d\n", x, y);
> 
> It looks like either the field width has to be increased everywhere
> to 5 digits, or else the new rescaling code needs to rethought
> (perhaps by adjusting both xsize and ysize rather than only adjusting
> ysize?)  Increasing the field width has the drawback that more bytes
> will be sent over the channel regardless of the window size, which
> can slow down the communication.
> 
> What to do?
> 
> 		Ethan

Hi Ethan.

Good you found the issue. Do you know why field widths are specified at
all? Why don't we PRINT2("V%d %d\n") and then sscanf("%d %d", ...) on
the other side? No efficiency is gained by specifying the widths, it
only builds in limitations and makes the code brittle, as we have just
observed.

I'm attaching a patch that removes hardcoded field sizes from ALL %d
and %u fields. Some extra care had to be taken in places where a
numerical field is followed by a string (%s), since the '4' was
hardcoded in those places too. The bug you described is now gone, and
the code is more robust.

I noticed another, very related issue. x11.trm has

    /* badly outrange labels can overflow into text field */
    if (x < 10000 && y < 10000) {
	PRINT3("T%d %d %s\n", x, y, str);
    }

Here we're hardcoding the 10000 again. This has the effect of not
printing the legend label when the window is skinny (as you were making
it). This test needs to be adjusted or removed entirely; not sure
which. CVS says this test was added by lhecking in 1998. This predates
all of sourceforge. Newsgroup logs go back that far, but I didn't see
any mention of this issue. Thoughts?


Finally, in writing the patch, I stumbled on what looks like a bug in
what looks like dead code. In gplt_x11.c, look at the

    else if (*buffer == X11_GR_FILLED_POLYGON) {	/* filled
    polygon */ ...
    }

block. Look at where the ptr is updated (the ptr += ... lines). I
suspect the 2nd update of this pointer (the one not in an if() or a
while()) was meant to happen only if the first one didn't happen.
Otherwise we're skipping over data we haven't looked at yet. The
attached patch could be wrong here, depending on what is actually
meant. In any case, I can't find anything in the inboard driver that
sends X11_GR_FILLED_POLYGON commands. None of the demos trigger this
block either. I suspect the whole block is dead, and this bug is thus
never hit. If this whole block is truly dead, it should be removed. If
this actually IS called somehow, I'd like to know from where to make
sure the attached patch is good.

dima

Re: [PATCH] x11 terminal respects the requested aspect ratio

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

On Thursday, September 27, 2012 11:41:50 am Ethan A Merritt wrote:
> On Thursday, September 27, 2012 01:40:18 am Dima Kogan wrote:
> > > On Tue, 25 Sep 2012 21:31:55 -0700
> > > "sfeam (Ethan Merritt)" <eam...@gm...> wrote:
> > >
> > > On Saturday, 22 September 2012, Dima Kogan
> > > <gn...@di...> wrote:
> > > > 
> > > > I tackled the long-standing issue of the x11 terminal not
> > > > respecting the requested plot aspect ratio
> > > <snip>
> > > 
> > > Hi Dima.  
> > > 
> > > I've applied your patch to CVS in the development branch after review
> > > and testing. <snip>
> > 
> > Hi Ethan. Thanks for applying the patch. Main difference I noticed so far is
> > that the point sizes appear smaller in the x11 terminal than they were before
> > this patch.
> 
> I have found another problem.  I suspect it may be an integer overflow, but
> if so I can't figure out where.  Here's a simple recipe to show the problem:
> gnuplot> set term x11
> gnuplot> set sample 15
> gnuplot> plot x with points pt 5
> 
> 1) Adjust the X-window so that the plot is very tall.
> 2) Gradually make the plot window narrower and narrower.
>    At some point the top border of the plot stops being correctly drawn near
>    the top of the window;  instead it is drawn near the bottom.
> 
> gnuplot> show var GPVAL_TERM
>         GPVAL_TERM_XMIN = 473
>         GPVAL_TERM_XMAX = 3837
>         GPVAL_TERM_YMIN = 280
>         GPVAL_TERM_YMAX = 10072
>         GPVAL_TERM_XSIZE = 4096
>         GPVAL_TERM_YSIZE = 10245
> 
> The problem seems to trigger when YMAX crosses exactly 10000,
> but I don't see any relevant use of 9999 or 10000 as a constant in the code.
> Perhaps it's a formatted field overflow from 4 digits to 5 in the y coordinate?

I think that must be it.  The coordinates sent from x11.trm to gnuplot_x11 use
format statements like PRINT2("V%04d%04d\n", x, y);

It looks like either the field width has to be increased everywhere to 5 digits,
or else the new rescaling code needs to rethought (perhaps by adjusting both
xsize and ysize rather than only adjusting ysize?)  Increasing the field width
has the drawback that more bytes will be sent over the channel regardless of the
window size, which can slow down the communication.

What to do?

		Ethan


> 
> 
> > I'm attaching another patch that tries to handle the point sizes in
> > the same way as the wxt and qt terminals do. After this, the points look similar
> > to the way they looked before.
> 
> OK, thanks. 
> But please have a look at the problem described above.
> 
> > 
> > dima
> > 
> 
> 	Ethan
> 
> 
> ------------------------------------------------------------------------------
> Everyone hates slow websites. So do we.
> Make your web apps faster with AppDynamics
> Download AppDynamics Lite for free today:
> http://ad.doubleclick.net/clk;258768047;13503038;j?
> http://info.appdynamics.com/FreeJavaPerformanceDownload.html
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
> 

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

Re: [PATCH] x11 terminal respects the requested aspect ratio

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

On Thursday, September 27, 2012 01:40:18 am Dima Kogan wrote:
> > On Tue, 25 Sep 2012 21:31:55 -0700
> > "sfeam (Ethan Merritt)" <eam...@gm...> wrote:
> >
> > On Saturday, 22 September 2012, Dima Kogan
> > <gn...@di...> wrote:
> > > 
> > > I tackled the long-standing issue of the x11 terminal not
> > > respecting the requested plot aspect ratio
> > <snip>
> > 
> > Hi Dima.  
> > 
> > I've applied your patch to CVS in the development branch after review
> > and testing. <snip>
> 
> Hi Ethan. Thanks for applying the patch. Main difference I noticed so far is
> that the point sizes appear smaller in the x11 terminal than they were before
> this patch.

I have found another problem.  I suspect it may be an integer overflow, but
if so I can't figure out where.  Here's a simple recipe to show the problem:
gnuplot> set term x11
gnuplot> set sample 15
gnuplot> plot x with points pt 5

1) Adjust the X-window so that the plot is very tall.
2) Gradually make the plot window narrower and narrower.
   At some point the top border of the plot stops being correctly drawn near
   the top of the window;  instead it is drawn near the bottom.

gnuplot> show var GPVAL_TERM
        GPVAL_TERM_XMIN = 473
        GPVAL_TERM_XMAX = 3837
        GPVAL_TERM_YMIN = 280
        GPVAL_TERM_YMAX = 10072
        GPVAL_TERM_XSIZE = 4096
        GPVAL_TERM_YSIZE = 10245

The problem seems to trigger when YMAX crosses exactly 10000,
but I don't see any relevant use of 9999 or 10000 as a constant in the code.
Perhaps it's a formatted field overflow from 4 digits to 5 in the y coordinate?


> I'm attaching another patch that tries to handle the point sizes in
> the same way as the wxt and qt terminals do. After this, the points look similar
> to the way they looked before.

OK, thanks. 
But please have a look at the problem described above.

> 
> dima
> 

	Ethan

Re: [PATCH] x11 terminal respects the requested aspect ratio

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

> On Tue, 25 Sep 2012 21:31:55 -0700
> "sfeam (Ethan Merritt)" <eam...@gm...> wrote:
>
> On Saturday, 22 September 2012, Dima Kogan
> <gn...@di...> wrote:
> > 
> > I tackled the long-standing issue of the x11 terminal not
> > respecting the requested plot aspect ratio
> <snip>
> 
> Hi Dima.  
> 
> I've applied your patch to CVS in the development branch after review
> and testing. <snip>

Hi Ethan. Thanks for applying the patch. Main difference I noticed so far is
that the point sizes appear smaller in the x11 terminal than they were before
this patch. I'm attaching another patch that tries to handle the point sizes in
the same way as the wxt and qt terminals do. After this, the points look similar
to the way they looked before.

dima

Re: [PATCH] x11 terminal respects the requested aspect ratio

[sfeam (E. Merritt) <eam...@gm...>]

On Saturday, 22 September 2012, Dima Kogan <gn...@di...> wrote:
> 
> I tackled the long-standing issue of the x11 terminal not respecting the
> requested plot aspect ratio. There have been many bugs about this on the
> tracker. The main one appears to be
> 
> http://sourceforge.net/tracker/index.php?func=detail&aid=3331162&group_id=2055&atid=102055
> 
> I have a branch that handles this issue similar to the way the wxt
> terminal does:
> 
> - inboard driver computes a particular x,y scale factors
> - terminal ALWAYS respects this aspect ratio
> - resizing the window does NOT touch the aspect ratio
> - a replot is required to re-compute the scale factors
> 
> Similar to the qt terminal, I added a replot-on-resize option to make
> things 'just work', at the expense of some extra cpu cycles.
> 
> The code works for my test cases, but I had to touch enough stuff to
> make me concerned about cases that I missed. How are such changes
> tested, usually? I didn't see a test suite.

Hi Dima.  

I've applied your patch to CVS in the development branch after review and 
testing.  This is a great addition. Thanks so much!

I made some trivial code changes to conform to coding style and wrapped
the relevant sections with  #ifdef X11  so that it does not affect builds
for non-X11 systems.  Also I flipped the default to "replotonresize",
because at least for me the speed penalty on resizing is negligible, 
while the benefit is clear.  The only actual logic change I made was to
restore the previous on_event() code for terminals other than x11.
I.e., it now reads
#ifdef X11
  if (!strcmp(term->name,"x11")) {
    /* New code */
  } else
#endif
    /* Old code */

Now to go close some old, old feature requests and bug tracker entries.

	Ethan	

Re: problems zooming into plot region

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

On Tue, Sep 25, 2012 at 5:00 PM, Petr Mikulik wrote:
>> ... and thanks to Petr for the hint about the 'u' key to get back to
>> the original range. But then my next question would be - how can I see
>> those shortcuts? I was playing with "help mouse", but that didn't
>> leave me anywhere.
>
> The 'h' is shown in the welcome message after gnuplot start-up:
>
>        G N U P L O T
>         ...
>        immediate help:   type "help"  (plot window: hit 'h')

I believe that I was hitting "h" before, but for some reason it didn't
work. Maybe there was something odd going on (maybe I accidentally
switched to a different keyboard or changed the terminal in the
meantime).

My next feature request will probably be to add an icon (to zoom to
original region) to the top of Qt terminal ;)

I also just remembered that wxt has a very intuitive way to trigger
help. It has a question mark in the GUI and that one suggests to hit
"h". Something similar should be added to Qt terminal.

>>> I would like to hear some
>>> feedback about whether the change is good or bad before deciding whether
>>> to keep it that way for an eventual release in 4.8/5.0.
>>
>>
>> To me it was a huge improvement. I'll use the trunk version for a
>
> I think you can add it to 4.6.1.

I would be very happy for that as well.

Mojca

Re: problems zooming into plot region

[Petr M. <mi...@ph...>]

> ... and thanks to Petr for the hint about the 'u' key to get back to
> the original range. But then my next question would be - how can I see
> those shortcuts? I was playing with "help mouse", but that didn't
> leave me anywhere.

The 'h' is shown in the welcome message after gnuplot start-up:

        G N U P L O T
         ...
        immediate help:   type "help"  (plot window: hit 'h')


>> I would like to hear some
>> feedback about whether the change is good or bad before deciding whether
>> to keep it that way for an eventual release in 4.8/5.0.
>
> To me it was a huge improvement. I'll use the trunk version for a

I think you can add it to 4.6.1.

---
Petr

Re: problems zooming into plot region

[<pl...@pi...>]

On 09/25/12 13:26, Mojca Miklavec wrote:
> On Tue, Sep 25, 2012 at 8:02 AM, sfeam (Ethan Merritt) wrote:
>>> On 09/24/12 16:58, Mojca Miklavec wrote:
>>>> Hello,
>>>>
>>>> I'm curious whether I'm the only one experiencing this problem or if
>>>> this appears to be "a feature" rather than a bug in the eyes of
>>>> developers.
>>>>
>>>> If I use
>>>>      plot [0:] 'datafile.dat' ...
>>>> then I'm unable to zoom into the desired region of a plot with a mouse
>>
>> Bug or feature or historical happenstance, this long-standing behavior has
>> now changed in the CVS version since about 10 days ago.  Please try it out
>> and see if it now behaves more agreeably.
>
> Thank you very much for the hint. I didn't know about that change and
> it actually works much better than in previous versions.
>
>> I would like to hear some
>> feedback about whether the change is good or bad before deciding whether
>> to keep it that way for an eventual release in 4.8/5.0.
>
> To me it was a huge improvement. I'll use the trunk version for a
> while to see if I spot any other problems, but from the first
> impressions I would give a strong vote to keep the new behaviour.
>

Yes, I also find this to be a lot better than the old behaviour. It 
seems obvious if I am trying to set the zoom with the mouse, that I do 
want to do that. Not only is it very disrouting when one axis does not 
change as expected, it meant the user can't control zoom manually which 
is unhelpful.

regards, Peter.

Re: problems zooming into plot region

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

Am 25.09.2012 13:26, schrieb Mojca Miklavec:>
 > ... and thanks to Petr for the hint about the 'u' key to get back to
 > the original range. But then my next question would be - how can I see
 > those shortcuts? I was playing with "help mouse", but that didn't
 > leave me anywhere.

Try pressing 'h' in a plot window.
	Bastian


 >
 > Thank you,
 >     Mojca
 >

Re: problems zooming into plot region

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

On Tue, Sep 25, 2012 at 8:02 AM, sfeam (Ethan Merritt) wrote:
>> On 09/24/12 16:58, Mojca Miklavec wrote:
>> > Hello,
>> >
>> > I'm curious whether I'm the only one experiencing this problem or if
>> > this appears to be "a feature" rather than a bug in the eyes of
>> > developers.
>> >
>> > If I use
>> >     plot [0:] 'datafile.dat' ...
>> > then I'm unable to zoom into the desired region of a plot with a mouse
>
> Bug or feature or historical happenstance, this long-standing behavior has
> now changed in the CVS version since about 10 days ago.  Please try it out
> and see if it now behaves more agreeably.

Thank you very much for the hint. I didn't know about that change and
it actually works much better than in previous versions.

> I would like to hear some
> feedback about whether the change is good or bad before deciding whether
> to keep it that way for an eventual release in 4.8/5.0.

To me it was a huge improvement. I'll use the trunk version for a
while to see if I spot any other problems, but from the first
impressions I would give a strong vote to keep the new behaviour.

... and thanks to Petr for the hint about the 'u' key to get back to
the original range. But then my next question would be - how can I see
those shortcuts? I was playing with "help mouse", but that didn't
leave me anywhere.

Thank you,
   Mojca

Re: problems zooming into plot region

[Petr M. <mi...@ph...>]

>> This does neither work by design:
>>         gnuplot> plot [1:10] sin(x)/x
>>         gnuplot> set xrange [5:8]; replot
>>
>> So why do you use   plot [x1:x2]  instead of  set xrange [x1:x2]?
>
> I find plot [x1:] more intuitive, shorter, one command less to write
> and faster to change from one command to the other.

I see, my findings are exactly opposite :-)

>>> Also, the mouse movement (moving wheel to left & right) which usually
>>> moves the graph to left & right is now zooming in & out instead of
>>> moving the graph.
>>
>> Wheel left and right? Do you have a trackball? I thought it works just as
>> mouse upside-down.
>
> I have a trackpad (http://www.apple.com/magictrackpad/).
>
>> The zooming in-out by +/- hotkeys and mouse wheel up/down implements my
>> patch
>>   [ gnuplot-Patches-3537423 ] zoom by mouse wheel and hotkeys
>> but it's not yet in sources so you have probably applied it yourself.
>
> No, I didn't apply any patch (even though I still want to test your
> patch more extensively) - I was using 4.6 stable branch. In X11 the
> usual mouse wheel is sending out buttons 4 and 5 for scrolling up and
> down, while 6 and 7 are for scrolling left and right. In wxt the
> following code moves left & right for example:
>
> 	mouse_button = (event.GetWheelRotation() > 0 ? 4 : 5);
> #if wxCHECK_VERSION(2, 9, 0)
> 	/* GetWheelAxis: 0 is the Y axis, 1 is the X axis. */
> 	if (event.GetWheelAxis() > 0)
> 	    mouse_button += 2;
> #endif
> 	wxt_exec_event(GE_buttonpress, x, y, mouse_button, 0, this->GetId());
>
>
>> The patch needs some testing ... because people using mouse with wheel like
>> zoom-in/out but people using touchpad expect scrolling instead
>
> Yes, exactly. I can use another "mouse gesture" to zoom in and out.
>
>> (even though it is rather useless for 2d graphs).
>
> Scrolling left and right is not useless for 2d graphs (maybe scrolling
> up and down is way less usable, but left and right is handy).

I meant the vertical scrolling in 2d graphs - zoom (around mouse cursor) is 
more useful.


> Slightly off-topic: what is the magic key combination (or another
> trick) to restore the original x and y range (the one set before
> moving & zooming the graph with the mouse)? I'm now using "p" key, but
> that takes forever to get back to the initial range.

That's the 'u' hotkey:
u = unzoom
a = autoscale
p = previous
n = next

---
Petr

Re: problems zooming into plot region

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

On Tue, Sep 25, 2012 at 8:07 AM, Petr Mikulik wrote:
>> I'm curious whether I'm the only one experiencing this problem or if
>> this appears to be "a feature" rather than a bug in the eyes of
>> developers.
>>
>> If I use
>>   plot [0:] 'datafile.dat' ...
>> then I'm unable to zoom into the desired region of a plot with a mouse
>> by selecting the desired rectangle. It zooms properly to the y axis
>> and (usually) to the right of x axis, but the left of x axis always
>> stays at zero which is a bit annoying.
>
> This does neither work by design:
>         gnuplot> plot [1:10] sin(x)/x
>         gnuplot> set xrange [5:8]; replot
>
> So why do you use   plot [x1:x2]  instead of  set xrange [x1:x2]?

I find plot [x1:] more intuitive, shorter, one command less to write
and faster to change from one command to the other.

> Anayway, Ethan has recently pushed a patch for 4.7 that allows zooming in
> both axes even if you explicitly disable it via plot [] []

I wasn't aware of that. Thanks to both for pointing it out. I'll test
and report. I usually use the trunk version, but I was playing with
4.6 branch.

>> Also, the mouse movement (moving wheel to left & right) which usually
>> moves the graph to left & right is now zooming in & out instead of
>> moving the graph.
>
> Wheel left and right? Do you have a trackball? I thought it works just as
> mouse upside-down.

I have a trackpad (http://www.apple.com/magictrackpad/).

> The zooming in-out by +/- hotkeys and mouse wheel up/down implements my
> patch
>   [ gnuplot-Patches-3537423 ] zoom by mouse wheel and hotkeys
> but it's not yet in sources so you have probably applied it yourself.

No, I didn't apply any patch (even though I still want to test your
patch more extensively) - I was using 4.6 stable branch. In X11 the
usual mouse wheel is sending out buttons 4 and 5 for scrolling up and
down, while 6 and 7 are for scrolling left and right. In wxt the
following code moves left & right for example:

	mouse_button = (event.GetWheelRotation() > 0 ? 4 : 5);
#if wxCHECK_VERSION(2, 9, 0)
	/* GetWheelAxis: 0 is the Y axis, 1 is the X axis. */
	if (event.GetWheelAxis() > 0)
	    mouse_button += 2;
#endif
	wxt_exec_event(GE_buttonpress, x, y, mouse_button, 0, this->GetId());


> The patch needs some testing ... because people using mouse with wheel like
> zoom-in/out but people using touchpad expect scrolling instead

Yes, exactly. I can use another "mouse gesture" to zoom in and out.

> (even though it is rather useless for 2d graphs).

Scrolling left and right is not useless for 2d graphs (maybe scrolling
up and down is way less usable, but left and right is handy). But then
I admit that it is kind of useless in gnuplot which reads and
recalculates the data over and over again for every few pixels I want
to scroll. Scrolling is actually prohibitively slow. If I have 1000
points on the graph, I don't need scrolling. But when I have 1-10
million points, I can basically forget about scrolling.

(Also, qt is prohibitively slow and totally confusing when resizing
the plot. When I want to resize the window to fill almost full screen,
Qt probably sends a couple of hundred "resize events" and gnuplot has
to recalculate the whole plot about a few hundred times. X11 basically
waits until I completely resize the window and draws some nonsense
below [copies of original image] and only redraws the graphic once or
twice, not hundred times.)

Slightly off-topic: what is the magic key combination (or another
trick) to restore the original x and y range (the one set before
moving & zooming the graph with the mouse)? I'm now using "p" key, but
that takes forever to get back to the initial range.

Mojca

Re: problems zooming into plot region

[Petr M. <mi...@ph...>]

> I'm curious whether I'm the only one experiencing this problem or if
> this appears to be "a feature" rather than a bug in the eyes of
> developers.
>
> If I use
>   plot [0:] 'datafile.dat' ...
> then I'm unable to zoom into the desired region of a plot with a mouse
> by selecting the desired rectangle. It zooms properly to the y axis
> and (usually) to the right of x axis, but the left of x axis always
> stays at zero which is a bit annoying.

This does neither work by design:
 	gnuplot> plot [1:10] sin(x)/x
 	gnuplot> set xrange [5:8]; replot

So why do you use   plot [x1:x2]  instead of  set xrange [x1:x2]?

Anayway, Ethan has recently pushed a patch for 4.7 that allows zooming in 
both axes even if you explicitly disable it via plot [] []


> Also, the mouse movement (moving wheel to left & right) which usually
> moves the graph to left & right is now zooming in & out instead of
> moving the graph.

Wheel left and right? Do you have a trackball? I thought it works just as 
mouse upside-down.

The zooming in-out by +/- hotkeys and mouse wheel up/down implements my 
patch
   [ gnuplot-Patches-3537423 ] zoom by mouse wheel and hotkeys
but it's not yet in sources so you have probably applied it yourself.

The patch needs some testing ... because people using mouse with wheel like 
zoom-in/out but people using touchpad expect scrolling instead (even though 
it is rather useless for 2d graphs).

---
Petr

Re: problems zooming into plot region

[sfeam (E. Merritt) <eam...@gm...>]

On Monday, 24 September 2012, pl...@pi... wrote:
> On 09/24/12 16:58, Mojca Miklavec wrote:
> > Hello,
> >
> > I'm curious whether I'm the only one experiencing this problem or if
> > this appears to be "a feature" rather than a bug in the eyes of
> > developers.
> >
> > If I use
> >     plot [0:] 'datafile.dat' ...
> > then I'm unable to zoom into the desired region of a plot with a mouse
> > by selecting the desired rectangle. It zooms properly to the y axis
> > and (usually) to the right of x axis, but the left of x axis always
> > stays at zero which is a bit annoying.
> >      Mojca
> >
> yes. I thought this was a bug too. Once a range is defined explicitly, 
> mouse zooming will not over ride it.
> 
> It is a feature, though I find it obstructive.  I would expect a direct 
> user interaction to over-ride any predetermined range.
> 
> I don't know if there are circumstances where allowing the user to zoom 
> where he needs to would be detrimental. Perhaps s/o could suggest where 
> this may be the wrong thing to allow.
> /peter.


Bug or feature or historical happenstance, this long-standing behavior has
now changed in the CVS version since about 10 days ago.  Please try it out
and see if it now behaves more agreeably.  I would like to hear some
feedback about whether the change is good or bad before deciding whether
to keep it that way for an eventual release in 4.8/5.0.

	Ethan

Re: problems zooming into plot region

[<pl...@pi...>]

On 09/24/12 16:58, Mojca Miklavec wrote:
> Hello,
>
> I'm curious whether I'm the only one experiencing this problem or if
> this appears to be "a feature" rather than a bug in the eyes of
> developers.
>
> If I use
>     plot [0:] 'datafile.dat' ...
> then I'm unable to zoom into the desired region of a plot with a mouse
> by selecting the desired rectangle. It zooms properly to the y axis
> and (usually) to the right of x axis, but the left of x axis always
> stays at zero which is a bit annoying.
>
> Also, the mouse movement (moving wheel to left & right) which usually
> moves the graph to left & right is now zooming in & out instead of
> moving the graph.
>
> Thank you,
>      Mojca
>
yes. I thought this was a bug too. Once a range is defined explicitly, 
mouse zooming will not over ride it.

It is a feature, though I find it obstructive.  I would expect a direct 
user interaction to over-ride any predetermined range.

I don't know if there are circumstances where allowing the user to zoom 
where he needs to would be detrimental. Perhaps s/o could suggest where 
this may be the wrong thing to allow.

/peter.

problems zooming into plot region

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

Hello,

I'm curious whether I'm the only one experiencing this problem or if
this appears to be "a feature" rather than a bug in the eyes of
developers.

If I use
   plot [0:] 'datafile.dat' ...
then I'm unable to zoom into the desired region of a plot with a mouse
by selecting the desired rectangle. It zooms properly to the y axis
and (usually) to the right of x axis, but the left of x axis always
stays at zero which is a bit annoying.

Also, the mouse movement (moving wheel to left & right) which usually
moves the graph to left & right is now zooming in & out instead of
moving the graph.

Thank you,
    Mojca

Re: Any issues that would hold up release of 4.6.1?

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

On Sun, Sep 23, 2012 at 4:35 AM, sfeam (Ethan Merritt) wrote:
>
>> Making install in docs
>> ../../original/mkinstalldirs
>> /Users/m/gnuplot/build-original/inst/share/gnuplot/4.6
>> /opt/local/bin/ginstall -c -m 644 gnuplot.gih
>> /Users/m/gnuplot/build-original/inst/share/gnuplot/4.6/gnuplot.gih
>> make[1]: *** No rule to make target
>> `../../original/docs/gnuplot.texi', needed by `gnuplot.info'.  Stop.
>> make: *** [install-recursive] Error 1
>
> Ah, but here I think you are seeing a difference of building from
> CVS vs. building from the distribution tarball.  The distribution
> tarball explicitly contains an up-to-date copy of gnuplot.texi, so
> it doesn't need to be rebuilt and this make rule is not needed.
>
> Try doing "make gnuplot.texi" manually before your subsequent testing,
> which should reproduce the state saved in the tarball.

It doesn't help. I can only run "make gnuplot.texi" in build tree (I
cannot run it in source tree when doing an out of source build). The
file *is* generated, already now. The problem is that Makefile
declares dependency on gnuplot.texi being present in $(srcdir) and
there is no way that the file can end up there unless it comes as
precompiled in distribution.

What about trying to copy the file explicitly if already present (in
the same way as 'gnuplot.doc')?

@@ -389,18 +389,20 @@ wxhelp/doc2html: wxhelp/doc2html.o termdoc.o
xref.o ../src/version.o
 ### GNU info format
 info: gnuplot.info

-gnuplot.info: $(srcdir)/gnuplot.texi
-	$(MAKEINFO) -I$(srcdir) $(srcdir)/gnuplot.texi --no-split --output=$@
+gnuplot.info: gnuplot.texi
+	$(MAKEINFO) -I$(srcdir) gnuplot.texi --no-split --output=$@

 # Thanks to Bruce Ravel for doc2texi.el!
 gnuplot.texi $(srcdir)/gnuplot-eldoc.el $(srcdir)/gnuplot-eldoc.elc:
$(srcdir)/doc2texi.el $(srcdir)/gnuplot.doc
 	@echo "Creating texinfo and eldoc strings file"
 	@if test "$(EMACS)" != no; then \
-	   @test "$(top_srcdir)" = "$(top_builddir)" || echo "COPYING GNUPLOT.DOC" ; \
-	   @test "$(top_srcdir)" = "$(top_builddir)" || cp $(srcdir)/gnuplot.doc . ; \
+	   test "$(top_srcdir)" = "$(top_builddir)" || echo "COPYING GNUPLOT.DOC" ; \
+	   test "$(top_srcdir)" = "$(top_builddir)" || cp $(srcdir)/gnuplot.doc . ; \
 	   $(EMACS) -batch -l $(srcdir)/doc2texi.el -f d2t-doc-to-texi ; \
 	   echo "Compiling gnuplot-eldoc.el" ; \
 	   $(EMACS) -batch --eval='(byte-compile-file "gnuplot-eldoc.el")' ; \
+	elif [ "$(top_srcdir)" != "$(top_builddir)" ] && [ -f
$(srcdir)/gnuplot.texi ]; then \
+		cp $(srcdir)/gnuplot.texi . ; \
 	else \
 	   echo "No emacs found - cannot create texinfo file" ; \
 	fi

I didn't test this patch extensively yet - I would first like to know
if the idea would be acceptable.

Mojca

Re: [PATCH] x11 terminal respects the requested aspect ratio

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

> On Sun, 23 Sep 2012 11:04:18 -0700
> "sfeam (Ethan Merritt)" <eam...@gm...> wrote:
>
> Several demos rely on "set size square", notably including
> 	poldat.dem polar.dem
> These work well with your patch.
> 
> We don't seem to have a demo that exercises "set view equal xyz".
> That would be a nice addition.
> 
> It's hard to make a test suite for manual interaction with the 
> terminal window.  What did you have in mind?

It would be a large undertaking to write a reliable tester that
actually looks at the generated output, so I'm not suggesting anything
in particular. I did manually test

- 2d, 3d plots
- pressing '7' and 'e' multiple times
- resizing windows
- starting with various aspect ratio settings
- all of the above in various combinations

I did NOT test

- multiplots
- switching terminals (i.e. making sure that nothing
  blows up when you set term pdf, and then set term x11 again)
- fancier x11 features, such as plotting into embedded windows
- any OS other than amd64 Debian
- any window manager other than ion3

These things are complicated, so subtle regressions may have been
introduced. I built a package with the patch, and will use it as my
everyday plotter for a while to at least exercise the common cases. If
some people on this list try it out as well, that'd be great.


> > As an aside, the main reason I'm touching the x11 terminal at all
> > (instead of just moving to wxt or qt) is that it appears to be much
> > faster than the newer terminals. Particularly, if you have a 3d plot
> > with lots of points, interactively rotating the data is noticeably
> > much snappier with x11. Is this expected?
> 
> I suppose so.  The x11 output goes through fewer layers of processing
> and buffer transfer.  Also it isn't being antialiased or
> oversampled. Still, for plots containing only points and lines I find
> the 3D response in both wxt and qt to be perfectly acceptable.
> 
> Both the wxt and qt terminals allow you to disable antialiasing and 
> oversampling;  that may or may not make a noticeable difference to
> your particular plots. 3D image plots are another story, slower,
> particularly in qt. 
> 
> Note the following caveat about the speed of qt rendering
> [from "help set term qt"]
>  
>  The Qt rendering speed is affected strongly by the rendering mode
> used. In Qt version 4.7 or newer this can be controlled by the
> environmental variable QT_GRAPHICSSYSTEM. The options are "native",
> "raster", or "opengl" in order of increasing rendering speed.  For
> earlier versions of Qt the terminal defaults to "raster".

When I did these tests a few months ago, x11 was by far the most
responsive, even after turning off all fancy rendering options in the
newer terminals (antialiasing and such). I'm perfectly happy to just
use the x11 terminal, so at least for me these aren't major issues.

dima

Re: [PATCH] x11 terminal respects the requested aspect ratio

[sfeam (E. Merritt) <eam...@gm...>]

On Saturday, 22 September 2012, gn...@di... wrote:
> Hi all.
> 
> I tackled the long-standing issue of the x11 terminal not respecting the
> requested plot aspect ratio. 

That's great.  
As you say, It has been a very long-standing request.

> I have a branch that handles this issue similar to the way the wxt
> terminal does:
> 
> - inboard driver computes a particular x,y scale factors
> - terminal ALWAYS respects this aspect ratio
> - resizing the window does NOT touch the aspect ratio
> - a replot is required to re-compute the scale factors
> 
> Similar to the qt terminal, I added a replot-on-resize option to make
> things 'just work', at the expense of some extra cpu cycles.
> 
> The code works for my test cases, but I had to touch enough stuff to
> make me concerned about cases that I missed. How are such changes
> tested, usually? I didn't see a test suite.

Several demos rely on "set size square", notably including
	poldat.dem polar.dem
These work well with your patch.

We don't seem to have a demo that exercises "set view equal xyz".
That would be a nice addition.

It's hard to make a test suite for manual interaction with the 
terminal window.  What did you have in mind?


 > The code is in a git repo at
> 
> https://github.com/dkogan/gnuplot
> 
> I'm also attaching a patch for a diff from the latest code in CVS, as
> of Sep 2012.
> 
> As an aside, the main reason I'm touching the x11 terminal at all
> (instead of just moving to wxt or qt) is that it appears to be much
> faster than the newer terminals. Particularly, if you have a 3d plot
> with lots of points, interactively rotating the data is noticeably much
> snappier with x11. Is this expected?

I suppose so.  The x11 output goes through fewer layers of processing
and buffer transfer.  Also it isn't being antialiased or oversampled.  
Still, for plots containing only points and lines I find the 3D response
in both wxt and qt to be perfectly acceptable.

Both the wxt and qt terminals allow you to disable antialiasing and 
oversampling;  that may or may not make a noticeable difference to your
particular plots. 3D image plots are another story, slower, particularly 
in qt. 

Note the following caveat about the speed of qt rendering
[from "help set term qt"]
 
 The Qt rendering speed is affected strongly by the rendering mode used.
 In Qt version 4.7 or newer this can be controlled by the environmental
 variable QT_GRAPHICSSYSTEM. The options are "native", "raster", or
 "opengl" in order of increasing rendering speed.  For earlier versions
 of Qt the terminal defaults to "raster".

It should note that there may be additional platform-dependent 
rendering options (e.g. "openvg" on symbian).

	Ethan

Re: [PATCH] x11 terminal respects the requested aspect ratio

[<pl...@pi...>]

On 09/23/12 01:14, gn...@di... wrote:
> As an aside, the main reason I'm touching the x11 terminal at all
> (instead of just moving to wxt or qt) is that it appears to be much
> faster than the newer terminals. Particularly, if you have a 3d plot
> with lots of points, interactively rotating the data is noticeably much
> snappier with x11. Is this expected?
>
> dima

  I'll have to try x11 again, I've been doing some 3D plots this week, 
Smoother , fast rotation would be nice.

I'm in the habit of using wxt since it looks a little less "bare-bones" 
than x11 and the button functions are useful.

Since both qt and wxt end up driving x11 windows,  it would be expected 
that working directly with x11 would be more efficient.

Thanks for the patch.

Peter.

Re: [PATCH] x11 terminal respects the requested aspect ratio

[Daniel J S. <dan...@ie...>]

On 09/22/2012 06:14 PM, gn...@di... wrote:
> Hi all.
>
> I tackled the long-standing issue of the x11 terminal not respecting the
> requested plot aspect ratio. There have been many bugs about this on the
> tracker. The main one appears to be
>
> http://sourceforge.net/tracker/index.php?func=detail&aid=3331162&group_id=2055&atid=102055
>
> I have a branch that handles this issue similar to the way the wxt
> terminal does:
>
> - inboard driver computes a particular x,y scale factors
> - terminal ALWAYS respects this aspect ratio
> - resizing the window does NOT touch the aspect ratio
> - a replot is required to re-compute the scale factors
>
> Similar to the qt terminal, I added a replot-on-resize option to make
> things 'just work', at the expense of some extra cpu cycles.
>
> The code works for my test cases, but I had to touch enough stuff to
> make me concerned about cases that I missed. How are such changes
> tested, usually? I didn't see a test suite.
>
> The code is in a git repo at
>
> https://github.com/dkogan/gnuplot
>
> I'm also attaching a patch for a diff from the latest code in CVS, as
> of Sep 2012.
>
> As an aside, the main reason I'm touching the x11 terminal at all
> (instead of just moving to wxt or qt) is that it appears to be much
> faster than the newer terminals. Particularly, if you have a 3d plot
> with lots of points, interactively rotating the data is noticeably much
> snappier with x11. Is this expected?

I'm not sure many of us here know what to expect given limited 
experience with Qt.  I thought I had read there is somewhere that Qt can 
be tweaked to refresh at a faster rate.  I suspect too that Qt terminal 
is doing much more internally, such as anti-aliasing and/or alpha 
scaling.  X11 terminal is really efficient code but has limited features 
on account of the limited nature of X terminals.

Anyway, I think X11 is still something good to have around.  Some 
systems might not have Qt installed for whatever reason.

Dan

Re: [PATCH] x11 terminal respects the requested aspect ratio

[Jonathan T. <jt...@as...>]

On Sat, 22 Sep 2012, gn...@di... wrote:
> As an aside, the main reason I'm touching the x11 terminal at all
> (instead of just moving to wxt or qt) is that it appears to be much
> faster than the newer terminals. Particularly, if you have a 3d plot
> with lots of points, interactively rotating the data is noticeably much
> snappier with x11.

Another advantage of the x11 terminal is that (in my experience
on various slightly unusual Unix-flavored systems) it's often easier
to build gnuplot with x11 terminal support than with wxt or qt support.

ciao,

-- 
-- "Jonathan Thornburg [remove -animal to reply]" <jt...@as...>
   Dept of Astronomy & IUCSS, Indiana University, Bloomington, Indiana, USA
   on sabbatical in Canada starting August 2012
   "Washing one's hands of the conflict between the powerful and the
    powerless means to side with the powerful, not to be neutral."
                                      -- quote by Freire / poster by Oxfam

Re: Any issues that would hold up release of 4.6.1?

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

On Sun, Sep 23, 2012 at 12:09 AM, sfeam (Ethan Merritt) wrote:
>
> After fighting with this all day yesterday, I decided to instead
> backport the emacs+info related Makefile scripting from 4.7 to 4.6.
> Please let me know whether the modified .../docs/Makefile.in
> from today's CVS resolves your out-of-source build problems.

Thank you very much.

The "make" phase seems to work without any problems (including usage
of obscure emacs, but only in branch 4.6, not yet in trunk), but the
"make install" fails here:

Making install in docs
../../original/mkinstalldirs
/Users/m/gnuplot/build-original/inst/share/gnuplot/4.6
/opt/local/bin/ginstall -c -m 644 gnuplot.gih
/Users/m/gnuplot/build-original/inst/share/gnuplot/4.6/gnuplot.gih
make[1]: *** No rule to make target
`../../original/docs/gnuplot.texi', needed by `gnuplot.info'.  Stop.
make: *** [install-recursive] Error 1

I first naively tried adding $(srcdir) in front of gnuplot.texi:

--- a/docs/Makefile.in
+++ b/docs/Makefile.in
@@ -393,7 +393,7 @@ gnuplot.info: $(srcdir)/gnuplot.texi
        $(MAKEINFO) -I$(srcdir) $(srcdir)/gnuplot.texi --no-split --output=$@

 # Thanks to Bruce Ravel for doc2texi.el!
-gnuplot.texi $(srcdir)/gnuplot-eldoc.el $(srcdir)/gnuplot-eldoc.elc:
$(srcdir)/doc2texi.el $(srcdir)/gnuplot.doc
+$(srcdir)/gnuplot.texi $(srcdir)/gnuplot-eldoc.el
$(srcdir)/gnuplot-eldoc.elc: $(srcdir)/doc2texi.el
$(srcdir)/gnuplot.doc
        @echo "Creating texinfo and eldoc strings file"
        @if test "$(EMACS)" != no; then \
           @test "$(top_srcdir)" = "$(top_builddir)" || echo "COPYING
GNUPLOT.DOC" ; \

which made the "make install" proceed a lot further. In particular,
the same chunk proceeded with


Making install in docs
../../original/mkinstalldirs
/Users/m/gnuplot/build-original/inst/share/gnuplot/4.6
/opt/local/bin/ginstall -c -m 644 gnuplot.gih
/Users/m/gnuplot/build-original/inst/share/gnuplot/4.6/gnuplot.gih
Creating texinfo and eldoc strings file
/bin/sh: @test: command not found
COPYING GNUPLOT.DOC
/bin/sh: @test: command not found
Loading /opt/local/share/emacs/site-lisp/subdirs.el (source)...
Inserting help for terminals ...
Analyzing doc file ...
Converting to texinfo ...
Menus, nodes, xrefs ...
Loading texinfo...
Making texinfo nodes ...

(I pasted this portion because I wasn't sure if "@test: command not
found" was something to be expected or not.)

But then it failed at

Updated level "3" menu following node: Bugs ...
Making or updating menus in *doc2texi*...done
Done...updated all the menus.  You may save the buffer.
Saving file /Users/m/gnuplot/build-original/docs/gnuplot.texi...
Wrote /Users/m/gnuplot/build-original/docs/gnuplot.texi
Compiling gnuplot-eldoc.el
Loading /opt/local/share/emacs/site-lisp/subdirs.el (source)...
Wrote /Users/m/gnuplot/build-original/docs/gnuplot-eldoc.elc
/bin/sh /Users/m/gnuplot/original/missing --run makeinfo
-I../../original/docs ../../original/docs/gnuplot.texi --no-split
--output=gnuplot.info
../../original/docs/gnuplot.texi: No such file or directory
make[1]: *** [gnuplot.info] Error 1
make: *** [install-recursive] Error 1

I was able to fix this by replacing
    $(MAKEINFO) -I$(srcdir) $(srcdir)/gnuplot.texi --no-split --output=$@
with
    $(MAKEINFO) -I$(srcdir) gnuplot.texi --no-split --output=$@

The problem was that gnuplot.texi was only inside build/docs/, not
inside sources.


All in all, the following patch solved the problem for me (the first
part is commented out and I didn't test anything there):

--- a/docs/Makefile.in
+++ b/docs/Makefile.in
@@ -237,8 +237,8 @@ doc2ms.o: doc2ms.c $(BUILT_SOURCES)
 html: htmldocs/gnuplot.html

 # requires makeinfo (GNU texinfo) 4.0 or better
-# htmldocs/gnuplot.html: $(srcdir)/gnuplot.texi
-#	$(MAKEINFO) --html -I$(srcdir) $(srcdir)/gnuplot.texi --no-split --output=$@
+# htmldocs/gnuplot.html: gnuplot.texi
+#	$(MAKEINFO) --html -I$(srcdir) gnuplot.texi --no-split --output=$@

 # requires a working latex2html, which is hard to find these days
 # htmldocs/gnuplot.html: $(srcdir)/gnuplot.tex
@@ -389,8 +389,8 @@ wxhelp/doc2html: wxhelp/doc2html.o termdoc.o
xref.o ../src/version.o
 ### GNU info format
 info: gnuplot.info

-gnuplot.info: $(srcdir)/gnuplot.texi
-	$(MAKEINFO) -I$(srcdir) $(srcdir)/gnuplot.texi --no-split --output=$@
+gnuplot.info: gnuplot.texi
+	$(MAKEINFO) -I$(srcdir) gnuplot.texi --no-split --output=$@

 # Thanks to Bruce Ravel for doc2texi.el!
 gnuplot.texi $(srcdir)/gnuplot-eldoc.el $(srcdir)/gnuplot-eldoc.elc:
$(srcdir)/doc2texi.el $(srcdir)/gnuplot.doc

But the patch might need a second pair of eyes to confirm that it
actually makes sense.

Mojca

PS: gnuplot then crashed during distcheck, but that might be a problem
of underlying libraries, and in any case completely unrelated:

(process:9196): Pango-CRITICAL **: void
pango_fontset_foreach(PangoFontset *, PangoFontsetForeachFunc,
gpointer): assertion `PANGO_IS_FONTSET (fontset)' failed

(process:9196): Pango-WARNING **: failed to choose a font, expect ugly
output. engine-type='PangoRenderCoreText', script='common'

(process:9196): GLib-GObject-CRITICAL **: g_object_ref: assertion
`G_IS_OBJECT (object)' failed

(process:9196): Pango-WARNING **: couldn't load font "frscript
Not-Rotated 400", modified variant/weight/stretch as fallback, expect
ugly output.

(process:9196): GLib-GObject-CRITICAL **: g_object_ref: assertion
`G_IS_OBJECT (object)' failed

(process:9196): Pango-ERROR **: Could not load fallback font, bailing out.
/bin/sh: line 1:  9196 Trace/BPT trap: 5       PATH=$bdir/../src:$PATH
GNUPLOT_DRIVER_DIR=$bdir/../src GNUPLOT_LIB=../../demo gnuplot all.dem
< /dev/null
make[3]: *** [check-noninteractive] Error 133
make[2]: *** [check-am] Error 2
make[1]: *** [check-recursive] Error 1
make: *** [distcheck] Error 1

[PATCH] x11 terminal respects the requested aspect ratio

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

Hi all.

I tackled the long-standing issue of the x11 terminal not respecting the
requested plot aspect ratio. There have been many bugs about this on the
tracker. The main one appears to be

http://sourceforge.net/tracker/index.php?func=detail&aid=3331162&group_id=2055&atid=102055

I have a branch that handles this issue similar to the way the wxt
terminal does:

- inboard driver computes a particular x,y scale factors
- terminal ALWAYS respects this aspect ratio
- resizing the window does NOT touch the aspect ratio
- a replot is required to re-compute the scale factors

Similar to the qt terminal, I added a replot-on-resize option to make
things 'just work', at the expense of some extra cpu cycles.

The code works for my test cases, but I had to touch enough stuff to
make me concerned about cases that I missed. How are such changes
tested, usually? I didn't see a test suite.

The code is in a git repo at

https://github.com/dkogan/gnuplot

I'm also attaching a patch for a diff from the latest code in CVS, as
of Sep 2012.

As an aside, the main reason I'm touching the x11 terminal at all
(instead of just moving to wxt or qt) is that it appears to be much
faster than the newer terminals. Particularly, if you have a 3d plot
with lots of points, interactively rotating the data is noticeably much
snappier with x11. Is this expected?

dima