|
From: Mojca M. <moj...@gm...> - 2006-08-21 21:17:46
|
Hello,
1.)
is there a way to get the default terminal settings? Postscript
terminal provides an option "default", but most terminals don't
(metapost terminal sets everything back to default values without
asking for it which is probably against the main phylosophy of how
terminals should work, but that's another topic which I don't intend
to discuss here).
I would like to write a longer gnuplot script with multiple changes of
terminal type and output file. The input will be provided from outside
(from other users, so I can't assume anything about it in advance).
The most safe way would be to write a single script for each input
(which is what is done now), but that influences efficiency
considerably (think of calling gnuplot 30 times versus calling gnuplot
only once with 30 plot commands and perhaps a few changes of the
terminal and output file inbetween).
Example:
the user selects PNG terminal and wants the first figure to be
transparent and the second one to use "default" values (whatever they
are, notransparent in that case).
first plot:
********
terminal: png
additional options: transparent
script: plot sin(x)
second plot:
********
terminal: png
additional options: -
script: plot sin(x)
The first approach would be to write two scripts, while the "efficient
one" would be to do something like this:
set term png transparent
set output 'p001.png'
set title 'first plot'
plot sin(x)
reset
# how to get the default terminal settings again?
set term png
set output 'p002.png'
plot sin(x)
"reset" is very handy, but I'm looking for a similar thing for
terminal settings as well.
In the worst case I can still warn the user that it's his own fault if
he wants to do such obscure things and that it's his own
responsibility to set the things back as they were. Or I can leave the
inefficient version there, but I would be very happy if there was some
"magic reset switch" for terminal settings as well. (There's only one
thing I'm sure about: I don't want to parse options in that program to
set them back to defaults.)
2.)
What is the main phylosophy behind terminals. Is a sentence like
set terminal post color monochrome
allowed? Well, the above is not, but for example
set term png notransparent transparent
doesn't complain. I prefer the later, since I don't have to worry then
if I set some settings which I consider to be default for my purpose
(for example "set term post color") and simply append user-provided
ones to the end of the string (if user wants portrait, the command
would become "set term post color portrait", if the user wants
monochrome, the command would become "set term post color monochrome",
but that doesn't work).
OK, I know, I can do it in two steps. I can first apply my own
defaults and then user-provided ones (wouldn't work with metapost, but
then again: I don't care about metapost terminal too much).
There are some work-arounds, but life would be much easier if
behaviour would be more consistent accross terminals. (I see no reason
why someone would make a restriction that an option may not be
specified more than once.)
Thank you very much for any answer,
Mojca
|
|
From: Ethan M. <merritt@u.washington.edu> - 2006-08-21 21:55:35
|
On Monday 21 August 2006 02:17 pm, Mojca Miklavec wrote: > 1.) > is there a way to get the default terminal settings? Postscript > terminal provides an option "default", but most terminals don't There is no coherent philosophy at present. Several people have proposed that during the next round of development (after 4.2) we modify all terminal drivers to have "set term <foo> default" option. It sounds reasonable to me. If you want to get a head start, go ahead and start putting together a patch that will convert your favorite terminals over to the new system. Ethan > (metapost terminal sets everything back to default values without > asking for it which is probably against the main phylosophy of how > terminals should work, but that's another topic which I don't intend > to discuss here). > > I would like to write a longer gnuplot script with multiple changes of > terminal type and output file. The input will be provided from outside > (from other users, so I can't assume anything about it in advance). > > The most safe way would be to write a single script for each input > (which is what is done now), but that influences efficiency > considerably (think of calling gnuplot 30 times versus calling gnuplot > only once with 30 plot commands and perhaps a few changes of the > terminal and output file inbetween). > > Example: > the user selects PNG terminal and wants the first figure to be > transparent and the second one to use "default" values (whatever they > are, notransparent in that case). > > first plot: > ******** > terminal: png > additional options: transparent > script: plot sin(x) > > second plot: > ******** > terminal: png > additional options: - > script: plot sin(x) > > The first approach would be to write two scripts, while the "efficient > one" would be to do something like this: > > set term png transparent > set output 'p001.png' > set title 'first plot' > plot sin(x) > reset > # how to get the default terminal settings again? > set term png > set output 'p002.png' > plot sin(x) > > "reset" is very handy, but I'm looking for a similar thing for > terminal settings as well. > > > In the worst case I can still warn the user that it's his own fault if > he wants to do such obscure things and that it's his own > responsibility to set the things back as they were. Or I can leave the > inefficient version there, but I would be very happy if there was some > "magic reset switch" for terminal settings as well. (There's only one > thing I'm sure about: I don't want to parse options in that program to > set them back to defaults.) > > > 2.) > What is the main phylosophy behind terminals. Is a sentence like > set terminal post color monochrome > allowed? Well, the above is not, but for example > set term png notransparent transparent > doesn't complain. I prefer the later, since I don't have to worry then > if I set some settings which I consider to be default for my purpose > (for example "set term post color") and simply append user-provided > ones to the end of the string (if user wants portrait, the command > would become "set term post color portrait", if the user wants > monochrome, the command would become "set term post color monochrome", > but that doesn't work). > > OK, I know, I can do it in two steps. I can first apply my own > defaults and then user-provided ones (wouldn't work with metapost, but > then again: I don't care about metapost terminal too much). > > There are some work-arounds, but life would be much easier if > behaviour would be more consistent accross terminals. (I see no reason > why someone would make a restriction that an option may not be > specified more than once.) > > Thank you very much for any answer, > Mojca > > ------------------------------------------------------------------------ >- Using Tomcat but need to do more? Need to support web services, > security? Get stuff done quickly with pre-integrated technology to make > your job easier Download IBM WebSphere Application Server v.1.0.1 based > on Apache Geronimo > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 > _______________________________________________ > gnuplot-beta mailing list > gnu...@li... > https://lists.sourceforge.net/lists/listinfo/gnuplot-beta -- Ethan A Merritt Biomolecular Structure Center University of Washington, Seattle 98195-7742 |
|
From: <br...@ph...> - 2006-08-22 01:26:57
|
Mojca Miklavec wrote: > The most safe way would be to write a single script for each input > (which is what is done now), but that influences efficiency > considerably (think of calling gnuplot 30 times versus calling gnuplot > only once with 30 plot commands and perhaps a few changes of the > terminal and output file inbetween). Huh? What does having separate scripts have to do with running a completely new instance of gnuplot for each script? > Example: > the user selects PNG terminal and wants the first figure to be > transparent and the second one to use "default" values (whatever they > are, notransparent in that case). Then the user should have a look at 'set term push' and 'set term pop', and maybe at 'save terminal', too. |
|
From: Petr M. <mi...@ph...> - 2006-08-22 08:38:31
|
>> The most safe way would be to write a single script for each input >> (which is what is done now), but that influences efficiency >> >> the user selects PNG terminal and wants the first figure to be >> transparent and the second one to use "default" values (whatever they >> are, notransparent in that case). As I remember, the need for an 'unset termoptions' or 'set termoptions reset' command emerged some years ago for the first time. It came from the octave community: how to reset terminal options to the default status after a script has changed them on its own. Shouldn't we provide a "dummy" command 'set termoptions' right now, with a proper implementation for postscript only (if possible), and with implementation for other terminals after 4.2? --- PM |
|
From: Mojca M. <moj...@gm...> - 2006-08-24 11:42:16
|
On 8/21/06, Ethan Merritt wrote:
> On Monday 21 August 2006 02:17 pm, Mojca Miklavec wrote:
> > 1.)
> > is there a way to get the default terminal settings? Postscript
> > terminal provides an option "default", but most terminals don't
>
> There is no coherent philosophy at present.
> Several people have proposed that during the next round of
> development (after 4.2) we modify all terminal drivers to have
> "set term <foo> default" option. It sounds reasonable to me.
>
> If you want to get a head start, go ahead and start putting together
> a patch that will convert your favorite terminals over to the new
> system.
I submitted a little patch to add the "default" option to the metapost term=
inal.
I would like to add it to PNG & PDF, but I have no idea how to compile
it properly (and thus I can't test it). I changed the compiler
yesterday (I was using MS Visual Studio - PNGs are crashing with that
compilation, and gave a try to MinGW). The very first time it worked,
but when I recompiled for the second time gnuplot started crashing
again. I have absolutely no clue about makefiles & compilers.
On 8/22/06, Hans-Bernhard Br=F6ker wrote:
> Mojca Miklavec wrote:
> > The most safe way would be to write a single script for each input
> > (which is what is done now), but that influences efficiency
> > considerably (think of calling gnuplot 30 times versus calling gnuplot
> > only once with 30 plot commands and perhaps a few changes of the
> > terminal and output file inbetween).
>
> Huh? What does having separate scripts have to do with running a
> completely new instance of gnuplot for each script?
I didn't understand your question, but the two alternatives I had in
mind were the following:
option A
----------
file1.plt:
set term png default
set term png transparent
plot sin(x)
set term png default
plot cos(x)
> gnuplot file1.plt
option B
----------
file1.plt
set term png transparent
plot sin(x)
file2.plt
set term png
plot cos(x)
> gnuplot file1.plt
> gnuplot file2.plt
The second option is considerably slower when dealing with lots of plots.
> > Example:
> > the user selects PNG terminal and wants the first figure to be
> > transparent and the second one to use "default" values (whatever they
> > are, notransparent in that case).
>
> Then the user should have a look at 'set term push' and 'set term pop',
> and maybe at 'save terminal', too.
set term push/pop preserve old terminal settings.
set term png transparent
set pop
set term png
will still result in "transparent".
"save terminal" (the option which I didn't know so far) does almost
exactly the thing that I want, but reading and writing from files when
things could be solved in another way is also an additional overhead.
There is also one additional issue (buglet perhaps?).
set term png
save terminal 'a.dat'
set term png transparent
load 'a.dat'
will keep transparent option since "notransparent" is not written to
the file and thus not reset when loading that file.
On 8/22/06, Hans-Bernhard Br=F6ker wrote:
> Petr Mikulik wrote:
> > Shouldn't we provide a "dummy" command 'set termoptions' right now, wit=
h
> > a proper implementation for postscript only (if possible), and with
> > implementation for other terminals after 4.2?
>
> What do you mean by "should we provide" it? "set termoption" already
> exists as a command, and has done for about 2 years at last, now.
So perhaps it's only "set termoption default" the one that is missing?
Mojca
|
|
From: <br...@ph...> - 2006-08-22 19:01:26
|
Petr Mikulik wrote: > Shouldn't we provide a "dummy" command 'set termoptions' right now, with > a proper implementation for postscript only (if possible), and with > implementation for other terminals after 4.2? What do you mean by "should we provide" it? "set termoption" already exists as a command, and has done for about 2 years at last, now. |
|
From: Petr M. <mi...@ph...> - 2006-08-24 18:38:24
|
> As I remember, the need for an 'unset termoptions' or 'set termoptions > reset' command emerged some years ago for the first time. It came from the > octave community: how to reset terminal options to the default status > after a script has changed them on its own. >> Shouldn't we provide a "dummy" command 'set termoptions' right now, with >> a proper implementation for postscript only (if possible), and with >> implementation for other terminals after 4.2? Sorry, I meant "unset termoptions". --- PM |
|
From: Ethan M. <merritt@u.washington.edu> - 2006-08-24 18:57:11
|
On Thursday 24 August 2006 11:38 am, Petr Mikulik wrote:
> >
> >> Shouldn't we provide a "dummy" command 'set termoptions' right
> >> now, with a proper implementation for postscript only (if
> >> possible), and with implementation for other terminals after 4.2?
>
> Sorry, I meant "unset termoptions".
I have no idea what "unset termoptions" is supposed to mean.
Could you please explain?
Right now, "set termoptions" simply passes the rest of the
command line to term->options().
But I cannot see a parallel mechanism for "unset termoptions".
There is no such thing as term->unset_options(), and in general
you cannot just negate options anyhow. You cannot, for example,
say either "set term <foo> nofont 'Times'"
or "unset term <foo> font 'Times'"
It seems to me that Mojca had the right idea:
If all terminals allowed "set term <foo> default", then it would
be possible to allow "set termoption default". In fact, it would
happen automatically as soon as you added "default" to the legal
options list.
--
Ethan A Merritt
Biomolecular Structure Center
University of Washington, Seattle WA
|
|
From: Petr M. <mi...@ph...> - 2006-08-24 19:01:25
|
> I have no idea what "unset termoptions" is supposed to mean. > Could you please explain? Here is the previous email (corrected): As I remember, the need for an 'unset termoptions' or 'set termoptions reset' or 'set termoptions default' command emerged some years ago for the first time. It came from the octave community: how to reset terminal options to the default status after a script has changed them on its own. Shouldn't we provide a "dummy" command 'unset termoptions' (named under any of the above synonyms) right now, with a proper implementation for postscript only (if possible), and with implementation for other terminals after 4.2? --- PM |
|
From: Ethan M. <merritt@u.washington.edu> - 2006-08-24 19:27:13
|
On Thursday 24 August 2006 12:01 pm, Petr Mikulik wrote: > > I have no idea what "unset termoptions" is supposed to mean. > > Could you please explain? > > Here is the previous email (corrected): > > As I remember, the need for an 'unset termoptions' or 'set > termoptions reset' or 'set termoptions default' "set term default" is 100% better than "unset termoptions". If nothing else, it will work automatically if the terminal in fact supports "set term <foo> default" <begin rant> When/why was there a change to the syntax "unset <foo> <baz>"? It is IMHO much uglier and harder to work with than "set <foo> no<baz>". The latter makes it clear that you are toggling option <baz>. Besides which, there is no verb "unset" in the English language. The usual antonym of 'set' is either 'clear' or 'reset'. <end rant> > command emerged some > years ago for the first time. It came from the octave community: how > to reset terminal options to the default status after a script has > changed them on its own. > > Shouldn't we provide a "dummy" command 'unset termoptions' (named > under any of the above synonyms) right now, with a proper > implementation for postscript only (if possible), and with > implementation for other terminals after 4.2? > > --- > PM -- Ethan A Merritt Biomolecular Structure Center University of Washington, Seattle WA |
|
From: <br...@ph...> - 2006-08-25 03:57:04
|
Ethan Merritt wrote: > When/why was there a change to the syntax "unset <foo> <baz>"? Never, actually. > It is IMHO much uglier and harder to work with than > "set <foo> no<baz>". The actual change was from 'set no<foo>' to 'unset foo', and that incompatible change to the syntax was the primary reason we had to increase the major version number for the release of the 3.8 development strain, so it became number 4.0. > The latter makes it clear that you are toggling option <baz>. > Besides which, there is no verb "unset" in the English language. > The usual antonym of 'set' is either 'clear' or 'reset'. ... both of which had already been taken up for other commands, at the time the idea of that change came up. |