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

Re: How to reset the x/yrange?

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

On Thu, Dec 8, 2011 at 22:36, Ethan Merritt wrote:
> On Thursday, December 08, 2011 01:26:54 pm Mojca Miklavec wrote:
>> Dear gnuplotters,
>>
>> I'm sorry for the slightly weird question, but I'm experiencing a
>> weird behaviour with x11 terminal (under Mac OS X; I used to use Aqua
>> a lot so far, so I'm not very familiar with mouse events ...).
>>
>> If I run
>>     plot 'somedata' w l
>> and then zoom into the data with mouse's scroll wheel (+shift and
>> ctrl), I'm unable to reset the range back to the original one. replot
>> has zero effect. Another plot just leaves the range where mouse left
>> it last.
>
> Correct. "replot" does not change the current range of the plot.
> You can can type "unzoom" to return to the original scale, or
> you can step back and forth through previous zoom operations by
> using the 'p' or 'n' hotkeys in the plot window.

Thank you.

The keys p and n help (it may happen that one has to hold 'p' for a
very very long time though if there were many iterations done with a
mouse), however 'unzoom' is not recognized.

> If you had trouble finding this information in the help system
> or documentation, please tell us where you tried to look so that
> we can add appropriate cross-indexing or a new section.

Mostly 'help xrange'. (The entry 'zoom' doesn't exist in help either,
but I didn't even think about using it until you suggested to type
unzoom.)

I've seen key kommands in wxt nicely documented somewhere (I'm trying
to install wxwidgets now, I don't remember how exactly it is done
there), but the same documentation is missing in x11, probably also
because it takes quite some space and many experienced users might
start complaining if a big bunch of help text pops up :)

But even now that I know about p & n: how can I reset the range for
plotting data to the same state as when gnuplot is started? So that it
doesn't default to [-10:10][5:5], but adjust to data range instead.

Thank you very much,
     Mojca

Re: How to reset the x/yrange?

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

On Thursday, December 08, 2011 01:26:54 pm Mojca Miklavec wrote:
> Dear gnuplotters,
> 
> I'm sorry for the slightly weird question, but I'm experiencing a
> weird behaviour with x11 terminal (under Mac OS X; I used to use Aqua
> a lot so far, so I'm not very familiar with mouse events ...).
> 
> If I run
>     plot 'somedata' w l
> and then zoom into the data with mouse's scroll wheel (+shift and
> ctrl), I'm unable to reset the range back to the original one. replot
> has zero effect. Another plot just leaves the range where mouse left
> it last.

Correct. "replot" does not change the current range of the plot.
You can can type "unzoom" to return to the original scale, or
you can step back and forth through previous zoom operations by
using the 'p' or 'n' hotkeys in the plot window.

If you had trouble finding this information in the help system
or documentation, please tell us where you tried to look so that
we can add appropriate cross-indexing or a new section.

	Ethan



> 
> I can do
>     set xrange restore
>     set yrange restore
> but this only sets the range to [-10:10] [-5:5] and any subsequent
> plot without an explicit range will fail to produce any useful result
> unless I quit gnuplot and start it again.
> 
> I would be grateful for any hints. Thank you,
>     Mojca
> 
> ------------------------------------------------------------------------------
> Cloud Services Checklist: Pricing and Packaging Optimization
> This white paper is intended to serve as a reference, checklist and point of 
> discussion for anyone considering optimizing the pricing and packaging model 
> of a cloud services business. Read Now!
> http://www.accelacomm.com/jaw/sfnl/114/51491232/
> _______________________________________________
> 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

How to reset the x/yrange?

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

Dear gnuplotters,

I'm sorry for the slightly weird question, but I'm experiencing a
weird behaviour with x11 terminal (under Mac OS X; I used to use Aqua
a lot so far, so I'm not very familiar with mouse events ...).

If I run
    plot 'somedata' w l
and then zoom into the data with mouse's scroll wheel (+shift and
ctrl), I'm unable to reset the range back to the original one. replot
has zero effect. Another plot just leaves the range where mouse left
it last.

I can do
    set xrange restore
    set yrange restore
but this only sets the range to [-10:10] [-5:5] and any subsequent
plot without an explicit range will fail to produce any useful result
unless I quit gnuplot and start it again.

I would be grateful for any hints. Thank you,
    Mojca

Re: plot range blocking interactive zoom

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

On 12/03/11 17:38, Ethan Merritt wrote:
> On Friday, 02 December 2011, pl...@pi... wrote:
>> Hi,
>>
>> someone may tell me this is a feature but it seems anomalous.
>>
>> if I specify a range in the plot command , interactive zoom feature is
>> unable to change the zoom view.
>
> zoom works internally by issuing a "replot" command.
> If you make the range a part of the plot command, then it is
> re-executed each time the zoom tries to replot.
>
> I personally find the inclusion of ranges in the plot command
> to be a poorly designed feature, and recommend against using it.
> At best it saves about 7 characters of typing. For this you give
> up being able to zoom or use "replot" after adjusting the range
> from the command line.
>
> 	Ethan
>
>

Ah, thank you!

maybe this should be pointed out in the doc. It is not at all obvious. 
Perhaps following this text in help plot:

  Ranges specified on the `plot` or `splot` command line affect only that
  graph; use the `set xrange`, `set yrange`, etc., commands to change the
  default ranges for future graphs.

++
Since the interactive terminals work by calling replot , specifying a 
range in the plot command will prevent interactive zooming from being 
able to change it. To avoid this use set xrange etc.


regards, Peter.



>
>>
>> Even if I manually rest xrange I cannot zoom it.
>>
>> plot [-4:16] datafile ....
>> show all
>>           set xrange [ * : * ] noreverse nowriteback  # (currently
>> [-4.00000:16.0000] )
>>
>>
>> I now select a rectangle to zoom in wxt. Y zooms X remains unchanged.
>> However, if I look at the variables my interaction has set xr , it is
>> just not respected in the display.
>>
>> show all
>>           set xrange [ -0.914620 : 5.53985 ] noreverse nowriteback
>>
>> Equally setting xr from the prompt has not effect, a refresh does not
>> change the display. Contrariwise, setting yr is effective.,
>>
>> Unless there's some subtlety I'm missing this seems like a bug.
>>
>> I'm running cvs from a couple of weeks back, but I noticed this 6-12m
>> ago . I was never sure why it was happening so did not report.
>>
>> (also reported on windoze build)
>>
>>
>> regards, Peter.
>>
>>










>> ------------------------------------------------------------------------------
>> All the data continuously generated in your IT infrastructure
>> contains a definitive record of customers, application performance,
>> security threats, fraudulent activity, and more. Splunk takes this
>> data and makes sense of it. IT sense. And common sense.
>> http://p.sf.net/sfu/splunk-novd2d
>> _______________________________________________
>> gnuplot-beta mailing list
>> gnu...@li...
>> https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
>>
>
>

Re: plot range blocking interactive zoom

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

On Friday, 02 December 2011, pl...@pi... wrote:
> Hi,
> 
> someone may tell me this is a feature but it seems anomalous.
> 
> if I specify a range in the plot command , interactive zoom feature is 
> unable to change the zoom view.

zoom works internally by issuing a "replot" command.
If you make the range a part of the plot command, then it is
re-executed each time the zoom tries to replot.

I personally find the inclusion of ranges in the plot command
to be a poorly designed feature, and recommend against using it.
At best it saves about 7 characters of typing. For this you give
up being able to zoom or use "replot" after adjusting the range
from the command line.

	Ethan



> 
> Even if I manually rest xrange I cannot zoom it.
> 
> plot [-4:16] datafile ....
> show all
>          set xrange [ * : * ] noreverse nowriteback  # (currently 
> [-4.00000:16.0000] )
> 
> 
> I now select a rectangle to zoom in wxt. Y zooms X remains unchanged. 
> However, if I look at the variables my interaction has set xr , it is 
> just not respected in the display.
> 
> show all
>          set xrange [ -0.914620 : 5.53985 ] noreverse nowriteback
> 
> Equally setting xr from the prompt has not effect, a refresh does not 
> change the display. Contrariwise, setting yr is effective.,
> 
> Unless there's some subtlety I'm missing this seems like a bug.
> 
> I'm running cvs from a couple of weeks back, but I noticed this 6-12m 
> ago . I was never sure why it was happening so did not report.
> 
> (also reported on windoze build)
> 
> 
> regards, Peter.
> 
> 
> ------------------------------------------------------------------------------
> All the data continuously generated in your IT infrastructure 
> contains a definitive record of customers, application performance, 
> security threats, fraudulent activity, and more. Splunk takes this 
> data and makes sense of it. IT sense. And common sense.
> http://p.sf.net/sfu/splunk-novd2d
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
> 

plot range blocking interactive zoom

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

Hi,

someone may tell me this is a feature but it seems anomalous.

if I specify a range in the plot command , interactive zoom feature is 
unable to change the zoom view.

Even if I manually rest xrange I cannot zoom it.

plot [-4:16] datafile ....
show all
         set xrange [ * : * ] noreverse nowriteback  # (currently 
[-4.00000:16.0000] )


I now select a rectangle to zoom in wxt. Y zooms X remains unchanged. 
However, if I look at the variables my interaction has set xr , it is 
just not respected in the display.

show all
         set xrange [ -0.914620 : 5.53985 ] noreverse nowriteback

Equally setting xr from the prompt has not effect, a refresh does not 
change the display. Contrariwise, setting yr is effective.,

Unless there's some subtlety I'm missing this seems like a bug.

I'm running cvs from a couple of weeks back, but I noticed this 6-12m 
ago . I was never sure why it was happening so did not report.

(also reported on windoze build)


regards, Peter.

[Fwd: Software Requirements Analysis]

[Lars H. <lhe...@us...>]

----- Forwarded message from des20 <de...@us...> -----

Date: Tue, 29 Nov 2011 03:44:56 -0500
From: des20 <de...@us...>
Subject: Software Requirements Analysis

Hi ..
i would like to know if there is a Software Requirements Analysis for the 
gnuplot development...because if it does not i would like to create it...
Thanks...


----- End forwarded message -----

Fw: Re: corruption of version.c in current cvs source

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

Hello 

I have forgotten to reply to the beta list

--- Tatsuro MATSUOKA  wrote:

> From: Tatsuro MATSUOKA 
> Subject: Re: corruption of version.c in current cvs source
> To: "Ethan Merritt" 
> Date: Sat, 26 Nov 2011 05:51:55 +0900
> 
> Hello
> 
> --- On Fri, 2011/11/25, Ethan Merritt wrote:
> 
> > On Thursday, 24 November 2011, Tatsuro MATSUOKA wrote:
> > > Hello
> > > 
> > > In cvs source dated at 2011-11-24, version.c is corrupted.  
> > > 
> > > 44: <<<<<<< version.c
> > > 45: const char gnuplot_date[] = "2011-11-12";
> > > 46: =======
> > > 47: const char gnuplot_date[] = "2011-11-24";
> > > 48: >>>>>>> 1.101
> > 
> > Could that be a merging conflict on your local machine?
> > The source files on Sourceforge contain instead:
> > 
> > 44: const char gnuplot_date{} = "November 2011";
> > 
> > I suggest that you delete that file and then repeat
> > the "cvs update" command.
> 
> > > 47: const char gnuplot_date[] = "2011-11-24";
> The part of "2011-11-24" was modified by myself.
> I have checked out the cvs source at home, no correption is found.
> 
> Anyway thank you for your reply.
> 
> Regards
> 
> Tatsuro
> 

corruption of version.c in current cvs source

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

Hello

In cvs source dated at 2011-11-24, version.c is corrupted.  

44: <<<<<<< version.c
45: const char gnuplot_date[] = "2011-11-12";
46: =======
47: const char gnuplot_date[] = "2011-11-24";
48: >>>>>>> 1.101

Comment out line 44, 45, 46, and 48, compile went well.
Please correct the above.

Regards

Tatsuro

Re: Suggestion: array should be supported

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

On Tuesday, November 22, 2011 11:22:09 pm gbliu wrote:
 
> By the way, there seems to be a small bug:
> gnuplot> s="a"
> gnuplot> i=1
> gnuplot> pr "a".1
>                 ^
>           ';' expected


Not really a bug.  The command is truly ambiguous because
".1" could be parsed as either the number one tenth or the
string concatenation operator followed by the integer 1.
Notice that
   print "A" . 1
works as expected because now there is a space between the
dot and the 1, removing the ambiguity. 

	Ethan



> gnuplot> pr "a".i
> a1
> gnuplot> pr s.1
>               ^
>           ';' expected
> gnuplot> pr s.i
> a1
> 
> So, only  value("a".i)  and value(s.i) works, and value("a".1) and 
> value(s.1) report errors. Is this a bug?
> 
> 
> 
> 
> 

Re: svg mouse coords in zoom

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

On Wednesday, November 23, 2011 11:40:43 am Tait wrote:
> 
> How does the SVG zooming work? I can't seem to get it in any browser.
> 
> 
> > I thought IE could not even render SVG at all. The only option being a
> > buggy and discontinued Abobe plug-in.  Such a platform is not even worth
> > testing on.
> 
> Internet Explorer was slow to support SVG, but it does have (fairly
> comprehensive, as far as I can tell) support now. IE represents the
> largest single market share of any browser, at around 35-50% of the
> total (depending on who's measuring), so personal religious views
> notwithstanding, it can't just be ignored.

You are performing a slight-of-hand trick there.
The only way that IE can be counted as having that large a market
share is if you include all the older versions.  But those versions
don't support SVG.   IE9 per se has ~25% share on Windows 7, 
but most of the Windows world isn't yet using Windows 7.

Anyhow, the issue here is not religious views. It's just a matter of
working code. If you have a pointer to a coding example that handles
svg + scroll bars in IE9, please send it to me so I can have a look.
Or even just report back whether the current CVS version of gnuplot_svg.js
does or does not work in IE9.  Maybe they've unexpectedly decided to
be consistent with Firefox :-)

	Ethan



> Mobile browsers are still a small fragment of the market at around 5%
> (nearly on-par with Opera), but their share will doubtless grow. My mobile
> browser doesn't appear to support SVG at all.

Re: svg mouse coords in zoom

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

How does the SVG zooming work? I can't seem to get it in any browser.


> I thought IE could not even render SVG at all. The only option being a
> buggy and discontinued Abobe plug-in.  Such a platform is not even worth
> testing on.

Internet Explorer was slow to support SVG, but it does have (fairly
comprehensive, as far as I can tell) support now. IE represents the
largest single market share of any browser, at around 35-50% of the
total (depending on who's measuring), so personal religious views
notwithstanding, it can't just be ignored.

Mobile browsers are still a small fragment of the market at around 5%
(nearly on-par with Opera), but their share will doubtless grow. My mobile
browser doesn't appear to support SVG at all.

Re: New stable CVS branch for version 4.6 on SourceForge

[Peter J. <pet...@gm...>]

On Wed, Nov 23, 2011 at 7:23 AM, sfeam (Ethan Merritt)
<eam...@gm...> wrote:
> Hi all,

[...]

> - Last time we put out a testing version (release candidate) prior to
>  releasing 4.4.0. There were some fairly serious problems picked up
>  by people testing the release candidate.

This is a strong argument for putting out a release candidate this time as well.

>  But recently we have been
>  getting a lot of feedback from people using the development version
>  itself,  much more then we had prior to releasing 4.4.  So we may
>  not need a separate pre-release testing version this time.
>  What do you think?
>

If we anticipate that most of the problems with the 4.6 branch will
have been already caught by the people using the development version
by the time of the release, we could perhaps shorten the wait time
before the "real" 4.6.0 release, but I'd say we shouldn't skip the RC.

> The option is still on the table to name the next release 5.0 rather
> than 4.6.  If you care, please speak up.

I vote 4.6 (assuming there is a vote and I can participate in it).

There was a long list of issues that could or should be fixed in a
potentially compatibility-breaking way. However, I doubt that there is
enough time (both in the sense of wallclock time and programmer time)
to
actually implement and test these fixes before the targeted release date.

(Unless we want to do a Linus and follow the current versioning fashion...)

>
>                Ethan

Péter Juhász

Re: New stable CVS branch for version 4.6 on SourceForge

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

On 11/23/11 07:23, sfeam (Ethan Merritt) wrote:
>   But recently we have been
>    getting a lot of feedback from people using the development version
>    itself,  much more then we had prior to releasing 4.4.  So we may
>    not need a separate pre-release testing version this time.
>    What do you think?

RC is always a good idea IMO. More flexible distros like Gentoo tend to 
include them and it will always bring up some issues so that has be to 
an advantage.

Gentoo boxes tend to be unconventional in many ways due to flexibility 
offered so they probably expose the software to a more hostile testing 
ground than the more homogeneous installations using other distros.

>
> The option is still on the table to name the next release 5.0 rather
> than 4.6.  If you care, please speak up.
>
> 		Ethan

m2c:
Odd/even is good concept. Shame it's not more universally applied.

Peter.

Re: svg mouse coords in zoom

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

On 11/22/11 23:47, Ethan A Merritt wrote:
> On Monday, November 21, 2011 11:36:48 pm pl...@pi... wrote:
>> Hi,
>>
>> while we have the svg box open it may be a good time to point out a
>> minor but rather annoying bug in the mouse coordinate label.
>>
>> If the svg is zoomed (Opera or FFx) the coord values are still correct
>> but the label and it's dot do not match the mouse position.
>>
>> All is OK on zoomed until the scroll bar is moved. Then mouse readout
>> stays at the same point on the graph with the same (correct) coords,
>> rather than staying with the mouse and assuming a new value.
>>
>> Sounds like a detail that was not anticipated.
>
> Unfortunately, the people who did not anticipate that detail were
> the members of the W3C working group.  They left the scrollbar
> coordinate information undefined in the SVG spec.   (Or so I concluded
> after Googling.  I suppose there may be some very recent addition).
> Many people have hit this same problem with other programs.

The coordinates of the mouse and portion of the graphic that a 
particular viewer chooses to look at are not properties of the SVG file, 
so I find it logical that this is not in the spec.

Is there anything in the broader html xml specs that define properties 
of the view window that is rendered?

The scroll bar position is just an interface detail and has nothing to 
do with the spec. , is there no property like viewport that represents 
the portion actually rendered?

I seem to recall seeing some such but it may be something else again.


>
> Each browser handles it differently, so there may not be a single
> universal solution.  I borrowed some code that seems to work on
> Firefox and Opera, but it works slightly differently on Chrome.
> I don't know about IE but suspect from the comments on the site where
> I found it that it won't work on IE.
>
> 	Ethan

I thought IE could not even render SVG at all. The only option being a 
buggy and discontinued Abobe plug-in.  Such a platform is not even worth 
testing on.

Thanks for the explanation. I thought this had been missed , you're 
obviously on top of it.

This coord read-off is an incredibly useful feature. It's even more 
useful when you can zoom in (almost indefinitely) for extra precision. 
It's great shame it is flawed.

Could this be made to work with a bit of browser sniffing in the js 
code? I may look at adding that locally. This is too useful to miss. Any 
pointers?

best regards, Peter.

Re: Suggestion: array should be supported

[gbliu <goo...@gm...>]

? 2011/11/23 10:13, sfeam (Ethan Merritt) ??:
> I can imagine numerical uses for arrays, but your example seems to
> be just a request for an easier way to order variable names.
> The following works currently, for example:
>
> col1 = 2; str1 = 'title 1 with multiple words'
> col2 = 3; str2 = 'title 2 etc'
> col3 = 6; str3 = 'title 3'
> ...
> COLUMN = "col"
> TITLE = "str"
>
>    plot for [i=1:7] 'data' u 1:(column(value(COLUMN.i))) title TITLE.i
>
> I grant you that column(value(COLUMN.i)) is a bit awkward compared
> to just col[i], but if we cleaned up that syntax a bit would it address
> your needs?   I really don't see anything in this particular request that
> requires an array in the usual mathematical sense.
Thanks for your reply. The value() function can  indeed  solve my 
problem. It can be used to simulate the functionality of array,  
combined with eval.  e.g.
  i=3
assign a value:       eval "a".i."=3" <------>   a[i]=3
access the value:   value("a".i) <------>   a[i]

It is only the introduction of value() in the devel. version that can do 
this.  I just know it after your reply.  I have been working with the 
4.4 version, which is the reason why no scheme can work and I need array 
functionality.  But to tell the truth. this is only an awkward 
alternative to simulate array, which is not graceful and concise.  I 
still hope array can be supported in the future, which is not a bad 
thing after all.  Anyway, it works now. So the need of array is not that 
urgent.

By the way, there seems to be a small bug:
gnuplot> s="a"
gnuplot> i=1
gnuplot> pr "a".1
                ^
          ';' expected
gnuplot> pr "a".i
a1
gnuplot> pr s.1
              ^
          ';' expected
gnuplot> pr s.i
a1

So, only  value("a".i)  and value(s.i) works, and value("a".1) and 
value(s.1) report errors. Is this a bug?

New stable CVS branch for version 4.6 on SourceForge

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

Hi all,

Since patchlevel 4 is the last release planned for the version 4.4 series,
I have created a new branch for development of version 4.6.  You can check
it out using the commands below.  Or you may have another set of commands
that you prefer.  Anyhow the branch name is branch-4-6-stable
    
cvs -d:pserver:ano...@gn...:/cvsroot/gnuplot \
     login
cvs -z3 -d:pserver:ano...@gn...:/cvsroot/gnuplot \
     checkout -r branch-4-6-stable -P gnuplot

I suggest that we follow the same general procedure as we did during
the period leading up to the 4.4 release:

- Bug fixes should be applied to both the main branch (currently 4.5)
  and to the 4.6.alpha source in branch-4-6-stable.  Since these are
  currently identical, there should be no problem with applying the
  same patch to both.

- New features should be added to the development branch *only*.
  If the feature proves to be trouble-free, we can decide later to 
  backport it to the 4.6 release series.

- I hope to keep on a roughly 6 month release schedule, meaning that
  version 4.6.0 would be officially released sometime in the spring.

- When 4.6 is released, the version number of the main development
  branch will be bumped to 4.7.

- Last time we put out a testing version (release candidate) prior to
  releasing 4.4.0. There were some fairly serious problems picked up
  by people testing the release candidate.   But recently we have been
  getting a lot of feedback from people using the development version
  itself,  much more then we had prior to releasing 4.4.  So we may
  not need a separate pre-release testing version this time.
  What do you think?

The option is still on the table to name the next release 5.0 rather
than 4.6.  If you care, please speak up.

		Ethan

Re: Suggestion: array should be supported

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

On Friday, 18 November 2011, gbliu wrote:
> Dear all:
> 
> These years gnuplot becomes more and more powerful. In sense, it's a
> quasi-programming-language. String variable is supported since ver4.0, and {}
> blocks and loops are supported in ver4.5. But a basic function, array, is still
> not supported now. I think this is highly needed, especially when loops are
> supported.
> 
> ------------------------
> e.g.
> 
> I have a data file with many columns, but want to plot only some columns, say,
> column 2, 3,6,7,9,15,24. And the lengeds for each column differ. Now, I can only
> use the command as follow:
> 
> 
> plot 'data' u 1:2 title '...', '' u 1:3 title '...', '' u 1:6 title '...',\
>      ''     u 1:7 title '...', '' u 1:9 title '...', '' u 1:15 title '...',\
>      ''     u 1:24 title '...'
> 
> Although gnuplot support "plot for [i=...]" now, but it cannot be used here,
> because the column numbers is not regular. In this case, array is needed to
> simplify the plot command.
> 
> Suppose there are two arrays, col and str:
> col[1]=2;  str[1]='...'
> col[2]=3;  str[2]='...'
> col[3]=6;  str[3]='...'
> col[4]=7;  str[4]='...'
> col[5]=9;  str[5]='...'
> col[6]=15; str[6]='...'
> col[7]=24; str[7]='...'
> 
> now, I can use the following more concise command:
> 
> plot for [i=1:7] 'data' u 1:(column(col[i])) title str[i]


I can imagine numerical uses for arrays, but your example seems to
be just a request for an easier way to order variable names.
The following works currently, for example:

col1 = 2; str1 = 'title 1 with multiple words'
col2 = 3; str2 = 'title 2 etc'
col3 = 6; str3 = 'title 3'
...
COLUMN = "col"
TITLE = "str"

  plot for [i=1:7] 'data' u 1:(column(value(COLUMN.i))) title TITLE.i

I grant you that column(value(COLUMN.i)) is a bit awkward compared
to just col[i], but if we cleaned up that syntax a bit would it address
your needs?   I really don't see anything in this particular request that
requires an array in the usual mathematical sense.

Re: svg mouse coords in zoom

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

On Monday, November 21, 2011 11:36:48 pm pl...@pi... wrote:
> Hi,
> 
> while we have the svg box open it may be a good time to point out a 
> minor but rather annoying bug in the mouse coordinate label.
> 
> If the svg is zoomed (Opera or FFx) the coord values are still correct 
> but the label and it's dot do not match the mouse position.
> 
> All is OK on zoomed until the scroll bar is moved. Then mouse readout 
> stays at the same point on the graph with the same (correct) coords, 
> rather than staying with the mouse and assuming a new value.
> 
> Sounds like a detail that was not anticipated.

Unfortunately, the people who did not anticipate that detail were
the members of the W3C working group.  They left the scrollbar 
coordinate information undefined in the SVG spec.   (Or so I concluded
after Googling.  I suppose there may be some very recent addition).
Many people have hit this same problem with other programs.

Each browser handles it differently, so there may not be a single
universal solution.  I borrowed some code that seems to work on
Firefox and Opera, but it works slightly differently on Chrome.
I don't know about IE but suspect from the comments on the site where 
I found it that it won't work on IE.

	Ethan
 

svg mouse coords in zoom

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

Hi,

while we have the svg box open it may be a good time to point out a 
minor but rather annoying bug in the mouse coordinate label.

If the svg is zoomed (Opera or FFx) the coord values are still correct 
but the label and it's dot do not match the mouse position.

All is OK on zoomed until the scroll bar is moved. Then mouse readout 
stays at the same point on the graph with the same (correct) coords, 
rather than staying with the mouse and assuming a new value.

Sounds like a detail that was not anticipated.

Regards, Peter.

Re: lua/tikz terminal is implemented to cvs binary of DJGPP

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

Hello

Sorry for my frequently and confusing post.
The problem for DJGPP in the Dosbox comes that file named the gnuplot-(style).lua (e.g. gnuplot-tikz.lua) cannot be read because of the restriction of 8.3 style file name in the Dosbox. 

I have renamed 'gnuplot-tikz.lua' to 'gptikz.lua' and patch attached lua.trm then tikz terminal worked.  I do not want that this binary is an official one. 

--- On Tue, 2011/11/22, Tatsuro MATSUOKA  wrote:

> Hello
> 
> Please ignore this mail because long file name issue exist in the dos emulator (DOSBOX) so that tikz terminal does not work.
> 
> Regards
> 
> Tatsuro
> 
> --- On Tue, 2011/11/22, Tatsuro MATSUOKA  wrote:
> 
> > Hello
> > 
> > As was seen in
> > http://sourceforge.net/tracker/?func=detail&aid=3440066&group_id=2055&atid=102055
> > 
> > snprintf issue was solved in DJGPP for context terminal.
> > Thus now we can support lua/tikz terminal on DJGPP.
> > 
> > I have updated cvs binary with lua/tikz terminal.
> > 
> > Regards
> > 
> > Tatsuro
> > 
> > 
> > ------------------------------------------------------------------------------
> > All the data continuously generated in your IT infrastructure 
> > contains a definitive record of customers, application performance, 
> > security threats, fraudulent activity, and more. Splunk takes this 
> > data and makes sense of it. IT sense. And common sense.
> > http://p.sf.net/sfu/splunk-novd2d
> > _______________________________________________
> > gnuplot-beta mailing list
> > gnu...@li...
> > https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
> > 
> 
> ------------------------------------------------------------------------------
> All the data continuously generated in your IT infrastructure 
> contains a definitive record of customers, application performance, 
> security threats, fraudulent activity, and more. Splunk takes this 
> data and makes sense of it. IT sense. And common sense.
> http://p.sf.net/sfu/splunk-novd2d
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
> 

Re: getting svg js included

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

On 11/22/11 05:46, sfeam (Ethan Merritt) wrote:
> On Monday, 21 November 2011, pl...@pi... wrote:
>> Hi,
>>
>> I would like to have the possibility to make the active mouse features
>> be included in svg file rather than as an external reference.
>>
>> This is not always desirable but has significant advantages when sending
>> svg output to collaborators where it adds a whole load of complex
>> explanations if I have two separate files.
>>
>> AFAIR this was the format when I originally submitted a patch with this
>> kind of interactive behaviour for svg.
>
> So you're "forgery69"?  I don't think I ever knew who submitted the
> original patch other than that pseudonym.  You should get some kudos
> in the source file.
>

Yeah, I only just noticed the credit you put in there when I started 
digging earlier. I'd forgotten it went in via that route rather than 
this ML.  IIRC I suggested it here and you asked me to post a comment on 
SF so that it didn't get forgotten.

Oh, well. I'll worry about the kudos later.

>> It would seem the best way to hook this into the existing structure
>> would be a special value of the jsdir dir option to svg terminal.
>>
>> eg.
>> set term svg jsdir="internal"
>
> My first thought is that this is more parallel to the "standalone"
> option in the various tex drivers and in the canvas terminal.
>
>> Before I dive in and start coding I would like to do something that fits
>> in with current philosophy and that could be submitted as a patch for
>> consideration.
>> Any comments or suggestions on how to go about this?
>
> My suggestion is to have it work like the postscript terminal does with
> its prologue files.  If the user specifies "set term svg standalone",
> the instead of writing out
>     <script type="text/javascript" xlink:href="JSDIR/gnuplot_svg.js"/>
> you would write out
>     <script type="text/javascript"><![CDATA["
> and then copy the contents of JSDIR:gnuplot_svg.js line by line into the
> output stream.
>
> Under this model the jsder="foo" option might still be useful in order
> to tell the program where to copy from, in the case that you want to
> include a locally customized version.
>
> 	Ethan
>
>
>> TIA, Peter.
>

Ok , I have some code roughed out to do it already , what variable 
should I be testing for to catch the "standalone" option?

Thx. Peter.

Re: getting svg js included

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

On 11/22/11 05:46, sfeam (Ethan Merritt) wrote:
> On Monday, 21 November 2011, pl...@pi... wrote:
>> Hi,
>>
>> I would like to have the possibility to make the active mouse features
>> be included in svg file rather than as an external reference.
>>
>> This is not always desirable but has significant advantages when sending
>> svg output to collaborators where it adds a whole load of complex
>> explanations if I have two separate files.
>>
>> AFAIR this was the format when I originally submitted a patch with this
>> kind of interactive behaviour for svg.
>
> So you're "forgery69"?  I don't think I ever knew who submitted the
> original patch other than that pseudonym.  You should get some kudos
> in the source file.
>
>> It would seem the best way to hook this into the existing structure
>> would be a special value of the jsdir dir option to svg terminal.
>>
>> eg.
>> set term svg jsdir="internal"
>
> My first thought is that this is more parallel to the "standalone"
> option in the various tex drivers and in the canvas terminal.
>
>> Before I dive in and start coding I would like to do something that fits
>> in with current philosophy and that could be submitted as a patch for
>> consideration.
>> Any comments or suggestions on how to go about this?
>
> My suggestion is to have it work like the postscript terminal does with
> its prologue files.  If the user specifies "set term svg standalone",
> the instead of writing out
>     <script type="text/javascript" xlink:href="JSDIR/gnuplot_svg.js"/>
> you would write out
>     <script type="text/javascript"><![CDATA["
> and then copy the contents of JSDIR:gnuplot_svg.js line by line into the
> output stream.
>
> Under this model the jsder="foo" option might still be useful in order
> to tell the program where to copy from, in the case that you want to
> include a locally customized version.
>
> 	Ethan
>
>
>> TIA, Peter.
>

Hmm , I'm confused , I added the following but it fails to recognise the 
new option. Does that need to be added somewhere else as well?

gnuplot> set terminal svg mouse standalone name basename  font 
"verdana,9" size 800,600;
                                 ^
          "monthly.gnu", line 19697: unrecognized terminal option


[ The caret is indicating "standalone" ]





static TBOOLEAN SVG_mouseable = FALSE;
static TBOOLEAN SVG_standalone = FALSE;

....


   if (equals(c_token, "mouse") || almost_equals(c_token, "mous$ing")) {
       c_token++;
       SVG_mouseable = TRUE;
       continue;
   }

   if (equals(c_token, "standalone") || almost_equals(c_token, 
"stan$dalone")) {
       c_token++;
       SVG_standalone = TRUE;
       continue;
   }



....



     if (SVG_mouseable) {
   /* This is sufficient to support toggling plots on/off */
       if (!SVG_standalone) {
         fprintf(gpoutfile,"<script type=\"text/javascript\" 
xlink:href=\"%sgnuplot_svg.js\"/>\n",
                 SVG_scriptdir);
       } else {
         char *fullname = NULL;
         char *name ="gnuplot_svg.js";
         char buf[256];
         FILE *svg_js_fd;
         fullname = gp_alloc(strlen(SVG_scriptdir) + strlen(name) + 
4,"javascript name");
         strcpy(fullname, SVG_scriptdir);
         PATH_CONCAT(fullname, name);

         svg_js_fd=NULL;
         svg_js_fd=fopen(fullname, "r");
         free(fullname);

         if (svg_js_fd){
           fprintf(gpoutfile,"<script type=\"text/javascript\" >\n");
           while (fgets(buf, sizeof(buf), svg_js_fd)) {
             fputs(buf, gpoutfile);
             fprintf(gpoutfile,"</script>\n");
           }
           fclose(svg_js_fd);
         } else {
// *** warn non fatal: failed to insert javascript
           fprintf(stderr,"Failed to insert SVG javaScript file %s\n", 
name);
         }

Re: getting svg js included

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

On Monday, 21 November 2011, pl...@pi... wrote:
> Hi,
> 
> I would like to have the possibility to make the active mouse features 
> be included in svg file rather than as an external reference.
> 
> This is not always desirable but has significant advantages when sending 
> svg output to collaborators where it adds a whole load of complex 
> explanations if I have two separate files.
> 
> AFAIR this was the format when I originally submitted a patch with this 
> kind of interactive behaviour for svg.

So you're "forgery69"?  I don't think I ever knew who submitted the
original patch other than that pseudonym.  You should get some kudos
in the source file.

> It would seem the best way to hook this into the existing structure 
> would be a special value of the jsdir dir option to svg terminal.
> 
> eg.
> set term svg jsdir="internal"

My first thought is that this is more parallel to the "standalone"
option in the various tex drivers and in the canvas terminal.

> Before I dive in and start coding I would like to do something that fits 
> in with current philosophy and that could be submitted as a patch for 
> consideration.
> Any comments or suggestions on how to go about this?

My suggestion is to have it work like the postscript terminal does with
its prologue files.  If the user specifies "set term svg standalone",
the instead of writing out
   <script type="text/javascript" xlink:href="JSDIR/gnuplot_svg.js"/>
you would write out
   <script type="text/javascript"><![CDATA["
and then copy the contents of JSDIR:gnuplot_svg.js line by line into the
output stream.

Under this model the jsder="foo" option might still be useful in order
to tell the program where to copy from, in the case that you want to
include a locally customized version.

	Ethan


> TIA, Peter.

Re: lua/tikz terminal is implemented to cvs binary of DJGPP

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

Hello

Please ignore this mail because long file name issue exist in the dos emulator (DOSBOX) so that tikz terminal does not work.

Regards

Tatsuro

--- On Tue, 2011/11/22, Tatsuro MATSUOKA  wrote:

> Hello
> 
> As was seen in
> http://sourceforge.net/tracker/?func=detail&aid=3440066&group_id=2055&atid=102055
> 
> snprintf issue was solved in DJGPP for context terminal.
> Thus now we can support lua/tikz terminal on DJGPP.
> 
> I have updated cvs binary with lua/tikz terminal.
> 
> Regards
> 
> Tatsuro
> 
> 
> ------------------------------------------------------------------------------
> All the data continuously generated in your IT infrastructure 
> contains a definitive record of customers, application performance, 
> security threats, fraudulent activity, and more. Splunk takes this 
> data and makes sense of it. IT sense. And common sense.
> http://p.sf.net/sfu/splunk-novd2d
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
>