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

Re: problems revealed by new demos

[Harald H. <h.h...@tu...>]

> > The relevant point here is that Harald introduces
> > a new driver entry point to term_api
> > 	term->set_output(char *outfile)
> >
> > and in the core code he uses it as follows
> > 	if (term->set_output)
> > 		(term->set_output)( newfilename )
> > 	else
> > 		term_set_output( newfilename )
> >
> > Would this approach solve the current problem with
> > using table.trm?  It would not fix existing scripts, but it
> > might be more flexible in the long run.
>
> I think new terminal API is not necessary. It can be organized in the
> current way using set_termoptions() and term->options(). (And that's how
> epslatex works until now, without problems.)

Sure it is problematic. I think it is bad style that set_output opens an
output file and the terminal has to change already opened file handles.
And the current solution prevents the user from giving a filename without
extension for terminals that use more than one output file. And, there is
another problem: LaTeX's \includegraphics command does not allow dots
within filenames. With the current solution it is not possible to test the
filename on validity for LaTeX before it is generated. This is bad style.

> Also, the "FILE *gpauxfile" should be declared in term_api.h, close to
> declaration of  extern FILE *postscript_gpoutfile;

This could be done, no problem. I have thaught to provide gpauxfile for
other terminals that might want to use an auxfile. But it is not
important.

> I think that the epslatex driver should use postscript_gpoutfile for its
> aux output, not its new gpauxfile. That's because there are tests within the
> gnuplot core for this output, and then a postscript-optimized code is
> shipped out (e.g. pm3d routines). Have you tested your epslatex with pm3d
> output? I guess it would fail.

I have never understood the sence of postscript_gpoutfile. What it is ment
for?

> > Right now it is permitted (though discouraged) to call
> > 'set output'  before calling 'set term'.   Would we have to
> > forbid this absolutely?
>
> The compatibity should be kept -- gnuplot cannot depend on the order of
> these two commands.

I agree. But 'set output' should not immediately open an output file (see
my other posting).

> Finally, this patch should be unified with
> 	[ 743667 ] Epslatex term merged w/ pslatex/pstex
> Harald, please take the best from both.

I agree. Unfortunately I won't have the time to merge these two patches in
the next months. We could either wait until I find the time again or any
other person could work on it. What about Theo Hopman who programmed patch
#743667?

Yours
Harald

-- 
Harald Harders
h.h...@tu...
http://www.harald-harders.de

Re: problems revealed by new demos

[Harald H. <h.h...@tu...>]

On Thu, 30 Sep 2004, Ethan Merritt wrote:

Sorry for not answering for such a long time. I have moved to another
city and changed my company.

> > > 'set term table' could take an optional file name,
> > > leaving the value of "set output" unchanged.
> >
> > I think that's the best solution.
>
> I have been looking at Harald Harder's patch to replace
> the existing epslatex.trm with a new driver that piggybacks
> on most of the post.trm driver routines.  I will leave general
> discussion of that to people who actually use the epslatex
> terminal.
>
> The relevant point here is that Harald introduces
> a new driver entry point to term_api
> 	term->set_output(char *outfile)
>
> and in the core code he uses it as follows
> 	if (term->set_output)
> 		(term->set_output)( newfilename )
> 	else
> 		term_set_output( newfilename )
>
> Would this approach solve the current problem with
> using table.trm?  It would not fix existing scripts, but it
> might be more flexible in the long run.

The cause for introducing the new API routine was that it allows some
interesting things that were not possible with the standard routine:

- The use is able to leave out the file extensions.
  For the user the question is: Since epslatex generates two files, which
  of these is the correct one? With the new routine it is possible to
  give 'outfile.eps', 'outfile.tex', or 'outfile' as output filename.
- The option fullheader made it necessary to use another file open
  routine. The fullheader mode is ment for producing a stand alone
  postscript or pdf output file that can be included by any application,
  using TeX texts. This is done by producing a full LaTeX file with the
  given output file name and an additional eps file with a prefix before
  the extension. This is done to prevent mixing up the gnuplot-produced
  eps file without text information and the final ps or pdf file produced
  by dvips or pdflatex.

I think, the new set_output routine could also be interesting for other
terminals, escpecially these with binary output or with more than one
output file.

> I have some questions about your new terminal entry.
>
> Right now it is permitted (though discouraged) to call
> 'set output'  before calling 'set term'.   Would we have to
> forbid this absolutely?

Mmh, I think it is a design bug that 'set output' immediately opens an
output file before it knows for which terminal the file will be used. For
example, it does not know if more than one file will be opened or if the
output file is ascii or binary. The result are strange routines that close
the outputfile and open it again with different settings (This is worse
than an file_open routine for different terminals, in my opinion).
There are two possible solutions:

- The fopen is postponed to a point where both terminal and output
  filename are known, for example to the occurance of 'set multiplot' or
  'plot' resp. 'splot'. Then, 'set output' can stay before or after
  'set terminal'. But this means a reorganisation of the routines.
- A terminal change is forbidden after 'set output'.

I think the first solution is better. If I remember correctly this has
already discussed sometimes.

> Would it be possible to separate the file descriptor opened
> by (term->set_output) from the one opened by term_set_output?
> That way a terminal with a private version of the routine
> would not destroy the current setting of "set output <foo>",
> which is the issue being raised by the example in vector.dem

I am not sure if this works without problems. The terminal that has a
private set_output routine could use another FILE variable than the global
one. But this leads into trouble if 'set output' is used before 'set
terminal'.

Yours
Harald

-- 
Harald Harders
h.h...@tu...
http://www.harald-harders.de

Re: GnuPlot and Aquaterm

[Per P. <per...@ma...>]

On Oct 1, 2004, at 19:46, jue...@ma... wrote:

> Hello,
>
> I was trying to use gnuplot with Aquaterm on OSX again after a time of
> disuse.
> To my great surprise I found the following error message in gnuplot 
> when
> trying to plot a function:
>
> Display server (AquaTerm) is too old, please update it.
> See http://qauaterm.sf.net for more info and download.

AquaTerm 1.x isn't backwards compatible with AquaTerm 0.3.x, 
unfortunately "too old" in this case means "too new", sorry for the 
confusion.

Somewhere along the line you must have installed to AquaTerm 1.x but 
not upgraded gnuplot.

>
> I was hardly believing my eyes. Shouldn't this decision be left to the
> user?
> However, after correcting the spelling error in the given url ;-) I was
> able to
> obtain the latest version and alas, it still wont let me plot.
>
> Any ideas on this? I was depending on it for fixing up some graphs in 
> my
> diploma thesis, and now I'm stuck. And stuck not of my own making, if
> you
> know what I mean. Which is vexing.

Easy solution: download AquaTerm 0.3.2, start it before running gnuplot 
if you have multiple versions around (beware that e.g. fink installs 
AquaTerm into /sw/Applications).

Best solution: install gnuplot 4.0

HTH,
Per

Re: problems revealed by new demos

[Hans-Bernhard B. <br...@ph...>]

On Fri, 1 Oct 2004, Daniel J Sebald wrote:

> No doubt there.  What about this "pstricks".  Way back, I saw that one
> and thought to update the image drivers in there.  Then looking at it,
> it seemed so outdated that I wondered about its worth.  I tried running
> 'all.dem' under pstricks; that soon failed.  I tried 'image.dem'; image
> don't pass through of course but some other elements in the plots
> failed.  pstricks is falling behind a bit.

Well, that's what happens if none of its users bothers to speak up or
participate in the maintenance.  I'm quite sure we have drivers that have
accumulated even more dust than pstricks.  

Putting such bugs into the SF.net tracker as soon as any of us notices
them might be a good idea.  Even if only to serve as a list of "things to
do on a boring rainy weekend".

[...]
>  From my understanding, EPS supposedly only differs from PS by the 
> presence of the bounding box information.

I was talking about epslatex vs. pslatex.  Those two are almost completely
independent of each other.

-- 
Hans-Bernhard Broeker (br...@ph...)
Even if all the snow were burnt, ashes would remain.

Re: problems revealed by new demos

[Hans-Bernhard B. <br...@ph...>]

On Fri, 1 Oct 2004, Ethan Merritt wrote:

[...]
> But a change to TERM_TABLE might resolve the more general
> problem seen in vector.dem, that the sequence 
> 	set term push
> 	set term <new>
> 	set output
> 	replot
> 	set term pop
> loses the original output setting.

I don't think these two are actually much related to each other.

The problem with the above sequence from vector.dem is mainly in the way
'set term push/pop' operate: they store the *command line* options of the
terminal, but they don't (and can't) store its internal state.  Which
means that 'set term push' closes the terminal (e.g. post.trm will write
out its epilogue), and 'set term pop' opens it again (so post.trm will
output the prologue with the next plot).  So even if we did keep the
output file open by storing its handle across the push/pop interval, the
contents of the file would probably be unusable afterwards.  

Not to mention what may happen if some smartass tries

	set term post
	set out 'my.ps'
	# plot something
	set term push
	set term post color
	set out 'my.ps'
	replot
	set term pop
	replot

In the current state of things, I suspect the only choice would be to
either declare 'set term push' an error if an output file is open, or make
it imply a 'set out' to close the file.

-- 
Hans-Bernhard Broeker (br...@ph...)
Even if all the snow were burnt, ashes would remain.

Re: Binary installer for Mac OS X

[Per P. <per...@ma...>]

On Oct 2, 2004, at 01:59, Ethan Merritt wrote:

> On Friday 01 October 2004 02:17 pm, Per Persson wrote:
>> What version?
>
> 1.0a2

Please try 1.0b2, comes with installer too.

[snip]

> Never mind.  I just rebooted the machine, and now it works.

Rebooting shouldn't be neccessary.

[snip]

> Looks basically pretty good.  The lack of mouse interaction makes
> it strictly inferior to X, but the plot quality is OK.

Well, AquaTerm support passing events to the client so all we need is 
someone with spare time to hook up the connection...

> The only
> glitches I see in a quick run through all.dem are:
>
> (aquaterm bug): the background of the plot is corrupted whenever
> it overlaps another window.  Not just a transparency effect - 
> overlapping
> even a small corner causes the color to streak across the entire
> horizontal extent of the aquaterm window.

Que? Could you send me a screenshot of this (press SHIFT-CMD-4). I've 
never seen or heard about anything like that.

>
> (pm3d bug): The pm3d surface plots suffer from what looks like the
> same bug we had to squash in postscript a few months back. Every
> individual pm3d rectangle is outlined in white, so the overall plot 
> looks
> either stripy or plaid.  We fixed this in PostScript by doing an extra
> gsave/grestore around the newpath/vectors/fill operation. I don't know
> if there is an equivalent operation in aqua.trm

This should be fixed in 1.0.b2

>
> (general style): It would be nice if the first 10-12 point styles 
> matched
> other terminals. It is annoying to preview a plot on the screen and
> then find when you print it that all the point symbol shapes have 
> changed.
> At the least it should offer open and filled circles (styles 6 and 7).

Agreed, but aquaterm relies on gnuplot to draw the points via 
do_point().
That will probably change in the future.

>
> (fonts): Text placement would be more accurate if the correct font 
> specs
> are passed back to the core code via the TERM_ENTRY fields
> v_char and h_char.  See for instance the box around the sample
> text in the output of "test".  I see that there is code in aqua.trm 
> that
> tries to do this, but it doesn't seem to be getting the correct 
> information.

No, it guesses from the current fontsize. Even if some "correct" 
information was passed to gnuplot, it wouldn't completely solve the 
problem unless the current font has a fixed with. Consider adding 
"iiii" as opposed to "MMMM", the bounding box can only be determined by 
taking both the string and the font into account. But, yes, 
aquaterm.trm should probably put a little more effort into this.

/Per
--------
Per Persson, Ph.D. Applied Signal Processing
Resume, contact info and more:
http://homepage.mac.com/persquare

Re: problems revealed by new demos

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

Daniel J Sebald wrote:

> I also just tried running gnuplot's "test" image through the epslatex 
> terminal.  Running the "xdvi" on the compiled output files results in 
> the polyfill not appearing.  Doing "dvips test -o test.ps" created a 
> PostScript file that crashed on the polyfill.  As you are arguing 
> above, if it works in PostScript, a seemless transition to related 
> terminals should be expected. 


Oh, I see that none of the common definitions are put inside the PS 
portion of the epslatex terminal scheme.  So the "PolyFill" command 
fails because it isn't defined in the files header.  Somewhere epslatex 
needs to call PS_common_init().  Skimming through Harald's epslatex 
patch, I don't see that it does that.  Should this be fixed before or 
after the patch is applied?

I see the problem doesn't exist in 4.0.0, probably because that code did 
not use a definition of PolyFill, just straight PostScript code.  The 
post.trm was probably rewritten to use PolyFill.  epslatex, like pslatex 
, uses the routine directly, however pslatex does call PS_common_init().

Dan Sebald

Re: problems revealed by new demos

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

Ethan Merritt wrote:

>>(Can't think of a reason to use that, but a user might do it by 
>>accident and get a resulting "file write" error after popping back the 
>>first terminal instance.
>>    
>>
>
>There wouldn't be any error.  It would just continue writing to
>the most recently specified output file.  Same as it does now.
>

Ah.  That wouldn't be much of a problem.

Dan

Re: Binary installer for Mac OS X

[Ethan M. <merritt@u.washington.edu>]

On Friday 01 October 2004 02:17 pm, Per Persson wrote:
> Ethan Merritt wrote
> > The problem I have is that aquaterm itself does not work.
> Now that is a pretty general statement which true in general..
> What version? 

1.0a2

> How did you install it? 

I followed the advice posted to comp.graphics.apps.gnuplot
by  fro...@sw... (frode):

  To install the Gnuplot Adapter and its shared library:
  Download AquaTerm1.0a2 or later
  bash>cd ~/AquaTerm1.0.a2/
  bash>cp -R AquaTerm.app /Applications/
  You may need to "sudo mkdir /usr/local/lib" if it doesn't exists
  before next step
  bash>sudo cp lib/libaquaterm.1.0.0.dylib /usr/local/lib/
  bash>sudo ln -s /usr/local/lib/libaquaterm.1.0.0.dylib
  /usr/local/lib/libaquaterm.dylib
  bash>sudo mkdir -p /usr/local/include/aquaterm
  bash>sudo cp -R include/ /usr/local/include/aquaterm/

Never mind.  I just rebooted the machine, and now it works.
There must be some system initialization script that needs to
run first, and it wasn't triggered merely by installing aquaterm
for the first time.

Please bear with me.  This is the first time I've ever used Mac OSX,
and the only reason I have a Mac to try it on is that one of the
Mac-fanatics in my lab dumped an old one onto my desk the other
day.

OK, now I will go and have a first look at gnuplot+aquaterm.

[some time later]

Looks basically pretty good.  The lack of mouse interaction makes
it strictly inferior to X, but the plot quality is OK.   The only 
glitches I see in a quick run through all.dem are:

(aquaterm bug): the background of the plot is corrupted whenever
it overlaps another window.  Not just a transparency effect - overlapping
even a small corner causes the color to streak across the entire 
horizontal extent of the aquaterm window.

(pm3d bug): The pm3d surface plots suffer from what looks like the
same bug we had to squash in postscript a few months back. Every
individual pm3d rectangle is outlined in white, so the overall plot looks
either stripy or plaid.  We fixed this in PostScript by doing an extra
gsave/grestore around the newpath/vectors/fill operation. I don't know
if there is an equivalent operation in aqua.trm

(general style): It would be nice if the first 10-12 point styles matched
other terminals. It is annoying to preview a plot on the screen and 
then find when you print it that all the point symbol shapes have changed. 
At the least it should offer open and filled circles (styles 6 and 7).

(fonts): Text placement would be more accurate if the correct font specs
are passed back to the core code via the TERM_ENTRY fields
v_char and h_char.  See for instance the box around the sample
text in the output of "test".  I see that there is code in aqua.trm that
tries to do this, but it doesn't seem to be getting the correct information.

	regards,

		Ethan
 

-- 
Ethan A Merritt       merritt@u.washington.edu
Biomolecular Structure Center
Mailstop 357742
University of Washington, Seattle, WA 98195

Re: problems revealed by new demos

[Ethan M. <merritt@u.washington.edu>]

On Friday 01 October 2004 11:45 am, Daniel J Sebald wrote:
> >but storing the output fd (or maybe the string used to open it)
> >in the TERM_TABLE is an interesting idea. 
> 
> Sounds good.  Would calling the same terminal after a push be a problem? 

No more so than under the current scheme.

>  (Can't think of a reason to use that, but a user might do it by 
> accident and get a resulting "file write" error after popping back the 
> first terminal instance.

There wouldn't be any error.  It would just continue writing to
the most recently specified output file.  Same as it does now.


-- 
Ethan A Merritt       merritt@u.washington.edu
Biomolecular Structure Center
Mailstop 357742
University of Washington, Seattle, WA 98195

Binary installer for Mac OS X

[Per P. <per...@ma...>]

So, I finally put my money where my mouth is and created a binary 
installer for Mac OS X (actually I created a script that does the job, 
I'm too lazy ;-)

Since there aren't a lot of people around here running Mac OS X, I've 
prepared a webpage so that you may comment on it anyway. Head over to 
http://homepage.mac.com/persquare/PhotoAlbum7.html

I'd also like to try it out with a number of guinea pigs^W^W beta 
testers before an official release since I only have access to OS X 
10.3. There may e.g. be issues with X11 on older systems since it 
wasn't part of a standard install until 10.3. Where would be the 
appropriate place to look for beta testers? comp.graphics.apps.gnuplot?

Also, the gnuplot.info file isn't quite correctly installed right now, 
i.e. an entry is not added to the top level menu. I guess it is a 
matter of feeding install-info the correct incantations in my 
postflight script, any experts here?

In the long term, should I add the script (that creates installers) and 
a few (3 at the moment) supporting files to gnuplot or should I keep it 
separate?

While I'm at it, could someone either close bug 1033446 (or assign it 
to me). It was a case of bad piloting.

Over and out for now,
Per
--------
Per Persson, Ph.D. Applied Signal Processing
Resume, contact info and more:
http://homepage.mac.com/persquare

Re: problems revealed by new demos

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

Daniel J Sebald wrote:

>   a seemless transition

seamless

Re: problems revealed by new demos

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

Hans-Bernhard Broeker wrote:

> Daniel J Sebald wrote:
>
>> No feeling on your main point, but I read through the patch comments 
>> because epslatex is one of my fav terminals.
>
>
> I suspect I'm the one among the developers who *uses* gnuplot least 
> frequently, so I don't have much of a favourite terminal driver, but 
> still, I have some points I'd like to make:
>
> *) we currently have *two* "combined ps + latex" drivers: pslatex
>    and epslatex.  Yet this discussion has been only about epslatex.
>    That doesn't seem right. In particular, it doesn't seem to make
>    sense to go about modifying one of them alone, instead of
>    collecting the best of both into a single, new one (while keeping
>    an eye on pstex, too). 


No doubt there.  What about this "pstricks".  Way back, I saw that one 
and thought to update the image drivers in there.  Then looking at it, 
it seemed so outdated that I wondered about its worth.  I tried running 
'all.dem' under pstricks; that soon failed.  I tried 'image.dem'; image 
don't pass through of course but some other elements in the plots 
failed.  pstricks is falling behind a bit.

I also just tried running gnuplot's "test" image through the epslatex 
terminal.  Running the "xdvi" on the compiled output files results in 
the polyfill not appearing.  Doing "dvips test -o test.ps" created a 
PostScript file that crashed on the polyfill.  As you are arguing above, 
if it works in PostScript, a seemless transition to related terminals 
should be expected.

> *) The two drivers have several differences.  Some of them are mainly
>    accidental, others were made intentionally.  I.e. there are things
>    in epslatex, like the particular choice of line type colours, that
>    were designed the way they are *because* someone wanted them to be
>    different from what pslatex does.  Harald's patch reverts some of
>    those decisions, which I'm not quite happy with. 


 From my understanding, EPS supposedly only differs from PS by the 
presence of the bounding box information.

Dan

Re: problems revealed by new demos

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

Ethan Merritt wrote:

>On Friday 01 October 2004 03:13 am, Hans-Bernhard Broeker wrote:
>  
>
>>*) I don't see why we should need a new term API entry for
>>    setting the output.  Yes, the output file is currently a global
>>    variable, which is bad from a structural point of view.  But I really
>>    don't see why a modification of a single terminal driver should be
>>    allowed to change the API.  If we want to change the API, that's a
>>    separate issue, to be discussed independently.
>>    
>>
>
>That is the discussion I hoped to trigger.
>I agree it is not a good thing to change the API for only one driver.
>But a change to TERM_TABLE might resolve the more general
>problem seen in vector.dem, that the sequence 
>	set term push
>	set term <new>
>	set output
>	replot
>	set term pop
>loses the original output setting.
>
>Adding an actual terminal-specific function may not be useful,
>but storing the output fd (or maybe the string used to open it)
>in the TERM_TABLE is an interesting idea.  Then each driver would
>have its own output stream, and you could ' set term push/pop/<new>'
>all day without having them trample on each other's output.
>

Sounds good.  Would calling the same terminal after a push be a problem? 
 (Can't think of a reason to use that, but a user might do it by 
accident and get a resulting "file write" error after popping back the 
first terminal instance.

Dan

Re: problems revealed by new demos

[Ethan M. <merritt@u.washington.edu>]

On Friday 01 October 2004 03:13 am, Hans-Bernhard Broeker wrote:
> *) I don't see why we should need a new term API entry for
>     setting the output.  Yes, the output file is currently a global
>     variable, which is bad from a structural point of view.  But I really
>     don't see why a modification of a single terminal driver should be
>     allowed to change the API.  If we want to change the API, that's a
>     separate issue, to be discussed independently.

That is the discussion I hoped to trigger.
I agree it is not a good thing to change the API for only one driver.
But a change to TERM_TABLE might resolve the more general
problem seen in vector.dem, that the sequence 
	set term push
	set term <new>
	set output
	replot
	set term pop
loses the original output setting.

Adding an actual terminal-specific function may not be useful,
but storing the output fd (or maybe the string used to open it)
in the TERM_TABLE is an interesting idea.  Then each driver would
have its own output stream, and you could ' set term push/pop/<new>'
all day without having them trample on each other's output.

GnuPlot and Aquaterm

[<jue...@ma...>]

Hello,

I was trying to use gnuplot with Aquaterm on OSX again after a time of 
disuse.
To my great surprise I found the following error message in gnuplot when
trying to plot a function:

Display server (AquaTerm) is too old, please update it.
See http://qauaterm.sf.net for more info and download.

I was hardly believing my eyes. Shouldn't this decision be left to the 
user?
However, after correcting the spelling error in the given url ;-) I was 
able to
obtain the latest version and alas, it still wont let me plot.

Any ideas on this? I was depending on it for fixing up some graphs in my
diploma thesis, and now I'm stuck. And stuck not of my own making, if 
you
know what I mean. Which is vexing.

Cheers,
J.L.Simon

Re: problems revealed by new demos

[Hans-Bernhard B. <br...@ph...>]

Daniel J Sebald wrote:

> No feeling on your main point, but I read through the patch comments 
> because epslatex is one of my fav terminals.

I suspect I'm the one among the developers who *uses* gnuplot least 
frequently, so I don't have much of a favourite terminal driver, but 
still, I have some points I'd like to make:

*) we currently have *two* "combined ps + latex" drivers: pslatex
    and epslatex.  Yet this discussion has been only about epslatex.
    That doesn't seem right. In particular, it doesn't seem to make
    sense to go about modifying one of them alone, instead of
    collecting the best of both into a single, new one (while keeping
    an eye on pstex, too).

*) The two drivers have several differences.  Some of them are mainly
    accidental, others were made intentionally.  I.e. there are things
    in epslatex, like the particular choice of line type colours, that
    were designed the way they are *because* someone wanted them to be
    different from what pslatex does.  Harald's patch reverts some of
    those decisions, which I'm not quite happy with.

*) I don't see why we should need a new term API entry for
    setting the output.  Yes, the output file is currently a global
    variable, which is bad from a structural point of view.  But I really
    don't see why a modification of a single terminal driver should be
    allowed to change the API.  If we want to change the API, that's a
    separate issue, to be discussed independently.

Re: problems revealed by new demos

[Petr M. <mi...@ph...>]

> > > 'set term table' could take an optional file name,
> > > leaving the value of "set output" unchanged.
> >
> > I think that's the best solution.
>
> I have been looking at Harald Harder's patch to replace
> the existing epslatex.trm with a new driver that piggybacks
> on most of the post.trm driver routines.  I will leave general
> discussion of that to people who actually use the epslatex
> terminal.
>
> The relevant point here is that Harald introduces
> a new driver entry point to term_api
> 	term->set_output(char *outfile)
>
> and in the core code he uses it as follows
> 	if (term->set_output)
> 		(term->set_output)( newfilename )
> 	else
> 		term_set_output( newfilename )
>
> Would this approach solve the current problem with
> using table.trm?  It would not fix existing scripts, but it
> might be more flexible in the long run.

I think new terminal API is not necessary. It can be organized in the
current way using set_termoptions() and term->options(). (And that's how
epslatex works until now, without problems.)

This new term API won't help the "table" terminal because writing graphs and
surfaces is made by the gnuplot core, not by the driver itself.

Also, the "FILE *gpauxfile" should be declared in term_api.h, close to
declaration of  extern FILE *postscript_gpoutfile;


I think that the epslatex driver should use postscript_gpoutfile for its
aux output, not its new gpauxfile. That's because there are tests within the
gnuplot core for this output, and then a postscript-optimized code is
shipped out (e.g. pm3d routines). Have you tested your epslatex with pm3d
output? I guess it would fail.


> Right now it is permitted (though discouraged) to call
> 'set output'  before calling 'set term'.   Would we have to
> forbid this absolutely?

The compatibity should be kept -- gnuplot cannot depend on the order of
these two commands.


Finally, this patch should be unified with
	[ 743667 ] Epslatex term merged w/ pslatex/pstex
Harald, please take the best from both.

--
PM

Re: problems revealed by new demos

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

Ethan Merritt wrote:

>On Wednesday 29 September 2004 11:42 pm, Petr Mikulik wrote:
>  
>
>>>'set term table' could take an optional file name,
>>>leaving the value of "set output" unchanged.
>>>      
>>>
>>I think that's the best solution.
>>    
>>
>
>I have been looking at Harald Harder's patch to replace
>the existing epslatex.trm with a new driver that piggybacks
>on most of the post.trm driver routines.  I will leave general
>discussion of that to people who actually use the epslatex
>terminal. 
>

No feeling on your main point, but I read through the patch comments 
because epslatex is one of my fav terminals.  For the most part, 
everything the patch does to enhance or correct problems sounds good to 
me.  Individual comments:

 > This approach ensures that new developments
 > of the postscript terminal are available in epslatex,
 > automatically.

This is very nice.

 > In addition to the old epslatex syntax and the
 > postscript options for epslatex (for example, rounded,
 > linewidth, dashlength), the patch supports:
 > - coloured text with epslatex (which can be switched on
 > and off locally for one plot or globally in the
 > preamble of the LaTeX document),

xfig added color text a year or two ago.  Requires as an additional 
LaTeX package, but no big deal.  Probably more use for colored text in 
gnuplot than in xfig.

I see another there is another patch on SourceForge that may be conflicting:

743667 Epslatex term merged w/ pslatex/pstex

Are these related?  Can they be combined?  The concepts sound the same, 
i.e., to combine the postscript related terminals in a better fashion.

On the subject of PostScript, I recall someone submitting a patch for 
using grayscale backgrounds in PostScript.  Looked promising at the time.

Dan

Re: problems revealed by new demos

[Ethan M. <merritt@u.washington.edu>]

On Wednesday 29 September 2004 11:42 pm, Petr Mikulik wrote:
> 
> > 'set term table' could take an optional file name,
> > leaving the value of "set output" unchanged.
> 
> I think that's the best solution.

I have been looking at Harald Harder's patch to replace
the existing epslatex.trm with a new driver that piggybacks
on most of the post.trm driver routines.  I will leave general
discussion of that to people who actually use the epslatex
terminal. 

The relevant point here is that Harald introduces
a new driver entry point to term_api
	term->set_output(char *outfile)

and in the core code he uses it as follows
	if (term->set_output)
		(term->set_output)( newfilename )
	else
		term_set_output( newfilename )

Would this approach solve the current problem with
using table.trm?  It would not fix existing scripts, but it
might be more flexible in the long run.

Harald:
	
I have some questions about your new terminal entry.

Right now it is permitted (though discouraged) to call
'set output'  before calling 'set term'.   Would we have to 
forbid this absolutely?

Would it be possible to separate the file descriptor opened
by (term->set_output) from the one opened by term_set_output?
That way a terminal with a private version of the routine
would not destroy the current setting of "set output <foo>",
which is the issue being raised by the example in vector.dem


-- 
Ethan A Merritt       merritt@u.washington.edu
Biomolecular Structure Center
Mailstop 357742
University of Washington, Seattle, WA 98195

Re: maximing/resizing multiple x11: change of palette

[Hans-Bernhard B. <br...@ph...>]

Ethan Merritt wrote:

> Is it acceptable style to call
> 	do_string( "set hidden3d default" )
> from inside reset_command()?

Uhm... no.  If hidden3d needs a reset function, it shall have one.
But I see you already did that in CVS, Ethan. ;-)

Re: problems revealed by new demos

[Petr M. <mi...@ph...>]

> > set term push
> > set term table
> > set out "equipo2.dat"
> > rep
> > set out
> > set term pop
> >
> > => it resets output!
> >
> > I don't see any easy workaround ... we will probably need new command
> > 	"save output"
> > because the output is not normally saved.

Now I think this won't help because there cannot be functionality like
"set output append <file>".


> 'set term table' could take an optional file name,
> leaving the value of "set output" unchanged.

I think that's the best solution.

--
PM

fonts in tgif and epslatex

[Ethan M. <merritt@u.washington.edu>]

I am going through the various term->set_font routines to check
for consistent behaviour.  I notice that both the tgif and epslatex
terminals claim to allow set_font, and return TRUE if you call it,
but even though they parse the requested string they do not
actually set the font.   

Is this intentional, or is it just a strange oversight shared by
both drivers?

-- 
Ethan A Merritt       merritt@u.washington.edu
Biomolecular Structure Center
Mailstop 357742
University of Washington, Seattle, WA 98195

Re: maximing/resizing multiple x11: change of palette

[Ethan M. <merritt@u.washington.edu>]

On Wednesday 29 September 2004 01:07 pm, Daniel J Sebald wrote:
> 
> That's it.  'reset' doesn't reset the "set hidden offset 0"

In fact, it doesn't reset anything to do with hidden3d.
It's a bit messy because the code that sets the default
values (hidden3d.c  set_hidden3doptions) is a command line
parsing routine.

Is it acceptable style to call
	do_string( "set hidden3d default" )
from inside reset_command()?

-- 
Ethan A Merritt       merritt@u.washington.edu
Biomolecular Structure Center
Mailstop 357742
University of Washington, Seattle, WA 98195

Re: maximing/resizing multiple x11: change of palette

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

Hans-Bernhard Broeker wrote:

> Guys, please keep in mind that hidden3d has a switch that lets you turn
> *off* the difference between front and back side line types:
>
>     set hidden offset 0
>
> So in searching for the reason of this, someone should make sure it's 
> not caused by world2.dem leaving this option in effect, and 'reset' 
> forgetting to reset it.


That's it.  'reset' doesn't reset the "set hidden offset 0"

set hidden offset 0
reset
load 'animate.dem'

duplicates the behavior.

Dan