|
From: Petr M. <mi...@ph...> - 2004-10-01 07:00:35
|
> > > '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 |