gnuplot development

On 04/27/12 22:48, Arun Persaud wrote:
> Hi
>
> I just ran into the following error when trying to open a svg file
> created by gnuplot:
>
> "test.svg:898: parser error : Input is not proper UTF-8, indicate encoding !
> Bytes: 0x80 0x22 0x20 0x3E"
>
> and I can't open the svg (tried inkscape and eog).
>
> Here is the script that produced the svg:
>
> --------------
> reset
> N=30
>
> set term svg
> set out "test.svg"
>
> set size N,N
>
> set multiplot
>
> set size 1,1
>
> do for [i=1:N] {
>    do for [j=i:N] {
>
>    set title "x: ".i." y: ".j
>    set origin ((i-1)),((j-1))
>
>    plot sin(i*j*x)
>    }
> }
>
> unset multiplot
> set out
> --------------
>
> The script works OK for small N, e.g. N=3.
>
> Not sure if this is a problem with gnuplot or my lib that reads svg...
> can someone reproduce this?
>
> I'm running the latest gnuplot cvs version (updated a few hours ago) on
> openSUSE Tumbleweed. Compiled cvs using "./prepare; configure; make".
>
> As a side question: in the above script how do I get to size the output
> of the svg to the N,N size? Or if I use set size 1,1 outside multiplot
> and set size 1.0/N,1.0/N inside multiplot, how to I get gnuplot to scale
> the whole plot including fonts, tics, etc.
>
> thanks
>
> Arun
>
> --------------------------------------

confirmed, I ran your script and this is what firefox reported when 
opening it.

XML Parsing Error: not well-formed
Location: file:///back/coredata/test.svg
Line Number 898, Column 23:	<g id="gnuplot_plot_1\uffff" 
 ><title>gnuplot_plot_1\uffff</title>


HTH

On Friday, April 27, 2012 01:48:32 pm Arun Persaud wrote:
> Hi
> 
> I just ran into the following error when trying to open a svg file
> created by gnuplot:
> 
> "test.svg:898: parser error : Input is not proper UTF-8, indicate encoding !
> Bytes: 0x80 0x22 0x20 0x3E"

You have indeed found a real bug, which I have just now fixed in the CVS
source code.  The subplots in a multiplot are labeled internally as 'a'-'z'.
The bug was an incorrect check to prevent letters beyond 'z' from being 
generated.  So it triggered whenever the number of subplots exceeded 30.


However, your script will not work as it is even after the bug fix.
See comments below.

> --------------
> reset
> N=30
> 
> set term svg
> set out "test.svg"
> 
> set size N,N

	Don't do this.  "set size" should never use values greater than 1.
   
> set multiplot
> 
> set size 1,1
>
> do for [i=1:N] {
>   do for [j=i:N] {
> 
>   set title "x: ".i." y: ".j
>   set origin ((i-1)),((j-1))
> 
>   plot sin(i*j*x)
>   }
> }
> 
> unset multiplot
> set out
> --------------

I think the revised script below does what you want.
You don't necessarily have to make the nominal x and y size bigger,
but if you don't then cramming in 900 subplots may run into the precision
issue that Peter brought up yesterday - that the coordinates written to the
output file only use 1 decimal place.


========================
XSIZE = 2400       # The default size is 600 x 480
YSIZE = 1800       # so this is roughly 4 times bigger
SCALE = 600./XSIZE
N = 30

set term svg  size 2400,1800  fsize (10. * SCALE)  lw  (1. * SCALE)
set out "newversion.svg"

set multiplot layout N,N
do for [i=1:N] {
  do for [j=i:N] {
    set title "x: ".i." y: ".j
    plot sin(i*j*x)
  }
}

unset multiplot
=======================


 
> The script works OK for small N, e.g. N=3.
> 
> Not sure if this is a problem with gnuplot or my lib that reads svg...
> can someone reproduce this?
> 
> I'm running the latest gnuplot cvs version (updated a few hours ago) on
> openSUSE Tumbleweed. Compiled cvs using "./prepare; configure; make".
> 
> As a side question: in the above script how do I get to size the output
> of the svg to the N,N size? Or if I use set size 1,1 outside multiplot
> and set size 1.0/N,1.0/N inside multiplot, how to I get gnuplot to scale
> the whole plot including fonts, tics, etc.

The revised script above shows how you can apply explicit scaling.

The CVS version has partial support for more generic scaling commands
but these are not yet implemented for the svg terminal.

	Ethan


> 
> thanks
> 
> Arun

Hi

>> I just ran into the following error when trying to open a svg file
>> created by gnuplot:
>>
>> "test.svg:898: parser error : Input is not proper UTF-8, indicate encoding !
>> Bytes: 0x80 0x22 0x20 0x3E"
> 
> You have indeed found a real bug, which I have just now fixed in the CVS
> source code.  The subplots in a multiplot are labeled internally as 'a'-'z'.
> The bug was an incorrect check to prevent letters beyond 'z' from being 
> generated.  So it triggered whenever the number of subplots exceeded 30.

Thanks for the bugfix... tested it and everything works great!

> [...]

> set term svg  size 2400,1800  fsize (10. * SCALE)  lw  (1. * SCALE)

also thanks for helping with the script... fsize and lw in "set term"
was what I was missing.

cheers

Arun

On 04/24/12 23:47, Ethan A Merritt wrote:
>> One more thing while you're around, I have xdata as timedata and the
>> mouse annotation feature is outputting a rather lengthy x coord.
>>
>> Sat 01, Jan 2000 16:03:47 GMT
>>
>> My graph runs 0:00 to 22:00 so the data part is spurious any way.
>> a) Is there a way to set this format
>> b) this is a bug since the date is spurious.
>>
>
> I'll start by saying that I know almost nothing about date handling in
> various javascript interpreters.  Gnuplot is just putting out raw seconds;
> the conversion from "epoch seconds" to Time/Date is done by the javascript
> engine. So if yours is producing the wrong date I have no clue where to
> set about fixing it.
>
> Anyhow, the supported options are limited to requesting it to print
> only the Date, only the Time, or both (default), using
>     set mouse mouseformat "Date"
>     set mouse mouseformat "Time"
>     set mouse mouseformat "DateTime"
>
> If you consistently want some other format, I'm afraid you're on
> your own to modify the javascript code in gnuplot_svg.js.
>
> In general it would be great if there were a way to translate the
> coordinate output formats (dates or otherwise) from gnuplot's own
> C-like format to something usable in javascript so that the svg
> and canvas terminals could use it.  But I failed to find any such
> C ->  javascript conversion library that could be linked to for
> this purpose.
>
> 	Ethan
>> from the console this system displays the following format (and knows
>> what day it is ;) )
>> #date
>> Tue Apr 24 21:24:04 UTC 2012
>>
>> regards.
>>
>

Thanks, I'd see the DATE TiME thing in the source but had not found out 
how to set it. Looks just the ticket.

Perhaps the current default is not the most logical choice. I would have 
thought that what has been chosen for the graph would be the obvious 
default for the label and the live coord read out , both in interactive 
and js context.

In this case I have
set timefmt  "%H:%M:%S"
set format x "%02Hh%02M"

Now timefmt is what is required by the *input* data , not the graph 
output. Never the less this is what is provided with an integer arg of 3

Similarly an argument of 5 will get me a simple hh:mm format which  may 
or may not be the same as my displayed x coord. In this case not.

help states:

  The following formats are available:

   0   default (same as 1)
   1   axis coordinates                    1.23, 2.45


This is wrong. Neither 0 nor 1 display what I have on the axis 
coordinates . In fact if I select "1" I get a decidedly unhelpful 
15032.4 instead of a legible time coord.

I would suggest that if xdata = time then mouse should be using this.
If format x is set this should be used rather than timefmt (which is the 
default x format, not the actual one).

In summary default mouse format should be what is displayed on the 
graph, taking into account any setting used in created it.

In an interactive terminal, I guess any later changes to format 
specifiers would change mouse behaviour. That is up to the use.


Perhaps this is what was originally intended since it seems odd having 
both 0 and 1 do the same.





Thanks for your help. I think this should do just what I want with an 
explicit option rather than the default.

Best regards, Peter.

On 04/25/12 10:24, plotter@... wrote:
> On 04/24/12 23:47, Ethan A Merritt wrote:
>>> One more thing while you're around, I have xdata as timedata and the
>>> mouse annotation feature is outputting a rather lengthy x coord.
>>>
>>> Sat 01, Jan 2000 16:03:47 GMT
>>>
>>> My graph runs 0:00 to 22:00 so the data part is spurious any way.
>>> a) Is there a way to set this format
>>> b) this is a bug since the date is spurious.
>>>
>>
>> I'll start by saying that I know almost nothing about date handling in
>> various javascript interpreters.  Gnuplot is just putting out raw seconds;
>> the conversion from "epoch seconds" to Time/Date is done by the javascript
>> engine. So if yours is producing the wrong date I have no clue where to
>> set about fixing it.
>>
>> Anyhow, the supported options are limited to requesting it to print
>> only the Date, only the Time, or both (default), using
>>      set mouse mouseformat "Date"
>>      set mouse mouseformat "Time"
>>      set mouse mouseformat "DateTime"
>>
>> If you consistently want some other format, I'm afraid you're on
>> your own to modify the javascript code in gnuplot_svg.js.
>>
>> In general it would be great if there were a way to translate the
>> coordinate output formats (dates or otherwise) from gnuplot's own
>> C-like format to something usable in javascript so that the svg
>> and canvas terminals could use it.  But I failed to find any such
>> C ->   javascript conversion library that could be linked to for
>> this purpose.
>>
>> 	Ethan
>>> from the console this system displays the following format (and knows
>>> what day it is ;) )
>>> #date
>>> Tue Apr 24 21:24:04 UTC 2012
>>>
>>> regards.
>>>
>>
>
> Thanks, I'd see the DATE TiME thing in the source but had not found out
> how to set it. Looks just the ticket.
>
> Perhaps the current default is not the most logical choice. I would have
> thought that what has been chosen for the graph would be the obvious
> default for the label and the live coord read out , both in interactive
> and js context.
>
> In this case I have
> set timefmt  "%H:%M:%S"
> set format x "%02Hh%02M"
>
> Now timefmt is what is required by the *input* data , not the graph
> output. Never the less this is what is provided with an integer arg of 3
>
> Similarly an argument of 5 will get me a simple hh:mm format which  may
> or may not be the same as my displayed x coord. In this case not.
>
> help states:
>
>    The following formats are available:
>
>     0   default (same as 1)
>     1   axis coordinates                    1.23, 2.45
>
>
> This is wrong. Neither 0 nor 1 display what I have on the axis
> coordinates . In fact if I select "1" I get a decidedly unhelpful
> 15032.4 instead of a legible time coord.
>
> I would suggest that if xdata = time then mouse should be using this.
> If format x is set this should be used rather than timefmt (which is the
> default x format, not the actual one).
>
> In summary default mouse format should be what is displayed on the
> graph, taking into account any setting used in created it.
>
> In an interactive terminal, I guess any later changes to format
> specifiers would change mouse behaviour. That is up to the use.
>
>
> Perhaps this is what was originally intended since it seems odd having
> both 0 and 1 do the same.
>
>
>
>
>
> Thanks for your help. I think this should do just what I want with an
> explicit option rather than the default.
>
> Best regards, Peter.
>

PS

I've just tested this and the svg js is always producing hh:mm:ss 
output. ie option 3 is that same as option 5 .

5 on interactive produces a short time format  like 3:18 or 21:50
5 on js term give output like 04:21:52

Presumably fixing the bug I noted in last msg will catch this too.


Peter.

Hi,

I have not tested this problem on canvas but I'm guessing it would be 
the same as seen in svg.

Part of the value of scalable formats is the lack of granularity and the 
ability to zoom to the desired resolution.

In testing mouse coords on svg I find there is granularity at the scale 
of the decimal point character. (or one dot of the colon).

I have configured Firefox to allow very high zoom levels , this is 
excellent for looking at my data plots and allows seeing this problem 
clearly.

The mouse cursor moves smoothly as expected but the coord readout only 
moves in jumps that are the size of the dot.

each jump moves the cursor text by a similar amount and updates to coords.

Is this due to the svg_scale  bug I caught last week?


Oops!
The dangers of cut-and-paste.
That should clearly be SVG_SCALE rather than CANVAS_OVERSAMPLE.
Fortunately they are both equal to 10

	Ethan



Would a higher value of SVG_SCALE increase the resolution here ? Any 
blow-back?

Thx.

On Wednesday, 25 April 2012, plotter@... wrote:
> On 04/25/12 10:24, plotter@... wrote:
> > On 04/24/12 23:47, Ethan A Merritt wrote:
> >>
> >> In general it would be great if there were a way to translate the
> >> coordinate output formats (dates or otherwise) from gnuplot's own
> >> C-like format to something usable in javascript so that the svg
> >> and canvas terminals could use it.  But I failed to find any such
> >> C ->   javascript conversion library that could be linked to for
> >> this purpose.
> >>
> >
> > Perhaps the current default is not the most logical choice. I would have
> > thought that what has been chosen for the graph would be the obvious
> > default for the label and the live coord read out , both in interactive
> > and js context.
> >
> > In this case I have
> > set timefmt  "%H:%M:%S"
> > set format x "%02Hh%02M"
> >
> > Now timefmt is what is required by the *input* data , not the graph
> > output. Never the less this is what is provided with an integer arg of 3
> >
> > Similarly an argument of 5 will get me a simple hh:mm format which  may
> > or may not be the same as my displayed x coord. In this case not.
> >
> > help states:
> >
> >    The following formats are available:
> >
> >     0   default (same as 1)
> >     1   axis coordinates                    1.23, 2.45

You're looking at the help for mouse formats, right?
I'm afraid that whole section of the documentation applies
only to the gnuplot mouse code itself (in mouse.c), not to
anything that happens outside the program.  So basically
only to the old interactive terminals (windows, x11, wxt, pm,
not sure about qt). And it may be out of date even for those
terminals.

> > This is wrong. Neither 0 nor 1 display what I have on the axis
> > coordinates . In fact if I select "1" I get a decidedly unhelpful
> > 15032.4 instead of a legible time coord.

At a guess, that is indeed the axis coordinate (time in seconds).

> PS
> 
> I've just tested this and the svg js is always producing hh:mm:ss 
> output. ie option 3 is that same as option 5 .
> 
> 5 on interactive produces a short time format  like 3:18 or 21:50
> 5 on js term give output like 04:21:52
> 
> Presumably fixing the bug I noted in last msg will catch this too.

No. The js time code knows nothing about format options inside
gnuplot.  That's where this thread started.  The js code uses 
whatever format is provided by the javascript interpreter's
Date() module.  The only control currently built into the 
gnuplot terminals (canvas, svg) is to toggle Date/Time/both.

Gnuplot's time/date code is IMHO a creaky relic of an earlier era.
I am reluctant to touch the code, and I try not to use it for
plotting.  In that regard I am fortunate in having to deal
with time data only rarely.

The mouse coordinate-tracking code is also showing its age.
It used to be that the small number of terminal drivers that
offered mousing (windows, x11, pm) all used the same support
routine in the core gnuplot code.   That is no longer true;
some of the interactive terminals contain separate code for
"-persist" mode, and the offline terminals like canvas and svg
rely on self-contained javascript support. 

So the intersection (tracking time coords while mousing)
is a particular weak spot.  Any suggestions of how to improve
this are welcome.  An improved system need not necessarily
replicate the current hodge-podge.

	Ethan

> 
> 
> Peter.

On Wednesday, April 25, 2012 02:09:19 am plotter@... wrote:
> Hi,
> 
> I have not tested this problem on canvas but I'm guessing it would be 
> the same as seen in svg.
> 
> Part of the value of scalable formats is the lack of granularity and the 
> ability to zoom to the desired resolution.
> 
> In testing mouse coords on svg I find there is granularity at the scale 
> of the decimal point character. (or one dot of the colon).

The precision of the coordinates is indeed one decimal place.
Not sure what you mean by "one dot of the colon".
 
> I have configured Firefox to allow very high zoom levels , this is 
> excellent for looking at my data plots and allows seeing this problem 
> clearly.

I cannot speak to exactly what happens when you zoom in Firefox.
Ideally it would employ the precision of the coordinates in the file,
meaning that it would still be accurate to one display pixel when the zoom
factor is 10X.

> The mouse cursor moves smoothly as expected but the coord readout only 
> moves in jumps that are the size of the dot.
> Each jump moves the cursor text by a similar amount and updates to coords.

Quantization of mouse movement is a whole separate issue.
If there is a limitation there, it's at the level of the X input layer
or whatever serves that purpose on your platform. I am told that some newer
platforms treat mouse position as a continuous variable, but to the best of
my knowledge X only provides an integer pixel coordinate, and the minimum
"delta" of mouse motion may be larger than one pixel.

> Is this due to the svg_scale  bug I caught last week?

The internal precision of the plot is set by SVG_SCALE, yes.
You could set it to 100. rather than 10. to get higher precision.
The tradeoff is that printing an additional decimal place in every 
coordinate of every command in the output file will make the file
significantly larger for a typical gnuplot graph.

It is also possible that changing the precision would uncover additional 
bugs, but we could consider that a good thing rather than a bad thing :-)

	Ethan

On 04/25/12 17:31, sfeam (Ethan Merritt) wrote:
> On Wednesday, 25 April 2012, plotter@... wrote:
>> On 04/25/12 10:24, plotter@... wrote:
>>> On 04/24/12 23:47, Ethan A Merritt wrote:
>>>>
>>>> In general it would be great if there were a way to translate the
>>>> coordinate output formats (dates or otherwise) from gnuplot's own
>>>> C-like format to something usable in javascript so that the svg
>>>> and canvas terminals could use it.  But I failed to find any such
>>>> C ->    javascript conversion library that could be linked to for
>>>> this purpose.
>>>>
>>>
>>> Perhaps the current default is not the most logical choice. I would have
>>> thought that what has been chosen for the graph would be the obvious
>>> default for the label and the live coord read out , both in interactive
>>> and js context.
>>>
>>> In this case I have
>>> set timefmt  "%H:%M:%S"
>>> set format x "%02Hh%02M"
>>>
>>> Now timefmt is what is required by the *input* data , not the graph
>>> output. Never the less this is what is provided with an integer arg of 3
>>>
>>> Similarly an argument of 5 will get me a simple hh:mm format which  may
>>> or may not be the same as my displayed x coord. In this case not.
>>>
>>> help states:
>>>
>>>     The following formats are available:
>>>
>>>      0   default (same as 1)
>>>      1   axis coordinates                    1.23, 2.45
>
> You're looking at the help for mouse formats, right?
> I'm afraid that whole section of the documentation applies
> only to the gnuplot mouse code itself (in mouse.c), not to
> anything that happens outside the program.  So basically
> only to the old interactive terminals (windows, x11, wxt, pm,
> not sure about qt). And it may be out of date even for those
> terminals.

I'm comparing this to wxt. mouse coords in wxt are the same within the 
proviso that both 5 and 3 do the same in js.

All comments about defaults apply to both.

>
>>> This is wrong. Neither 0 nor 1 display what I have on the axis
>>> coordinates . In fact if I select "1" I get a decidedly unhelpful
>>> 15032.4 instead of a legible time coord.
>
> At a guess, that is indeed the axis coordinate (time in seconds).
>
Yup, a lousy default.

>> PS
>>
>> I've just tested this and the svg js is always producing hh:mm:ss
>> output. ie option 3 is that same as option 5 .
>>
>> 5 on interactive produces a short time format  like 3:18 or 21:50
>> 5 on js term give output like 04:21:52
>>
>> Presumably fixing the bug I noted in last msg will catch this too.
>
> No. The js time code knows nothing about format options inside
> gnuplot.  That's where this thread started.


gnuplot is feeding something that is determined by the set mouse format 
options. I've done it this morning, it does make a difference.

I understand that the long time format is drawn from the system running 
the viewer (browser in this case) not run system running gnuplot, where 
that is different.

I can see that timefmt is not transmitted to the js code and it would 
maybe load js code too much to start parsing that in js.


   This means that 5 is effectively the same as 3. Perhaps a note in 
help could clarify the limitations.

Also I found the help quite hard to follow at first since there is no 
explicit declaration of the syntax nor example for the integer form of 
the command.  I think that needs to be clearer.

Also an error in the last eg.
   7   format from `set mouse mouseformat`, e.g. "mouse x,y = 1.23, 
2.450"


Best regards, Peter.




The js code uses
> whatever format is provided by the javascript interpreter's
> Date() module.  The only control currently built into the
> gnuplot terminals (canvas, svg) is to toggle Date/Time/both.
>
> Gnuplot's time/date code is IMHO a creaky relic of an earlier era.
> I am reluctant to touch the code, and I try not to use it for
> plotting.  In that regard I am fortunate in having to deal
> with time data only rarely.
>
> The mouse coordinate-tracking code is also showing its age.
> It used to be that the small number of terminal drivers that
> offered mousing (windows, x11, pm) all used the same support
> routine in the core gnuplot code.   That is no longer true;
> some of the interactive terminals contain separate code for
> "-persist" mode, and the offline terminals like canvas and svg
> rely on self-contained javascript support.
>
> So the intersection (tracking time coords while mousing)
> is a particular weak spot.  Any suggestions of how to improve
> this are welcome.  An improved system need not necessarily
> replicate the current hodge-podge.
>
> 	Ethan
>
>>
>>
>> Peter.
>

On 04/25/12 19:37, Ethan A Merritt wrote:
> On Wednesday, April 25, 2012 02:09:19 am plotter@... wrote:
>> Hi,
>>
>> I have not tested this problem on canvas but I'm guessing it would be
>> the same as seen in svg.
>>
>> Part of the value of scalable formats is the lack of granularity and the
>> ability to zoom to the desired resolution.
>>
>> In testing mouse coords on svg I find there is granularity at the scale
>> of the decimal point character. (or one dot of the colon).
>
> The precision of the coordinates is indeed one decimal place.
> Not sure what you mean by "one dot of the colon".
>
>> I have configured Firefox to allow very high zoom levels , this is
>> excellent for looking at my data plots and allows seeing this problem
>> clearly.
>
> I cannot speak to exactly what happens when you zoom in Firefox.
> Ideally it would employ the precision of the coordinates in the file,
> meaning that it would still be accurate to one display pixel when the zoom
> factor is 10X.
>
>> The mouse cursor moves smoothly as expected but the coord readout only
>> moves in jumps that are the size of the dot.
>> Each jump moves the cursor text by a similar amount and updates to coords.
>
> Quantization of mouse movement is a whole separate issue.
> If there is a limitation there, it's at the level of the X input layer
> or whatever serves that purpose on your platform. I am told that some newer
> platforms treat mouse position as a continuous variable, but to the best of
> my knowledge X only provides an integer pixel coordinate, and the minimum
> "delta" of mouse motion may be larger than one pixel.
>

Ethan,

I think the point is that FF zoom does not alter the coords of the page, 
it just makes it look bigger,  so it's the image size at creation time 
that sets the coordinate quantisation when viewed in a browser.

I think I need to try to set larger dimensions in set term svg , then 
display it at a reduced size.


>> Is this due to the svg_scale  bug I caught last week?
>
> The internal precision of the plot is set by SVG_SCALE, yes.
> You could set it to 100. rather than 10. to get higher precision.
> The tradeoff is that printing an additional decimal place in every
> coordinate of every command in the output file will make the file
> significantly larger for a typical gnuplot graph.
>
> It is also possible that changing the precision would uncover additional
> bugs, but we could consider that a good thing rather than a bad thing :-)

Yeah, I may try that just for fun.

It could improve the precision of the plots when I zoom in.

xx.x -> xx.xx  = 25% growth
xxx.x -> xxx.xx = 20% growth.
rest fixed.

Should net out at about 20%, may be worth the hit.

Thanks for you help in understanding this.

I'll let you know if it throws any bugs ;)

Peter.

On 04/25/12 19:37, Ethan A Merritt wrote:
> On Wednesday, April 25, 2012 02:09:19 am plotter@... wrote:
>> Hi,
>>
>> I have not tested this problem on canvas but I'm guessing it would be
>> the same as seen in svg.
>>
>> Part of the value of scalable formats is the lack of granularity and the
>> ability to zoom to the desired resolution.
>>
>> In testing mouse coords on svg I find there is granularity at the scale
>> of the decimal point character. (or one dot of the colon).
>
> The precision of the coordinates is indeed one decimal place.
> Not sure what you mean by "one dot of the colon".
>
>> I have configured Firefox to allow very high zoom levels , this is
>> excellent for looking at my data plots and allows seeing this problem
>> clearly.
>
> I cannot speak to exactly what happens when you zoom in Firefox.
> Ideally it would employ the precision of the coordinates in the file,
> meaning that it would still be accurate to one display pixel when the zoom
> factor is 10X.
>
>> The mouse cursor moves smoothly as expected but the coord readout only
>> moves in jumps that are the size of the dot.
>> Each jump moves the cursor text by a similar amount and updates to coords.
>
> Quantization of mouse movement is a whole separate issue.
> If there is a limitation there, it's at the level of the X input layer
> or whatever serves that purpose on your platform. I am told that some newer
> platforms treat mouse position as a continuous variable, but to the best of
> my knowledge X only provides an integer pixel coordinate, and the minimum
> "delta" of mouse motion may be larger than one pixel.
>
>> Is this due to the svg_scale  bug I caught last week?
>
> The internal precision of the plot is set by SVG_SCALE, yes.
> You could set it to 100. rather than 10. to get higher precision.
> The tradeoff is that printing an additional decimal place in every
> coordinate of every command in the output file will make the file
> significantly larger for a typical gnuplot graph.
>
> It is also possible that changing the precision would uncover additional
> bugs, but we could consider that a good thing rather than a bad thing :-)
>
> 	Ethan
>

Hi,

I just tried a build with  CANVAS_OVERSAMPLE aka SVG_SCALE=100

Good news is nothing too bad happens but I'm not sure what I get for my 
money.



	<path  d='M489.2,197.0 L484.7,197.0 M489.2,193.3 L484.7,193.3 
M489.2,189.6 L484.7,189.6 M489.2,186.0 L484.7,186.0
		M489.2,182.3 L484.7,182.3 M489.2,178.6 L484.7,178.6 M489.2,175.0 
L484.7,175.0 M489.2,171.3 L484.7,171.3
		M489.2,167.7 L484.7,167.7 M489.2,164.0 L480.2,164.0  h0.01'/>


What difference should I see ?  I thought this was supposed to add and 
extra d.p. to the x,y coords.

 From the source, it just looks like it changes the preset variables it 
prints for the js mouse code.


<script type="text/javascript"><![CDATA[
// plot boundaries and axis scaling information for mousing
gnuplot_svg.plot_term_xmax = 60;
gnuplot_svg.plot_term_ymax = 48;
gnuplot_svg.plot_xmin = 6.4;
gnuplot_svg.plot_xmax = 48.9;
gnuplot_svg.plot_ybot = 40.2;
gnuplot_svg.plot_ytop = 5.4;
gnuplot_svg.plot_width = 42.6;
gnuplot_svg.plot_height = 34.8;
gnuplot_svg.plot_axis_xmin = 0;
gnuplot_svg.plot_axis_xmax = 1980;
gnuplot_svg.plot_axis_ymin = -5;
gnuplot_svg.plot_axis_ymax = 90;
gnuplot_svg.polar_mode = false;
gnuplot_svg.plot_axis_x2min = "none"
gnuplot_svg.plot_axis_y2min = -50;
gnuplot_svg.plot_axis_y2max = 900;
gnuplot_svg.plot_logaxis_x = 0;
gnuplot_svg.plot_logaxis_y = 0;
gnuplot_svg.plot_timeaxis_x = "Time";
]]>
</script>




also mouse coords gets a  bit confused though I don't understand how.

y mouse coord is upside down , x TIME coord gets 24h in several times 
across the plot that is just a daily plot.


x=00:30 reads 05:53 ; y1=30 reads -640 !?


Needs a fix.



Thx, Peter

On Thursday, 26 April 2012, plotter@... wrote:
> Hi,
> 
> I just tried a build with  CANVAS_OVERSAMPLE aka SVG_SCALE=100
> 
> Good news is nothing too bad happens but I'm not sure what I get for my 
> money.
> 
> 
> 
> 	<path  d='M489.2,197.0 L484.7,197.0 M489.2,193.3 L484.7,193.3 
> M489.2,189.6 L484.7,189.6 M489.2,186.0 L484.7,186.0
> 		M489.2,182.3 L484.7,182.3 M489.2,178.6 L484.7,178.6 M489.2,175.0 
> L484.7,175.0 M489.2,171.3 L484.7,171.3
> 		M489.2,167.7 L484.7,167.7 M489.2,164.0 L480.2,164.0  h0.01'/>
> 
> 
> What difference should I see ?  I thought this was supposed to add and 
> extra d.p. to the x,y coords.

Yeah, I noticed that right after I posted my previous suggestion.
I fixed it in CVS yesterday, but you probably haven't updated since
then.

	Ethan


> 
>  From the source, it just looks like it changes the preset variables it 
> prints for the js mouse code.
> 
> 
> <script type="text/javascript"><![CDATA[
> // plot boundaries and axis scaling information for mousing
> gnuplot_svg.plot_term_xmax = 60;
> gnuplot_svg.plot_term_ymax = 48;
> gnuplot_svg.plot_xmin = 6.4;
> gnuplot_svg.plot_xmax = 48.9;
> gnuplot_svg.plot_ybot = 40.2;
> gnuplot_svg.plot_ytop = 5.4;
> gnuplot_svg.plot_width = 42.6;
> gnuplot_svg.plot_height = 34.8;
> gnuplot_svg.plot_axis_xmin = 0;
> gnuplot_svg.plot_axis_xmax = 1980;
> gnuplot_svg.plot_axis_ymin = -5;
> gnuplot_svg.plot_axis_ymax = 90;
> gnuplot_svg.polar_mode = false;
> gnuplot_svg.plot_axis_x2min = "none"
> gnuplot_svg.plot_axis_y2min = -50;
> gnuplot_svg.plot_axis_y2max = 900;
> gnuplot_svg.plot_logaxis_x = 0;
> gnuplot_svg.plot_logaxis_y = 0;
> gnuplot_svg.plot_timeaxis_x = "Time";
> ]]>
> </script>
> 
> 
> 
> 
> also mouse coords gets a  bit confused though I don't understand how.
> 
> y mouse coord is upside down , x TIME coord gets 24h in several times 
> across the plot that is just a daily plot.
> 
> 
> x=00:30 reads 05:53 ; y1=30 reads -640 !?
> 
> 
> Needs a fix.
> 
> 
> 
> Thx, Peter
> 
> 
> 
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and 
> threat landscape has changed and how IT managers can respond. Discussions 
> will include endpoint security, mobile security and the latest in malware 
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> gnuplot-beta mailing list
> gnuplot-beta@...
> https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
>

On 04/27/12 04:15, sfeam (Ethan Merritt) wrote:
>> >  What difference should I see ?  I thought this was supposed to add and
>> >  extra d.p. to the x,y coords.
> Yeah, I noticed that right after I posted my previous suggestion.
> I fixed it in CVS yesterday, but you probably haven't updated since
> then.
>
> 	Ethan
>
>

ah, thanks.  I've been buggering around with this all afternoon, 
wondering if I was making some dumb mistake.

I'll get a fresh pull in a day or two.

regards.

Hi,

just updated from cvs and it fails to compile version.h

looks like a patching error:


const char gnuplot_version[] = "4.7";
const char gnuplot_patchlevel[] = "0";
<<<<<<< version.c
const char gnuplot_date[] = "2012-02-08 ";
const char gnuplot_copyright[] = "Copyright (C) 1986-1993, 1998, 2004, 
2007-2011";
=======
const char gnuplot_date[] = "2012-03-02 ";
const char gnuplot_copyright[] = "Copyright (C) 1986-1993, 1998, 2004, 
2007-2012";
 >>>>>>> 1.104

On Fri, Apr 27, 2012 at 14:48,  <plotter@...> wrote:
> Hi,
>
> just updated from cvs and it fails to compile version.h
>
> looks like a patching error:
>
>
> const char gnuplot_version[] = "4.7";
> const char gnuplot_patchlevel[] = "0";
> <<<<<<< version.c
> const char gnuplot_date[] = "2012-02-08 ";
> const char gnuplot_copyright[] = "Copyright (C) 1986-1993, 1998, 2004,
> 2007-2011";
> =======
> const char gnuplot_date[] = "2012-03-02 ";
> const char gnuplot_copyright[] = "Copyright (C) 1986-1993, 1998, 2004,
> 2007-2012";
>  >>>>>>> 1.104

My guess is that while you were building gnuplot your local copy was
changed. In the meantime it was also changed in CVS and when you tried
to update, CVS had problems with merging the changes (it wasn't able
to decide whether to obey your local modifications or to take the one
from CVS).

It probably helps to simply delete this file and update again.

Mojca

On Wednesday, 25 April 2012, Jon Oddie wrote:
> 
> 3521460 patches doc2texi to additionally create an Elisp file of ElDoc
> strings (Emacs' version of tooltips) extracted from the Syntax:
> 
> 3521457 fixes a couple of minor bugs (avoiding inserting multiple
> copies of the same terminal help, which sometimes happened before)
> 
> There's probably little point in merging these unless/until the
> corresponding pieces are merged in a new release of gnuplot-mode

When you say "little point in merging", does that mean it's harmless
or does it mean it will break something for people not using an
updated gnuplot-mode?   Harmless looking back but useful going
forward is fine.  Broken until you upgrade is not.

	Ethan




> , but
> I wanted to put them out there. If there are any interested Emacs
> users on this list they can check out the `context' branch of
> gnuplot-mode at
> https://github.com/bruceravel/gnuplot-mode/tree/context and see if it
> works for them.
> 
> I also wanted to ask if it would be OK in the meantime to include a
> copy of either (a) the auto-generated 'gnuplot-eldoc.el' strings file
> or (b) the patched doc2texi.el, in the gnuplot-mode repository.
> 
> Thanks,
> 
> Jon
> 
> 
> 
> 
> On 9 Feb 2012, at 18:50, Ethan A Merritt wrote:
> 
> >>> 
> >>> I'd say the better method would be to write a quick doc2tooltip.c
> >>> program to parallel the others.  It would look for the string
> >>>  Syntax:
> >>> in gnuplot.doc and extract the following lines into a tooltip
> >>> collection.
> >> 
> >> 
> >> Indeed, that's a better idea; thanks for the suggestion. Now that I
> >> look at the docs/ directory I see there is already a `doc2texi.el'
> >> contributed by Bruce Ravel, the author of gnuplot-mode. It would
> >> probably make the most sense for me to modify that to output an Elisp
> >> file of tooltips along with the texinfo file. Any objections?
> > 
> > No objections. Just a warning that the code in doc2texi.el may itself 
> > be a bit rusty.  I seem to recall some reports of problems with the
> > *.info file involving infinite loops of redirected links or something
> > like that.
> > 
> > 	Ethan
> 
> 
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and 
> threat landscape has changed and how IT managers can respond. Discussions 
> will include endpoint security, mobile security and the latest in malware 
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> gnuplot-beta mailing list
> gnuplot-beta@...
> https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
>

>> 
>> There's probably little point in merging these unless/until the
>> corresponding pieces are merged in a new release of gnuplot-mode
> 
> When you say "little point in merging", does that mean it's harmless
> or does it mean it will break something for people not using an
> updated gnuplot-mode?   Harmless looking back but useful going
> forward is fine.  Broken until you upgrade is not.

It's harmless.  All it will do is create two unused Lisp files, which
are only loaded into Emacs if someone has the patched gnuplot-mode.

The other patch just eliminates some duplicate pages in the Info
file. (I confirmed this by diffing the output of the original and
the patched version).

It is not exactly about the topic at hand (I'm not emacs user and know
even less about lisp), but there were three bug reports in macports
about misconfigured emacs support (not necessary related to bad
configuration in gnuplot itself).

The main problem is that gnuplot package doesn't depend on emacs (but
that can easily be fixed in macports), the second problem reported
reported is that gnuplot sometimes uses some random emacs present on
computer and may fail to install.

If there is some volunteer (pointing at Jonathar, but there might be
others) willing to explain me what exactly has to be done, how to make
sure that exactly the specified version of emacs is used, whether it
makes sense to create a separate package "gnuplot-emacs" that only
installs the list files to the desired place etc. ... please let me
know.

Mojca

Hi Mojca,

I have both Macports and several versions of Emacs scattered about so
I'd be happy to help if I can.  Can you point me to the bug reports?

Jon


On 26 Apr 2012, at 10:32, Mojca Miklavec wrote:

> It is not exactly about the topic at hand (I'm not emacs user and know
> even less about lisp), but there were three bug reports in macports
> about misconfigured emacs support (not necessary related to bad
> configuration in gnuplot itself).
> 
> The main problem is that gnuplot package doesn't depend on emacs (but
> that can easily be fixed in macports), the second problem reported
> reported is that gnuplot sometimes uses some random emacs present on
> computer and may fail to install.
> 
> If there is some volunteer (pointing at Jonathar, but there might be
> others) willing to explain me what exactly has to be done, how to make
> sure that exactly the specified version of emacs is used, whether it
> makes sense to create a separate package "gnuplot-emacs" that only
> installs the list files to the desired place etc. ... please let me
> know.
> 
> Mojca

On Thursday, April 26, 2012 02:14:46 am Jonathan Oddie wrote:
>
> The other patch just eliminates some duplicate pages in the Info
> file. (I confirmed this by diffing the output of the original and
> the patched version).
>
OK, but there seems to be a problem.
After applying that patch, the build script no longer works here:

[343] patch -p1 < ../../doc2texi-bugfix-patch.diff
patching file doc2texi.el

[344] make gnuplot.texi
Creating texinfo
Loading /etc/emacs/site-start.d/autoconf.el (source)...
Loading /etc/emacs/site-start.d/cmake.el (source)...
Loading /etc/emacs/site-start.d/desktop-file-utils.el (source)...
Loading /etc/emacs/site-start.d/gettext.el (source)...
Loading /etc/emacs/site-start.d/python.el (source)...
Loading /etc/emacs/site-start.d/rpm-mandriva-setup.el (source)...
Loading /etc/emacs/site-start.d/rst.el (source)...
Loading /etc/emacs/site-start.d/ruby.el (source)...
Loading /etc/emacs/site-start.d/vc_git.el (source)...
Inserting help for terminals ...
Wrong type argument: stringp, ("linux")
make: *** [gnuplot.texi] Error 255

[345] emacs --version
GNU Emacs 23.1.1