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