Re: extending pstricks terminal driver

[Mojca M. <moj...@gm...>]

On Mon, Dec 8, 2008 at 6:47 PM, Ethan Merritt wrote:
> On Monday 08 December 2008 01:25:58 Juergen Wieferink wrote:
>> > > Fixing PSTricks terminal still makes sense if there are minor patches.
>> > > For the rest, I would claim that TikZ should become *the* (La)TeX
>> > > terminal of the future.
>> >
>> > As far as im in it, one of the ideas behind gnuplot is to be as portable
>> > as possible and to support a great variety of different output formats.
>> > So there will hardly ever be a discussion of favoring one format over
>> > another from the developer side. This choice is up to the user!

I only meant that since resources are limited it's better to have one
really good terminal than having ten "broken"/nonfunctional ones.
So it makes senso to put some considerable amount of time into
creating one good terminal.

Having a 'preferred' terminal should by no means prevent developers
from applying patches to other terminals and it should not prevent
users from using them.


Gnuplot currently provides the following "TeX" terminals:
            eepic  EEPIC -- extended LaTeX picture environment
            emtex  LaTeX picture environment with emTeX specials
         epslatex  LaTeX picture environment using graphicx package
            latex  LaTeX picture environment
               mf  Metafont plotting standard
               mp  MetaPost plotting standard
          pslatex  LaTeX picture environment with PostScript \specials
            pstex  plain TeX with PostScript \specials
         pstricks  LaTeX picture environment with PSTricks macros
          texdraw  LaTeX texdraw environment
             tpic  TPIC -- LaTeX picture environment with tpic \specials
plus (also TeX-friendly)
              pdf  PDF (Portable Document File) file driver
       postscript  PostScript graphics, including EPSF embedded files (*.eps)

where there is no single one that would satisfy my expectations.
PS/PDF provides no TeX labels, pslatex doesn't work with pdftex,
pstricks have serious problems working with pdftex apart from the fact
that a lot of functionality is missing, latex looks ugly and doesn't
even have color output, mp is lacking functionality, all others are
old and not maintained. How should some newbie user know which
terminal to use?

Apart from that, colors and point shapes differ between terminals.

>> I think so, too.  But nevertheless the TikZ terminal seems quite
>> promising.
>>
>> > I think you should ask Peter why he did not contact the gnuplot
>> > developer for including his terminal. Maybe its an issue with the
>> > license?! (lua terminal is under GPL license)
>>
>> Peter has kindly uploaded his terminal to the patches tracker recently:
>>
>> http://sourceforge.net/tracker/index.php?func=detail&aid=2183264&group_id=2055&atid=302055
>>
>> He writes that he has no objections in changing the license.
>
> I am afraid that I have no time to check out lua + TikZ myself,
> but I am  certainly open to adding this new driver to CVS if multiple
> people agree that it is a useful addition, and if Peter confirms that
> we can include it under the gnuplot license.
>
> Do you think it is ready for inclusion in CVS?

As far as I know it's fully functional. There's only one thing that
I'm not sure about:
    set term lua
It uses lua, but outputs tikz code. I would prefer to call the
terminal tikz or maybe set a synonym
    set term lua tikz options = set term tikz options

If terminal is called lua, nobody will figure out that it's used for
generating TeX code. On the other hand, one can plug in any code to
generate any other kind of ouput from the lua interface, so the name
"lua" for terminal does make sense.

But that's up to gnuplot developers.

I wanted to suggest some modifications to enable compatibility with
ConTeXt (terminal only works with LaTeX at the moment), but this
should not prevent the code from being added to CVS. Functionality is
not frozen right after being added to CVS, and as long as you accept
patches from the author himself, it should be fine.

> Does the ./configure script need to be modified for it (that is,
> should it try to autodetect lya and/or TikZ)?

TikZ: definitely not. Firstly: it's literally impossible to figure out
whether it is installed or not. Secondly: gnuplot should not care.
Providing the right package in TeX is the responsibility of user.

Lua: yes. One could also *include* it into gnuplot itself. The whole
source is only 0.5MB. See also:

     http://peter.affenbande.org/gnuplot/gnuplot_lua_terminal/INSTALL

Mojca