gnuplot-beta

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.)

Re: extending pstricks terminal driver

[Ethan A M. <merritt@u.washington.edu>]

On Thursday 18 December 2008, Mojca Miklavec wrote:

> > - ./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.)

I think multiple TeX installations are not typical.
Is there a uniform mechanism to add a directory to TeX's search path?
Instead of guessing where are the existing directories, we could
simply add our own to the list as part of the installation process.
Isn't that what the kpathsea package is for?
 
> 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.

Ugh. That's a problem.  Are you saying that if you have older and
newer plots in the same directory, they will conflict with each other?
If so, then I think we must provide a versioning mechanism:
\usepackage{gnuplot-tikz-01}
Either that, or we must be clever enough to get it right the first
time and not introduce incompatible changes later on.

> 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.

Sorry, that doesn't follow.  If you save the plots for later use with
a TeX document, you still need to have TeX able to find the appropriate
*.sty file even if gnuplot and the original lua code is no longer around.
They might be on a different machine or a different version.
 


-- 
Ethan A Merritt
Biomolecular Structure Center
University of Washington, Seattle 98195-7742

Re: extending pstricks terminal driver

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

On Thu, Dec 18, 2008 at 5:59 PM, Ethan A Merritt wrote:
> On Thursday 18 December 2008, Mojca Miklavec wrote:
>
>> > - ./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.)
>
> I think multiple TeX installations are not typical.
> Is there a uniform mechanism to add a directory to TeX's search path?

Yes. One can modify texmf.cnf on unix (or create a new file where
configuration takes precedence.
On MikTeX it's usually done with GUI.

I would not advise you to choose that way.

> Instead of guessing where are the existing directories, we could
> simply add our own to the list as part of the installation process.
> Isn't that what the kpathsea package is for?
>
>> 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.
>
> Ugh. That's a problem.  Are you saying that if you have older and
> newer plots in the same directory, they will conflict with each other?

The style file should change in some incompatible ways in the near
future if TikZ terminal would be modified to support ConTeXt. But this
would change only once.

I have no idea what plans Peter (the author) has with the terminal,
but my estimate would be that lifetime of compatible changes should be
around one or two years for example. Note that gnuplot syntax changes
as well, so one needs to adapt the scripts as well.

If one has a few ancient and a few newer plots in the same folder -
yes, it might be a problem, but one doesn't update gnuplot on a daily
basis and usually a new project goes into a new folder.

If files of all ages really need to coexist in the same folder, one
can just as well regenerate the old plots. I'll stop with phylosophy
now.

In short: in my opinion it's much better to create the style in every
folder. Not only because the style file *might* change (usually it
should not), but also because one can transfer the files and they will
still work on any computer without having gnuplot & that particular
style file installed.

> If so, then I think we must provide a versioning mechanism:
> \usepackage{gnuplot-tikz-01}
> Either that, or we must be clever enough to get it right the first
> time and not introduce incompatible changes later on.

Trying to be clever enough in the first try makes sense in either case.

>> 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.
>
> Sorry, that doesn't follow.  If you save the plots for later use with
> a TeX document, you still need to have TeX able to find the appropriate
> *.sty file even if gnuplot and the original lua code is no longer around.
> They might be on a different machine or a different version.

Yes, but I would store the sty file in the same folder as the
resulting plot. That basically only means creating two files (one for
header and one for plot) instead of a single file with header + plot.

If one installs the style file in some weird place and then reinstalls
the whole system & forgets to install that file & loses the gnuplot
binary that's a much bigger chance for problems than having two files
generated by incompatible binaries in the same folder.

You can try
   set term lua createstyle size 10cm,7cm
   set output 'sin.tex'
   plot sin(x)
and it will generate two files: the actual plot and the style file. My
idea was to "createstyle" by default.

Mojca

Re: extending pstricks terminal driver

[Ethan M. <merritt@u.washington.edu>]

On Thursday 18 December 2008 11:52:35 Mojca Miklavec wrote:

> > Ugh. That's a problem.  Are you saying that if you have older and
> > newer plots in the same directory, they will conflict with each other?
> 
> The style file should change in some incompatible ways in the near
> future if TikZ terminal would be modified to support ConTeXt. But this
> would change only once.
> 
> I have no idea what plans Peter (the author) has with the terminal,
> but my estimate would be that lifetime of compatible changes should be
> around one or two years for example. Note that gnuplot syntax changes
> as well, so one needs to adapt the scripts as well.

I have plots on my disk going back many years, used for various
publications and presentations.  If it is a *.png or *.ps file, then
it doesn't matter how old it is or how many versions of gnuplot have
come and gone since it was originally created.  But if I save a 
*.tex file, then I will need to run some TeX variant perhaps years
later in order to use it.  It is not acceptable that the associated
style file no longer works.  Note that new and old plot files may
exist in the same directory, so creating a new style file that 
over-writes the old one is a very bad thing.

> If one has a few ancient and a few newer plots in the same folder -
> yes, it might be a problem, but one doesn't update gnuplot on a daily
> basis and usually a new project goes into a new folder.

You obviously arrange your work environment in a very different fashion
than I do.  Plots associated with a multi-year project would indeed 
typically be kept together in a single place.  And I shudder at the 
thought that the results of processing a plot would depend on which
directory I am currently sitting in.

Updating gnuplot is not the issue.  I cannot always re-run gnuplot
itself easily, because the datasets I would run it on are often large
and not typically kept together with the plots and text from the analysis.
The plot itself must continue to be usable, not so much the
original gnuplot script.

> If files of all ages really need to coexist in the same folder, one
> can just as well regenerate the old plots.

Only if the raw data your are plotting are also kept in parallel.
That is not practical for many kinds of data, for reasons ranging
from file size to privacy issues to read-once data sources to
shared external data repositories.

> In short: in my opinion it's much better to create the style in every
> folder. 

I am strictly opposed to that.  If absolutely necessary, we can
(maybe?) include the style as a preamble to each document.  But 
potentially over-writing a *.sty file needed by a different plot
is very bad design.

> Not only because the style file *might* change (usually it 
> should not), but also because one can transfer the files and they will
> still work on any computer without having gnuplot & that particular
> style file installed.

???  You certainly would not have to have gnuplot itself installed
on that other computer.  And as to requiring a compatible style file,
that's always the case for latex documents.

> You can try
>    set term lua createstyle size 10cm,7cm
>    set output 'sin.tex'
>    plot sin(x)
> and it will generate two files: the actual plot and the style file. My
> idea was to "createstyle" by default.

As I tried to explain above, I think the existence of the "createstyle"
option is a design flaw.  Either the style file never changes, in which
case there is no need to keep regenerating it dynamically, or it *does*
change, in which case this option will potentially overwrite a previous
copy of the file that is necessary in its own right.

If we are to keep the "createstyle" option at all, then it needs to 
create a file that has a version number distinguishing it from all
incompatible previous versions.

I should note that this problem is not just hypothetical.
I currently struggle with this issue, in particular for BibTeX style
files.  There is, for example, a style file nar.bst in the standard
TeX repositories originally created to aid submissions to the journal
Nucleic Acids Research.  But the journal itself has changed its
requirements over the years, and so I have multiple copies of
"nar.bst" corresponding to different years of journal submission.
This would have been considerably easier to deal with if the convention
had been to name these files "nar2003.bst", "nar2005.bst", etc. 



-- 
Ethan A Merritt

Re: extending pstricks terminal driver

[Peter <pe...@af...>]

Am Donnerstag, 18. Dezember 2008 schrieb Ethan Merritt:
> On Thursday 18 December 2008 11:52:35 Mojca Miklavec wrote:
> > > Ugh. That's a problem.  Are you saying that if you have older and
> > > newer plots in the same directory, they will conflict with each other?
> >
> > The style file should change in some incompatible ways in the near
> > future if TikZ terminal would be modified to support ConTeXt. But this
> > would change only once.
> >
> > I have no idea what plans Peter (the author) has with the terminal,
> > but my estimate would be that lifetime of compatible changes should be
> > around one or two years for example. Note that gnuplot syntax changes
> > as well, so one needs to adapt the scripts as well.
>
> I have plots on my disk going back many years, used for various
> publications and presentations.  If it is a *.png or *.ps file, then
> it doesn't matter how old it is or how many versions of gnuplot have
> come and gone since it was originally created.  But if I save a
> *.tex file, then I will need to run some TeX variant perhaps years
> later in order to use it.  It is not acceptable that the associated
> style file no longer works.  Note that new and old plot files may
> exist in the same directory, so creating a new style file that
> over-writes the old one is a very bad thing.

I would also prefer a single style file at a central place. The "interface" 
between the Lua script (respectively the generated TeX code) and the style 
file should be quite stable once the changes for the other TeX flavors are 
in. As far as there are no major changes in TikZ there will be mainly 
additions, that should not interfere with plots that were generated before 
(thinking of e.g. the do_arc function).


> > If one has a few ancient and a few newer plots in the same folder -
> > yes, it might be a problem, but one doesn't update gnuplot on a daily
> > basis and usually a new project goes into a new folder.
>
> You obviously arrange your work environment in a very different fashion
> than I do.  Plots associated with a multi-year project would indeed
> typically be kept together in a single place.  And I shudder at the
> thought that the results of processing a plot would depend on which
> directory I am currently sitting in.
>
> Updating gnuplot is not the issue.  I cannot always re-run gnuplot
> itself easily, because the datasets I would run it on are often large
> and not typically kept together with the plots and text from the analysis.
> The plot itself must continue to be usable, not so much the
> original gnuplot script.
>
> > If files of all ages really need to coexist in the same folder, one
> > can just as well regenerate the old plots.
>
> Only if the raw data your are plotting are also kept in parallel.
> That is not practical for many kinds of data, for reasons ranging
> from file size to privacy issues to read-once data sources to
> shared external data repositories.
>
> > In short: in my opinion it's much better to create the style in every
> > folder.
>
> I am strictly opposed to that.  If absolutely necessary, we can
> (maybe?) include the style as a preamble to each document.  But
> potentially over-writing a *.sty file needed by a different plot
> is very bad design.
>
> > Not only because the style file *might* change (usually it
> > should not), but also because one can transfer the files and they will
> > still work on any computer without having gnuplot & that particular
> > style file installed.
>
> ???  You certainly would not have to have gnuplot itself installed
> on that other computer.  And as to requiring a compatible style file,
> that's always the case for latex documents.
>
> > You can try
> >    set term lua createstyle size 10cm,7cm
> >    set output 'sin.tex'
> >    plot sin(x)
> > and it will generate two files: the actual plot and the style file. My
> > idea was to "createstyle" by default.
>
> As I tried to explain above, I think the existence of the "createstyle"
> option is a design flaw.  Either the style file never changes, in which
> case there is no need to keep regenerating it dynamically, or it *does*
> change, in which case this option will potentially overwrite a previous
> copy of the file that is necessary in its own right.
>
> If we are to keep the "createstyle" option at all, then it needs to
> create a file that has a version number distinguishing it from all
> incompatible previous versions.

The "createstyle" option was meant as a convenient way to create the file from 
the gnuplot console. I never intended to use this as a default. But maybe it 
is of use for someone, who knows what he/she is doing? The script could also 
check If there already exists a style file in the current directory and only 
generate one on demand. This way even local changes could be made without 
worrying to overwrite them accidently.


> I should note that this problem is not just hypothetical.
> I currently struggle with this issue, in particular for BibTeX style
> files.  There is, for example, a style file nar.bst in the standard
> TeX repositories originally created to aid submissions to the journal
> Nucleic Acids Research.  But the journal itself has changed its
> requirements over the years, and so I have multiple copies of
> "nar.bst" corresponding to different years of journal submission.
> This would have been considerably easier to deal with if the convention
> had been to name these files "nar2003.bst", "nar2005.bst", etc.

IMHO if we have to change it in an incompatible way at some point we can still 
change the naming scheme then.

-Peter