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

Re: Undocumented behaviour of "smooth" options

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

On 21/02/17 23:21, Ethan A Merritt wrote:
>
> On the bug tracker    <https://sourceforge.net/p/gnuplot/bugs/1911/>
> Rainald Koch points out that when a data set contains some points with
> invalid y values, the result of smoothing is unexpected. This is true
> also if you use a filter to select a subset of the points, e.g.
>
>     plot FOO using 1:( filter($2) ? $2 : 1/0) smooth acsplines
>
> I can't find any mention of it in the documentation, but it seems that
> this is intentional.  The "smooth" code has a pre-processing step that
> splits the input data into N subsets separated by one or more "undefined"
> points. The smoothing is then applied separately to each of the N segments
> with no attempt to make the fit smooth or continuous at the junctions
> between segments.

I can see that this will be a problem with some splines which tend to be 
unstable at the end points and can veer off in either direction in a 
very unsmooth fashion.

In passing, I would even question whether linking to the end points of 
Bezier spline is even desirable. This seems poorly constrained and gives 
unsatisfactory results. Test with a limited dataset of say 20 points to 
get the idea.

This raises the question of why the code is splitting otherwise 
continuous data. Is this required to reduce computation for some of the 
smoothing methods, is it required for all types of smoothing algo. ?

If  this does  give unexpected results for datasets with breaks , as 
reported, is this a bug or a feature?  Would a smoothing process be 
expected to smooth and link across breaks in the data. Perhaps the 
pre-processing should be removing NaNs non inserting them.

Should this be an option to "smooth" ?

Peter.



>
> Is this documented somewhere that I haven't found?
>
> Is there a recommended way to fit a single smooth curve to the
> entire set of points after filtering?
>
> Current CVS allows this work-around:
>
>    set datafile missing NaN
>
> but that is very recent.  Was there no way to handle this in the past?
>
> 	Ethan
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> Membership management via: https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
>

Undocumented behaviour of "smooth" options

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

On the bug tracker    <https://sourceforge.net/p/gnuplot/bugs/1911/>
Rainald Koch points out that when a data set contains some points with
invalid y values, the result of smoothing is unexpected. This is true
also if you use a filter to select a subset of the points, e.g.

    plot FOO using 1:( filter($2) ? $2 : 1/0) smooth acsplines

I can't find any mention of it in the documentation, but it seems that
this is intentional.  The "smooth" code has a pre-processing step that
splits the input data into N subsets separated by one or more "undefined"
points. The smoothing is then applied separately to each of the N segments
with no attempt to make the fit smooth or continuous at the junctions
between segments.

Is this documented somewhere that I haven't found?

Is there a recommended way to fit a single smooth curve to the
entire set of points after filtering?

Current CVS allows this work-around:

   set datafile missing NaN

but that is very recent.  Was there no way to handle this in the past?

	Ethan

Re: Tester for the patch for linewidth option of aqua term

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

On Thursday, 09 February, 2017 14:09:10 Mojca Miklavec wrote:
> On 9 February 2017 at 07:54, Tatsuro MATSUOKA wrote:
> > In the Features Request 459
> > https://sourceforge.net/p/gnuplot/feature-requests/459/
> > (qt term does not suppoert linewidth option )
> >
> > Ethan also made patch for aqua terminal.
> >
> > Does anyone try whether the patch works correctly?
> 
> It seems to work correctly for me.
> I would also replace
> 
>     if (equals(c_token, "linewidth")) {
> with 
>     if (equals(c_token, "lw") || almost_equals(c_token, "linew$idth")) {


OK.
I've also set the TERM_LINEWIDTH flag for aquaterm, qt, and wxt
so that you can use "set termopt" to change just the linewidth.

	Ethan

Re: Tester for the patch for linewidth option of aqua term

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

On 9 February 2017 at 07:54, Tatsuro MATSUOKA wrote:
> In the Features Request 459
> https://sourceforge.net/p/gnuplot/feature-requests/459/
> (qt term does not suppoert linewidth option )
>
> Ethan also made patch for aqua terminal.
>
> Does anyone try whether the patch works correctly?

It seems to work correctly for me.


However in the light of

    if (equals(c_token, "dl") || almost_equals(c_token, "dashl$ength")) {

I would also replace

    if (equals(c_token, "linewidth")) {

with

    if (equals(c_token, "lw") || almost_equals(c_token, "linew$idth")) {

(I replied that in the ticket, but it seems that the browser or the
website sent my reply to digital heaven.)

Mojca

Tester for the patch for linewidth option of aqua term

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

In the Features Request 459
https://sourceforge.net/p/gnuplot/feature-requests/459/
(qt term does not suppoert linewidth option )

Ethan also made patch for aqua terminal.

Does anyone try whether the patch works correctly?

Tatsuro

linewidth option at set terminal (terminal name) for qt (Feature Requests 459)

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

There was a Feature Request for linewidth option for qt terminal.
https://sourceforge.net/p/gnuplot/feature-requests/459/

Currently qt terminal does not have linewidth option at "set terminal" command


gnuplot> set term wxt linewidth 2
Terminal type set to 'wxt'
Options are '0 lw 2 enhanced'
gnuplot> set term qt linewidth 2  
Terminal type set to 'qt'
         undefined variable: linewidth

Seeing manual of gnuplot for qt terminal,  linewidth option is not described.

For major interactive terminals, the "linewidth" option

wxt, x11, windows : implemented
qt, aqua : unimplemented

There might be a historical reason qt terminal has not implemented line width option.  

However, qt terminal is a now major terminal. 

I hope that those who are familiar qt terminal accept the feature requests 459 and 

implement linewidth option for qt terminal.

Tatsuro  

Re: gnuplot error code

[sfeam <sf...@us...>]

On Saturday, 04 February 2017 09:38:31 AM pl...@pi... wrote:
> On 04/02/17 04:14, sfeam wrote:
> > On Saturday, 04 February 2017 01:17:25 AM :	pl...@pi... wrote:
> >> Hi,
> >>
> >> I am calling gnuplot as a child process and need to conditionally return
> >> a non zero error code in some circumstances. From a quick search it
> >> seems that this is not possible, It always returns zero: yet that seems
> >> a little surprising.
> >>
> >> perl -e 'system("gnuplot -e \"exit 1;\""); print "$?\n"'
> >>
> >> The only way I can get a non zero result is if there is a parsing error
> >> in the gnuplot commands.
> >>
> >> I am using gnuplot to display real time data on a server and it would be
> >> good to be able to do some basic error trapping, not least for
> >> debugging. Is there a way to do this?
> >
> > Correct. There is no way to control the gnuplot exit value.
> >
> >
> 
> Thanks for the confirmation, Ethan.
> 
> Would this be a worthwhile feature to add? 

Sure.  But I have no idea how we would do it.
Adding a command "exit <status>" would not help so far as I can see,
because in order to execute that command the program must be
in a non-error state. So the only code it makes sense to emit is 0.

If there is a serious error like segfault or divide-by-zero the
program exits via the system fault-handling and gnuplot's normal
exit routine is not invoked.  If there is a non-fatal error
(read past end-of-file, say) gnuplot handles this internally and
by the time it is ready to parse a new command like "exit" the
error state no longer exists.

What sort of error do you imagine reporting?

	Ethan



> I'm thinking of something 
> like the awk exit which allows an optional  integer argument to  return.
> 
> if ( ! happy ) { print "not happy" ; exit 1; )
> 
> gnuplot is an excellent tool for plotting real time data on embedded 
> devices to provide real time graphic output but obviously the 
> possibility to exit with an error condition can be helpful, firstly in 
> debugging and also trapping possible error conditions with a meaningful 
> response should they happen.
> 
> The current behaviour is just jexit 0 , for backwards compat, some 
> thought would need to be given to current non zero return in case of a 
> syntax error in a gnuplot script but this does not seem to raise any 
> conflict for those trapping current behaviour.
> 
> Peter.
> 
> 
> 
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> Membership management via: https://lists.sourceforge.net/lists/listinfo/gnuplot-beta

Re: gnuplot error code

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

On 04/02/17 04:14, sfeam wrote:
> On Saturday, 04 February 2017 01:17:25 AM :	pl...@pi... wrote:
>> Hi,
>>
>> I am calling gnuplot as a child process and need to conditionally return
>> a non zero error code in some circumstances. From a quick search it
>> seems that this is not possible, It always returns zero: yet that seems
>> a little surprising.
>>
>> perl -e 'system("gnuplot -e \"exit 1;\""); print "$?\n"'
>>
>> The only way I can get a non zero result is if there is a parsing error
>> in the gnuplot commands.
>>
>> I am using gnuplot to display real time data on a server and it would be
>> good to be able to do some basic error trapping, not least for
>> debugging. Is there a way to do this?
>
> Correct. There is no way to control the gnuplot exit value.
>
>

Thanks for the confirmation, Ethan.

Would this be a worthwhile feature to add? I'm thinking of something 
like the awk exit which allows an optional  integer argument to  return.

if ( ! happy ) { print "not happy" ; exit 1; )

gnuplot is an excellent tool for plotting real time data on embedded 
devices to provide real time graphic output but obviously the 
possibility to exit with an error condition can be helpful, firstly in 
debugging and also trapping possible error conditions with a meaningful 
response should they happen.

The current behaviour is just jexit 0 , for backwards compat, some 
thought would need to be given to current non zero return in case of a 
syntax error in a gnuplot script but this does not seem to raise any 
conflict for those trapping current behaviour.

Peter.

Re: gnuplot error code

[sfeam <sf...@us...>]

On Saturday, 04 February 2017 01:17:25 AM :	pl...@pi... wrote:
> Hi,
> 
> I am calling gnuplot as a child process and need to conditionally return 
> a non zero error code in some circumstances. From a quick search it 
> seems that this is not possible, It always returns zero: yet that seems 
> a little surprising.
> 
> perl -e 'system("gnuplot -e \"exit 1;\""); print "$?\n"'
> 
> The only way I can get a non zero result is if there is a parsing error 
> in the gnuplot commands.
> 
> I am using gnuplot to display real time data on a server and it would be 
> good to be able to do some basic error trapping, not least for 
> debugging. Is there a way to do this?

Correct. There is no way to control the gnuplot exit value.

gnuplot error code

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

Hi,

I am calling gnuplot as a child process and need to conditionally return 
a non zero error code in some circumstances. From a quick search it 
seems that this is not possible, It always returns zero: yet that seems 
a little surprising.

perl -e 'system("gnuplot -e \"exit 1;\""); print "$?\n"'

The only way I can get a non zero result is if there is a parsing error 
in the gnuplot commands.

I am using gnuplot to display real time data on a server and it would be 
good to be able to do some basic error trapping, not least for 
debugging. Is there a way to do this?

Thanks, Peter.

Re: Any utility to adding a color wheel to WXT (and Qt) terminals?

[Allin C. <cot...@wf...>]

On Wed, 1 Feb 2017, Daniel J Sebald wrote:

> Often when I am developing a set of plot commands I'll just toss in some
> colors that are distinguishable, e.g., "red", "green".  Something quick.
>  But those colors are often too bright or too monochrome to view
> comfortably in a more "finished-product" plot such as a publication or
> application.  To choose customized colors "#RRGGBB", I often go to some
> color wheel (usually gimp) and pick the colors visually, for which the
> color wheel presents the associated RGB values.
>
> The thought just came to mind, Why not add a color wheel to the Qt and
> WXT terminals for the sake of convenience? [...]

When I'm doing that sort of thing, my go-to is gcolor2 -- much 
lighter than gimp -- http://gcolor2.sourceforge.net/ I like to have 
not only a color wheel with a hex read-out but also an "eye-dropper" 
tool to grab a nice color from somewhere on the desktop if required. 
gcolor2 has that (as also gimp, of course).

Whether this sort of tool is something that gnuplot should arrange 
to provide, I don't know. I think it may fall under the "Swiss army 
knife" (good software should not aim to be) objection.

Allin Cottrell

Re: Any utility to adding a color wheel to WXT (and Qt) terminals?

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

On 02/01/2017 04:35 PM, Daniel J Sebald wrote:
> On 02/01/2017 04:23 PM, Allin Cottrell wrote:
[snip]
>> When I'm doing that sort of thing, my go-to is gcolor2 -- much lighter
>> than gimp -- http://gcolor2.sourceforge.net/ I like to have not only a
>> color wheel with a hex read-out but also an "eye-dropper" tool to grab a
>> nice color from somewhere on the desktop if required. gcolor2 has that
>> (as also gimp, of course).
>>
>> Whether this sort of tool is something that gnuplot should arrange to
>> provide, I don't know. I think it may fall under the "Swiss army knife"
>> (good software should not aim to be) objection.
>
> Yes, true.  I was thinking that since these frameworks already have
> color-picker features, they are simply a matter of a few lines.
>
> I installed gcolor2 and this works nicely, thanks.  In addition to the
> eye-dropper, it also goes one step more in convenience by combining the
> RGB into a ready-made triplet #rrggbb that can be easily selected,
> copied and pasted.

And there is a list of colors to choose from in gcolor2, including the 
"w3c" or "html" names that Ethan pointed out.

Dan

Re: Any utility to adding a color wheel to WXT (and Qt) terminals?

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

On 02/01/2017 04:23 PM, Allin Cottrell wrote:
> On Wed, 1 Feb 2017, Daniel J Sebald wrote:
>
>> Often when I am developing a set of plot commands I'll just toss in some
>> colors that are distinguishable, e.g., "red", "green".  Something quick.
>>  But those colors are often too bright or too monochrome to view
>> comfortably in a more "finished-product" plot such as a publication or
>> application.  To choose customized colors "#RRGGBB", I often go to some
>> color wheel (usually gimp) and pick the colors visually, for which the
>> color wheel presents the associated RGB values.
>>
>> The thought just came to mind, Why not add a color wheel to the Qt and
>> WXT terminals for the sake of convenience? [...]
>
> When I'm doing that sort of thing, my go-to is gcolor2 -- much lighter
> than gimp -- http://gcolor2.sourceforge.net/ I like to have not only a
> color wheel with a hex read-out but also an "eye-dropper" tool to grab a
> nice color from somewhere on the desktop if required. gcolor2 has that
> (as also gimp, of course).
>
> Whether this sort of tool is something that gnuplot should arrange to
> provide, I don't know. I think it may fall under the "Swiss army knife"
> (good software should not aim to be) objection.

Yes, true.  I was thinking that since these frameworks already have 
color-picker features, they are simply a matter of a few lines.

I installed gcolor2 and this works nicely, thanks.  In addition to the 
eye-dropper, it also goes one step more in convenience by combining the 
RGB into a ready-made triplet #rrggbb that can be easily selected, 
copied and pasted.

Dan

Re: Any utility to adding a color wheel to WXT (and Qt) terminals?

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

On 02/01/2017 03:36 PM, Ethan A Merritt wrote:
> On Wednesday, 01 February, 2017 14:04:18 Daniel J Sebald wrote:
>> Often when I am developing a set of plot commands I'll just toss in some
>> colors that are distinguishable, e.g., "red", "green".  Something quick.
>>   But those colors are often too bright or too monochrome to view
>> comfortably in a more "finished-product" plot such as a publication or
>> application.
>
> Why not use the default colors? Thay are specifically chosen to be
> distinguishable even if the viewer has color vision abnormalities or
> the publication process has changed the color space.  If you like primary
> colors or extremes of hue, fine, but what matches your personal
> preference may be very far from what is suitable in publication or in
> a widely-used GUI.  See for example Wong (2011) [Nature Methods 8:441],
> which was used as a guide for the default colors.

I personally don't like the extreme hue, but the point was the color 
wheel is a convenient way of picking non-extreme colors.

Anyway, the colors listed in "test", i.e., 1, 2, 3, ... sort of works. 
I've just tried that (7 looks to be a good medium hue red), but ran into 
a little snag with the present code I have:

gnuplot> set object 1 rectangle from first 0,0 to first 2,2 fillcolor 7 
fillstyle solid 1.0
                                                                       ^
          colorspec option not recognized

Although "linecolor 7" appears to work for lines, fillcolor 7 doesn't 
for polygons.  Is that supposed to work?  I need the color of a fill to 
match the color of a line.  Oh, wait, guess it does:

gnuplot> set object 1 rectangle from first 0,0 to first 2,2 fillcolor ls 
7 fillstyle solid 1.0


> It might be worth extending or replacing this list to include the 140 color
> names in the current w3c HTML standard.  Those, by the way, are available
> via a menu at http://www.w3schools.com/colors/colors_names.asp

Or an interpreter option "w3c", e.g.:

    ... linecolor w3c "PapayaWhip"

Interestingly, w3schools provides a color picker on its website:

http://www.w3schools.com/colors/colors_picker.asp

Dan


>
> 	Ethan
>
>
>
>> To choose customized colors "#RRGGBB", I often go to some
>> color wheel (usually gimp) and pick the colors visually, for which the
>> color wheel presents the associated RGB values.
>>
>> The thought just came to mind, Why not add a color wheel to the Qt and
>> WXT terminals for the sake of convenience?  That is, in the menu bar,
>> put a small "color-wheel" icon that will pop up the framework's
>> color-selector... the selector wouldn't control anything, but simply
>> help the user determine suitable RGB values.
>>
>> Does such a thing sound useful?
>>
>> Having said that, looking through the Qt terminal I see there is a
>> color-selector example already used for picking the background.  So,
>> what I'm suggesting is already present.  However, the color-selector
>> isn't obvious enough as a feature for convenience.
>>
>> BTW, the Qt background color selection has what I'd consider a bug.  Do
>> some test plot:
>>
>> set term qt
>> plot x
>>
>> and then click on the wrench/settings icon.  "Select background color"
>> has a white patch associated with it.  Click on "Select background
>> color".  Click "Cancel", and the QColorDialog closes but the associated
>> patch has turned black.  I'd assume that "Cancel" should not change the
>> example patch.
>>
>> Dan
>>
>> ------------------------------------------------------------------------------
>> Check out the vibrant tech community on one of the world's most
>> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
>> _______________________________________________
>> gnuplot-beta mailing list
>> gnu...@li...
>> Membership management via: https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
>
>

Re: Any utility to adding a color wheel to WXT (and Qt) terminals?

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

On Wednesday, 01 February, 2017 14:04:18 Daniel J Sebald wrote:
> Often when I am developing a set of plot commands I'll just toss in some 
> colors that are distinguishable, e.g., "red", "green".  Something quick. 
>   But those colors are often too bright or too monochrome to view 
> comfortably in a more "finished-product" plot such as a publication or 
> application.  

Why not use the default colors? Thay are specifically chosen to be
distinguishable even if the viewer has color vision abnormalities or
the publication process has changed the color space.  If you like primary
colors or extremes of hue, fine, but what matches your personal 
preference may be very far from what is suitable in publication or in
a widely-used GUI.  See for example Wong (2011) [Nature Methods 8:441],
which was used as a guide for the default colors.

Regardless of whether you love or hate the current default colors,
the mechanism for replacing them with your own colors is pretty easy.
Just add your preferred set of colors to the ~/gnuplot initialization file.

Say you want colors that match the desktop theme Tango from a few
years back:

#
# Medium saturation colors from the Tango theme (freedesktop.org)
#
set linetype 1 lc rgb "#75507b" lw 1 # Plum
set linetype 2 lc rgb "#73d216" lw 1 # Chameleon
set linetype 3 lc rgb "#cc0000" lw 1 # Scarlet Red
set linetype 4 lc rgb "#edd400" lw 1 # Butter
set linetype 5 lc rgb "#3465a4" lw 1 # Sky Blue
set linetype 6 lc rgb "#c17d11" lw 1 # Chocolate
set linetype 7 lc rgb "#555753" lw 1 # Aluminum 5
set linetype 8 lc rgb "#f57900" lw 1 # Orange

Or suppose you are a fan of Matlab colors for the palette:

#
# Matlab "Jet" colormap
#
set pal defined (1 '#00008f', 8 '#0000ff', 24 '#00ffff', 40 '#ffff00', \
                 56 '#ff0000', 64 '#800000')


Gnuplot also knows at least some of the color names from the old
X11 color set (rgb.txt).  Try "show colornames".

It might be worth extending or replacing this list to include the 140 color
names in the current w3c HTML standard.  Those, by the way, are available
via a menu at http://www.w3schools.com/colors/colors_names.asp

	Ethan



> To choose customized colors "#RRGGBB", I often go to some 
> color wheel (usually gimp) and pick the colors visually, for which the 
> color wheel presents the associated RGB values.
> 
> The thought just came to mind, Why not add a color wheel to the Qt and 
> WXT terminals for the sake of convenience?  That is, in the menu bar, 
> put a small "color-wheel" icon that will pop up the framework's 
> color-selector... the selector wouldn't control anything, but simply 
> help the user determine suitable RGB values.
> 
> Does such a thing sound useful?
> 
> Having said that, looking through the Qt terminal I see there is a 
> color-selector example already used for picking the background.  So, 
> what I'm suggesting is already present.  However, the color-selector 
> isn't obvious enough as a feature for convenience.
> 
> BTW, the Qt background color selection has what I'd consider a bug.  Do 
> some test plot:
> 
> set term qt
> plot x
> 
> and then click on the wrench/settings icon.  "Select background color" 
> has a white patch associated with it.  Click on "Select background 
> color".  Click "Cancel", and the QColorDialog closes but the associated 
> patch has turned black.  I'd assume that "Cancel" should not change the 
> example patch.
> 
> Dan
> 
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> Membership management via: https://lists.sourceforge.net/lists/listinfo/gnuplot-beta

Any utility to adding a color wheel to WXT (and Qt) terminals?

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

Often when I am developing a set of plot commands I'll just toss in some 
colors that are distinguishable, e.g., "red", "green".  Something quick. 
  But those colors are often too bright or too monochrome to view 
comfortably in a more "finished-product" plot such as a publication or 
application.  To choose customized colors "#RRGGBB", I often go to some 
color wheel (usually gimp) and pick the colors visually, for which the 
color wheel presents the associated RGB values.

The thought just came to mind, Why not add a color wheel to the Qt and 
WXT terminals for the sake of convenience?  That is, in the menu bar, 
put a small "color-wheel" icon that will pop up the framework's 
color-selector... the selector wouldn't control anything, but simply 
help the user determine suitable RGB values.

Does such a thing sound useful?

Having said that, looking through the Qt terminal I see there is a 
color-selector example already used for picking the background.  So, 
what I'm suggesting is already present.  However, the color-selector 
isn't obvious enough as a feature for convenience.

BTW, the Qt background color selection has what I'd consider a bug.  Do 
some test plot:

set term qt
plot x

and then click on the wrench/settings icon.  "Select background color" 
has a white patch associated with it.  Click on "Select background 
color".  Click "Cancel", and the QColorDialog closes but the associated 
patch has turned black.  I'd assume that "Cancel" should not change the 
example patch.

Dan

Re: standards checking SVG output

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

On 31/01/17 04:21, sfeam wrote:
> On Monday, 30 January 2017 11:55:07 PM pl...@pi... wrote:
>> Hi,
>>
>> in doing some standards checking I found the leading line in gnuplots
>> SVG 'mousing' output has errors.
>>
>> <script language="javaScript" TYPE="text/javascript" >
>>
>> xml requires lower case. so 'type' not 'TYPE'
>>
>> also language should be "text/javascript"  too and now is js by default
>> so not required by current std. , though specifying  may be good to
>> cover all bases.
>>
>> Unless this has been carefully crafted to work on a maximum number of
>> browsers, it would presumably be best to stick as closely as possible to
>> standards.
>
> The line you quote is only output if the terminal option "standalone"
> is selected, right?

That is correct.

>  If you generate for display inside a web page you
> get a line like this instead:
>    <script type="text/javascript" xlink:href="./gnuplot_svg.js"/>
>
> Did your standards check catch anything else?
No, otherwise it was perfectly compliant. I was checking as part of 
testing cross browser compatibility which is still rather complicated 
for SVG. A frist step seemed like ensuring the output was fully compliant.

> Is there an on-line validation tool that is reasonably current
> (the ones I know from a few years ago have all gone defunct).
>
this is the one I was referring to :
https://validator.w3.org/

seems to be from the horse's mouth.

> Anyhow I'm confused. If you open the file in a web browser isn't
> the line being read according to HTML standards (case insensitive)
> rather than xml standards (case sensitive)?  I don't mind changing
> it but I would like to understand better what the target standard is.

I do not think the viewer is what defines the applicable standard , it 
is the document and it's declared doctype and dtd.

I doubt that this is a real compatibility issue but a load of 
cross-browser problems come from historical lack of respect for 
standards by major corporations. If documents do validate fully it would 
seem to be the way to go, unless some tweak was necessary to get around 
show stopper issue due to browser/viewer non compliance.

It is a detail that it would be good to tidy up , not a major issue.

Peter.
>
>
> 	Ethan
>
>
>

Re: standards checking SVG output

[sfeam <sf...@us...>]

On Monday, 30 January 2017 11:55:07 PM pl...@pi... wrote:
> Hi,
> 
> in doing some standards checking I found the leading line in gnuplots 
> SVG 'mousing' output has errors.
> 
> <script language="javaScript" TYPE="text/javascript" >
> 
> xml requires lower case. so 'type' not 'TYPE'
> 
> also language should be "text/javascript"  too and now is js by default 
> so not required by current std. , though specifying  may be good to 
> cover all bases.
> 
> Unless this has been carefully crafted to work on a maximum number of 
> browsers, it would presumably be best to stick as closely as possible to 
> standards.

The line you quote is only output if the terminal option "standalone"
is selected, right?  If you generate for display inside a web page you
get a line like this instead: 
   <script type="text/javascript" xlink:href="./gnuplot_svg.js"/>

Did your standards check catch anything else?
Is there an on-line validation tool that is reasonably current
(the ones I know from a few years ago have all gone defunct).

Anyhow I'm confused. If you open the file in a web browser isn't
the line being read according to HTML standards (case insensitive)
rather than xml standards (case sensitive)?  I don't mind changing
it but I would like to understand better what the target standard is.


	Ethan  

standards checking SVG output

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

Hi,

in doing some standards checking I found the leading line in gnuplots 
SVG 'mousing' output has errors.

<script language="javaScript" TYPE="text/javascript" >

xml requires lower case. so 'type' not 'TYPE'

also language should be "text/javascript"  too and now is js by default 
so not required by current std. , though specifying  may be good to 
cover all bases.

Unless this has been carefully crafted to work on a maximum number of 
browsers, it would presumably be best to stick as closely as possible to 
standards.

Regards, Peter.

Re: a patch for giving limited number of points along a line

[KH.Moriyama <khm...@gm...>]

Hi.
It is a very late reply to Nov. 19 mail about a patch for "pointnumber".
I modified the patch so that it does not use random number to move
the offset of the first point.
and i uploaded the patch to the Sourceforge patch page.
best regards :-)
-------
KH.Moriyama <khm...@gm...>
Blog: http://whoraibo.hatenablog.com/
+81-(0)80-3386-0618 (japan)
+82-(0)10-2999-2246 (korea)

On Sat, Nov 19, 2016 at 2:54 PM, KH.Moriyama <khm...@gm...> wrote:

> Hi, Ethan,
>
> Thanks for reply.
>
> > Could I ask you to upload your patch to the tracking page on
> > SourceForge?
> >
> >         https://sourceforge.net/p/gnuplot/patches/
>
> Sorry, I do not know how to upload a file there. But, you can
> use the attached patch in anyway at your convenience.
> I attach a modified patch to this mail for fix of the error message
> in case of conflict with pointinterval, and the description
> about "set ..." that was actually not correct.
>
> > I will have a look at it in more detail, but as a first comment
> > I think that randomizing the point placement is not a good idea.
> > It makes the points jump around when you replot, zoom, or scroll.
> > Also the output of a script would not be exactly reproducible.
>
> Yes. I agree about that problem.
> Maybe a better way is to add another parameter to set the
> offset of the starting points or automatically change
> the location of starting points according to the number of lines
> plotted simultaneously. It seemed a little complicated.
> The present way with the random number was simpler and so far
> (for many years) I and some of my friends did not
> have practical inconvenience.
>
> mori
>
>

mouse cursor secondary axes

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

Hi,

I wanted to display secondary axes on 'mousing' feature of SVG terminal. 
Specifically I have a plot line on x1y2 which I need to see displayed on 
the floating cursor readout.

It is displayed on the cursor under the graph when second y2 is used 
but not on the text box which follows the cursor.

I looked at modifying the relevant gnuplot_svg.js file to modify fn 
gnuplot_svg.updateCoordBox()

this includes the following for y1 coordinatte:
  label_y = plotcoord.y.toFixed(2);


I was expecting a plotcoord.y2 abut this does not seem to be defined. I 
started backing and duping code but it was getting more complex than I 
expected.

Am I missing something here or did x2y2 not get included when this 
feature was added?

Tnanks, Peter.



	

Recent changes to polar coordinates in gnuplot 5.1

[sfeam <sf...@us...>]

The development version of gnuplot (5.1) now contains a set of fixes, 
improvements, and additions to the support for polar coordinates.
Please give them a test and report any problems.


- The r axis now has a full set of range, label, and tic properties
	set rrange [min:max]
	set log r
	set rlabel "R-axis"
	set rtics
	set grid [no]rtics [no]mrtics


- New commands
	
  "set ttics" and "set mttics" control placement and labeling of tics
  around the perimeter of a polar plot

  "set border polar" draws a circular solid line at the perimeter


- Use of polar coordinates to position labels, arrows, objects

  You can now use the keyword "polar" when specifying coordinates for
  any position.  For example to place a labeled arrow on a polar plot:
	theta = 15; r = 1.23
	set arrow 1 from polar 0,0 to polar theta, r 
	set label 1 at polar theta,r "Current place" offset 1,1


- New demos
	http://gnuplot.sourceforge.net/demo_5.1/ttics.html
	http://gnuplot.sourceforge.net/demo_5.1/solar_path.html


- Internal code reorganization

  There is now a single utility routine polar_to_xy(theta, r, &x, &y)
  to convert from polar coordinates to cartesian coordinates.
  It is used for both data input and plot layout.  If you add new 
  code that supports polar coordinates please use this routine.

Re: variable colors with newhistograms

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

On Wednesday, 25 January, 2017 23:12:08 Valerio Schiavoni wrote:
> >
> >
> > > What I need in the end is the following:
> > > - any column whose value is  <= 0.50 should be in red
> > > - any column whose value is between 0.50 and  0.75 should be in orange
> > > - any column whose value is between 0.75 1.0  should be in green
> > >
> > > Does this makes the task any simpler ? ...
> >
> > That is not possible for the "with histograms" plot style.
> > It always colors boxes using the next linetype color in sequence.
> > You can control the linetype definitions and which one is used
> > first but nothing else.
> >
> > There are many other plot styles that do allow providing color
> > information in a separate column.  Perhaps you can reformat your
> > data so that it can be plotted "with boxes".
> >
> 
> Ok then. Can you point me to a gnuplot demo where "with boxes" is used, so
> that I can adapt my data to the right format ?

http://gnuplot.sourceforge.net/demo/varcolor.html
http://gnuplot.sourceforge.net/demo/boxplot.html

Re: variable colors with newhistograms

[Valerio S. <val...@gm...>]

>
>
> > What I need in the end is the following:
> > - any column whose value is  <= 0.50 should be in red
> > - any column whose value is between 0.50 and  0.75 should be in orange
> > - any column whose value is between 0.75 1.0  should be in green
> >
> > Does this makes the task any simpler ? ...
>
> That is not possible for the "with histograms" plot style.
> It always colors boxes using the next linetype color in sequence.
> You can control the linetype definitions and which one is used
> first but nothing else.
>
> There are many other plot styles that do allow providing color
> information in a separate column.  Perhaps you can reformat your
> data so that it can be plotted "with boxes".
>

Ok then. Can you point me to a gnuplot demo where "with boxes" is used, so
that I can adapt my data to the right format ?

Re: variable colors with newhistograms

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

On Wednesday, 25 January, 2017 22:49:01 Valerio Schiavoni wrote:
> Hello Ethan,
> 
> On Wednesday, 25 January, 2017 11:43:11 Valerio Schiavoni wrote:
> > > Hello,
> > > i'd like to assign colors to the bars of histograms according to the
> > value
> > > of a given column in the input file.
> >
> > The only way I can think of to do that is to make 2 passes through the
> > data file.
> > Pass 1:
> >   read in 1st column only and use it somehow to redefine linetype colors
> > 1-N
> > Pass 2:
> >   plot with histograms as usual will color by linetype with the redefined
> > colors
> >
> 
> When I say "according to the value" I really mean that the column specify
> the color ("red", "green", or some RGB code).
> Is there really need to redefine that ?
> 
> Let's make my use-case more concrete.
> What I need in the end is the following:
> - any column whose value is  <= 0.50 should be in red
> - any column whose value is between 0.50 and  0.75 should be in orange
> - any column whose value is between 0.75 1.0  should be in green
> 
> Does this makes the task any simpler ? ...

That is not possible for the "with histograms" plot style.
It always colors boxes using the next linetype color in sequence.
You can control the linetype definitions and which one is used
first but nothing else.

There are many other plot styles that do allow providing color
information in a separate column.  Perhaps you can reformat your
data so that it can be plotted "with boxes".

	Ethan


> 
> 
> 
> > > I'm using gnuplot version 5.0 patchlevel 5 on Mac OSX.
> > >
> > > The current gnuplot script is:
> > >
> > > set term post color eps 22 enhanced
> > > set output "single.eps"
> > > set size 1.9,0.65
> > > set lmargin 6
> > > set rmargin 1
> > > set bmargin 4
> > > set tmargin 2
> > > set style data histogram
> > > set style fill solid
> > > set style histogram clustered gap 0.05
> > > set datafile missing '-'
> > > set style fill solid
> > > set boxwidth 0.7
> > > set yrange [0:1.6]
> > > set xrange [-0.5:104]
> > > set xtics  norangelimit
> > > # Labels
> > > set xtics font "Arial,15" offset +0.5 #rotate by -90
> > > set grid noxtics
> > > set grid y
> > > set xtics () nomirror
> > > set key autotitle columnhead
> > > unset key
> > >
> > > plot newhistogram, "data/ratio_small.txt"   using ( $2):xtic(1) notitle,\
> > > newhistogram,    "data/ratio_small.txt"   using ( $3):xtic(1) notitle,\
> > > newhistogram,   "data/ratio_small.txt"   using ( $4):xtic(1) notitle,\
> > >          newhistogram,    "data/ratio_small.txt"  using ( $5):xtic(1)
> > > notitle,\
> > > newhistogram,    "data/ratio_small.txt"  using ( $6):xtic(1) notitle,\
> > > newhistogram,    "data/ratio_small.txt"  using ( $7):xtic(1) notitle,\
> > > newhistogram,    "data/ratio_small.txt"  using ( $8):xtic(1) notitle,\
> > > newhistogram,    "data/ratio_small.txt"  using ( $9):xtic(1) notitle,\
> > > newhistogram,    "data/ratio_small.txt"  using ($10):xtic(1) notitle,\
> > > newhistogram,    "data/ratio_small.txt"  using ($11):xtic(1) notitle,\
> > > newhistogram,    "data/ratio_small.txt"  using ($12):xtic(1) notitle,\
> > > newhistogram,    "data/ratio_small.txt"  using ($13):xtic(1) notitle,\
> > > newhistogram,    "data/ratio_small.txt"  using ($14):xtic(1) notitle,\
> > > newhistogram,    "data/ratio_small.txt"  using ($15):xtic(1) notitle,\
> > >      1 with lines linecolor 0 linetype 6;
> > >
> > > !epstopdf single.eps
> > > !rm single.eps
> > > quit
> > >
> > > The input file ratio_small.txt is the following :
> > > The first column is an identifier.
> > > The following 14 columns have the values of the bar.
> > > The last 14 columns (for example "124 124 124 124 124 124 lime lime 124
> > 124
> > > 124 124 124") have the colors to use for the corresponding column at the
> > > (i-14) place. For instance, in the 2nd row, the var with value
> > > 0.60237220283 should be colored with color 124.
> > >
> > >
> > > - "cryfs" "ecryptfs" "encfs" "lessfs" "metfs" "sdsfuse\\_aligned\\_aes"
> > > "sdsfuse\\_aligned\\_det" "sdsfuse\\_aligned\\_nop"
> > > "sdsfuse\\_aligned\\_nop\\_padded" "sdsfuse\\_fuse"
> > > "sdsfuse\\_nop\\_encode\\_nop\\_align" "sdsfuse\\_rep" "sdsfuse\\_xor"
> > - -
> > > - - - - - - - - - - -
> > > "{/ZapfDingbats \300} " 0.60237220283 0.711344856725 0.582073883361
> > > 0.561468395169 0.603971833124 0.575229774521 0.813573769298
> > 0.771643308547
> > > 0.740536179457 0.557035680285 0.548084588862 0.725980132011
> > 0.583761565013
> > > 124 124 124 124 124 124 lime lime 124 124 124 124 124
> > > "{/ZapfDingbats \301} " 0.828140563793 0.765377304019 0.525156213021
> > > 0.499275338734 0.82259078758 0.810583550209 0.90517243804 0.832808370792
> > > 0.85616508535 0.435176869986 0.497580109525 0.980843387581 0.537928091583
> > > lime lime 124 red lime lime lime lime lime red red lime 124
> > > "{/ZapfDingbats \302}" 0.904716215072 0.9782538275 0.890741302346
> > > 0.854583799197 0.917847306987 0.896293508144 1.0256528681 1.0177182497
> > > 1.03861543433 0.828367721449 0.86518859574 0.994039596381 0.889451921888
> > > lime lime lime lime lime lime lime lime lime lime lime lime lime
> > > "{/ZapfDingbats \303} " 1.08435421701 0.908573825168 1.31416588444
> > > 1.20433784027 1.05710491103 1.0877693675 0.990982804418 0.861592538595
> > > 0.94912224641 0.9949811268 1.21051107427 0.833466477602 1.33826965709
> > lime
> > > lime lime lime lime lime lime lime lime lime lime lime lime
> > > "{/ZapfDingbats \304} " 0.984592491056 1.01684770897 0.881511303546
> > > 0.897089139514 1.03427135005 0.992558483823 1.06725668178 1.07300848486
> > > 1.06531720912 0.908734725952 0.861996719541 1.0868248165 0.856056225665
> > > lime lime lime lime lime lime lime lime lime lime lime lime lime
> > > "{/ZapfDingbats \305} " 0.560462965052 0.924647572034 1.36731646391
> > > 1.32606135282 0.640285625269 0.587394675894 1.13208012281 1.23169129299
> > > 1.10314905856 1.31119793361 1.27579591436 1.09900540945 1.33576106248 124
> > > lime lime lime 124 124 lime lime lime lime lime lime lime
> > > "{/ZapfDingbats \306} " 0.601744213649 0.945552385642 0.639627276921
> > > 0.602851791101 0.617152828593 0.538149627645 1.16342545291 1.54587559776
> > > 1.12360405139 0.629261782578 0.55989311075 1.16338958747 0.644274734595
> > 124
> > > lime 124 124 124 124 lime lime lime 124 124 lime 124
> > >
> > > The current output is in attachment.
> > > Can anyone help ?
> > >
> > > Thanks a lot,
> > > --
> > > Valerio
> >
> >