gnuplot-beta — Developers and beta testers of new gnuplot code

Re: corner case?

[Allin C. <cot...@wf...>]

On Mon, 22 Dec 2008, Ethan A Merritt wrote:

> On Monday 22 December 2008, Allin Cottrell wrote:
> > Plotting the following wacky dataset (from a test for statistical
> > programs by Leland Wilkinson)...
> >
> > obs  y          x
> >
> > 1    99999991   0.99999991
> > 2    99999992   0.99999992 <etc>
> >
> > gnuplot does fine, except that it puts "1" for each of 11 x-axis
> > tics, and "1e+08" for each of 6 y-axis tics, which looks a little
> > brain-damaged...
> >
> > Any thoughts on whether it's worth working on making the tics look
> > better by default for this sort of case?
>
> There's already a feature request open for this issue:
>   2007285  	  Auto-expand number of digits for tics with small axis range
>
> But it's a surprisingly hard thing to fix.
> Patches welcome.

I've taken a look in axis.c, but I don't yet have a good
understanding of the machinery therein.  But I've found that this
heuristic hack seems to work quite nicely at the caller level and
something of the sort could perhaps be written into axis.c:

1. Write the min and max data values into strings using the
default precision for tic labels.  If these strings are identical,
then compute the minimal precision required to make them differ,
add one, and write this into the <axis> format using "%% .%dg".

To get the required precision I'm doing something like:

    for (d=6; d<12; d++) {
        sprintf(s1, "%.*g", d, vmin);
        sprintf(s2, "%.*g", d, vmax);
        if (strcmp(s1, s2)) {
            break;
        }
    }

2. Set the axis tics using start = (the min data value) and incr =
(max data value - min data value) / 4.0.

E.g., for the x-axis with the data I mentioned:

 set format x "% .8g"
 set xtics 0.99999991 2.00000e-08

Merry Christmas!

Allin Cottrell

Re: Tweak for interactive SVGs?

[<pl...@pi...>]

Ethan A Merritt wrote:

> In pretty much all cases that I generate SVG plots, it is for display on
> dynamically generated pages that contain multiple plots.  Again I don't
> know that much about it, but it would seem to me that you would need a
> single copy of the script that serves the entire page, and mousing into
> the box of any individual plot just triggers a new mouse_coord->plot_coord
> transformation matrix.  I don't know if you can have multiple copies of
> the same script on the same page, separated by the scope of the 
> <svg> tags.  But maybe you can.
> 

js can be added either externally or within each <svg> tag pair.

<script type="text/ecmascript" xlink:href="scripts/gnuplot.js" />
<script type="text/ecmascript"><![CDATA[
...
]]></script>

I would favour each svg object being complete and autonomous.
Outsourcing the scripts should be regarded as (possibly) an optimisation.


As for the coordinate display, I've given this some thought and I think
there are significant obstacles to using mouse event coords and a matrix.

The main issue being how to detect zoom level in the viewer and also
scrolling of an svg that is bigger than the viewer window. (I often zoom
to max available to examine detail, after all, that is one of the
biggest advantages of using scalar graphics).

I think we would need some coordinate info in the svg output.

I'm thinking of trying:

Each line of a grid could have an onmouseover method called with it's x
or y coord , thus once the mouse has passed at least two x and two y
grid lines the current view is calibrated and your matrix upto date.
This way, current mouse coords could be kept upto date and used in
mousehover to display coords in a bubble (or in status bar of browser?).
It would mean a lot of calls to the mouseover event but there would be
little processing in it and at the time where the user is waving his
mouse around, the system is probably not doing much work in displaying
the svg anyway. This is probably acceptable.

This could potentially leave a period after a zoom or scroll where the
coord transform is out of date but it would basically work. It seems
reasonable to assume that if the user is looking for coord display he
will be moving the mouse around the plot. The calibration grid would
have to be detailed enough to minimise the dead time.

I don't think this would be the actual plot grid as it is now. It may be
better to add a second invisible grid with suitable intervals when this
sort of interactive output is requested. Since the paths would be
straight lines with two end points, this could be done with minimal
overhead in file size.

I think that outlines an implementation method as far as svg markup is
concerned.

regards, Peter.

Re: Some misprints and problems

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

On Wed, Dec 24, 2008 at 11:36 AM, Shigeharu TAKENO wrote:
> shige 12/24 2008
> ----------------
>
> I found some points that seem to be problems and misprints in CVS
> version.
>
> 1) problems for new Lua terminal.
>
> [b] I think the help document inlcuded in term/lua/gnuplot.lua
>  (at pgf.print_help) should also be included in term/lua.trm.

I'm not entirely sure, but I guess that the terminal code should be
able to output the contents of term/lua/gnuplot.lua. When one says
"help term lua" it returns some help of little use for someone who
wants to use the TikZ terminal.

help term tikzlua (or whatever the terminal would be called) should
return full help for tikz terminal. I'm almost sure that this is
possible with properly implemented functions in lua.

Mojca

Some misprints and problems

[Shigeharu T. <sh...@ie...>]

shige 12/24 2008
----------------

I found some points that seem to be problems and misprints in CVS
version. 

1) problems for new Lua terminal.

[a] The definition of CORETERM in docs/Makefile.in lacks the 
  entry of lua terminal.
[b] I think the help document inlcuded in term/lua/gnuplot.lua 
  (at pgf.print_help) should also be included in term/lua.trm.
[c] The help document in term/lua.trm uses the C macro 
  "LUA_SCRIPT" defined as "gnuplot.lua" at the top of the file. 
  But, it may not replace when making allterm.h which is used 
  docs/doc2tex.

2) misprints (docs/gnuplot.doc rev.1.551)

----- From here -----
--- gnuplot.doc.org	2008-12-24 19:03:52.000000000 +0900
+++ gnuplot.doc	2008-12-24 19:16:40.000000000 +0900
@@ -256,9 +256,10 @@
 3 New plot elements
 =circles
 =ellipse
+=polygon
  The `set object` command can now be used to define fixed circles, ellipses, and
  polygons as well as rectangles. There is a corresponding new plot style
- `plot with circles`.  See `circles` `ellipse`.
+ `plot with circles`.  See `circle` `ellipse` `polygon`.
 
 3 New or revised terminal drivers
  Two new drivers based on the cairo and pango libraries are included,
@@ -4661,7 +4662,7 @@
  For each point in the file, the index value of the data set it appears in is
  available via the pseudo-column `column(-2)`.  This leads to an alternative way
  of distinguishing individual data sets within a file as shown below.  This is
- more awkward that the `index` command if all you are doing is selecting one
+ more awkward than the `index` command if all you are doing is selecting one
  data set for plotting, but is very useful if you want to assign different
  properties to each data set.  See `pseudocolumns`, `lc variable`.
 
@@ -5100,7 +5101,7 @@
 ^ <a href="http://www.gnuplot.info/demo/using.html">
  Feeble using demos.
 ^ </a>
-5 pseuodocolumns
+5 pseudocolumns
 ?pseudocolumns
 ?commands plot datafile using pseudocolumns
 ?plot datafile using pseudocolumns
@@ -7300,7 +7301,7 @@
 #\verb@%A@ & full name of day of the week \\
 #\verb@%b@ or \verb@%h@ & abbreviated name of the month \\
 #\verb@%B@ & full name of the month \\
-#\verb@%d@ & day of the month, 1--31 \\
+#\verb@%d@ & day of the month, 01--31 \\
 #\verb@%D@ & shorthand for \verb@"%m/%d/%y"@ (only output) \\
 #\verb@%F@ & shorthand for \verb@"%Y-%m-%d"@ (only output) \\
 #\verb@%k@ & hour, 0--23 (one or two digits)\\
@@ -7308,7 +7309,7 @@
 #\verb@%l@ & hour, 1--12  (one or two digits)\\
 #\verb@%I@ & hour, 01--12 (always two digits)\\
 #\verb@%j@ & day of the year, 1--366 \\
-#\verb@%m@ & month, 1--12 \\
+#\verb@%m@ & month, 01--12 \\
 #\verb@%M@ & minute, 0--60 \\
 #\verb@%p@ & "am" or "pm" \\
 #\verb@%r@ & shorthand for \verb@"%I:%M:%S %p"@ (only output)\\
@@ -7327,7 +7328,7 @@
 %%A@full name of day of the week
 %%b or %h@abbreviated name of the month
 %%B@full name of the month
-%%d@day of the month, 1--31
+%%d@day of the month, 01--31
 %%D@shorthand for "%m/%d/%y" (only output)
 %%F@shorthand for "%Y-%m-%d" (only output)
 %%k@hour, 0--23 (one or two digits)
@@ -7335,7 +7336,7 @@
 %%l@hour, 1--12 (one or two digits)
 %%I@hour, 01--12 (always two digits)
 %%j@day of the year, 1--366
-%%m@month, 1--12
+%%m@month, 01--12
 %%M@minute, 0--60
 %%p@"am" or "pm"
 %%r@shorthand for "%I:%M:%S %p" (only output)
@@ -8612,7 +8613,7 @@
  or
          from <position> rto <position> ... {rto <position>}
 
- The position of the rectangle may be specified by giving the position of a
+ The position of the polygon may be specified by giving the position of a
  sequence of vertices. These may be given in axis, graph, or screen coordinates.
  If relative coordinates are used (rto) then the coordinate type must match
  that of the previous vertex.
@@ -10379,9 +10380,9 @@
 
  The first sets all the four default values.  The second changes only scale,
  to 0.5.
-4 equal_axes
-?set view equal_axes
-?view equal_axes
+4 equal
+?set view equal
+?view equal
  The command `set view equal xy` forces the unit length of the x and y axes
  to be on the same scale, and chooses that scale so that the plot will fit on
  the page.  The command `set view equal xyz` additionally sets the z axis 
----- To here -----

+========================================================+
 Shigeharu TAKENO     NIigata Institute of Technology
                       kashiwazaki,Niigata 945-1195 JAPAN
 sh...@ie...   TEL(&FAX): +81-257-22-8161
+========================================================+

Patch for makefile.mgw using gdlib-config

[Tatsuro M. <tma...@ya...>]

Hello

The current gd (gd-2.0.36RC1) has gdlib-config, which enable us to get information for configuration
of the gd libraries and tools.  Therefore it is better to use it for makefile,mgw.
Perhaps similar modification can be made for makefile.cyg.

Please consider a patch at the end of this mail.

Regards

Tatsuro

*************
http://www.nabble.com/gd.trm-issue-for-mingw-gcc-4.3.0-building-to20755231.html
- Tatsuro MATSUOKA-5 Dec 20, 2008; 04:19pm 
Hello 

After I have looked around the Gd libraries (gd-2.0.36RC1 build by mingw) in detail, I have found the 
'gdlib-config' shell script. 

  :
  :
*******************
*** makefile.mgw.orig	Sat Nov 29 06:10:28 2008
--- makefile.mgw	Tue Dec 23 16:16:25 2008
***************
*** 208,219 ****
    CFLAGS += -DHAVE_GD_GIF -DGIF_ANIMATION -DHAVE_GD_PNG
  ifdef JPEG
    CFLAGS += -DHAVE_GD_JPEG
-   TERMLIBS += -ljpeg
  endif
  ifdef FREETYPE
    CFLAGS += -DHAVE_GD_TTF
-   TERMLIBS += -lfreetype
  endif
  endif
  
  ifdef PDF
--- 208,218 ----
    CFLAGS += -DHAVE_GD_GIF -DGIF_ANIMATION -DHAVE_GD_PNG
  ifdef JPEG
    CFLAGS += -DHAVE_GD_JPEG
  endif
  ifdef FREETYPE
    CFLAGS += -DHAVE_GD_TTF
  endif
+   TERMLIBS += $(shell gdlib-config --libs)
  endif
  
  ifdef PDF




--------------------------------------
Power up the Internet with Yahoo! Toolbar.
http://pr.mail.yahoo.co.jp/toolbar/

Re: TikZ terminal

[Juergen W. <wie...@fr...>]

Am Dienstag, 23. Dezember 2008 schrieb Mojca Miklavec:
> Hello,
>
> here are a few suggestions for the new TikZ terminal:
>
> 1.) I would rename gnuplot.lua into tikz.lua or gnuplot-tikz.lua. The
> terminal lua is generic, but gnuplot.lua is TikZ-specific.
>
> 2.) I would require calling
>    set term tikz
> or
>    set term lua tikz
> and not
>    set term lua
>
> Lua is a generic driver and would not tell anything to the user that
> wants to plot something in TeX.
>
> If one writes metapost.lua then one could for example call
>     set term lua metapost
> to invoke that file.

Full ACK.  Maybe "set term lua xxx" can search for the file
"gnuplot-xxx.lua" in some search path including the current
directory and the libexec directory.


> 4.) Help should also be returned via
>    help term tikz
>
> Now set term lua help returns something useful, but help term tikz
> should be more informative as well.

True.  Though this probably is more tricky.

> 5.) Maybe there could be
>    gnuplot.lua
> that has a list of available terminals, for example a list containing
> "tikz" terminal with both terminal name and filename that needs to be
> included to make that terminal work properly.

Can this be built automatically by a search for all available
gnuplot-*.lua files?


Juergen

Re: corner case?

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

On Monday 22 December 2008, Allin Cottrell wrote:
> Plotting the following wacky dataset (from a test for statistical
> programs by Leland Wilkinson)...
> 
> obs  y          x
> 
> 1    99999991   0.99999991
> 2    99999992   0.99999992
> 3    99999993   0.99999993
> 4    99999994   0.99999994
> 5    99999995   0.99999995
> 6    99999996   0.99999996
> 7    99999997   0.99999997
> 8    99999998   0.99999998
> 9    99999999   0.99999999
> 
> gnuplot does fine, except that it puts "1" for each of 11 x-axis
> tics, and "1e+08" for each of 6 y-axis tics, which looks a little
> brain-damaged.
> 
> The tic marks can, of course, be improved manually, but it's a bit
> of a sweat, particularly since the C'ism '#' does not seem to be
> recognized in format strings (I mean, as in "%#.8g").
> 
> Any thoughts on whether it's worth working on making the tics look
> better by default for this sort of case?

There's already a feature request open for this issue:
  2007285  	  Auto-expand number of digits for tics with small axis range

But it's a surprisingly hard thing to fix.
Patches welcome.

 



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

corner case?

[Allin C. <cot...@wf...>]

Plotting the following wacky dataset (from a test for statistical
programs by Leland Wilkinson)...

obs  y          x

1    99999991   0.99999991
2    99999992   0.99999992
3    99999993   0.99999993
4    99999994   0.99999994
5    99999995   0.99999995
6    99999996   0.99999996
7    99999997   0.99999997
8    99999998   0.99999998
9    99999999   0.99999999

gnuplot does fine, except that it puts "1" for each of 11 x-axis
tics, and "1e+08" for each of 6 y-axis tics, which looks a little
brain-damaged.

The tic marks can, of course, be improved manually, but it's a bit
of a sweat, particularly since the C'ism '#' does not seem to be
recognized in format strings (I mean, as in "%#.8g").

Any thoughts on whether it's worth working on making the tics look
better by default for this sort of case?

-- 
Allin Cottrell
Department of Economics
Wake Forest University

Re: TikZ terminal

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

On Tue, Dec 23, 2008 at 12:53 AM, Ethan A Merritt wrote:
> On Monday 22 December 2008, Mojca Miklavec wrote:
>> Hello,
>>
>> here are a few suggestions for the new TikZ terminal:
>>
>> 1.) I would rename gnuplot.lua into tikz.lua or gnuplot-tikz.lua. The
>> terminal lua is generic, but gnuplot.lua is TikZ-specific.
>>
>> 2.) I would require calling
>>    set term tikz
>> or
>>    set term lua tikz
>> and not
>>    set term lua
>>
>> Lua is a generic driver and would not tell anything to the user that
>> wants to plot something in TeX.
>
> How about using a scheme similar to the cairo-based terminals
> pdfcairo and pngcairo.  The current terminal would have the full name
> tikzlua, and the short form "tikz" would work

This sounds reasonable. Well - that's the design decision of gnuplot
team anyway :)

> unless/until someone
> writes a pure tikz terminal that doesn't use lua (just as the old
> pdf and png terminals don't use cairo).

(One could of course write a pure TikZ terminal producing exactly the
same output. That would be a tiny plus for compatibility, but quite
some time investment.)

Mojca

Re: TikZ terminal

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

On Monday 22 December 2008, Mojca Miklavec wrote:
> Hello,
> 
> here are a few suggestions for the new TikZ terminal:
> 
> 1.) I would rename gnuplot.lua into tikz.lua or gnuplot-tikz.lua. The
> terminal lua is generic, but gnuplot.lua is TikZ-specific.
> 
> 2.) I would require calling
>    set term tikz
> or
>    set term lua tikz
> and not
>    set term lua
> 
> Lua is a generic driver and would not tell anything to the user that
> wants to plot something in TeX.

How about using a scheme similar to the cairo-based terminals
pdfcairo and pngcairo.  The current terminal would have the full name
tikzlua, and the short form "tikz" would work unless/until someone 
writes a pure tikz terminal that doesn't use lua (just as the old
pdf and png terminals don't use cairo).



> If one writes metapost.lua then one could for example call
>     set term lua metapost
> to invoke that file.
> 
> 3.) I agree that the terminal should return a list of values chosen
> for the terminal
> 
> 4.) Help should also be returned via
>    help term tikz
> 
> Now set term lua help returns something useful, but help term tikz
> should be more informative as well.
> 
> 5.) Maybe there could be
>    gnuplot.lua
> that has a list of available terminals, for example a list containing
> "tikz" terminal with both terminal name and filename that needs to be
> included to make that terminal work properly.
> 
> Mojca (with more comments to come)
> 
> ------------------------------------------------------------------------------
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
> 



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

TikZ terminal

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

Hello,

here are a few suggestions for the new TikZ terminal:

1.) I would rename gnuplot.lua into tikz.lua or gnuplot-tikz.lua. The
terminal lua is generic, but gnuplot.lua is TikZ-specific.

2.) I would require calling
   set term tikz
or
   set term lua tikz
and not
   set term lua

Lua is a generic driver and would not tell anything to the user that
wants to plot something in TeX.

If one writes metapost.lua then one could for example call
    set term lua metapost
to invoke that file.

3.) I agree that the terminal should return a list of values chosen
for the terminal

4.) Help should also be returned via
   help term tikz

Now set term lua help returns something useful, but help term tikz
should be more informative as well.

5.) Maybe there could be
   gnuplot.lua
that has a list of available terminals, for example a list containing
"tikz" terminal with both terminal name and filename that needs to be
included to make that terminal work properly.

Mojca (with more comments to come)

Re: Tweak for interactive SVGs?

[<pl...@pi...>]

Ethan A Merritt wrote:

>> Hi Ethan,
>>
>> maybe I'm missing the point but can't the javascript be included in the
>> SVG xml? I don't see it as desirable solution to wait for a response
>> from sourceforge before my plot can fully render, nor that I need an
>> open internet connection to diplay a local file.
> 
> I know very little about mixing javascript and svg, so I can't answer
> that question.  But the shared URL could still be a local file.

I'll try to find time to look into that a bit over the new year. If you
can link to an external script I dont see why it can't be within the
file itself.

> 
>> Externalising what could potentially be common and invariant code may be
>> an option but I would have thought the first aim should be a self
>> contained svg file.
> 
> In pretty much all cases that I generate SVG plots, it is for display on
> dynamically generated pages that contain multiple plots.  Again I don't
> know that much about it, but it would seem to me that you would need a
> single copy of the script that serves the entire page, and mousing into
> the box of any individual plot just triggers a new mouse_coord->plot_coord
> transformation matrix.  I don't know if you can have multiple copies of
> the same script on the same page, separated by the scope of the 
> <svg> tags.  But maybe you can.
> 

I have not tried to do this in detail but I envisage a <script> tag
defining the function called from an onclick or onhover event on
elements on the graph. This may be possible on the <svg> itself.

Bill's plot toggle seems to establish the principal of how to do that.

In the mean time it would be good to start defining what functionality
to add and how to integrate this into gnuplot command structure.

I would strongly recommend a well thought out and extensible structure
because the possibilities that this kind of technique opens up are vast.
It should be anticipated from the outset that this will develop over
time to be a very full featured extension quite likely with the need to
user definable elements.

Maybe a starting point would be to see how to add Bill's toggle and the
coord display features to the command structure.

I only have a user's understanding of the command syntax so I'll let
others consider that one.

regards, Peter.

Re: Tweak for interactive SVGs?

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

On Sunday 21 December 2008, pl...@pi... wrote:
> Ethan A Merritt wrote:
> > On Sunday 21 December 2008, pl...@pi... wrote:
> >> I have had another think about adding functionality to svg terminal.
> >> Today I realised that in using my gnuplot output to study system
> >> performance I am constantly needing to read x,y values off the graph.
> >> This currently means zooming to a large magnification, placing the mouse
> >> cursor and then scrolling with arrow keys and praying that it falls near
> >> enought to the axis to read the minor ticks near the cursor.
> >>
> >> In short rather unsatisfactory and hacky.
> >>
> >> What I need is something like the wxt terminal cursor output.
> >>
> >> How feasible would it be to add an onhover or onclick event  and grab
> >> the event x,y and display plot related x,y values?
> > 
> > It should be feasible.  I have been trying to drum up enthusiasm for this,
> > and find a volunteer to code it.
> > 
> >> That sounds like it would be fraught with browser compatibility issues.
> > 
> > To some extent. But there are working example of cross-platform code that
> > uses javascript to do mouse-tracking.  Here is one:
> >    http://dunnbypaul.net/js_mouse/
> > 
> > As I see it, we need to put the following in place:
> > 
> >  - create a jscript/ECMScript/javascript/whatever mouse-tracker, which
> >    can be loaded from either the user's own web site or from some 
> >    central place like the gnuplot pages on SourceForge.  It should
> >    read the current mouse coords, apply a transformation matrix (see next)
> >    and print the transformed coordinates on the page, similar to the 
> >    current interactive terminals.
> 
> Hi Ethan,
> 
> maybe I'm missing the point but can't the javascript be included in the
> SVG xml? I don't see it as desirable solution to wait for a response
> from sourceforge before my plot can fully render, nor that I need an
> open internet connection to diplay a local file.

I know very little about mixing javascript and svg, so I can't answer
that question.  But the shared URL could still be a local file.

> Externalising what could potentially be common and invariant code may be
> an option but I would have thought the first aim should be a self
> contained svg file.

In pretty much all cases that I generate SVG plots, it is for display on
dynamically generated pages that contain multiple plots.  Again I don't
know that much about it, but it would seem to me that you would need a
single copy of the script that serves the entire page, and mousing into
the box of any individual plot just triggers a new mouse_coord->plot_coord
transformation matrix.  I don't know if you can have multiple copies of
the same script on the same page, separated by the scope of the 
<svg> tags.  But maybe you can.

-- 
Ethan A Merritt

Re: Tweak for interactive SVGs?

[<pl...@pi...>]

Ethan A Merritt wrote:
> On Sunday 21 December 2008, pl...@pi... wrote:
>> I have had another think about adding functionality to svg terminal.
>> Today I realised that in using my gnuplot output to study system
>> performance I am constantly needing to read x,y values off the graph.
>> This currently means zooming to a large magnification, placing the mouse
>> cursor and then scrolling with arrow keys and praying that it falls near
>> enought to the axis to read the minor ticks near the cursor.
>>
>> In short rather unsatisfactory and hacky.
>>
>> What I need is something like the wxt terminal cursor output.
>>
>> How feasible would it be to add an onhover or onclick event  and grab
>> the event x,y and display plot related x,y values?
> 
> It should be feasible.  I have been trying to drum up enthusiasm for this,
> and find a volunteer to code it.
> 
>> That sounds like it would be fraught with browser compatibility issues.
> 
> To some extent. But there are working example of cross-platform code that
> uses javascript to do mouse-tracking.  Here is one:
>    http://dunnbypaul.net/js_mouse/
> 
> As I see it, we need to put the following in place:
> 
>  - create a jscript/ECMScript/javascript/whatever mouse-tracker, which
>    can be loaded from either the user's own web site or from some 
>    central place like the gnuplot pages on SourceForge.  It should
>    read the current mouse coords, apply a transformation matrix (see next)
>    and print the transformed coordinates on the page, similar to the 
>    current interactive terminals.

Hi Ethan,

maybe I'm missing the point but can't the javascript be included in the
SVG xml? I don't see it as desirable solution to wait for a response
from sourceforge before my plot can fully render, nor that I need an
open internet connection to diplay a local file.

Externalising what could potentially be common and invariant code may be
an option but I would have thought the first aim should be a self
contained svg file.

regards, Peter.

> 
>  - have the svg driver emit code that refers to the script by its URL,
>    and initializes the coordinate system to correspond to the one in
>    the current plot by providing an appropriate transformation matrix.
> 
> There may be other ways to do it.  I am intrigued by the "canvas terminal
> driver" uploaded to SourceForge as patch   #2056054
> 
> 

Re: Tweak for interactive SVGs?

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

On Sunday 21 December 2008, pl...@pi... wrote:
>
> I have had another think about adding functionality to svg terminal.
> Today I realised that in using my gnuplot output to study system
> performance I am constantly needing to read x,y values off the graph.
> This currently means zooming to a large magnification, placing the mouse
> cursor and then scrolling with arrow keys and praying that it falls near
> enought to the axis to read the minor ticks near the cursor.
> 
> In short rather unsatisfactory and hacky.
> 
> What I need is something like the wxt terminal cursor output.
> 
> How feasible would it be to add an onhover or onclick event  and grab
> the event x,y and display plot related x,y values?

It should be feasible.  I have been trying to drum up enthusiasm for this,
and find a volunteer to code it.

> That sounds like it would be fraught with browser compatibility issues.

To some extent. But there are working example of cross-platform code that
uses javascript to do mouse-tracking.  Here is one:
   http://dunnbypaul.net/js_mouse/

As I see it, we need to put the following in place:

 - create a jscript/ECMScript/javascript/whatever mouse-tracker, which
   can be loaded from either the user's own web site or from some 
   central place like the gnuplot pages on SourceForge.  It should
   read the current mouse coords, apply a transformation matrix (see next)
   and print the transformed coordinates on the page, similar to the 
   current interactive terminals.

 - have the svg driver emit code that refers to the script by its URL,
   and initializes the coordinate system to correspond to the one in
   the current plot by providing an appropriate transformation matrix.

There may be other ways to do it.  I am intrigued by the "canvas terminal
driver" uploaded to SourceForge as patch   #2056054


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

Re: Tweak for interactive SVGs?

[<pl...@pi...>]

Ethan A Merritt wrote:
> On Sunday 14 December 2008, Bill Broadley wrote:
>> I've been generating some plots that get a bit busy, sometimes it's nice to be
>> able to toggle what you see.  So I wrote a script to tweak the gnuplot output,
>> and it generates:
>>          http://cse.ucdavis.edu/bill/barc.svg
>>
>> Try clicking on any of key titles like "1-thread add".  Currently it's a short
>> perl script.  The changes are just things like adding a
>> onclick=ToggleVisibilty call for each key text entry, adding a id= group for
>> each line in the graph, and of course the small routine to actually toggle the
>> visibility.
>>
>> Any comments on how hard it would be to add to the gnuplot SVG output routine?
>> How useful? 
>> Would a reasonably written patch to do this be accepted?
> 
> That's very nice.
> 
> Please have a look at the patchset  #2172587  "Embedded hyperlinks"
> https://sourceforge.net/tracker/index.php?func=detail&aid=2172587&group_id=2055&atid=302055
> 
> That patchset contains an extension to the svg terminal driver that does
> something parallel to your idea. It wraps each plot (and key entry) in
> a group with an attached xlink hyperref.   
> 
> It may be that you could re-use much of that code.
> It may also be that you can see a cleaner way to do it, or better yet
> propose an extension that handles both uses via the same mechanism.
> 
> As to the associated routine that does the toggling, here also I would 
> very much encourage brainstorming about how this could be made as 
> general as possible. My long-term vision for the svg terminal
> (a goal that I keep trying to hand off to someone else :-)
> is to  provide all the necessary infrastructure for a set of associated
> scripts to carry out client-side mousing operations like the existing
> interactive terminals.  I had been thinking mostly of mouse-tracking and
> zoom, but your example makes me realize that other operations like 
> toggling the grid or ruler bars are even easier.
> 

Hi,

I have had another think about adding functionality to svg terminal.
Today I realised that in using my gnuplot output to study system
performance I am constantly needing to read x,y values off the graph.
This currently means zooming to a large magnification, placing the mouse
cursor and then scrolling with arrow keys and praying that it falls near
enought to the axis to read the minor ticks near the cursor.

In short rather unsatisfactory and hacky.

What I need is something like the wxt terminal cursor output.

How feasible would it be to add an onhover or onclick event  and grab
the event x,y and display plot related x,y values? That sounds like it
would be fraught with browser compatibility issues.

Is there a more suitable means of picking up the plot coords of a click?

Thanks, Peter.

gnuplot 4.3 (cvs) winodws binaries prepared by gcc-4.3.0 is uploaded. (ChangeLog Date 2008-12-17)

[Tatsuro M. <tma...@ya...>]

Hello

I have prepared gnuplot 4.3 (cvs) for windows binaries prepared by gcc-4.3.0-dw2 with -O3 optimizing
option for higher performance
(latest ChangeLog date: 2008-12-17)

http://www.tatsuromatsuoka.com/gnuplot/Eng/winbin/

Regards

Tatsuro



--------------------------------------
Power up the Internet with Yahoo! Toolbar.
http://pr.mail.yahoo.co.jp/toolbar/

gnuplot 4.3 (cvs) cygwin binaries prepared by gcc-4.x.x is updated. (ChangeLog Date 2008-12-17)

[Tatsuro M. <tma...@ya...>]

 Hello

gnuplot 4.3 (cvs) cygwin binaries prepared by gcc-4.x.x is updated.
(latest ChangeLog date: 2008-11-27)

http://www.tatsuromatsuoka.com/gnuplot/Eng/cygbin/

Regards

Tatsuro

--------------------------------------
Power up the Internet with Yahoo! Toolbar.
http://pr.mail.yahoo.co.jp/toolbar/

Re: gd.trm issue for mingw-gcc-4.3.0 building

[Tatsuro M. <tma...@ya...>]

Hello 

After I have looked around the Gd libraries (gd-2.0.36RC1 build by mingw) in detail, I have found the 
'gdlib-config' shell script.

I think that it is better to determine flags using gdlib-config like in the WXT case: 

ifdef WXT
	CFLAGS += -DWXWIDGETS
	CXXFLAGS += $(shell wx-config --cxxflags)
	CAIRO_CFLAGS = $(shell pkg-config --cflags cairo)
	CAIRO_LIBS = $(shell pkg-config --libs cairo)
	PANGO_CFLAGS = $(shell pkg-config --cflags pangocairo)
	PANGO_LIBS = $(shell pkg-config --libs pangocairo)
	WX_LIBS = $(shell wx-config --libs)
	WX_OBJS = wxt_gui.o gp_cairo.o
endif

I would like to consider the patch using 'gdlib-config'

Regards

Tatsuro

snapshot of gdlib-config
*********************************
$ gdlib-config
Print information on GD library's version, configuration, and use.
Usage: gdlib-config [options]
Options:
        --libdir          # directory where GD library is installed
        --includedir      # directory where GD library headers are installed
        --version         # complete GD library version string
        --majorversion    # GD library major version number
        --minorversion    # GD library minor version number
        --revision        # GD library revision version number
        --ldflags         # options required for linking against GD library
        --libs            # libs required for linking against GD library
        --cflags          # options required for compiling GD library apps
        --includes        # same as --cflags
        --features        # lists optional features compiled into gd, separated
                          # by spaces. Currently (as of 2.0.26) the optional
                          # features are GD_PNG, GD_JPEG, GD_XPM, and
                          # GD_FREETYPE. When these features are reported by
                          # --features, it is safe to include calls to the
                          # related functions in your code.
        --all             # print a summary of all GD library configure options

$ gdlib-config --libs
-ljpeg -lfontconfig -lfreetype -lpng12 -lz /GnuWin32/lib/libiconv.dll.a -Wl,-rpath -Wl,/GnuWin32/lib
 **************************************

--- Tatsuro MATSUOKA <tma...@ya...> wrote:

> Hello
> 
> The patch in the previous includes a few errors.
> So I am sending the revised one
> 
> Regards
> 
> Tatsuro
> 
> *** makefile.mgw.orig	Tue Nov 25 16:46:59 2008
> --- makefile.mgw	Fri Dec 19 09:40:47 2008
> ***************
> *** 47,56 ****
>   # If libgd has been compiled with TrueType font support, then you can use
>   # scaled TrueType fonts. If not, then uncomment FREETYPE.
>   # Requires GD, PNG and Z libraries, optionally libfreetype.
> ! #
>   NEWGD=1
>   JPEG=1
>   FREETYPE=1
>   
>   # PDF device driver
>   # Requires PNG and Z libraries based on particular PDF library used, and
> --- 47,61 ----
>   # If libgd has been compiled with TrueType font support, then you can use
>   # scaled TrueType fonts. If not, then uncomment FREETYPE.
>   # Requires GD, PNG and Z libraries, optionally libfreetype.
> ! # The recent GD requires libfontconfig, and optionally uses libiconv
> ! # If GD ilibraries require either and both, uncomment FONTCONFIG
> ! # (and ICONV) suitably.
>   NEWGD=1
>   JPEG=1
>   FREETYPE=1
> + #FONTCONFIG=1
> + #ICONV=1
> + 
>   
>   # PDF device driver
>   # Requires PNG and Z libraries based on particular PDF library used, and
> ***************
> *** 214,219 ****
> --- 219,230 ----
>     CFLAGS += -DHAVE_GD_TTF
>     TERMLIBS += -lfreetype
>   endif
> + ifdef FONTCONFIG
> +   TERMLIBS += -lfontconfig
> + endif
> + ifdef ICONV
> +   TERMLIBS += -liconv
> + endif
>   endif
>   
>   ifdef PDF
> 
> 


--------------------------------------
Power up the Internet with Yahoo! Toolbar.
http://pr.mail.yahoo.co.jp/toolbar/

Re: gd.trm issue for mingw-gcc-4.3.0 building

[Tatsuro M. <tma...@ya...>]

Hello

The patch in the previous includes a few errors.
So I am sending the revised one

Regards

Tatsuro

*** makefile.mgw.orig	Tue Nov 25 16:46:59 2008
--- makefile.mgw	Fri Dec 19 09:40:47 2008
***************
*** 47,56 ****
  # If libgd has been compiled with TrueType font support, then you can use
  # scaled TrueType fonts. If not, then uncomment FREETYPE.
  # Requires GD, PNG and Z libraries, optionally libfreetype.
! #
  NEWGD=1
  JPEG=1
  FREETYPE=1
  
  # PDF device driver
  # Requires PNG and Z libraries based on particular PDF library used, and
--- 47,61 ----
  # If libgd has been compiled with TrueType font support, then you can use
  # scaled TrueType fonts. If not, then uncomment FREETYPE.
  # Requires GD, PNG and Z libraries, optionally libfreetype.
! # The recent GD requires libfontconfig, and optionally uses libiconv
! # If GD ilibraries require either and both, uncomment FONTCONFIG
! # (and ICONV) suitably.
  NEWGD=1
  JPEG=1
  FREETYPE=1
+ #FONTCONFIG=1
+ #ICONV=1
+ 
  
  # PDF device driver
  # Requires PNG and Z libraries based on particular PDF library used, and
***************
*** 214,219 ****
--- 219,230 ----
    CFLAGS += -DHAVE_GD_TTF
    TERMLIBS += -lfreetype
  endif
+ ifdef FONTCONFIG
+   TERMLIBS += -lfontconfig
+ endif
+ ifdef ICONV
+   TERMLIBS += -liconv
+ endif
  endif
  
  ifdef PDF


--- Tatsuro MATSUOKA <tma...@ya...> wrote:

> Hello Ethan A Merritt
> 
> cc. Petr Mikulik  and Pierre Joye
> 
> Considering that the libfontconfig is not required for previous version of libgd and iconv is
> optional
> for libdgd-2.0.36RC1, I have considered the following patch to  makefile.mgw. 
> 
> Regards
> 
> Tatsuro
> 
> 
> *** makefile.mgw.orig	Tue Nov 25 16:46:59 2008
> --- makefile.mgw	Thu Dec 18 09:03:32 2008
> ***************
> *** 47,56 ****
>   # If libgd has been compiled with TrueType font support, then you can use
>   # scaled TrueType fonts. If not, then uncomment FREETYPE.
>   # Requires GD, PNG and Z libraries, optionally libfreetype.
> ! #
>   NEWGD=1
>   JPEG=1
>   FREETYPE=1
>   
>   # PDF device driver
>   # Requires PNG and Z libraries based on particular PDF library used, and
> --- 47,61 ----
>   # If libgd has been compiled with TrueType font support, then you can use
>   # scaled TrueType fonts. If not, then uncomment FREETYPE.
>   # Requires GD, PNG and Z libraries, optionally libfreetype.
> ! # The recent GD requires libfontconfig, and optinally uses libiconv
> ! # If GD ilibraries requires either and both, uncomment FONTCONFIG
> ! # (and ICONV) suitably.
>   NEWGD=1
>   JPEG=1
>   FREETYPE=1
> + #FONTCONFIG=1
> + #ICONV=1
> + 
>   
>   # PDF device driver
>   # Requires PNG and Z libraries based on particular PDF library used, and
> ***************
> *** 214,219 ****
> --- 219,230 ----
>     CFLAGS += -DHAVE_GD_TTF
>     TERMLIBS += -lfreetype
>   endif
> + ifdef FONTCONFIG
> +   TERMLIBS += -lfontconfig
> + endif
> + ifdef ICONV
> +   TERMLIBS += -liconv
> + endif
>   endif
>   
>   ifdef PDF
> 
> # ****end of the patch *********
> 
> --- Ethan A Merritt <merritt@u.washington.edu> wrote:
> 
> > On Wednesday 17 December 2008, Tatsuro MATSUOKA wrote:
> > > Hello Ethan and Petr
> > > 
> > > Thank you for your replies. 
> > > 
> > > From the config.log, the configure script of the gd-2.0.36RC1 searches both libiconv and
> > fontconfig.
> > > 
> > > The gd-2.0.36RC1 is the latest gd source except for that on cvs-trees.
> > 
> > OK. I have now read the source files for gd-2.0.36RC1.
> > I see that libiconv is optional, and used only by the file:
> > 
> > /* gdkanji.c (Kanji code converter)                            */
> > /*                 written by Masahito Yamaga (ma...@ya...) */
> > 
> > I think this is only relevant if you need conversion from SJIS encoding,
> > because kanji use works on my UTF8-based machines without using libiconv.
> > The ./configure script for libgd searches for libiconv on your system
> > when building libgd, and includes this optional code only if it is found.
> > 
> > 	Ethan
> 
> 
> --------------------------------------
> Power up the Internet with Yahoo! Toolbar.
> http://pr.mail.yahoo.co.jp/toolbar/
> 
> ------------------------------------------------------------------------------
> SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada.
> The future of the web can't happen without you.  Join us at MIX09 to help
> pave the way to the Next Web now. Learn more and register at
> http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/
> _______________________________________________
> gnuplot-beta mailing list
> gnu...@li...
> https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
> 


--------------------------------------
Power up the Internet with Yahoo! Toolbar.
http://pr.mail.yahoo.co.jp/toolbar/

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

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

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