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

Re: How best to plot contours + explicit lines?

[Petr M. <mi...@ph...>]

> .. you didn't mention the usually recommended method: doing it via 'set
> term table' to put the contours into a file, then plotting that along
> with whatever else you want, in a single 'splot' or 'plot' commands.

That's like the only well-working method to draw contours together with pm3d
and surface, and to make contours in a single-color.

Here, we miss "{no}countour" and "{no}surface" options:

set pm3d explicit
splot x+y, x*x+y*y with pm3d

set contour base
splot x+y, x*x+y*y with pm3d

unset surface
splot x+y, x*x+y*y with pm3d

=> now it suppresses even pm3d?!


> I.e. we should not need a 'nocontour' option to turn off contouring for
> one dataset as much as we need a 'contour' option to turn it *on*.
> What I'm getting at is that 'set contour' needs to be changed like we
> changed 'set pm3d' already: from a global, all-encompassing gnuplot
> state to a per-dataset processing option. We need
>
> 	set contour explicit

That's
>
> (off by default for backward compatibility) and
>
> 	splot 'file' with contours

Or
	splot 'file' contours with line ...
?

I wish also an option "samecolor" or whatever... even I have tried:

set contour
set cntrpar levels 30
splot x*x-y*y with line lc rgb "#000000"
splot x*x-y*y with line lc rgb "#000000"

but it uses the whole color palette instead of a single color. Bug?
This works correctly:

splot x*x-y*y with line palette


---
PM

Re: How best to plot contours + explicit lines?

[Hans-Bernhard B. <br...@ph...>]

Ethan Merritt wrote:
> I want to plot a contour map with several explicit paths
> superimposed on it.  

.. you didn't mention the usually recommended method: doing it via 'set 
term table' to put the contours into a file, then plotting that along 
with whatever else you want, in a single 'splot' or 'plot' commands.

 > So far as I can work it out, the only
> way to do this currently is using multiplot:

Not really, I think.  If the secondary file is not in grid format 
(isolated isolines), contouring should leave it alone, and you can just
plot it along with the contoured surface data.

> This works, but I don't like having to depend on multiplot
> mode to exactly superimpose things.  So I am wondering if there
> is a simple extension to the splot syntax that would allow this
> within a single plot.  

Well, setting aside "simple" for a moment, I think the real problem is
elsewhere: it's that 'set contour' itself is a flawed user interface
concept. Contouring is a data modification method (like 'smooth bezier'
in 2D), not a global plotting mode.

I.e. we should not need a 'nocontour' option to turn off contouring for
one dataset as much as we need a 'contour' option to turn it *on*.
What I'm getting at is that 'set contour' needs to be changed like we
changed 'set pm3d' already: from a global, all-encompassing gnuplot
state to a per-dataset processing option. We need

	set contour explicit

(off by default for backward compatibility) and

	splot 'file' with contours

> This brings up an issue with whether "unset surface" should
> have any effect at all on plots that are not contour plots.

With my above proposal in place, I guess 'unset surface' could go
away completely.

It might sense to change its meaning, instead. E.g. it could implement
the mildly frequently requested feature of plotting data as simple lines
instead of a cross-connected mesh, even though it does have grid
structure. 'unset surface' could be changed to disable that automatism.

Re: [Gnuplot-bugs] a suggestion

[Hans-Bernhard B. <br...@ph...>]

Igor Bray wrote:

[CC'ing this to -beta, because this is not a bug but a feature proposal.]

> modifying the graphics.c file in the way that is listed below. I had
> hoped that the latest version of gnuplot would give me the required
> capacity, but I don't believe it does. 

Unfortunately, the patch, as attached, is quite unusable --- version 
3.7.1 is 3 release versions, or 7 years out of date; and the patch 
itself is backwards.

To first approximation, I agree with the reasoning of that patch:
'set key spacing <sp>' really should affect the line spacing of the key 
title, too.

Could you please try to re-do this patch, based on the current CVS 
sources, and post it to the patches tracker?

How best to plot contours + explicit lines?

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

I want to plot a contour map with several explicit paths
superimposed on it.  So far as I can work it out, the only
way to do this currently is using multiplot:

  set view map
  set multiplot

  set contour
  unset surface
  splot "map.dat"

  unset contour
  set surface
  splot "path1.dat" with lines, "path2.dat" with lines

  unset multiplot

This works, but I don't like having to depend on multiplot
mode to exactly superimpose things.  So I am wondering if there
is a simple extension to the splot syntax that would allow this
within a single plot.  I had in mind something like:

  set view map
  set contour
  unset surface
  splot "map.dat", "path1.dat" nocontour with lines

This brings up an issue with whether "unset surface" should
have any effect at all on plots that are not contour plots.
Right now,
  unset contour; unset surface; 
  splot <foo> with lines
produces a plot with no lines at all, which I think is a bug. 

So what do you all think - am I overlooking an existing
non-multiplot method of superimposing contours and explicit
paths?  

Would a "splot ... nocontour" option be a reasonable
extension?  

Should an explicit "splot <foo> with lines" ignore the status
of set/unset surface?


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

Re: gnuplot.texi missing postscript terminal docs

[Hans-Bernhard B. <br...@ph...>]

Juergen Wieferink wrote:
> On Sunday 20 March 2005 16:09, Hans-Bernhard Broeker wrote:

> I'm sorry.  

No need to be.

[...]
> a good idea?

Possibly.  The important thing is that this doesn't happen on a regular 
basis.

> I tried to get the values of $(CPP) and $(CPPFLAGS) from the
> autotools into doc2texi.el.  Unfortunately "gcc -E" doesn't work in
> this case because gcc doesn't recognize the suffix ".trm".

You may profit from a look into how allterm.h is built.  Or maybe 
combine the second half of your proposal with using allterm.h right away 
--- that might also solve the maintenance problem of yet another copy of 
the terminal list currently being hardwired inside doc2texi.el.

Re: gnuplot manual misprint (no.16)

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

shige 03/21 2005
----------------

| Date: Fri, 18 Mar 2005 19:15:28 +0100
| From: Hans-Bernhard Broeker <br...@ph...>
| To: Shigeharu TAKENO <sh...@ie...>
| Cc: gnu...@li...
| Subject: Re: gnuplot manual misprint (no.16)
=====
| > ! They are plotted one surface after another is found in the data file.
| >   Parts overlapping in 2D projection are overdrawn.
| >   
| >   Gnuplot is not 3D modeling program. Its hidden routines apply for points and
| 
| This one is a subtle case.  The old text was factually correctly, but 
| could benefit from a strategically placed comma to ease understanding. 
| Will do that.

Thanks. I am not so good at English. I am translating gnuplot.doc
and faq.tex to Japanese, it is also for studying English.

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

Re: gnuplot.texi missing postscript terminal docs

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

On Sunday 20 March 2005 16:09, Hans-Bernhard Broeker wrote:
> [Please try to stick with one email address --- so I don't have to
> manually approve your postings from the "wrong" one, only to find that
> you've re-posted them under the correct address in the meantime...]

I'm sorry.  I realized too late that I used a wrong address.  Then I
resent it with the right address.  I thought about sending you a
note not to put the first message on the list.  Would that have been
a good idea?

> > The attached patch is a proof of concept for an extension of
> > doc2texi.el.  AFAICS it works.  It calls the preprocessor from within
> >  doc2texi.el.  This could be done somewhat more portable than just
> > calling "cpp -DTERM_HELP", though.
>
> It quite probably must be, too.  For starters, the preprocessor isn't
> called 'cpp' everywhere, and you'll almost certainly have to provide
> some other macros to make *all* terminal help work correctly.

Good point.  At first glance: x11.trm needs PM3D and USE_MOUSE...

> > How portable should this step be?
>
> As portable as it can possibly be.

I tried to get the values of $(CPP) and $(CPPFLAGS) from the
autotools into doc2texi.el.  Unfortunately "gcc -E" doesn't work in
this case because gcc doesn't recognize the suffix ".trm".

> Having doc2texi.el invoke CPP doesn't exactly seem like the most elegant
> solution possible.  But if it works, it's worth a shot.

Using CPP indeed seems to be the wrong way.

FYI: The epslatex patch breaks doc2texi.el for two reasons:
1) usage of "#define"s
2) having more then one START_HELP() ... END_HELP() in one file

My patch might still give an idea how to cope with the second one.


Juergen

Re: gnuplot.texi missing postscript terminal docs

[Hans-Bernhard B. <br...@ph...>]

Juergen Wieferink wrote:

[Please try to stick with one email address --- so I don't have to
manually approve your postings from the "wrong" one, only to find that
you've re-posted them under the correct address in the meantime...]

> The attached patch is a proof of concept for an extension of 
> doc2texi.el.  AFAICS it works.  It calls the preprocessor from within
>  doc2texi.el.  This could be done somewhat more portable than just 
> calling "cpp -DTERM_HELP", though.

It quite probably must be, too.  For starters, the preprocessor isn't
called 'cpp' everywhere, and you'll almost certainly have to provide
some other macros to make *all* terminal help work correctly.

We used to process all terminal drivers through the preprocessor to
create files docs/term.h and docs/allterm.h, until I disabled that
mechanism --- it was causing problems elsewhere.

Having doc2texi.el invoke CPP doesn't exactly seem like the most elegant
solution possible.  But if it works, it's worth a shot.

> How portable should this step be?

As portable as it can possibly be.

 > Will gnuplot.info be prebuilt in releases?

No.  But gnuplot.texi, the direct output of doc2texi.el, will be.

But releases aren't the main point of concern here.  CVS checkins from 
non-GNUish platforms are.  gnuplot.texi itself is contained in CVS 
(although arguably, it shouldn't be), and rebuilt each time gnuplot.doc 
changes (it should be rebuilt if any terminal changes, too, but 
docs/Makefile.in fails to say so).  So a "cvs checkin" without a list of 
files to be checked in (so all new files will be checked in, including 
gnuplot.texi), done from a platform that doc2texi.el fails to run 
properly on could generate some nuisance.  As such, it's rather 
important that doc2texi.el behaves portably.

Re: gnuplot.texi missing postscript terminal docs

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

> > please fix the doc sections of term/post.trm such that they make it into
> > docs/gnuplot.texi (and other files built from it).  It looks like the
> > driver tries to be too clever, relying on C preprocessing tricks to
> > generate repeated text blocks, which doc2texi.el can't follow.
>
> This was my fault. Unfortunately, I don't have an idea how to fix it.
> Should doc2texi.el be extended, or could term/post.trm be changed without
> losing the feature of repeated text blocks?

The attached patch is a proof of concept for an extension of
doc2texi.el.  AFAICS it works.  It calls the preprocessor from within
doc2texi.el.  This could be done somewhat more portable than just
calling "cpp -DTERM_HELP", though.  But I don't know an easy way to
get the values of $(CPP) and $(CPPFLAGS) into the elisp processor
other than through the enviroment (which seems to be quite easy, but
not quite elegant).  How portable should this step be?  Will
gnuplot.info be prebuilt in releases?


Juergen

Re: gnuplot.texi missing postscript terminal docs

[<wie...@we...>]

> > please fix the doc sections of term/post.trm such that they make it into
> > docs/gnuplot.texi (and other files built from it).  It looks like the
> > driver tries to be too clever, relying on C preprocessing tricks to
> > generate repeated text blocks, which doc2texi.el can't follow.
>
> This was my fault. Unfortunately, I don't have an idea how to fix it.
> Should doc2texi.el be extended, or could term/post.trm be changed without
> losing the feature of repeated text blocks?

The attached patch is a proof of concept for an extension of
doc2texi.el.  AFAICS it works.  It calls the preprocessor from within
doc2texi.el.  This could be done somewhat more portable than just
calling "cpp -DTERM_HELP", though.  But I don't know an easy way to
get the values of $(CPP) and $(CPPFLAGS) into the elisp processor
other than through the enviroment (which seems to be quite easy, but
not quite elegant).  How portable should this step be?  Will
gnuplot.info be prebuilt in releases?


Juergen

Re: gnuplot manual misprint (no.16)

[Hans-Bernhard B. <br...@ph...>]

Shigeharu TAKENO wrote:
> *** gnuplot.doc.ORG	2005-03-18 20:31:57.000000000 +0900
> --- gnuplot.doc	2005-03-18 20:32:34.000000000 +0900
> ***************
> *** 8757,8763 ****
>    the plot.  `set title` is a special case of `set label`.
>   
>    Syntax:
> !        set title {"<title-text>"} {offset <offset>} {"<font>{,<size>}"}
> !        set title {"<title-text>"} {offset <offset>} {font "<font>{,<size>}"}

Accepted (the documented syntax is still accepted, but deprecated).


[...faq.tex...]

> ***************
> *** 834,840 ****
>   \texttt{splot ... with pm3d}.
>   
>   In the above example, pm3d displays triangles as independent surfaces.
> ! They are plotted one surface after another as found in the data file.
>   Parts overlapping in 2D projection are overdrawn.
>   
>   Gnuplot is not 3D modeling program. Its hidden routines apply for points and
> --- 834,840 ----
>   \texttt{splot ... with pm3d}.
>   
>   In the above example, pm3d displays triangles as independent surfaces.
> ! They are plotted one surface after another is found in the data file.
>   Parts overlapping in 2D projection are overdrawn.
>   
>   Gnuplot is not 3D modeling program. Its hidden routines apply for points and

This one is a subtle case.  The old text was factually correctly, but 
could benefit from a strategically placed comma to ease understanding. 
Will do that.

Re: gnuplot.texi missing postscript terminal docs

[Hans-Bernhard B. <br...@ph...>]

Harald Harders wrote:

> This was my fault.  Unfortunately, I don't have an idea how to fix 
> it.  Should doc2texi.el be extended, or could term/post.trm be 
> changed without losing the feature of repeated text blocks?

If you want to keep that feature, you'll have to extend the
functionality of doc2texi.el, or create a work-alike of the C 
preprocessor macro tricks, using TeX or texinfo macros.  OTOH, I don't 
really see why you have to have complete copies of text blocks repeated 
in various terminal driver doc sections, as opposed to just putting in 
references to a single instance.

gnuplot manual misprint (no.16)

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

shige 03/18 2005
----------------

In gnuplot.doc of current CVS version

 C RCS $Id: gnuplot.doc,v 1.279 2005/03/09 19:05:34 sfeam Exp $

and in faq.tex of revision 1.16 at

 http://cvs.sourceforge.net/viewcvs.py/gnuplot/faq/faq.tex

I found some points that seem to be misprints. I send the unified
diff file for them.

----- From here (gnuplot.doc) -----
*** gnuplot.doc.ORG	2005-03-18 20:31:57.000000000 +0900
--- gnuplot.doc	2005-03-18 20:32:34.000000000 +0900
***************
*** 8757,8763 ****
   the plot.  `set title` is a special case of `set label`.
  
   Syntax:
!        set title {"<title-text>"} {offset <offset>} {"<font>{,<size>}"}
                   {{textcolor | tc} {lt <line_type> | default}} {{no}enhanced}
         show title
  
--- 8757,8763 ----
   the plot.  `set title` is a special case of `set label`.
  
   Syntax:
!        set title {"<title-text>"} {offset <offset>} {font "<font>{,<size>}"}
                   {{textcolor | tc} {lt <line_type> | default}} {{no}enhanced}
         show title
  
----- To here (gnuplot.doc) -----
  
----- From here (faq.tex) -----
*** faq.tex.ORG	2005-03-12 12:23:36.000000000 +0900
--- faq.tex	2005-03-18 20:27:11.000000000 +0900
***************
*** 434,440 ****
  is \verb+patch -p0 <newfunctionality.diff+.
  
  There is repository of contributed patches in the "Patches" section on gnuplot's
! sourceforge site http://www.sourceforge.net/projects/gnuplot/.
  
  
  \section{Working with it.}
--- 434,440 ----
  is \verb+patch -p0 <newfunctionality.diff+.
  
  There is repository of contributed patches in the "Patches" section on gnuplot's
! sourceforge site \http{www.sourceforge.net/projects/gnuplot/}.
  
  
  \section{Working with it.}
***************
*** 581,587 ****
  be further edited by a svg editor, e.g. 
  \textbf{Sodipodi} (\http{sodipodi.sourceforge.net}),
  \textbf{Sketch} (\http{sketch.sourceforge.net}) or
! \textbf{Dia} (\http{http://www.lysator.liu.se/~alla/dia}).
  
  \item PostScript or PDF output can be edited directly by tools such
  as Adobe Illustrator or Acrobat, or can be converted to a variety
--- 581,587 ----
  be further edited by a svg editor, e.g. 
  \textbf{Sodipodi} (\http{sodipodi.sourceforge.net}),
  \textbf{Sketch} (\http{sketch.sourceforge.net}) or
! \textbf{Dia} (\http{www.lysator.liu.se/~alla/dia}).
  
  \item PostScript or PDF output can be edited directly by tools such
  as Adobe Illustrator or Acrobat, or can be converted to a variety
***************
*** 708,714 ****
  which adds blank lines to a data file whenever number in the first column
  changes:
  \begin{verbatim}
! /[:blank:]*#/ {next} # ignore comments (lines starting with #)
  NF < 3 {next} # ignore lines which don't have at least 3 columns
  $1 != prev {printf "\n"; prev=$1} # print blank line
  {print} # print the line
--- 708,714 ----
  which adds blank lines to a data file whenever number in the first column
  changes:
  \begin{verbatim}
! /^[[:blank:]]*#/ {next} # ignore comments (lines starting with #)
  NF < 3 {next} # ignore lines which don't have at least 3 columns
  $1 != prev {printf "\n"; prev=$1} # print blank line
  {print} # print the line
***************
*** 762,768 ****
  reset
  # Change single blank lines to double blank lines
  !awk "NF<2{printf\"\n\"}{print}" <contour.dat >contour1.dat
! plot 'contour1.dat' with line -1
  \end{verbatim}
  See also the following question "How to overlay contour plot over pm3d map/surface".
  
--- 762,768 ----
  reset
  # Change single blank lines to double blank lines
  !awk "NF<2{printf\"\n\"}{print}" <contour.dat >contour1.dat
! splot 'contour1.dat' with line -1
  \end{verbatim}
  See also the following question "How to overlay contour plot over pm3d map/surface".
  
***************
*** 834,840 ****
  \texttt{splot ... with pm3d}.
  
  In the above example, pm3d displays triangles as independent surfaces.
! They are plotted one surface after another as found in the data file.
  Parts overlapping in 2D projection are overdrawn.
  
  Gnuplot is not 3D modeling program. Its hidden routines apply for points and
--- 834,840 ----
  \texttt{splot ... with pm3d}.
  
  In the above example, pm3d displays triangles as independent surfaces.
! They are plotted one surface after another is found in the data file.
  Parts overlapping in 2D projection are overdrawn.
  
  Gnuplot is not 3D modeling program. Its hidden routines apply for points and
***************
*** 851,857 ****
  happy writing a convertor of your facets into a VRML file.
  
  
! \subsection{Palette for printing my color map on color as well as blank\&white
  printer?}
  
  I think it is this one, for example: \texttt{set palette rgbformulae -25,-24,-32}.
--- 851,857 ----
  happy writing a convertor of your facets into a VRML file.
  
  
! \subsection{Palette for printing my color map on color as well as black\&white
  printer?}
  
  I think it is this one, for example: \texttt{set palette rgbformulae -25,-24,-32}.
***************
*** 1089,1095 ****
  (\http{www.octave.org}), uses this method. This also works from a cgi script to
  drive \gnuplot{} from a forms-based web page.
  
! John Campbell \mailto{jd...@na...} modified a much earlier
  version of \gnuplot{} (3.5) to be a library of C subroutines callable 
  from a C program.  Gnuplot itself has changed radically since then,
  and we are not aware of any plans to create a similar library based on
--- 1089,1095 ----
  (\http{www.octave.org}), uses this method. This also works from a cgi script to
  drive \gnuplot{} from a forms-based web page.
  
! John Campbell (\mailto{jd...@na...}) modified a much earlier
  version of \gnuplot{} (3.5) to be a library of C subroutines callable 
  from a C program.  Gnuplot itself has changed radically since then,
  and we are not aware of any plans to create a similar library based on
***************
*** 1196,1202 ****
  
  If your gnuplot is running as the plotting engine of Octave under X11, then
  please put \texttt{gset mouse} into your \texttt{\$HOME/.octaverc}. According to
! gnuplot's \texttt{help x11}, gnuplot under x11 running through a pipe needs
  \texttt{set mouse} to be executed before launching the x11 plot window.
  
  
--- 1196,1202 ----
  
  If your gnuplot is running as the plotting engine of Octave under X11, then
  please put \texttt{gset mouse} into your \texttt{\$HOME/.octaverc}. According to
! gnuplot's \texttt{help x11\_mouse}, gnuplot under x11 running through a pipe needs 
  \texttt{set mouse} to be executed before launching the x11 plot window.
  
  
***************
*** 1243,1249 ****
  \subsection{Open questions for inclusion into the FAQ?}
  
  
! \mailto{gnu...@li...}.
  
  Please submit your questions (along with the answer) to 
  \mailto{gnu...@li...}.
--- 1243,1249 ----
  \subsection{Open questions for inclusion into the FAQ?}
  
  
! % \mailto{gnu...@li...}.
  
  Please submit your questions (along with the answer) to 
  \mailto{gnu...@li...}.
----- To here (faq.tex) -----

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

Re: gnuplot.texi missing postscript terminal docs

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

On Thursday 17 March 2005 10:43 am, Harald Harders wrote:
> On Wed, 16 Mar 2005, Hans-Bernhard Broeker wrote:
> 
> > Ethan, (or whoever feels up to it),
> >
> > please fix the doc sections of term/post.trm such that they make it into
> > docs/gnuplot.texi (and other files built from it).  It looks like the
> > driver tries to be too clever, relying on C preprocessing tricks to
> > generate repeated text blocks, which doc2texi.el can't follow.
> 
> This was my fault. Unfortunately, I don't have an idea how to fix it.
> Should doc2texi.el be extended, or could term/post.trm be changed without
> losing the feature of repeated text blocks?

I have no idea either.  I do not understand the "texi" process at all.
Sorry. Can't help.




-- 
Ethan A Merritt       merritt@u.washington.edu
Biomolecular Structure Center
Mailstop 357742
University of Washington, Seattle, WA 98195

Re: gnuplot.texi missing postscript terminal docs

[Harald H. <h.h...@tu...>]

On Wed, 16 Mar 2005, Hans-Bernhard Broeker wrote:

> Ethan, (or whoever feels up to it),
>
> please fix the doc sections of term/post.trm such that they make it into
> docs/gnuplot.texi (and other files built from it).  It looks like the
> driver tries to be too clever, relying on C preprocessing tricks to
> generate repeated text blocks, which doc2texi.el can't follow.

This was my fault. Unfortunately, I don't have an idea how to fix it.
Should doc2texi.el be extended, or could term/post.trm be changed without
losing the feature of repeated text blocks?

Regards
Harald

-- 
Harald Harders
h.h...@tu...
http://www.harald-harders.de

gnuplot.texi missing postscript terminal docs

[Hans-Bernhard B. <br...@ph...>]

Ethan, (or whoever feels up to it), 

please fix the doc sections of term/post.trm such that they make it into
docs/gnuplot.texi (and other files built from it).  It looks like the
driver tries to be too clever, relying on C preprocessing tricks to
generate repeated text blocks, which doc2texi.el can't follow.

-- 
Hans-Bernhard Broeker (br...@ph...)
Even if all the snow were burnt, ashes would remain.

Plotting in real time

[Sig L. <sig...@gm...>]

I would like to plot data in real time. I am not sure if this is
possible but I would like to have time on my X axis, and various
values on Y. I know this could be possible by tailing the last "20
entries" of a file and then feeding that into gnuplot, but was
wondering if there was a better way.

Has anyone any other alternative than feeding gnuplot a "plot
'myfile.txt' with lines" every update interval?

I tried feeding data into gnuplot via a fifo but graphing didn't start
until the fifo was closed on the  writing end. Is there a way around
that?

I understand that gnuplot would have to shift the graph or redraw the
entire thing, this may not have been considered when designing.


TIA,
Sig

Re: ./prepare fails

[Lars H. <lhe...@us...>]

> It also seems that the version of automake installed by default on Mandrake 
> 10.1 is pretty old:
> 
> autoconf (GNU Autoconf) 2.59
> automake (GNU automake) 1.4-p6
 
 Definitely stay away from the automake -pN versions, they are quite broken.

Re: ./prepare fails

[Jeff H. <unu...@gm...>]

On Monday 14 March 2005 09:10 am, Ethan Merritt wrote:
> On Saturday 12 March 2005 07:39 pm, Jeff Hagen wrote:
> > 	I am trying to install the gnuplot beta so that I can play around with
> > histograms.... I get to the point of running prepare then it fails. It
> > can not find config.guess and config.sub....
>
> Yes.
> I have that same problem.
> It seems to be a recent autoconf bug.
>
> The work-around is to create empty instances of these files before hand,
> and they will be replaced with correct ones.
>
> [1] touch config.guess config.sub
> [2] ./prepare
> [3] ./configure

That fixed it, thanks!

It also seems that the version of automake installed by default on Mandrake 
10.1 is pretty old:

autoconf (GNU Autoconf) 2.59
automake (GNU automake) 1.4-p6

It seems that Mandrake hasn't updated it since 2002. Time to send them a bug 
report.

Thanks,
-Jeff Hagen
jh...@uc...

Re: width of text in latex terminals

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

On Monday 14 March 2005 09:45 am, Robert Hart wrote:
> On Mon, 2005-03-14 at 09:22 -0800, Ethan Merritt wrote:
> > There is a new dummy driver in the current cvs version called
> > "estimate.trm" that is used internally to do exactly what you 
> > want for strings using gnuplot's own enhanced text mode.
> > 
> > But that is not going to get you a full TeX interpreter inside
> > gnuplot.  
> 
> so, in principle, if I added an "enhanced" mode to the pslatex driver,
> it would be able to give gnuplot an *estimate* of the length of a latex
> fragment, but actually just output the text in an unenhanced way? 

I don't think so.  gnuplot's enhanced text mode has its own syntax and 
conventions, and they are not the same as TeX/LaTeX.  So I'm pretty
sure feeding a TeX command string to gnuplot's enhanced text parser
will not produce useful information.

> The enhanced mode functions don't seem to be documented in term/README

The enhanced text mode was originally part of the postscript driver (only).
It was later extended to apply to other drivers as well. But the basic
documentation files are still hiding in .../docs/psdoc/
They should probably move to a more general location.

If you were looking for specific details of the driver entry points
used by enhanced text mode, that's another story.   The implementation
in dumb.trm was intended as a simplest-case example of how to add
support to a new driver.  Beyond that simplest case, however, each
terminal type is a bit different in its needs.

	hope that helps


-- 
Ethan A Merritt       merritt@u.washington.edu
Biomolecular Structure Center
Mailstop 357742
University of Washington, Seattle, WA 98195

Re: width of text in latex terminals

[Robert H. <en...@no...>]

On Mon, 2005-03-14 at 18:37 +0100, Hans-Bernhard Broeker wrote:
> Robert Hart wrote:
> 
> > set format y '[r]{%.0t$\times$10$^{%+03T}$}'
> > ends up with a huge gap between the border of the plot and yaxis label
> > because gnuplot assumes the tic labels are much bigger than the actually
> > are.
> 
> And you have command like 'set lmargin' for the express reason that they 
> enable you to work around that misfeature.

This I am aware of. These workarounds are difficult to find for novice
users and inconsistently implemented (e.g "set lmargin" completely
overrides the calculated width, but "set key width" and "set ylabel
offset" require a number of charwidths to add or remove)

At very least, the terminal help should mention the possible need for
these commands, but I would have thought a better estimate of the length
would eliminate the need for them in the majority of cases.

-- 
Robert Hart <en...@no...>
University of Nottingham


This message has been checked for viruses but the contents of an attachment
may still contain software viruses, which could damage your computer system:
you are advised to perform your own checks. Email communications with the
University of Nottingham may be monitored as permitted by UK legislation.

Re: ./prepare fails

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

On Monday 14 March 2005 09:34 am, Hans-Bernhard Broeker wrote:
> Ethan Merritt wrote:

> > It seems to be a recent autoconf bug.
> 
> How recent, i.e. what version numbers are we talking about here?  It'd 
> have to be an automake bug actually, since automake is generating that 
> error message, not autoconf.

autoconf2.5-2.59-3
automake 1.8.3-1

 
> > There is a similar long-standing problem with the way gnuplot's
> > ./configure file tries to initialize the local lisp directories.
> 
> What exactly is the issue (and why am I not experiencing it here?)

I have explained this at length twice previously.
In a nutshell, when you run ./configure it tries to create new files
gnuplot.* in a system directory
	/usr/share/emacs/site-lisp/

Unless you are running as root, you don't have write access to this
directory, so it fails.

-- 
Ethan A Merritt       merritt@u.washington.edu
Biomolecular Structure Center
Mailstop 357742
University of Washington, Seattle, WA 98195

Re: width of text in latex terminals

[Robert H. <en...@no...>]

On Mon, 2005-03-14 at 09:22 -0800, Ethan Merritt wrote:
> On Monday 14 March 2005 09:02 am, Robert Hart wrote:

> > Is this something that could fit into the existing enhanced text support
> > (used by other terminals). Or would the terminal drivers need to be
> > extended with an optional "strlen" function?
> 
> There is a new dummy driver in the current cvs version called
> "estimate.trm" that is used internally to do exactly what you 
> want for strings using gnuplot's own enhanced text mode.
> 
> But that is not going to get you a full TeX interpreter inside
> gnuplot.  

so, in principle, if I added an "enhanced" mode to the pslatex driver,
it would be able to give gnuplot an *estimate* of the length of a latex
fragment, but actually just output the text in an unenhanced way? or is
it going to cause problems if an enhanced mode terminal doesn't use
enhanced mode syntax?

The enhanced mode functions don't seem to be documented in term/README

Rob

-- 
Robert Hart <en...@no...>
University of Nottingham


This message has been checked for viruses but the contents of an attachment
may still contain software viruses, which could damage your computer system:
you are advised to perform your own checks. Email communications with the
University of Nottingham may be monitored as permitted by UK legislation.

Re: width of text in latex terminals

[Hans-Bernhard B. <br...@ph...>]

Robert Hart wrote:

> set format y '[r]{%.0t$\times$10$^{%+03T}$}'
> ends up with a huge gap between the border of the plot and yaxis label
> because gnuplot assumes the tic labels are much bigger than the actually
> are.

And you have command like 'set lmargin' for the express reason that they 
enable you to work around that misfeature.

Re: ./prepare fails

[Hans-Bernhard B. <br...@ph...>]

Ethan Merritt wrote:
> On Saturday 12 March 2005 07:39 pm, Jeff Hagen wrote:
> 
>>	I am trying to install the gnuplot beta so that I can play around with 
>>histograms.... I get to the point of running prepare then it fails. It can 
>>not find config.guess and config.sub....
> 
> 
> Yes.
> I have that same problem.
> It seems to be a recent autoconf bug.

How recent, i.e. what version numbers are we talking about here?  It'd 
have to be an automake bug actually, since automake is generating that 
error message, not autoconf.

> The work-around is to create empty instances of these files before hand,
> and they will be replaced with correct ones.

That would mean we have to consider changing the automake invocation 
options in 'prepare' to include -a -c options to all invocations of
automake (not just the main one), or at least to run automake in the 
top-level directory *before* doing so in 'lisp'.

> There is a similar long-standing problem with the way gnuplot's
> ./configure file tries to initialize the local lisp directories.

What exactly is the issue (and why am I not experiencing it here?)