Menu
▾
▴
gnuplot-beta
|
From: Dmitri A. S. <das...@gm...> - 2005-09-22 03:17:59
|
FYI From the octave list: Sincerely, Dmitri. ---------- Forwarded message ---------- From: John W. Eaton <jw...@be...> Date: Sep 21, 2005 8:24 PM Subject: Re: pslatex terminal output--Problem identified. To: Pete Gustafson <wat...@ya...> Cc: he...@oc... OK, I think this might be a bug in gnuplot. You can reproduce it with the following commands (these are essentially the commands that Octave is sending to gnuplot, but plotting a function instead of a data file to simplify things a bit)): plot sin(x) title "line 1" set terminal push set term postscript eps enhanced color solid set output "foo.eps" replot set terminal pop set output replot set term pslatex set output "foo.tex" replot quit I have not looked at the code, so I am only guessing here, but it seems that the problem might be that gnuplot is hanging on to some postscript terminal options even after the set terminal pop statement is executed. If you insert something like set term postscript landscape just after the set terminal pop statement, the problem goes away. But how can Octave know that it should do that? It seems it would be better for "set term pop" to restore the state of the terminal driver to whatever it was when "set term push" was executed. Here is a simpler example. Compare foo.eps vs. foo.ps from the following two scripts. 1: plot sin(x) title "line 1" set terminal push set term postscript set output "foo.ps" replot set terminal pop set output replot set term postscript eps enhanced color solid set output "foo.eps" replot quit 2: plot sin(x) title "line 1" set terminal push set term postscript eps enhanced color solid set output "foo.eps" replot set terminal pop set output replot set term postscript set output "foo.ps" replot quit Looking at these I would expect foo.ps in both cases to be the simple full page postscript plot. But in the second case, both plots are small eps style plots. I just checked the latest CVS gnuplot and it seems the behavior is the same. Would someone like to report this problem and find out if it is intentional behavior or a bug? Thanks, jwe ------------------------------------------------------------- Octave is freely available under the terms of the GNU GPL. Octave's home on the web: http://www.octave.org How to fund new projects: http://www.octave.org/funding.html Subscription information: http://www.octave.org/archive.html ------------------------------------------------------------- |
|
From: Ethan A M. <merritt@u.washington.edu> - 2005-10-02 18:27:45
|
On Sunday 02 October 2005 09:54 am, Dmitri A. Sergatskov wrote:
> Petr Mikulik wrote:
> > IMHO, these permanent options are a good idea even for interactive
> > driving: for example, you can set terminals to "enhanced" mode in your
> > .gnuplot file and don't need to do this in the driving program.
>
> I would need to do it
> if somewhere in the middle of the session the mode has changed
> to "noenhanced" for whatever reason...
This is already supported in 4.1 via the "set termoption" command.
"set termoption enhanced" will flip the current terminal into
enhanced mode without changing anything else.
As of now only a limited subset of the possible terminal options
can be changed mid-flight in this way: {no}enhanced and the
default font. Other options may be added, subject to the
concern that the option must have the same meaning for multiple
terminals.
--
Ethan A Merritt
Biomolecular Structure Center
University of Washington, Seattle 98195-7742
|
|
From: Dmitri A. S. <das...@gm...> - 2005-10-02 19:02:58
|
Ethan A Merritt wrote:
> On Sunday 02 October 2005 09:54 am, Dmitri A. Sergatskov wrote:
>
>>Petr Mikulik wrote:
>>
>>>IMHO, these permanent options are a good idea even for interactive
>>>driving: for example, you can set terminals to "enhanced" mode in your
>>>.gnuplot file and don't need to do this in the driving program.
>>
>>I would need to do it
>>if somewhere in the middle of the session the mode has changed
>>to "noenhanced" for whatever reason...
>
>
> This is already supported in 4.1 via the "set termoption" command.
> "set termoption enhanced" will flip the current terminal into
> enhanced mode without changing anything else.
>
> As of now only a limited subset of the possible terminal options
> can be changed mid-flight in this way: {no}enhanced and the
> default font. Other options may be added, subject to the
> concern that the option must have the same meaning for multiple
> terminals.
>
I guess I am not being clear. As I said, the problem with sticky options
is that it is impossible to predict what setting one going to get when
issued a command "set term post color". Let's say I am using a gnuplot
as a graphical backend to some program and I want to have a command
"print" that does "set term post color; set output 'file.out'; replot".
The only way I can get a consistent format of the output graph if I
specify explicitly _all_ the options to the "set term postscript" thing.
One example is when one does "set term post eps" and later
"set term pslatex". Since the "eps" option is sticky it messes up the
pslatex terminal...
Sincerely,
Dmitri.
--
|
|
From: Petr M. <mi...@ph...> - 2005-10-03 13:30:52
|
>> This is already supported in 4.1 via the "set termoption" command.
>> "set termoption enhanced" will flip the current terminal into
>> enhanced mode without changing anything else.
>>
>> As of now only a limited subset of the possible terminal options
>> can be changed mid-flight in this way: {no}enhanced and the
>> default font. Other options may be added, subject to the
>> concern that the option must have the same meaning for multiple
>> terminals.
>>
>
> I guess I am not being clear. As I said, the problem with sticky options
> is that it is impossible to predict what setting one going to get when
> issued a command "set term post color". Let's say I am using a gnuplot
> as a graphical backend to some program and I want to have a command "print"
> that does "set term post color; set output 'file.out'; replot".
> The only way I can get a consistent format of the output graph if I specify
> explicitly _all_ the options to the "set term postscript" thing.
In summary, there are cases where modifiable options are preferred, and
other where sticky options would be preferred.
Possible solutions:
- "set term{options} {no}stickyoptions"
- set term {xxx} default or reset term or unset termoptions
This would require an update to terminals. IMHO, it would be quite easy.
I propose this:
change
TERM_PUBLIC void XXX_options __PROTO((void));
to
TERM_PUBLIC void XXX_options __PROTO((int flag));
and if (flag==0) execute the current code, and if (flag==1) then reset all
options to default values.
It needs to a small update to all terminals, but is easy to do.
> One example is when one does "set term post eps" and later "set term
> pslatex". Since the "eps" option is sticky it messes up the pslatex
> terminal...
Options are particular for a given terminal, not for different terminals. So
the above case won't happen.
---
PM
|
|
From: Dmitri A. S. <das...@gm...> - 2005-10-02 19:20:22
|
The sticky options may help with typing in a short interactive session, but generally they are bad idea (in my opinion). E.g. you may have set some options at the beginning of the session and later you want some different options. Since you may have forgotten which options you did modify the only sure way to get the desired options is to set terminal with _all_ options explicitly specified. What making thing worse is that "default" keyword apparently does not set all options to the default state but only some. Those problems become especially painful, when gnuplot is driven by an exte= rnal program (e.g. octave). See this thread for one example: http://www.octave.org/octave-lists/archive/help-octave.2005/msg03471.html Sincerely, Dmitri. On 10/1/05, Petr Mikulik <mi...@ph...> wrote: > No, there is no bug. And it has nothing to do with "set term pop|push". > > According to "help set terminal": > > Several terminals have many additional options. For example, see `png`= , > or `postscript`. > The options used by a previous invocation `set term <term> <options>` o= f a > given `<term>` are remembered, thus subsequent `set term <term>` does > not reset them. This helps in printing, for instance, when switching > among different terminals---previous options don't have to be repeated. > > Thus with > set term post eps > show term > set term post > show term > > it will stay with eps options. > > For postscript terminal, use "set term default" to reset to default value= s. > (However, this option is not available for other terminals.) > > > FYI > >> From the octave list: > > > > Sincerely, > > > > Dmitri. > > > > ---------- Forwarded message ---------- > > From: John W. Eaton <jw...@be...> > > Date: Sep 21, 2005 8:24 PM > > Subject: Re: pslatex terminal output--Problem identified. > > To: Pete Gustafson <wat...@ya...> > > Cc: he...@oc... > > > > OK, I think this might be a bug in gnuplot. You can reproduce it with > > the following commands (these are essentially the commands that Octave > > is sending to gnuplot, but plotting a function instead of a data file > > to simplify things a bit)): > > > > plot sin(x) title "line 1" > > set terminal push > > set term postscript eps enhanced color solid > > set output "foo.eps" > > replot > > set terminal pop > > set output > > replot > > set term pslatex > > set output "foo.tex" > > replot > > quit > > > > I have not looked at the code, so I am only guessing here, but it > > seems that the problem might be that gnuplot is hanging on to some > > postscript terminal options even after the set terminal pop statement > > is executed. If you insert something like > > > > set term postscript landscape > > > > just after the set terminal pop statement, the problem goes away. But > > how can Octave know that it should do that? It seems it would be > > better for "set term pop" to restore the state of the terminal driver > > to whatever it was when "set term push" was executed. > > > > Here is a simpler example. Compare foo.eps vs. foo.ps from the > > following two scripts. > > > > 1: > > plot sin(x) title "line 1" > > set terminal push > > set term postscript > > set output "foo.ps" > > replot > > set terminal pop > > set output > > replot > > set term postscript eps enhanced color solid > > set output "foo.eps" > > replot > > quit > > > > 2: > > plot sin(x) title "line 1" > > set terminal push > > set term postscript eps enhanced color solid > > set output "foo.eps" > > replot > > set terminal pop > > set output > > replot > > set term postscript > > set output "foo.ps" > > replot > > quit > > > > Looking at these I would expect foo.ps in both cases to be the simple > > full page postscript plot. But in the second case, both plots are > > small eps style plots. > > > > I just checked the latest CVS gnuplot and it seems the behavior is the > > same. Would someone like to report this problem and find out if it is > > intentional behavior or a bug? > > > > Thanks, > > > > jwe > |
|
From: Petr M. <mi...@ph...> - 2005-10-02 21:55:25
|
> The sticky options may help with typing in a short interactive > session, but generally > they are bad idea (in my opinion). E.g. you may have set some options > at the beginning of the session and later you want some different options. > Since you may have forgotten which options you did modify > the only sure way to get the desired options is to set terminal with > _all_ options > explicitly specified. What making thing worse is that "default" keyword > apparently does not set all options to the default state but only some. > Those problems become especially painful, when gnuplot is driven by an external > program (e.g. octave). See this thread for one example: > > http://www.octave.org/octave-lists/archive/help-octave.2005/msg03471.html You can reset "set" commands to the default values by the "reset" command. This works for all except for the "set terminal" command. There, a command like "set terminal reset" would be required (for the current terminal) or "reset terminals" (to reset all terminals). You are welcome to implement this feature. IMHO, these permanent options are a good idea even for interactive driving: for example, you can set terminals to "enhanced" mode in your .gnuplot file and don't need to do this in the driving program. --- PM |
|
From: Dmitri A. S. <das...@gm...> - 2005-10-02 16:54:52
|
Petr Mikulik wrote: > IMHO, these permanent options are a good idea even for interactive > driving: for example, you can set terminals to "enhanced" mode in your > .gnuplot file and don't need to do this in the driving program. > I would need to do it if somewhere in the middle of the session the mode has changed to "noenhanced" for whatever reason... The issue here is that if I (or the driving program) issues command "set term postscript" there is no way to predict the result without knowing entire history of the current gnuplot session. I cannot to see how this is a good idea. > --- > PM > Sincerely, Dmitri. -- |
|
From: Ethan A M. <merritt@u.washington.edu> - 2005-10-02 19:54:52
|
On Sunday 02 October 2005 12:02 pm, Dmitri A. Sergatskov wrote: > One example is when one does "set term post eps" and later > "set term pslatex". Since the "eps" option is sticky it messes up the > pslatex terminal... Are you sure? That would indeed be a bug. But it doesn't seem to be the case here when I try it. I get identical output from the pslatex terminal whether or not a previous plot has used "set term post eps". If you can reproduce your problem, please send a bug report and a script that demonstrates the problem. gnuplot> set term post eps Terminal type set to 'postscript' Options are 'eps noenhanced defaultplex \ leveldefault monochrome colortext \ dashed dashlength 1.0 linewidth 1.0 butt \ palfuncparam 2000,0.003 \ "Helvetica" 14 ' gnuplot> set term pslatex Terminal type set to 'pslatex' Options are 'rotate leveldefault monochrome colortext \ dashed dashlength 1.0 linewidth 1.0 butt \ palfuncparam 2000,0.003 \ rotate noauxfile ' -- Ethan A Merritt Biomolecular Structure Center University of Washington, Seattle 98195-7742 |
|
From: John W. E. <jw...@be...> - 2005-10-04 13:53:45
|
On 2-Oct-2005, Ethan A Merritt wrote:
| On Sunday 02 October 2005 12:02 pm, Dmitri A. Sergatskov wrote:
| > One example is when one does "set term post eps" and later
| > "set term pslatex". Since the "eps" option is sticky it messes up the
| > pslatex terminal...
|
| Are you sure? That would indeed be a bug.
| But it doesn't seem to be the case here when I try it.
| I get identical output from the pslatex terminal whether or not
| a previous plot has used "set term post eps". If you can
| reproduce your problem, please send a bug report and a script
| that demonstrates the problem.
|
| gnuplot> set term post eps
| Terminal type set to 'postscript'
| Options are 'eps noenhanced defaultplex \
| leveldefault monochrome colortext \
| dashed dashlength 1.0 linewidth 1.0 butt \
| palfuncparam 2000,0.003 \
| "Helvetica" 14 '
| gnuplot> set term pslatex
| Terminal type set to 'pslatex'
| Options are 'rotate leveldefault monochrome colortext \
| dashed dashlength 1.0 linewidth 1.0 butt \
| palfuncparam 2000,0.003 \
| rotate noauxfile '
Try
plot sin(x) title "line 1"
set term postscript eps enhanced color solid
set output "foo.eps"
replot
set term pslatex
set output "foo.tex"
replot
quit
With gnuplot 4.0 patchlevel 0, then include the resulting foo.tex file
in a simple document like
\documentclass{article}
\usepackage{graphicx}
\begin{document}
\input{foo}
\end{document}
and process with latex and dvips. The final output has the axes and
labels (the stuff in the TeX part of the figure) correctly rendered,
but the PS part is 1/4 the proper size, and displayed in the lower
left corner of the TeX part.
I can't seem to reproduce the problem with a recent CVS version so
that's good.
But the problem with sticky terminal options remains. For
non-interactive use by programs like Octave, it would be very helpful
if there were some way to push and pop all settings, not just some of
them. That way, the application that is driving gnuplot does not have
to keep track of the complete history of all option settings when
making a temporary change.
Another thing that would be very useful would be a way to query
individual settings. Parsing text output would be OK, provided that
it is easy to do that (i.e., the output is structured in some way, not
some natural language thing) and the format does not change.
jwe
|
|
From: Petr M. <mi...@ph...> - 2005-10-04 20:59:32
|
> I can't seem to reproduce the problem with a recent CVS version so > that's good. The (e)pslatex drivers have been completely rewritten for 4.1. > But the problem with sticky terminal options remains. For > non-interactive use by programs like Octave, it would be very helpful > if there were some way to push and pop all settings, not just some of > them. That way, the application that is driving gnuplot does not have > to keep track of the complete history of all option settings when > making a temporary change. That would require the previously proposed "unset termoptions". > Another thing that would be very useful would be a way to query > individual settings. Parsing text output would be OK, provided that > it is easy to do that (i.e., the output is structured in some way, not > some natural language thing) and the format does not change. Do you mean gget.m from octave-forge? It works OK. --- PM |
|
From: John W. E. <jw...@be...> - 2005-10-04 22:35:57
|
On 4-Oct-2005, Petr Mikulik wrote: | > Another thing that would be very useful would be a way to query | > individual settings. Parsing text output would be OK, provided that | > it is easy to do that (i.e., the output is structured in some way, not | > some natural language thing) and the format does not change. | | Do you mean gget.m from octave-forge? | It works OK. No, it is a terrible kluge and has a built-in race condition because it sends a "save" command to gnuplot then waits a while (how long is long enough?) and then parses the output. The parsing step seems a bit dicey to me, since as far as I know, the format of the output is not well defined and could change with any new release of gnuplot. jwe |
|
From: Ethan M. <merritt@u.washington.edu> - 2005-10-04 22:55:17
|
On Tuesday 04 October 2005 03:35 pm, John W. Eaton wrote:
> On 4-Oct-2005, Petr Mikulik wrote:
>
> | > Another thing that would be very useful would be a way to query
> | > individual settings. Parsing text output would be OK, provided that
> | > it is easy to do that (i.e., the output is structured in some way, not
> | > some natural language thing) and the format does not change.
Would it be preferable if gnuplot's "show <foo>" command produced output
corresponding to the input syntax, just as "save" does now?
For example, for "show title"
current output:
title is "Foo", offset at ((character units) 0, 0, 0)
equivalent line in "save" corresponds in input syntax:
set title "Foo" offset character 0, 0, 0 font "" norotate
>> Do you mean gget.m from octave-forge?
>>
> it is a terrible kluge and has a built-in race condition because
> it sends a "save" command to gnuplot then waits a while (how long is
> long enough?) and then parses the output.
Can it not read back synchronously?
fprintf(GNUPLOT_OUT,"save '| outpipe'\n");
fflush(GNUPLOT_OUT);
while ( fgets(&line, sizeof(line), GNUPLOT_INPIPE) )
look_for_desired_option(&line);
--
Ethan A Merritt merritt@u.washington.edu
Biomolecular Structure Center
Mailstop 357742
University of Washington, Seattle, WA 98195
|
|
From: Petr M. <mi...@ph...> - 2005-10-05 22:32:30
Attachments:
gget2.m
|
> | Do you mean gget.m from octave-forge? > | It works OK. > > No, it is a terrible kluge and has a built-in race condition because > it sends a "save" command to gnuplot then waits a while (how long is Yes, it is quite strange ... I think that's due to Windows (no stdout et al). Please find enclosed gget2.m. It's a version with implementation according to the current ginput.m (available from gnuplot's site, Octave section). I think the code is clean. However, I don't know what happens on Windows. > the format of the output is not well defined and could change with any new > release of gnuplot. I don't think this is happening. There may be some changes due to addition of new options. --- PM |
|
From: Dmitri A. S. <das...@gm...> - 2005-09-22 14:54:31
|
Hans-Bernhard Broeker wrote: > From: John W. Eaton <jw...@be...> > >> OK, I think this might be a bug in gnuplot. You can reproduce it with >> the following commands (these are essentially the commands that Octave >> is sending to gnuplot, but plotting a function instead of a data file >> to simplify things a bit)): > > > [...] > > > I have not looked at the code, so I am only guessing here, but it > > seems that the problem might be that gnuplot is hanging on to some > > postscript terminal options even after the set terminal pop statement > > is executed. If you insert something like > > This is not really a bug, but intended behaviour. gnuplot terminal > drivers save settings internally, so going to some other driver and then > back will give you the previously used driver in the same state is was > in before. Users can't seem to make up their mind whether they like > this or not... > Ok, in that case how do I undo "eps" setting for the file foo.ps in the following script? plot sin(x) title "line 1" set terminal push set term postscript eps enhanced color solid set output "foo.eps" replot set terminal pop set output replot set term postscript set output "foo.ps" replot quit There are enhanced|noenhanced, color|monochrome, but there is no eps|noeps switch, which in my mind imply that "eps" should not be a sticky option. Sincerely, Dmitri. |
|
From: Hans-Bernhard B. <br...@ph...> - 2005-09-22 15:21:31
|
Dmitri A. Sergatskov wrote:
> Hans-Bernhard Broeker wrote:
>> This is not really a bug, but intended behaviour. gnuplot terminal
>> drivers save settings internally, so going to some other driver and
>> then back will give you the previously used driver in the same state
>> is was in before. Users can't seem to make up their mind whether they
>> like this or not...
> Ok, in that case how do I undo "eps" setting for the file foo.ps in
> the following script?
RTFM ('help postscript'):
Syntax:
set terminal postscript {<mode>} {enhanced | noenhanced}
[...]
where <mode> is landscape, portrait, eps or default
Select one of the others, and 'eps' will be turned off. The "default"
setting may only actually work in the CVS version, not in 4.0
|
|
From: Dmitri A. S. <das...@gm...> - 2005-09-22 15:51:45
|
Hans-Bernhard Broeker wrote:
>
> RTFM ('help postscript'):
>
> Syntax:
> set terminal postscript {<mode>} {enhanced | noenhanced}
> [...]
> where <mode> is landscape, portrait, eps or default
>
> Select one of the others, and 'eps' will be turned off. The "default"
> setting may only actually work in the CVS version, not in 4.0
>
Thanks, this works.
I do not know which FM you are referring to, mine says the following
(from 1 hour ago CVS):
gnuplot> help postscript
Several options may be set in the `postscript` driver.
Syntax:
set terminal postscript {landscape | portrait | eps}
{enhanced | noenhanced}
{defaultplex | simplex | duplex}
{fontfile [add | delete] "<filename>"
| nofontfiles}
{default}
{level1 | leveldefault}
{color | colour | monochrome}
{solid | dashed}
{dashlength | dl <DL>}
{linewidth | lw <LW>}
{rounded | butt}
{palfuncparam <samples>{,<maxdeviation>}}
{blacktext | colortext | colourtext}
{"<fontname>"} {<fontsize>}
...
Though, perhaps, one can deduce that "default" option reverses
"eps" it is not that obvious to me.
Sincerely,
Dmitri.
|
|
From: Petr M. <mi...@ph...> - 2005-10-02 23:02:51
|
No, there is no bug. And it has nothing to do with "set term pop|push". According to "help set terminal": Several terminals have many additional options. For example, see `png`, or `postscript`. The options used by a previous invocation `set term <term> <options>` of a given `<term>` are remembered, thus subsequent `set term <term>` does not reset them. This helps in printing, for instance, when switching among different terminals---previous options don't have to be repeated. Thus with set term post eps show term set term post show term it will stay with eps options. For postscript terminal, use "set term default" to reset to default values. (However, this option is not available for other terminals.) > FYI >> From the octave list: > > Sincerely, > > Dmitri. > > ---------- Forwarded message ---------- > From: John W. Eaton <jw...@be...> > Date: Sep 21, 2005 8:24 PM > Subject: Re: pslatex terminal output--Problem identified. > To: Pete Gustafson <wat...@ya...> > Cc: he...@oc... > > OK, I think this might be a bug in gnuplot. You can reproduce it with > the following commands (these are essentially the commands that Octave > is sending to gnuplot, but plotting a function instead of a data file > to simplify things a bit)): > > plot sin(x) title "line 1" > set terminal push > set term postscript eps enhanced color solid > set output "foo.eps" > replot > set terminal pop > set output > replot > set term pslatex > set output "foo.tex" > replot > quit > > I have not looked at the code, so I am only guessing here, but it > seems that the problem might be that gnuplot is hanging on to some > postscript terminal options even after the set terminal pop statement > is executed. If you insert something like > > set term postscript landscape > > just after the set terminal pop statement, the problem goes away. But > how can Octave know that it should do that? It seems it would be > better for "set term pop" to restore the state of the terminal driver > to whatever it was when "set term push" was executed. > > Here is a simpler example. Compare foo.eps vs. foo.ps from the > following two scripts. > > 1: > plot sin(x) title "line 1" > set terminal push > set term postscript > set output "foo.ps" > replot > set terminal pop > set output > replot > set term postscript eps enhanced color solid > set output "foo.eps" > replot > quit > > 2: > plot sin(x) title "line 1" > set terminal push > set term postscript eps enhanced color solid > set output "foo.eps" > replot > set terminal pop > set output > replot > set term postscript > set output "foo.ps" > replot > quit > > Looking at these I would expect foo.ps in both cases to be the simple > full page postscript plot. But in the second case, both plots are > small eps style plots. > > I just checked the latest CVS gnuplot and it seems the behavior is the > same. Would someone like to report this problem and find out if it is > intentional behavior or a bug? > > Thanks, > > jwe |
