Re: extending pstricks terminal driver

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

On Thu, Dec 18, 2008 at 5:31 AM, Ethan A Merritt wrote:
> I've uploaded a patchset to SourceForge that places the current contents
> of your tarball into .../term/lua/ and .../term/,
> and modifies thethe autoconf scripts to configure and install with no
> additional intervention.

Thanks a lot.

> Comments:
>
> - ./configure currently installs gnuplot-lua-tikz.sty to
> /usr/local/share/gnuplot/<version>/ but of course TeX doesn't know to look
> for it there.  Where is the proper place to install this style file?

There is no proper place. (I have four TeX installations on my
computer and it's neary impossible to figure out where this file
belongs. Out of those 4 installations, one can install into HOME, into
texmf-local, into the main tree etc.)

My proposal to Peter was to create that file by default in every
folder where one wants to use it. It might make sense to install it
globally, but since the terminal changes over time, it might be more
safe to have a copy of the style wherever we are creating the plot,
else older plots are likely to get broken when one would use a
different sty file.

It probably makes no sense to put that file anywhere. TeX does not
find it under /usr/local/share/gnuplot and I would not find it either.
Since the terminal is able to generate that file on the fly, I would
not bother about trying to install it anywhere.

I also sent to Peter a big bunch of comments, requesting support for
ConTeXt. Once those changes are applied (there are modifications to
gnuplot.lua only), the new sty file will probably become incompatible
with the current one for example.

But this should not prevent anyone from commiting the code into CVS.
Modifying gnuplot.lua (or however it will be called - I would use some
other name as well) later is a minor issue.

> - Tested using TeXLive:
>  pdflatex works great. dvi output is still useless.

Dvi has not been created with handling colors and drawings in mind.
Some dvi viewers (like yap under MikTeX on Windows) have a great deal
of support for handling PostScript specials. DVI is still OK for plain
text, for anything else it's just an intermediate format before one
post-processes it with dvips or dvipdfm(x).

> - dvips partially works, and may be fixable. It places 90% of the plot
>  off the bottom of the page, and then clips it so you can't recover
>  even by editing the BoundingBox.

But this is not up to the terminal to solve. I suspect that you are
using TeX Live 2007. If you have a chance, try to repeat the
experiment on the same document using TikZ version 2 or later (TeX
Live 2008 for example). I would not be surprised if the result would
suddenly start working much better.

I rarely use LaTeX, so that was just a blind guess, but in any case -
as long as it works OK with pdfLaTeX and not with dvips, the only
thing that could be fixed is TikZ, not the gnuplot terminal.

> - Tested using texmf:
>  Works fine using pdflatex except that I had to hunt for a copy of
>  ifxetex.sty

It's present on newer TeX distributions, but I agree that it's almost
trivial to rewrite ifxetex.
I also suggested to modify that part of code slightly and ask about
the backend being used.

> - I have not touched the code in lua.trm, but it needs a pass to remove
>  these warnings:

(up to Peter)

> - set term lua should accept at least the following options:
>    size XX, YY    # units of inches or cm

That's already supported.

>    dashed/solid
>    color/monochrome

I agree.

>  and it needs to echo back the options string to the user to confirm it
>  was accepted

I agree.

> But that's all minor stuff, and can be fixed up after the code goes into
> cvs.

I also agree.

> What do you think - should the whole lot go into cvs more or less
> immediately?

Unless going into CVS means "no more changes allowed", I see no objection.

Mojca

(I would like to see some changes to the terminal before the official
gnuplot release, but that can all be done after inclusion into CVS.)