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

Re: granularity in xml terminals

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

On 04/25/12 19:37, Ethan A Merritt wrote:
> On Wednesday, April 25, 2012 02:09:19 am pl...@pi... 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

Re: doc2texi.el and gnuplot-mode contextual help

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

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

Re: doc2texi.el and gnuplot-mode contextual help

[Jon O. <j.j...@gm...>]

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

Re: doc2texi.el and gnuplot-mode contextual help

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

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

Re: doc2texi.el and gnuplot-mode contextual help

[Jonathan O. <j.j...@gm...>]

>> 
>> 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).

Re: doc2texi.el and gnuplot-mode contextual help

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

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
> gnu...@li...
> https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
> 

doc2texi.el and gnuplot-mode contextual help

[Jon O. <j.j...@gm...>]

Hi all,

A couple of months ago I wrote about wanting to support quick
contextual documentation in Emacs' gnuplot-mode, then let it drop as I
was busy with other things.

It's working now and I've submitted two patches for doc2texi.el to the
tracker:

3521460 patches doc2texi to additionally create an Elisp file of ElDoc
strings (Emacs' version of tooltips) extracted from the Syntax:
descriptions in gnuplot.doc. It also compiles it and installs it in
the site-lisp directory. The generated file includes a copy of the
Gnuplot license at the top along with a disclaimer that it is
auto-generated and not meant to be edited by hand.

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, 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

Re: granularity in xml terminals

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

On 04/25/12 19:37, Ethan A Merritt wrote:
> On Wednesday, April 25, 2012 02:09:19 am pl...@pi... 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.

Re: crosscompiling installing js bits

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

On 04/25/12 17:31, sfeam (Ethan Merritt) wrote:
> On Wednesday, 25 April 2012, pl...@pi... wrote:
>> On 04/25/12 10:24, pl...@pi... 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.
>

Re: granularity in xml terminals

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

On Wednesday, April 25, 2012 02:09:19 am pl...@pi... 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

Re: crosscompiling installing js bits

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

On Wednesday, 25 April 2012, pl...@pi... wrote:
> On 04/25/12 10:24, pl...@pi... 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.

granularity in xml terminals

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

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.

Re: crosscompiling installing js bits

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

On 04/25/12 10:24, pl...@pi... 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.

Re: crosscompiling installing js bits

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

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.

Re: crosscompiling installing js bits

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

> 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.
> 

Re: crosscompiling installing js bits

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

On 04/24/12 22:45, Ethan A Merritt wrote:
> On 04/24/12 20:54, Ethan A Merritt wrote:
>>> On Monday, April 23, 2012 05:19:04 pm pl...@pi... wrote:
>>
>> In fact what would be far more convinient for this xml type of terminal
>> would be to include the js file (optionally) inside the svg/canvas xml
>> document.
>
> That's what the "standalone" option does.
>
> ... which, I see, is missing from "help set term svg".
> Oops. Documentation bug.
>

Thanks, that works brilliantly. Much easier.

4.6.0 seems to work perfectly on ARM including the js features.

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.

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.

Re: crosscompiling installing js bits

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

On 04/24/12 22:45, Ethan A Merritt wrote:
> On 04/24/12 20:54, Ethan A Merritt wrote:
>>> On Monday, April 23, 2012 05:19:04 pm pl...@pi... wrote:
>>
>> In fact what would be far more convinient for this xml type of terminal
>> would be to include the js file (optionally) inside the svg/canvas xml
>> document.
>
> That's what the "standalone" option does.
>
> ... which, I see, is missing from "help set term svg".
> Oops. Documentation bug.
>

Ah cool !

I had a nagging feeling as I added "mouse" to set term svg , that I was 
missing another option.  ;)

Many thanks. Peter.

Re: crosscompiling installing js bits

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

On 04/24/12 20:54, Ethan A Merritt wrote:
> > On Monday, April 23, 2012 05:19:04 pm pl...@pi... wrote:
> 
> In fact what would be far more convinient for this xml type of terminal 
> would be to include the js file (optionally) inside the svg/canvas xml 
> document.

That's what the "standalone" option does.

... which, I see, is missing from "help set term svg".
Oops. Documentation bug.

Re: crosscompiling installing js bits

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

On 04/24/12 20:54, Ethan A Merritt wrote:
> On Monday, April 23, 2012 05:19:04 pm pl...@pi... wrote:
>> Hi,
>>
>> I am buildin 4.6.0 for embedded and it seems to work fine except for
>> mouse features on svg, where I'm finding it is inserting links to the
>> build directory structure not the target.
>>
>> using
>>
>> set term svg mouse
>>
>> I get the following at the top of my svg
>>
>> <script type="text/javascript"
>> xlink:href="/embedded_build/root/usr/share/gnuplot/4.6/js/gnuplot_svg.js"/>
>>
>>    ARCH=arm  ./configure --host=arm-unknown-linux-gnueabi --without-x
>> --without-pdf \
>> --without-cairo --disable-wxwidgets --without-x --without-tutorial \
>> --prefix=/embedded_build/root/usr   --without-lua
>>
>>
>>
>> Can you give a hint on what options/flags I need to set before calling
>> make etc so that gnuplot creates a standard /usr/share/ href here.
>
> It is taken from GNUPLOT_JS_DIR, which is defined in  .../src/Makefile.am
>
> # Default javascript location
> GNUPLOT_JS_DIR=$(pkgdatadir)/$(VERSION_MAJOR)/js
>
> Some autoconf magic converts $(pkgdatadir) into what it thinks is the
> correct target directory for installation.  I would have thought that if
> it gets this one wrong it would similarly get all other instances of
> $(pkgdatadir) wrong.   Are the *.js files themselves getting installed
> in this same incorrect place, or do they end up somewhere else?
>
> 	Ethan
>
Thanks Ethan,

I had found that var in the code and tried setting it as and env var on 
the make command line, but it made no difference. Maybe I need to hack 
the Makefile.am

Hmm, I'd prefer a tidier way to do this.

The js file is going to the standard share/gnuplot/4.6js under the 
install dir given in --prefix.

Thx.

Re: crosscompiling installing js bits

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

On 04/24/12 20:54, Ethan A Merritt wrote:
> On Monday, April 23, 2012 05:19:04 pm pl...@pi... wrote:
>> Hi,
>>
>> I am buildin 4.6.0 for embedded and it seems to work fine except for
>> mouse features on svg, where I'm finding it is inserting links to the
>> build directory structure not the target.
>>
>> using
>>
>> set term svg mouse
>>
>> I get the following at the top of my svg
>>
>> <script type="text/javascript"
>> xlink:href="/embedded_build/root/usr/share/gnuplot/4.6/js/gnuplot_svg.js"/>
>>
>>    ARCH=arm  ./configure --host=arm-unknown-linux-gnueabi --without-x
>> --without-pdf \
>> --without-cairo --disable-wxwidgets --without-x --without-tutorial \
>> --prefix=/embedded_build/root/usr   --without-lua
>>
>>
>>
>> Can you give a hint on what options/flags I need to set before calling
>> make etc so that gnuplot creates a standard /usr/share/ href here.
>
> It is taken from GNUPLOT_JS_DIR, which is defined in  .../src/Makefile.am
>
> # Default javascript location
> GNUPLOT_JS_DIR=$(pkgdatadir)/$(VERSION_MAJOR)/js
>
> Some autoconf magic converts $(pkgdatadir) into what it thinks is the
> correct target directory for installation.  I would have thought that if
> it gets this one wrong it would similarly get all other instances of
> $(pkgdatadir) wrong.   Are the *.js files themselves getting installed
> in this same incorrect place, or do they end up somewhere else?
>
> 	Ethan
>

In fact what would be far more convinient for this xml type of terminal 
would be to include the js file (optionally) inside the svg/canvas xml 
document.

I thought I submitted some code a year or two ago to do just that by 
inserting the js in a CDATA block or something,

This may not always be a good choice since just gnuplot_svg.js is about 
6kB. However, my svg is about 37k so that's acceptable for my use.

Since I quite often email these to colleges, it would be much easier to 
send one self contained file.  These days 6k is a small price to pay for 
that convenience.

regards, Peter.

Re: Updating generated lua help

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

On Tue, Apr 24, 2012 at 20:40, Ethan A Merritt wrote:
> On Tuesday, April 24, 2012 10:57:55 am Mojca Miklavec wrote:
>> Hello,
>>
>> may I request updating lua help? (Else the system keeps complaining
>> about modified file.)
>
> The help system files are fully generated for inclusion in each release,
> but they are not regenerated for the CVS repository every time there is a
> change to the source.  I don't mind updating gnuplot-tikz.help, but you
> really shouldn't expect the CVS copy of any generated file to be in sync
> with the copy produced by build+install.

It is ok if the files are occasionally out of sync, but if that is
noticed, I cannot hurt to sync them.

> By "the system keeps complaining", do you mean some "make" target or
> do you mean git?

There are no problems with "make" target (so it is harmless in
principle). It is only annoying that differences are shown when there
shouldn't be any.

The other problem with TEXDIR ignoring --prefix is something that
would result in a failure to install gnuplot however.

Mojca

Re: crosscompiling installing js bits

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

On Monday, April 23, 2012 05:19:04 pm pl...@pi... wrote:
> Hi,
> 
> I am buildin 4.6.0 for embedded and it seems to work fine except for 
> mouse features on svg, where I'm finding it is inserting links to the 
> build directory structure not the target.
> 
> using
> 
> set term svg mouse
> 
> I get the following at the top of my svg
> 
> <script type="text/javascript" 
> xlink:href="/embedded_build/root/usr/share/gnuplot/4.6/js/gnuplot_svg.js"/>
> 
>   ARCH=arm  ./configure --host=arm-unknown-linux-gnueabi --without-x 
> --without-pdf \
> --without-cairo --disable-wxwidgets --without-x --without-tutorial \
> --prefix=/embedded_build/root/usr   --without-lua
> 
> 
> 
> Can you give a hint on what options/flags I need to set before calling 
> make etc so that gnuplot creates a standard /usr/share/ href here.

It is taken from GNUPLOT_JS_DIR, which is defined in  .../src/Makefile.am

# Default javascript location
GNUPLOT_JS_DIR=$(pkgdatadir)/$(VERSION_MAJOR)/js

Some autoconf magic converts $(pkgdatadir) into what it thinks is the
correct target directory for installation.  I would have thought that if
it gets this one wrong it would similarly get all other instances of
$(pkgdatadir) wrong.   Are the *.js files themselves getting installed
in this same incorrect place, or do they end up somewhere else?

	Ethan

Re: Updating generated lua help

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

On Tuesday, April 24, 2012 10:57:55 am Mojca Miklavec wrote:
> Hello,
> 
> may I request updating lua help? (Else the system keeps complaining
> about modified file.)

The help system files are fully generated for inclusion in each release,
but they are not regenerated for the CVS repository every time there is a
change to the source.  I don't mind updating gnuplot-tikz.help, but you
really shouldn't expect the CVS copy of any generated file to be in sync
with the copy produced by build+install.

By "the system keeps complaining", do you mean some "make" target or
do you mean git?

	Ethan

Updating generated lua help

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

Hello,

may I request updating lua help? (Else the system keeps complaining
about modified file.)

--- a/term/lua/gnuplot-tikz.help
+++ b/term/lua/gnuplot-tikz.help
@@ -15,6 +15,7 @@
 "      {nogppoints | gppoints}",
 "      {picenvironment | nopicenvironment}",
 "      {noclip | clip}",
+"      {notightboundingbox | tightboundingbox}",
 "      {background \"<colorpec>\"}",
 "      {size <x>{unit},<y>{unit}}",
 "      {scale <x>,<y>}",
@@ -62,7 +63,10 @@
 " 'clip' crops the plot at the defined canvas size. Default is",
 " 'noclip' by which only a minimum bounding box of the canvas size",
 " is set. Neither a fixed bounding box nor a crop box is set if the",
-" 'plotsize' option is used.",
+" 'plotsize' or 'tightboundingbox' option is used.",
+"",
+" If 'tightboundingbox' is set the 'clip' option is ignored and the",
+" final bounding box is the natural bounding box calculated by tikz.",
 "",

The option has been added by Ethan's commit:

2011-07-20  Peter Hedwig <pe...@af...>

  * term/lua/gnuplot-tikz.lua:  Point types 10 and 11 were upside down.
    Bug #3368877
  * fill paths now have a pensize > 0 to have slight overlap of tiles to
    avoid rendering artifacts
  * path building was broken and showed interrupted lines on certain plots
    e.g. plot '+' u 1:($1**2):($1**2) with lines pal lw 3 title '$x^2$'
  * a new terminal option (tightboundingbox|notightboundingbox) is added

but the corresponding generated files have not been updated.

Also: macports developers discovered that the TeX files like
gnuplot-lua-tikz.sty don't obey DESTDIR during installation. The weird
thing is that I'm not yet able to reproduce the problem outside of
macports (but it is consistent inside macports), so I'm not yet sure
how to provide a "minimal example" for that.

Thank you,
    Mojca

crosscompiling installing js bits

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

Hi,

I am buildin 4.6.0 for embedded and it seems to work fine except for 
mouse features on svg, where I'm finding it is inserting links to the 
build directory structure not the target.

using

set term svg mouse

I get the following at the top of my svg

<script type="text/javascript" 
xlink:href="/embedded_build/root/usr/share/gnuplot/4.6/js/gnuplot_svg.js"/>

  ARCH=arm  ./configure --host=arm-unknown-linux-gnueabi --without-x 
--without-pdf \
--without-cairo --disable-wxwidgets --without-x --without-tutorial \
--prefix=/embedded_build/root/usr   --without-lua



Can you give a hint on what options/flags I need to set before calling 
make etc so that gnuplot creates a standard /usr/share/ href here.

Thx. Peter.