gnuplot-info — For questions and discussion about gnuplot

[Gnuplot-info] textcolor for multiplot title

[Daniel B. <dbo...@gm...>]

Hello,

I noticed that "set multiplot title" takes a font argument but provides no
way to specify the colour of its text, so it's always black. This is
problematic if using black or any other dark colour as the background of
the plot.

Is it possible to get "textcolor" parsed here, to address that issue?

Thanks,
Daniel

Re: [Gnuplot-info] SVG terminal "mousing" option causes "background" colour not to work

[Ethan A M. <eam...@gm...>]

On Thursday, 08 February 2018 00:23:23 Daniel Boles wrote:
> Hi,
> 
> One last hijack of this thread... while we're on the subject of SVG and
> colours: Is there any way to change the colour of the coordinate label that
> follows the mouse pointer in SVGs, from its default black to something
> visible on the new black background? I'm having no luck finding an option
> in the docs, or googling generally, and I don't understand the JS well
> enough to conclude either way.

Find these lines in the javascript

  <text id="coord_text" text-anchor="start" pointer-events="none"
  font-size="12" font-family="Arial"
  visibility="hidden"> </text>

and add 
  fill="white"
after the font-family

There is currently no program option to do this automatically.


	Ethan

Re: [Gnuplot-info] SVG terminal "mousing" option causes "background" colour not to work

[Daniel B. <dbo...@gm...>]

Hi,

One last hijack of this thread... while we're on the subject of SVG and
colours: Is there any way to change the colour of the coordinate label that
follows the mouse pointer in SVGs, from its default black to something
visible on the new black background? I'm having no luck finding an option
in the docs, or googling generally, and I don't understand the JS well
enough to conclude either way.

Thanks,
Daniel

Re: [Gnuplot-info] SVG terminal "mousing" option causes "background" colour not to work

[Daniel B. <dbo...@gm...>]

On 7 February 2018 at 18:33, Daniel Boles <dbo...@gm...> wrote:

> It looks like (A) the textcolor after the title determines its color and
> (B) another textcolor anywhere else determines the color of the individual
> series titles.
>

That is to say, something like this:

set key title "TITLE" textcolor rgb "blue" textcolor rgb "red"
>

Re: [Gnuplot-info] SVG terminal "mousing" option causes "background" colour not to work

[Daniel B. <dbo...@gm...>]

On 7 February 2018 at 18:17, Ethan A Merritt <eam...@gm...> wrote:

> > Now add "mousing" to the "set terminal" line.
> >
> > That results in the background being lost, so everything is white on
> white,
> > and thus invisible.
>
> Yes. That seems to be a bug.
>
> > It looks like the code that creates the mousing bounding box
> > unconditionally sets a white rectangle with a black stroke, thus
> > overridding or hiding the background the user wants.
>
> Other way around I think.  If you set a background color then
> normally the plot output begins with a filled rectangle of that color.
> However if you select "standalone mousing" the program starts the
> output with a copy of the mousing code and omits the filled background
> rectangle.
>
> > Is this bugworthy, or is there a reason that it has to be this way?
>
> According to the code, it was intentional.  But quick testing does
> not show any obvious problem so I am not sure why that was.
> I will investigate further.
>

Thanks for that!


> I would really like to be able to render white (and other colours) on
> > black, as I prefer "inverted" colours - but I also want to be able to use
> > mousing in my reports. At present, it doesn't look like I can have both.
>
> Sure you can. No problem.
> You can always include a filled background rectangle as a separate
> command.  This should work independent of anything else:
>
>     set obj 1 rectangle from screen 0,0 to screen 1,1 behind
>     set obj 1 fillstyle solid fillcolor "black"
>

Ta again - I found others suggesting this method shortly after posting.
It'll probably be fine for now, at least since you revealed the secrets of
the key title textcolor(s). :D

Re: [Gnuplot-info] SVG terminal "mousing" option causes "background" colour not to work

[Daniel B. <dbo...@gm...>]

Thanks for the replies.

On 7 February 2018 at 18:03, Ethan A Merritt <eam...@gm...> wrote:

> On Wednesday, 07 February 2018 17:26:33 Daniel Boles wrote:
> > Another apparent bug is that, this time in both SVG and PNGcairo (and
> > probably others), the key "title" does not obey the "textcolor" set in
> the
> > key command (regardless of whether it comes before or after the "title"
> > clause)
>
> Please always show what version of gnuplot you are using and
> provide an example of the command that fails.
>
> I do not see this problem in current gnuplot (5.2.2).
> I would not expect this sort of problem to depend on the terminal
> type, but I confirmed that the following commands produce correct
> key title color for qt, svg, and pngcairo.
>
>    set key title "TITLE" tc "blue"
>    plot for [i=1:5] i*x
>


Yeah, 5.2 patch 2. I must not have properly tested all combinations... or
realised that I need 2 textcolor clauses.

It looks like (A) the textcolor after the title determines its color and
(B) another textcolor anywhere else determines the color of the individual
series titles.

I guess this is intended and I just didn't read the docs properly?

Re: [Gnuplot-info] SVG terminal "mousing" option causes "background" colour not to work

[Ethan A M. <eam...@gm...>]

On Wednesday, 07 February 2018 17:20:31 Daniel Boles wrote:
> Hi,
> 
> Take the following script, minimally modified from
> https://stackoverflow.com/a/30832843
> 
> set terminal svg background rgb 'black'
> > set output 'bw.svg'
> >
> > set xlabel 'ylabel' tc rgb 'white'
> > set ylabel 'xlabel' tc rgb 'white'
> > set border lc rgb 'white'
> > set key tc rgb 'white'
> >
> > set linetype 1 lc rgb 'white'
> > plot x lc 1, x**2 lc 1
> >
> 
> It renders an SVG with a black background and white everything else.
> 
> Now add "mousing" to the "set terminal" line.
> 
> That results in the background being lost, so everything is white on white,
> and thus invisible.

Yes. That seems to be a bug.
 
> It looks like the code that creates the mousing bounding box
> unconditionally sets a white rectangle with a black stroke, thus
> overridding or hiding the background the user wants.

Other way around I think.  If you set a background color then 
normally the plot output begins with a filled rectangle of that color.
However if you select "standalone mousing" the program starts the
output with a copy of the mousing code and omits the filled background
rectangle.   

> Is this bugworthy, or is there a reason that it has to be this way?

According to the code, it was intentional.  But quick testing does
not show any obvious problem so I am not sure why that was.
I will investigate further.

> I would really like to be able to render white (and other colours) on
> black, as I prefer "inverted" colours - but I also want to be able to use
> mousing in my reports. At present, it doesn't look like I can have both.

Sure you can. No problem.
You can always include a filled background rectangle as a separate 
command.  This should work independent of anything else:

    set obj 1 rectangle from screen 0,0 to screen 1,1 behind
    set obj 1 fillstyle solid fillcolor "black"

 cheers,

		Ethan
	
> 
> Thanks,
> Daniel

Re: [Gnuplot-info] SVG terminal "mousing" option causes "background" colour not to work

[Ethan A M. <eam...@gm...>]

On Wednesday, 07 February 2018 17:26:33 Daniel Boles wrote:
> Another apparent bug is that, this time in both SVG and PNGcairo (and
> probably others), the key "title" does not obey the "textcolor" set in the
> key command (regardless of whether it comes before or after the "title"
> clause)

Please always show what version of gnuplot you are using and
provide an example of the command that fails.

I do not see this problem in current gnuplot (5.2.2).
I would not expect this sort of problem to depend on the terminal 
type, but I confirmed that the following commands produce correct
key title color for qt, svg, and pngcairo.

   set key title "TITLE" tc "blue"
   plot for [i=1:5] i*x
 
> Therefore adding a title to the above sample results in it always being
> rendered in black, and thereby not visible when the black background is
> working properly.

If there is some separate interaction of the key title with
the background and mousing commands, you'll have to show a
particular command sequence that reproduces it.  I don't see
any problem here even after setting the background to black.

   cheers,

      Ethan 

Re: [Gnuplot-info] SVG terminal "mousing" option causes "background" colour not to work

[Daniel B. <dbo...@gm...>]

Another apparent bug is that, this time in both SVG and PNGcairo (and
probably others), the key "title" does not obey the "textcolor" set in the
key command (regardless of whether it comes before or after the "title"
clause)

Therefore adding a title to the above sample results in it always being
rendered in black, and thereby not visible when the black background is
working properly.

[Gnuplot-info] SVG terminal "mousing" option causes "background" colour not to work

[Daniel B. <dbo...@gm...>]

Hi,

Take the following script, minimally modified from
https://stackoverflow.com/a/30832843

set terminal svg background rgb 'black'
> set output 'bw.svg'
>
> set xlabel 'ylabel' tc rgb 'white'
> set ylabel 'xlabel' tc rgb 'white'
> set border lc rgb 'white'
> set key tc rgb 'white'
>
> set linetype 1 lc rgb 'white'
> plot x lc 1, x**2 lc 1
>

It renders an SVG with a black background and white everything else.

Now add "mousing" to the "set terminal" line.

That results in the background being lost, so everything is white on white,
and thus invisible.

It looks like the code that creates the mousing bounding box
unconditionally sets a white rectangle with a black stroke, thus
overridding or hiding the background the user wants.

Is this bugworthy, or is there a reason that it has to be this way?

I would really like to be able to render white (and other colours) on
black, as I prefer "inverted" colours - but I also want to be able to use
mousing in my reports. At present, it doesn't look like I can have both.
Hopefully that's solvable.

Thanks,
Daniel

Re: [Gnuplot-info] Using columntitle() in other contexts - or: other ways to reuse title of series (from block header)

[Daniel B. <dbo...@gm...>]

Hi Ethan,

Thanks for the fast reply and the welcome! And, of course, for all the work
you're doing on gnuplot.

Apologies for slacking on the info and test case. I'm using gnuplot 5.2
patchlevel 2. Including a test case would've shown you that I was just
being silly, but thankfully you linked to a thread that proved that
anyway...

I think, but I'm not 100% sure, that what you want is possible in the
> current release version of gnuplot (5.2.2).  See the discussion attached
> to tracker issue #1968
>         https://sourceforge.net/p/gnuplot/bugs/1968/
>
> That discussion ends with a note that a "using" specifier can now
> (Sept 2017) call columnhead(index) as a function.  However the test case
> shown does not involve hypertext, and it uses real column headers rather
> than index labels.  So it might not cover your specific data format.
> If not, please provide an example data file and the hypertext command
> you are trying to use.  You can attach these to the above issue tracker
> and I will re-open the bug if appropriate.
>

I honestly had no idea that columnhead and columnheader were different
things, and I had only been trying the latter...  It might've taken me a
while to realise these were 2 distinct things!

You'll be please do know that, indeed, using columnhead(index) does work on
hypertext points, too. So I can drop my ugly workarounds now!

Many thanks for the quick and direct response. It's also an interesting
thread to read; I dare say that I'd currently be requesting the same
feature, if it weren's already in. :)

Cheers,
Daniel

Re: [Gnuplot-info] Using columntitle() in other contexts - or: other ways to reuse title of series (from block header)

[Ethan A M. <eam...@gm...>]

On Sunday, 28 January 2018 17:46:41 Daniel Boles wrote:
> (Just started using gnuplot 2 days ago, so I might've missed a trick here,
> but I like to think I read and absorb documentation at a rapid rate)

Welcome.
It seems that you are accelerating rapidly up the learning curve.

> I have a datafile with multiple blocks, each of which is headed by a title.
> Each block represents a series on my line graph. I can't hard-code these,
> because the count and names of series are totally arbitrary. I then do a
> "plot for" until STATS_blocks, and this gets me the desired lines.
> 
> Using "set autotitle columnheader" or "title columnheader(optional index)",
> I can make the title of each block visible in the key. So far, so great!

> However, I now want to be able to use that title elsewhere - chiefly, in
> the mousing tooltip (with "hypertext point"). This is because, although I
> generate unique colours and cycling pointttypes per series, on datasets
> with many series they can still be difficult to tell apart. Also, I just
> love tooltips!
> 
> The problem is it seems columnheader(optional index) can only be used
> alongside [auto]title, not anywhere else, e.g. the "using" for the
> hypertext point or as a function arg to stuff it in a variable.

When reporting a problem or asking a specific question please 
1) tell us exactly what version of gnuplot you are using
2) show the commands you already tried that either didn't work
   or produced an unexpected result.  If it requires data in a
   specific format, show that also.

I think, but I'm not 100% sure, that what you want is possible in the
current release version of gnuplot (5.2.2).  See the discussion attached
to tracker issue #1968
	https://sourceforge.net/p/gnuplot/bugs/1968/

That discussion ends with a note that a "using" specifier can now
(Sept 2017) call columnhead(index) as a function.  However the test case
shown does not involve hypertext, and it uses real column headers rather
than index labels.  So it might not cover your specific data format.
If not, please provide an example data file and the hypertext command
you are trying to use.  You can attach these to the above issue tracker
and I will re-open the bug if appropriate.

	Ethan

> So, for now, I have to have the script that prepares my dataset write out
> the indexes into its titles above each block, then just use column(-2) in
> my tooltip - so at least users can have some way to marry a point on a
> dataseries with its tooltip, to the corresponding title shown in the key.
> That's better than nothing, but it's an extra hassle to have to do that
> lookup; I want to see the title directly.
> 
> While it's probably possible to have gnuplot run through the file and stash
> the block titles in an array to be used later - or even just to have my
> script preparing the dataset write an extra column with the title
> duplicated, or the full text of the tooltip... I feel like it shouldn't be
> this difficult just to reuse a piece of data that gnuplot already has
> available in a tooltip.
> 
> 
> And that makes me hopeful that I've just overlooked an easy way. So, is
> there one you can think of?
> 
> If not, is it possible that columnheader() could be made usable in more
> contexts? Not necessarily everywhere, but it makes sense here to me; the
> tooltip has all columns; data available, after all, so why not headers too?
> 
> Thanks!

-- 

[Gnuplot-info] Using columntitle() in other contexts - or: other ways to reuse title of series (from block header)

[Daniel B. <dbo...@gm...>]

(Just started using gnuplot 2 days ago, so I might've missed a trick here,
but I like to think I read and absorb documentation at a rapid rate)


I have a datafile with multiple blocks, each of which is headed by a title.
Each block represents a series on my line graph. I can't hard-code these,
because the count and names of series are totally arbitrary. I then do a
"plot for" until STATS_blocks, and this gets me the desired lines.

Using "set autotitle columnheader" or "title columnheader(optional index)",
I can make the title of each block visible in the key. So far, so great!


However, I now want to be able to use that title elsewhere - chiefly, in
the mousing tooltip (with "hypertext point"). This is because, although I
generate unique colours and cycling pointttypes per series, on datasets
with many series they can still be difficult to tell apart. Also, I just
love tooltips!

The problem is it seems columnheader(optional index) can only be used
alongside [auto]title, not anywhere else, e.g. the "using" for the
hypertext point or as a function arg to stuff it in a variable.

So, for now, I have to have the script that prepares my dataset write out
the indexes into its titles above each block, then just use column(-2) in
my tooltip - so at least users can have some way to marry a point on a
dataseries with its tooltip, to the corresponding title shown in the key.
That's better than nothing, but it's an extra hassle to have to do that
lookup; I want to see the title directly.

While it's probably possible to have gnuplot run through the file and stash
the block titles in an array to be used later - or even just to have my
script preparing the dataset write an extra column with the title
duplicated, or the full text of the tooltip... I feel like it shouldn't be
this difficult just to reuse a piece of data that gnuplot already has
available in a tooltip.


And that makes me hopeful that I've just overlooked an easy way. So, is
there one you can think of?

If not, is it possible that columnheader() could be made usable in more
contexts? Not necessarily everywhere, but it makes sense here to me; the
tooltip has all columns; data available, after all, so why not headers too?

Thanks!

[Gnuplot-info] use and distribution of binary gnuplot in servers/systems sold to customers, what to do?

[Michael L. <Mic...@sc...>]

Good afternoon,

We intend to use gnuplot as (tiny) part of a larger software suite we're developing. Gnuplot would be shipped in binary form (from the SLES repository) with the server hosting our software.

>From your page's FAQ entry (1.7) it seems that this would be a perfectly fine use and distribution of gnuplot.
However, as far as I interpret the "Copyright" file from the sourcecode tarball that is only fine, "provided that the [...]copyright notice and this permission notice appear in supporting documentation".
What do we need to do, to conform to this requirement? Would it be sufficient to distribute the sourcecode tarball or even just the copyright file with our software?


Cheers,
Michael Lenz
___________________________________________________________

Michael Lenz
Software Engineer
Space
SCISYS Deutschland GmbH
T:  +49 2349258485 | F:  +49 2349258190
E:  Mic...@sc...<mailto:Mic...@sc...> | http://www.space.scisys.de

SCISYS Deutschland GmbH, Borgmannstraße 2, 44894 Bochum, Germany
Geschäftsf.: Prof. Dr.-Ing. Klaus-G. Meng (Vors.), Sandra Krewerth, Ulli Leibnitz, Dr.-Ing. Karl-W. Pieper, Dr.-Ing. Horst Wulf
Amtsgericht Bochum HRB 13694, Ust.-IdNr. DE 813242674, WEEE-Reg.-Nr. DE 74530735

Re: [Gnuplot-info] Making/finding a timefmt for the unix date command default output

[Alan C. <ala...@gm...>]

In case anybody finds this and tries to use it, that alias may not work right.

This is different and seems to work:

alias newbp='cd /usr/tmp/health ; echo `date +"%Y-%m-%d_%H-%M"` >>
bp.txt ; joe bp.txt'

single quotes at the outermost level
double quotes around the format string to date
backticks around the whole date command to feed date's output to echo


On 1/20/18, Hans-Bernhard Bröker <HBB...@t-...> wrote:
> Am 20.01.2018 um 16:20 schrieb Alan Corey:
>> OK, I hadn't really tried parsing this format in Gnuplot before I
>> don't think, I've done the more common American YY-MM-DD HH:MM:SS.
>
> To give credit where it's due: that format is really not American in any
> meaningful way.  That's an abridged version of the international format
> ISO 8601 offered by date -I.  That International Standard ended up
> looking that way in no small part because _somebody_ had to tackle that
> unholy mess created by the actual English and American formats: DD/MM/YY
> and MM/DD/YY.  And no, I won't even try to remember which of those was
> which.
>
>> I
>> thought Gnuplot date parsing was a more complete subset of strptime
>> and strftime.
>
> It is.  But parsing the week day would not make sense for gnuplot, where
> strptime()'s output is not a struct tm, but rather the single
> time_t-style number.  In short, the weekday is entirely redundant in a
> classic date string, so all it could add to the input is a new problem,
> if it's given incorrectly.
>


-- 
-------------
No, I won't  call it "climate change", do you have a "reality problem"? - AB1JX
Impeach  Impeach  Impeach  Impeach  Impeach  Impeach  Impeach  Impeach

Re: [Gnuplot-info] Making/finding a timefmt for the unix date command default output

[Hans-Bernhard B. <HBB...@t-...>]

Am 20.01.2018 um 16:20 schrieb Alan Corey:
> OK, I hadn't really tried parsing this format in Gnuplot before I
> don't think, I've done the more common American YY-MM-DD HH:MM:SS.

To give credit where it's due: that format is really not American in any 
meaningful way.  That's an abridged version of the international format 
ISO 8601 offered by date -I.  That International Standard ended up 
looking that way in no small part because _somebody_ had to tackle that 
unholy mess created by the actual English and American formats: DD/MM/YY 
and MM/DD/YY.  And no, I won't even try to remember which of those was 
which.

> I
> thought Gnuplot date parsing was a more complete subset of strptime
> and strftime.  

It is.  But parsing the week day would not make sense for gnuplot, where 
strptime()'s output is not a struct tm, but rather the single 
time_t-style number.  In short, the weekday is entirely redundant in a 
classic date string, so all it could add to the input is a new problem, 
if it's given incorrectly.

Re: [Gnuplot-info] Making/finding a timefmt for the unix date command default output

[Alan C. <ala...@gm...>]

Or at a higher level:
alias newbp="cd /usr/tmp/health ; echo  `date +"%Y-%m-%d_%H-%M"` >>
bp.txt ; joe bp.txt"

Now I can track and plot my blood pressure and print it out to hand the doctor.

On 1/20/18, Alan Corey <ala...@gm...> wrote:
> OK, I hadn't really tried parsing this format in Gnuplot before I
> don't think, I've done the more common American YY-MM-DD HH:MM:SS.  I
> thought Gnuplot date parsing was a more complete subset of strptime
> and strftime.  A way to ignore 1 character (at a time) would help
> since default date output is fixed width, but then there's that month
> abbreviation.  %s is just so handy.
>
> Yeah, I've done stuff like
> adate=`date +"%Y-%m-%d_%H-%M"`
> outname=bp_$adate.txt
> for file names
>
> In the Joe editor I can do ctrl-k r like I was going to read from a
> file, then supply !date instead of a file name, but I still get the
> Sat Jan 20 09:57:00 EST 2018 format.  Oh well, so I wasn't misreading
> the documentation.
>
> Got it.  Using bash anyway.  Mismash of single, double quotes and
> backticks:
> pi3# alias gdate='echo `date +"%Y-%m-%d_%H-%M"`'
> pi3# gdate
> 2018-01-20_10-11
>
>
> On 1/20/18, Hans-Bernhard Bröker <HBB...@t-...> wrote:
>> Am 20.01.2018 um 04:28 schrieb Alan Corey:
>>> I'd like to be able to do date >> datafile, then edit the file to add
>>> other columns, and have Gnuplot understand the date/time format which
>>> looks like:
>>>
>>> Fri Jan 19 22:08:14 EST 2018
>>>
>>> It seems like this must be a common thing to do.
>>
>> Not really, since the common approach would be that, if you want a
>> machine to parse that timestamp, you better not output it in a format
>> designed strictly for human consumption.  Not even if that's the default
>> format.
>>
>> This is what date options like +'%s', -Iseconds or --rfc3339 are for,
>> the latter two possibly combined with -u to get absolute timestamps.
>>
>> Or better yet, see if your editor can't insert the timestamps itself,
>> instead of you having to do this in a two-step process.
>>
>
>
> --
> -------------
> No, I won't  call it "climate change", do you have a "reality problem"? -
> AB1JX
> Impeach  Impeach  Impeach  Impeach  Impeach  Impeach  Impeach  Impeach
>


-- 
-------------
No, I won't  call it "climate change", do you have a "reality problem"? - AB1JX
Impeach  Impeach  Impeach  Impeach  Impeach  Impeach  Impeach  Impeach

Re: [Gnuplot-info] Making/finding a timefmt for the unix date command default output

[Alan C. <ala...@gm...>]

OK, I hadn't really tried parsing this format in Gnuplot before I
don't think, I've done the more common American YY-MM-DD HH:MM:SS.  I
thought Gnuplot date parsing was a more complete subset of strptime
and strftime.  A way to ignore 1 character (at a time) would help
since default date output is fixed width, but then there's that month
abbreviation.  %s is just so handy.

Yeah, I've done stuff like
adate=`date +"%Y-%m-%d_%H-%M"`
outname=bp_$adate.txt
for file names

In the Joe editor I can do ctrl-k r like I was going to read from a
file, then supply !date instead of a file name, but I still get the
Sat Jan 20 09:57:00 EST 2018 format.  Oh well, so I wasn't misreading
the documentation.

Got it.  Using bash anyway.  Mismash of single, double quotes and backticks:
pi3# alias gdate='echo `date +"%Y-%m-%d_%H-%M"`'
pi3# gdate
2018-01-20_10-11


On 1/20/18, Hans-Bernhard Bröker <HBB...@t-...> wrote:
> Am 20.01.2018 um 04:28 schrieb Alan Corey:
>> I'd like to be able to do date >> datafile, then edit the file to add
>> other columns, and have Gnuplot understand the date/time format which
>> looks like:
>>
>> Fri Jan 19 22:08:14 EST 2018
>>
>> It seems like this must be a common thing to do.
>
> Not really, since the common approach would be that, if you want a
> machine to parse that timestamp, you better not output it in a format
> designed strictly for human consumption.  Not even if that's the default
> format.
>
> This is what date options like +'%s', -Iseconds or --rfc3339 are for,
> the latter two possibly combined with -u to get absolute timestamps.
>
> Or better yet, see if your editor can't insert the timestamps itself,
> instead of you having to do this in a two-step process.
>


-- 
-------------
No, I won't  call it "climate change", do you have a "reality problem"? - AB1JX
Impeach  Impeach  Impeach  Impeach  Impeach  Impeach  Impeach  Impeach

Re: [Gnuplot-info] Making/finding a timefmt for the unix date command default output

[Hans-Bernhard B. <HBB...@t-...>]

Am 20.01.2018 um 04:28 schrieb Alan Corey:
> I'd like to be able to do date >> datafile, then edit the file to add
> other columns, and have Gnuplot understand the date/time format which
> looks like:
> 
> Fri Jan 19 22:08:14 EST 2018
> 
> It seems like this must be a common thing to do.  

Not really, since the common approach would be that, if you want a 
machine to parse that timestamp, you better not output it in a format 
designed strictly for human consumption.  Not even if that's the default 
format.

This is what date options like +'%s', -Iseconds or --rfc3339 are for, 
the latter two possibly combined with -u to get absolute timestamps.

Or better yet, see if your editor can't insert the timestamps itself, 
instead of you having to do this in a two-step process.

[Gnuplot-info] Making/finding a timefmt for the unix date command default output

[Alan C. <ala...@gm...>]

I'd like to be able to do date >> datafile, then edit the file to add
other columns, and have Gnuplot understand the date/time format which
looks like:

Fri Jan 19 22:08:14 EST 2018

I think it's the same as the ctime() format, haven't seen that lately.
It seems like this must be a common thing to do.  I need to skip over
the day of week abbreviation, then deal with an abbreviation for month
name for starters, the rest other than time zone looks
straightforward.  But somebody's probably done it before.

Since the output format of the date command can be controlled by a
method similar to gnuplot's timefmt my approach would probably be to
set up an alias or script to do that.

I don't usually stay in this list between questions.

  Alan

-- 
-------------
No, I won't  call it "climate change", do you have a "reality problem"? - AB1JX
Impeach  Impeach  Impeach  Impeach  Impeach  Impeach  Impeach  Impeach

Re: [Gnuplot-info] Avoid reding comments

[BBands <bb...@gm...>]

help set datafile commentschars

    John

On Mon, Jan 15, 2018 at 5:30 AM, Patrick Dupre <pd...@gm...> wrote:

> Hello,
>
> When I read data with read, I would like to avoid to read the line
> starting with #
> In on words,
> I would like to have this option
> /^[[:blank:]]*#/ {next}
>
> always activated when I read a data file.
>
> Can I have it in a .rc file of something similar?
>
> Thank.
>
> ============================================================
> ===============
>  Patrick DUPRÉ                                 | | email: pd...@gm...
>  Laboratoire de Physico-Chimie de l'Atmosphère | |
>  Université du Littoral-Côte d'Opale           | |
>  Tel.  (33)-(0)3 28 23 76 12                   | | Fax: 03 28 65 82 44
>  189A, avenue Maurice Schumann                 | | 59140 Dunkerque, France
> ============================================================
> ===============
>
> ------------------------------------------------------------
> ------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> gnuplot-info mailing list
> gnu...@li...
> Membership management via: https://lists.sourceforge.net/
> lists/listinfo/gnuplot-info
>

[Gnuplot-info] Avoid reding comments

[Patrick D. <pd...@gm...>]

Hello,

When I read data with read, I would like to avoid to read the line starting with #
In on words,
I would like to have this option
/^[[:blank:]]*#/ {next}

always activated when I read a data file.

Can I have it in a .rc file of something similar?

Thank.

===========================================================================
 Patrick DUPRÉ                                 | | email: pd...@gm...
 Laboratoire de Physico-Chimie de l'Atmosphère | |
 Université du Littoral-Côte d'Opale           | |
 Tel.  (33)-(0)3 28 23 76 12                   | | Fax: 03 28 65 82 44
 189A, avenue Maurice Schumann                 | | 59140 Dunkerque, France
===========================================================================

[Gnuplot-info] ignore comments (lines starting with #)

[Patrick D. <pd...@gm...>]

Hello,

I would like to have this option
/^[[:blank:]]*#/ {next}

always activated when I read a data file.

Can I have it in a .rc file of someting similar?

Thank.

===========================================================================
 Patrick DUPRÉ                                 | | email: pd...@gm...
 Laboratoire de Physico-Chimie de l'Atmosphère | |
 Université du Littoral-Côte d'Opale           | |
 Tel.  (33)-(0)3 28 23 76 12                   | | Fax: 03 28 65 82 44
 189A, avenue Maurice Schumann                 | | 59140 Dunkerque, France
===========================================================================

Re: [Gnuplot-info] Plotting fortran formatted data

[ivana r. <iva...@mf...>]

Hi Sergei,

there may be some rubbish that lures gnuplot to find xrange although
"plotting" 'with table'

try put 'reset' in the begin of the code.

Alternatively, you can also plot your data directly, if their amount
is ok with the PC performance:

# begin gnuplot code
# replace datafile with real filename
file="datafile"
# set empty data separator
set datafile separator ""

# use string functions to extract columns of a given width
plot file u (real(stringcolumn(1)[11:14])):(real(stringcolumn(1)[16:]))
w lp t "direct"

# end of gnuplot code


sincerely

Iva

Re: [Gnuplot-info] Plotting fortran formatted data

[Sergei N. <vo...@ra...>]

Thanks a lot, Iva.Tried this but:

Terminal type set to 'qt'
gnuplot> set datafile separator ";"
gnuplot> set table $mydata
gnuplot> plot "qq" u (stringcolumn(1)[11:14]):(stringcolumn(1)[16:]) w table
^
x range is invalidgnuplot>

Here is the test data one more time:

J0023+092311.8D 0.085
J0030+045158.8P 0.861
J0034-0534 6.6D 1.255
-- Sergei


  28.12.2017, 20:12, ivana richterova <iva...@mf...>Hi Sergei,

  although to use external simple filter was intended in such cases,
  under unix-like OS e.g. "cut":


  gnuplot> plot '<cut -b 11-14,16- --output-delimiter=" " datafile'


  you can do this directly by gnuplot as well:


  # begin gnuplot code

  # replace datafile with real filename
  file="datafile"

  # set the data separator to a char missed in the file
  set datafile separator ";"

  # use string functions to extract columns of a given width to a named
  datablock
  set table $mydata
  plot file u (stringcolumn(1)[11:14]):(stringcolumn(1)[16:]) w table
  unset table

  # reset the data separator
  set datafile separator

  # uncomment to print the preprocessed datablock if you wish
  # print $mydata

  # plot the preprocessed datablock

  plot $mydata w lp t "extracted data"

  # end of gnuplot code


  sincerely

  Iva