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