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