Menu
▾
▴
gnuplot-beta
|
From: <pl...@pi...> - 2012-04-24 04:33:57
|
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. |
|
From: Ethan A M. <sf...@us...> - 2012-04-24 18:56:09
|
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 |
|
From: <pl...@pi...> - 2012-04-24 20:42:45
|
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. |
|
From: <pl...@pi...> - 2012-04-24 20:25:27
|
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. |
|
From: Ethan A M. <sf...@us...> - 2012-04-24 20:48:36
|
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. |
|
From: <pl...@pi...> - 2012-04-24 21:17:47
|
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. |
|
From: <pl...@pi...> - 2012-04-24 21:25:07
|
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. |
|
From: Ethan A M. <sf...@us...> - 2012-04-24 21:48:09
|
> 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. > |
|
From: <pl...@pi...> - 2012-04-25 08:24:57
|
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. |
|
From: sfeam (E. Merritt) <eam...@gm...> - 2012-04-25 15:31:24
|
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. |
|
From: <pl...@pi...> - 2012-04-25 18:27:45
|
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. > |
|
From: <pl...@pi...> - 2012-04-25 08:48:01
|
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. |
|
From: <pl...@pi...> - 2012-04-25 09:18:07
|
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. |
|
From: Ethan A M. <sf...@us...> - 2012-04-25 17:40:28
|
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 |
|
From: <pl...@pi...> - 2012-04-25 18:33:33
|
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. |
|
From: <pl...@pi...> - 2012-04-27 00:52:42
|
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 |
|
From: sfeam (E. Merritt) <eam...@gm...> - 2012-04-27 02:15:23
|
On Thursday, 26 April 2012, pl...@pi... 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 > gnu...@li... > https://lists.sourceforge.net/lists/listinfo/gnuplot-beta > |
|
From: <pl...@pi...> - 2012-04-27 03:10:19
|
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. |
|
From: <pl...@pi...> - 2012-04-27 12:52:44
|
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 |
|
From: Mojca M. <moj...@gm...> - 2012-04-29 18:38:13
|
On Fri, Apr 27, 2012 at 14:48, <pl...@pi...> 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 |
