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

Re: Bug report and whishlist

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

On Sunday 08 May 2005 12:57 pm, Ga=EBl Varoquaux wrote:
>   There is something I don't really understand : the online help (
> http://gnuplot.sourceforge.net/docs/gnuplot.html#mouse_variables )
> suggest that "set pause mouse" should work. But it doesn't. It think the
> actual syntax is "pause mouse".

That documentation error was fixed in the documentation source
some time ago.  This sort of correction doesn't retractively fix
the on-line html version, however.

If you are working with the cvs version of gnuplot, there is a very
recent html version of the docs at
=20
	http://gnuplot.sourceforge.net/docs_4.1/



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

Re: Compile problem on Mac OS X 10.4/gcc 4.0

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

On Monday 09 May 2005 04:36 am, Hans-Bernhard Br=F6ker wrote:
> Ethan Merritt wrote:
> >>1) Change the name "Class" in gplt_x11.c
> >>2) Increase granularity in buildsystem to only compile aquaterm.trm (or
> >>term.c) with "-ObjC"
> > (3) Clean up aquaterm.trm so that it compiles without the -ObjC flag
>=20
> (4) rename that thing in gplt_x11.c from "Class" to something else.=20

I thought that was already suggestion (1)?

=46ine with me.  I'll do it.

But I'm still rather uneasy about compiling the whole source tree
with -ObjC just because the one terminal driver wants it.

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

Re: Povray terminal update

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

On Sun, 2005-05-08 at 22:14 +0200, Ga=EBl Varoquaux wrote:

>   I have just come back to my computer after being away one week and I
> have the pleasure to see that a openGl terminal in progress.=20

btw. I have posted the opengl terminal to the patch tracker on
sourceforge. It's been updated a bit since I last posted it here.
It would be good to get feedback from anybody who's managed to compile
it and use it.

I look forward to hearing your suggestions concerning extending gnuplot
to do real 3D. I've had a few ideas myself, but I'm wary of taking on
anything that big alone.

I think there may well be cases where we would need to redesign some
existing "features" in order to get them to sit well with an alternative
terminal interface.

The first one that springs to mind is multiplot. I have to say I had
never used this feature before I started writing my terminal driver, and
I found it quite difficult to get to work even with the way I had
implemented opengl as a 2D driver.

Rob

--=20
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: Compile problem on Mac OS X 10.4/gcc 4.0

[<br...@ph...>]

Ethan Merritt wrote:
>>1) Change the name "Class" in gplt_x11.c
>>2) Increase granularity in buildsystem to only compile aquaterm.trm (or
>>term.c) with "-ObjC"
> (3) Clean up aquaterm.trm so that it compiles without the -ObjC flag

(4) rename that thing in gplt_x11.c from "Class" to something else.

Re: Compile problem on Mac OS X 10.4/gcc 4.0

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

On Sunday 08 May 2005 05:23 am, Per Persson wrote:
> When detecting Mac OS X and libaquaterm "-ObjC" is added to CFLAGS
> (apple.m4), and every file is compiled as ObjC although only
> aquaterm.trm needs the "-ObjC" flag.
> As I see it, there are two ways to fix this:
> 1) Change the name "Class" in gplt_x11.c
> 2) Increase granularity in buildsystem to only compile aquaterm.trm (or
> term.c) with "-ObjC"

(3) Clean up aquaterm.trm so that it compiles without the -ObjC flag

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

Povray terminal update

[V. <gae...@en...>]

  Hello again,

  I have just come back to my computer after being away one week and I
have the pleasure to see that a openGl terminal in progress. I had been
talk about with my brother who studies graphical engeneering and we had
come to the conclusion that a openGL terminal would be a great
interactive terminal to do 3D with gnuplot.

  As for my projects to rewrite the 2D code, I haven't made any progress
at all. However I have decided to write a 2D povray terminal to get a
proper understanding of gnuplot's code before I tackle the more
difficult problem of reshaping it. This has done quite a lot of
progress and it has given me a good idea of the work needed to adapt the
existing gnuplot code to 3D. I'll post the first draft of this terminal
in a few days (I have just broken color support by adding RGB color).

--
  Ga=EBl

Bug report and whishlist

[V. <gae...@en...>]

   Hello,

  I am just forwarding a few issues some friends have had with gnuplot
recently :

  First a non intuitive behavior :=20

set term win
plot 'foo' using 1:2
set term post
set output 'result.ps'
replot
(then result.ps is drawn)
set term win
plot 'foo' using 1:2
(then result.ps becomes blanck

   A correct way to do the same thing was found :

set term win
plot 'foo' using 1:2
set term post
set output 'result.ps'
replot
set output 'result2.ps'
set term win
plot 'foo' using 1:2

 That forbids gnuplot to scramble result.ps.

 This is a rather non natural behavior that must trick a quite a few
users.


  Secondly more interactive terminals : I have never used the win
terminal (as I don't have a windows box) but it seems to have nice
features for beginners that could be add to the X11 terminal (and the
new born Glut terminal ?). These menus should of course be controled by
a option for the terminal.

  There is something I don't really understand : the online help (
http://gnuplot.sourceforge.net/docs/gnuplot.html#mouse_variables )
suggest that "set pause mouse" should work. But it doesn't. It think the
actual syntax is "pause mouse".

--
  Ga=EBl

Re: Compile problem on Mac OS X 10.4/gcc 4.0

[Per P. <per...@ma...>]

On May 8, 2005, at 18:47, Hans-Bernhard Broeker wrote:

> Per Persson wrote:
>> I've had a report that gnuplot won't compile on OS X 10.4 and gcc 4.0 
>> because of a conflict with a static char array "Class" in gplt_x11.c 
>> and the Objective-C type "Class". It has not been a problem before so 
>> it seems gcc 4 is pickier about this than gcc 3.x.
>
> Or maybe it's plain wrong about it.  Stranger bugs have crept into 
> little-used corners of GCC before.

Agreed.

>
>> When detecting Mac OS X and libaquaterm "-ObjC" is added to CFLAGS 
>> (apple.m4), and every file is compiled as ObjC although only 
>> aquaterm.trm needs the "-ObjC" flag.
>> As I see it, there are two ways to fix this:
>> 1) Change the name "Class" in gplt_x11.c
>> 2) Increase granularity in buildsystem to only compile aquaterm.trm 
>> (or term.c) with "-ObjC"
>
> I'm not convinced that (2) can work.  -ObjC effectively switches to a 
> different language, with possibly different calling conventions and 
> name mangling rules.

ObjC is a strict superset of C, in the sense that any C (well make that 
C89 or whatever) code *should* compile using the ObjC compiler. There 
is no C++ style name mangling going on in ObjC. It is common practice 
to mix C and ObjC using each where it is best suited.

> I wouldn't be surprised in any way if this broke the
> link completely.

Not a linker issue, it is the compiler complaining...
The following is from a bugreport to DarwinPorts (package manager) list:

> if gcc -DHAVE_CONFIG_H -I. -I. -I..  -I../term -I../term 
> -DBINDIR=\"/opt/local/bin\" -
> DX11_DRIVER_DIR=\"/opt/local/libexec/gnuplot/4.0\" -DCONTACT=\"gnuplot-
> bugs at lists.sourceforge.net\" 
> -DHELPFILE=\"/opt/local/share/gnuplot/4.0/gnuplot.gih\" -I/opt/local/
> include -no-cpp-precomp  -I/usr/X11R6/include -I/opt/local/include 
> -I/opt/local/include  -g -O2 -
> ObjC -MT gplt_x11.o -MD -MP -MF ".deps/gplt_x11.Tpo" \
>   -c -o gplt_x11.o `test -f 'gplt_x11.c' || echo './'`gplt_x11.c; \
> then mv ".deps/gplt_x11.Tpo" ".deps/gplt_x11.Po"; \
> else rm -f ".deps/gplt_x11.Tpo"; exit 1; \
> fi
> gplt_x11.c:519: error: 'Class' redeclared as different kind of symbol
> <built-in>:0: error: previous declaration of 'Class' was here
> make[3]: *** [gplt_x11.o] Error 1
> make[2]: *** [all-recursive] Error 1
> make[1]: *** [all-recursive] Error 1
> make: *** [all] Error 2

As I said, until I get 10.4 installed I really can't explore this 
further. Still, I think that (2) would be nice to implement some time 
from a pure cleanlyness perpspective...

/Per

Re: Compile problem on Mac OS X 10.4/gcc 4.0

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

Per Persson wrote:
> I've had a report that gnuplot won't compile on OS X 10.4 and gcc 4.0 
> because of a conflict with a static char array "Class" in gplt_x11.c and 
> the Objective-C type "Class". It has not been a problem before so it 
> seems gcc 4 is pickier about this than gcc 3.x.

Or maybe it's plain wrong about it.  Stranger bugs have crept into 
little-used corners of GCC before.

> When detecting Mac OS X and libaquaterm "-ObjC" is added to CFLAGS 
> (apple.m4), and every file is compiled as ObjC although only 
> aquaterm.trm needs the "-ObjC" flag.
> As I see it, there are two ways to fix this:
> 1) Change the name "Class" in gplt_x11.c
> 2) Increase granularity in buildsystem to only compile aquaterm.trm (or 
> term.c) with "-ObjC"

I'm not convinced that (2) can work.  -ObjC effectively switches to a 
different language, with possibly different calling conventions and name 
mangling rules.  I wouldn't be surprised in any way if this broke the
link completely.

Re: [Gnuplot-info] logscale and autoscale improvement (was logscale and manual range setting?)

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

Jim Kleckner wrote:
> It would be nice to have the autoscale logic be able to
> handle the scaling to waste less space, I think.  

The case you stumbled on is quite particular.  The data yrange is
[1-epsilon:4.0]  This drives autoscaling for log axis exactly into its 
worst-case scenario.

1) the input range is scarcely one decade long
2) it's positioned uncomfortably, with one end point scarcely below a
    natural tic position.
3) it's a logarithmic axis.

Item 2) means that the autoscaled range will be extended beyond that
power-of-ten.  Throwing data points off the plot (like 'set yrange 
[1:10]' does it in this case), is strictly a non-option for the 
automatic behaviour of gnuplot.  You can turn off this extension, at the 
risk of getting rather ugly ranges.  See "help autoscale"; the 'fix' 
options.

Item 3) means that the extension cannot currently be shorter than one
full unit in logarithm (i.e. a factor of 10) --- that's why the 
autoscaled range ends up being [0.1:10].  The core limitation here is 
that gnuplot still has no way ofcontinuously changing from the only 
sensible ticking pattern for long log axes (labelled, graphically 
equidistant major tics, unlabelled, arithmetically equidistant tics in 
between) to the only sensible one for very short axes (labelled, 
arithmetically equidistant tics).

The fact that the additional is perceived to be creating such a huge
"waste" of plot space is because of item 1).  In the essence, you're in 
violation of an old lemma of scientific plotting: "He who uses a 
logarithmic axis spanning less than two decades is rather probably 
trying to brush some embarrasing detail under the carpet."

> How hard do you think it would be to start/end the axis
> on a minitic rather than a major tic if too large a
> fraction of the range is wasted?

Starting the axis on a minitic is IMHO not the right solution.  Lifting 
the limitation that in log axes only at integer powers of the base can 
currently be major tics is what really needs tackling.  While at it, 
other axis re-mappings than pow()/log() should be made possible.

Unfortunately, that'd end up in having to essentially re-write the 
entire autoticking stuff from scratch.  James Van Zandt made a proposal 
for that a long time ago, but it never made it into serious discussion, 
let alone the CVS code.

Compile problem on Mac OS X 10.4/gcc 4.0

[Per P. <per...@ma...>]

Hi,
I've had a report that gnuplot won't compile on OS X 10.4 and gcc 4.0 
because of a conflict with a static char array "Class" in gplt_x11.c 
and the Objective-C type "Class". It has not been a problem before so 
it seems gcc 4 is pickier about this than gcc 3.x.

I haven't upgraded to 10.4 yet, but I thought that I could be 
"pro-active" and fix it anyway...

When detecting Mac OS X and libaquaterm "-ObjC" is added to CFLAGS 
(apple.m4), and every file is compiled as ObjC although only 
aquaterm.trm needs the "-ObjC" flag.
As I see it, there are two ways to fix this:
1) Change the name "Class" in gplt_x11.c
2) Increase granularity in buildsystem to only compile aquaterm.trm (or 
term.c) with "-ObjC"

Obviously, (2) is the right thing to do, but I have to confess that I 
don't understand how to properly change the build system to achieve 
that. Suggestions would be appreciated.

/Per

Re: Gnuplot for pocket pc?

[Zoran O. <zo...@im...>]

Max Velasques <maxvelasques <at> gmail.com> writes:

> 
> Hi,
>    exist some version of gnuplot for pocket pc?
> 
> Thanks!!
> 
> Max
> 

Have a look at:

http://www.rainer-keuchel.de/wince/gnuplot-ce.html

Never tried it, but it should work...

Zoran

Re: timecolumn()

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

Ethan Merritt wrote:

> But before anyone plunges in, I point out that there is probably
> another approach that should be considered.  If the task is
> specifically to read time info from the file and associate it
> with axis labels, 

It's not just for labels --- it's for reading timeseries data
in typical human-readable format, i.e. hours, days, and whatnot,
and turning it into continuous data.  timecolumn(n) is supposed to do 
the same thing inside an extended using spec for time/date data as $<n> 
or column(n) already do for ordinary numbers.  The example from that bug 
report I mentioned was time-dependent rescaling of stock prices across 
the change from D-Mark to Euros:

	set xdata time
	set timefmt x '%d/%m/%y'
	to_euro(year,value) = (year < 2002) ? value / 1.95 : value
	plot 'data' using 1:(to_euro(tm_year(timecolumn(1)),$2))

That one works with today's version --- but it's a close shave.

Re: [Gnuplot-developers] [ gnuplot-Bugs-1194516 ] [postscript] default font override

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

On Thursday 05 May 2005 08:20 am, Hans-Bernhard Broeker wrote:
> Juergen Wieferink wrote:
> 
> > I looked into the postscript output file and played with the
> > switches.  The problem only occurs if "Blacktext" is false.  
> 
> I think that's a red herring.

Yes.

> Apparently current terminal font selection tracking got broken when
> enhanced text processing was ripped out of post.trm.

I am not so sure.  For one thing I did extensive line-by-line comparisons
of the PostScript output before and after moving the code from post.term
into term.c.  They were line-for-line identical for all demos in the test
suite and for all the convoluted enhanced text tests I could think of.
I could have missed something, but...
 
The version 3.7 output file from the current problem case *also* doesn't
restore the font after each tic label.  I am uncertain, but
the bug appears to be related specifically to the key title processing.
Consider the following pair of plots run through either version 4.0
the current cvs version:


set term post enhanced color colortext
#
set noxtics
set noytics
set xlabel "{/Symbol Xlabel}"
set ylabel "Ylabel"
#
set output "autotitle.ps"
plot x
#
set output "noautotitle.ps"
plot x title "x"


The first plot shows the bug.
The second one does not.
The only relevant difference between the two output files
is the failure of the autotitled plot to set a font.

diff -ur autotitle.ps noautotitle.ps
--- autotitle.ps        2005-05-05 10:08:58.172952608 -0700
+++ notitle.ps  2005-05-05 10:09:43.490063360 -0700
@@ -339,7 +339,8 @@
 LT0
 LTb
 6311 4739 M
-(x) Rshow
+[ [(Helvetica) 140.0 0.0 true true 0 (x)]
+] -46.7 MRshow
 LT0
 6395 4739 M
 399 0 V

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

Re: timecolumn()

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

On Thursday 05 May 2005 07:52 am, Hans-Bernhard Broeker wrote:
> 
> The obviously correct solution would be to pass a timeformat string 
> directly as a second argument to timecolumn().  Back when I added 
> per-axis timefmt strings, that wasn't possible.  Nowadays, with the 
> stringvariables patch integrated, it probably is.

Yes. Passing a string as a 2nd argument (or even a string-valued
function) is easy.  The hard part would have been to retain
backward-compatibility with scripts using only one argument.
Fortunately timecolumn was a secret undocumented function,
so there are no such scripts :-)

But before anyone plunges in, I point out that there is probably
another approach that should be considered.  If the task is
specifically to read time info from the file and associate it
with axis labels, then I think this is almost possible already
by passing a sting-function to the [xyz]xticlabels option.
The following doesn't quite work, but could be made to work:

   timeformat = "some time format"
   plot 'foo' using 4:5:xtic(gprintf(timeformat,column(1)))

The trick would be to extend routine plot_ticlabel_using(int axis)
in datafile.c so that it parses the argument to xtic() as a
general expression rather as an integer constant.  That's something
I meant to do originally, but never got around to it.  It would
have uses beyond timeformats, of course.


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

Re: [Gnuplot-developers] [ gnuplot-Bugs-1194516 ] [postscript] default font override

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

Juergen Wieferink wrote:

> I looked into the postscript output file and played with the
> switches.  The problem only occurs if "Blacktext" is false.  

I think that's a red herring.

With Juergen's example modified to use

	set format x "{Symbol /p} %P"
	set xtics pi/4

I get the following PostScript output regarding strings:

--
0 setgray
newpath
(Helvetica) findfont 140 scalefont setfont
1.000 UL
LTb
--
574 280 M
Blacktext { gsave 0 setgray } if
[ [(Helvetica) 140.0 0.0 true true 0 ( 0.1)]
] -46.7 MRshow
Blacktext { grestore } if

[...]

574 4872 M
Blacktext { gsave 0 setgray } if
[ [(Helvetica) 140.0 0.0 true true 0 ( 1000)]
] -46.7 MRshow
Blacktext { grestore } if
--
658 140 M
Blacktext { gsave 0 setgray } if
[ [(Symbol) 140.0 0.0 true true 0 (p)]
[(Helvetica) 140.0 0.0 true true 0 ( 0.000000)]
] -46.7 MCshow
Blacktext { grestore } if
--

[...]

6962 140 M
Blacktext { gsave 0 setgray } if
[ [(Symbol) 140.0 0.0 true true 0 (p)]
[(Helvetica) 140.0 0.0 true true 0 ( 1.000000)]
] -46.7 MCshow
Blacktext { grestore } if
--
6311 4739 M
Blacktext { gsave 0 setgray } if
(1./sin\(x/2.\)**4) Rshow
Blacktext { grestore } if
LT0

The "Blacktext" option will indeed put gsave/grestore() pairs around
each string --- but that's just a side effect.  The real problem is that
Rshow relies on the original font (the "(Helvetica) ... findfont" in the
beginning) to still be in effect, but MFshow doesn't seem to save it
across its own invocation, nor does it re-issue a set_font to the
terminal default.

> It seems the gsave-grestore pair is missing in this case.  And
> ENHPS_put_text does not explicitly set the font.  

It shouldn't.  That's for the core to do.  It's the core that should
call term->set_font at the appropriate places.  Apparently, it doesn't
do that.

Apparently current terminal font selection tracking got broken when
enhanced text processing was ripped out of post.trm.

timecolumn()

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

Hello, guys.

A while ago, Ethan asked what the secret function timecolumn() was 
about.  Then, more recently, a bug reporter ended up needing it as the 
way to work around a limitation, but it didn't work...  I just patched 
it and added documentation, but some open issues remain.

timecolumn() is sitting between a rock and a hard place because of the
way I implemented multiple separate timefmt specifications a long time 
ago (part of the 'axis patch'), yet another feature that was never 
actually documented.  Each axis can have its own timefmt string.

But parsing of time/date input doesn't really have anything to with axes 
--- it deals with datafile columns.   Taking into account extended using 
specs, the relation between column numbers and axes is many-to-many, so 
the two really have no particular link to each other.

The obviously correct solution would be to pass a timeformat string 
directly as a second argument to timecolumn().  Back when I added 
per-axis timefmt strings, that wasn't possible.  Nowadays, with the 
stringvariables patch integrated, it probably is.

So: anybody interested in implementing support for

	plot 'file' using (timecolumn(1,'%Y-%m-%d %H:%M:%S')):5

or
	tf1='%Y-%m-%d %H:%M:%S'
	plot 'file' using (timecolumn(1,tf1)):5

Re: auto-generate index for documentation

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

On Saturday 30 April 2005 07:33, Ethan Merritt wrote:
> I've uploaded a patch to SourceForge (#1192870) that modifies
> the generation of gnuplot.tex from .../docs/Makefile.
> It uses the makeindex utility to create an index, which then
> propagates into the TeX-derived documenation (dvi, PostScript, pdf).
>
> Please report any problems.
> For instance, is makeindex universally distributed with TeX?
>
> Also please suggest procedures for identifying what keywords
> in the documentation are worth adding to the index.  Right now
> it's fully automated, but doesn't catch everything it should.

I really like it.  But I'm not sure if also the cross references
should lead to an index entry.  It lessens the value of an average
index reference.

The possibility to explicitly specify an index entry is a good
thing.  The attached patch includes these entries in gnuplot.info.


Juergen

Re: [Gnuplot-developers] [ gnuplot-Bugs-1194516 ] [postscript] default font override

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

On Tuesday 03 May 2005 18:13, Ethan Merritt wrote:
> This is an example of a more general bug that I have not yet been
> able squelch in a satisfactory manner.  In enhanced mode, the first
> font output to the device in a plot sometimes gets "stuck" as the
> default font. Usually this is whatever font is used for the plot title.
> But in your example there is no title, so the first font used is for
> the tics.

The title is not the first text output in the postscript file in
this case.

>
> Trivial work-around:
>
>  set title " "      # Single space force invocation of default font
>
> Fix:
>
> I don't know.  I haven't pinned down exactly when/why this occurs.
> There is not *supposed* to be any difference in the PostScript
> enhanced text processing between version 3.7 and 4.0/4.1
> Obviously some difference has crept in.  The bug crops up in other
> terminal drivers also; it's not just PostScript.

I looked into the postscript output file and played with the
switches.  The problem only occurs if "Blacktext" is false.  It
seems the gsave-grestore pair is missing in this case.  And
ENHPS_put_text does not explicitly set the font.  The attached patch
fixes this at least for the postscript terminal.  There might be a
deeper problem behind this, though ...


Juergen

Re: [Gnuplot-developers] [ gnuplot-Bugs-1194516 ] [postscript] default font override

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

On Tuesday 03 May 2005 08:21 am, SourceForge.net wrote:
> Bugs item #1194516, was opened at 2005-05-03 17:21
> https://sourceforge.net/tracker/?func=detail&atid=102055&aid=1194516&group_id=2055
> Submitted By: Juergen Wieferink (wieferink)
> Summary: [postscript] default font override
> 
> Initial Comment:
> Using the following short script with current CVS version:
> 
> set term post landscape enhanced
> set output "sin4.ps"
> set grid
> set logscale y
> set xtics ("{/Symbol p}/4" pi/4., "{/Symbol p}/2" pi/2.,            "3{/Symbol p}/4" 3.*pi/4., "{/Symbol p}" pi)
> plot [0:pi] [0.1:1000] 1./sin(x/2.)**4
> 
> I get a postscript file where the key is typeset in Symbol font.

This is an example of a more general bug that I have not yet been
able squelch in a satisfactory manner.  In enhanced mode, the first
font output to the device in a plot sometimes gets "stuck" as the
default font. Usually this is whatever font is used for the plot title.
But in your example there is no title, so the first font used is for
the tics.

Trivial work-around:

 set title " "      # Single space force invocation of default font

Fix:

I don't know.  I haven't pinned down exactly when/why this occurs.
There is not *supposed* to be any difference in the PostScript
enhanced text processing between version 3.7 and 4.0/4.1
Obviously some difference has crept in.  The bug crops up in other
terminal drivers also; it's not just PostScript.


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

Re: [Gnuplot-developers] [ gnuplot-Bugs-1194035 ] gnuplot 4.1 coredump with hidden3d set

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

On Monday 02 May 2005 01:32 pm, Way...@su... wrote:
> Bugs item #1194035, was opened at 2005-05-02 13:32
> Message generated for change (Tracker Item Submitted) made by Item Submitter
> You can respond by visiting: 
> https://sourceforge.net/tracker/?func=detail&atid=102055&aid=1194035&group_id=2055

> Summary: gnuplot 4.1 coredump with hidden3d set

>    We think this is a 4.1 bug because we have been
>    running the same a.gp file using gnuplot4.0.0
>    for months...without problems. and i think gnuplto4.1
>    should not core dump but gives a meaningful
>    error msg before it exits.

It turns out that this was a "hidden bug".
The error was already present in 4.0, but it did not cause
a segfault.   Consider the following patch a band-aid, rather than a 
proper fix, because I do not yet understand when/why these illegal
vertices are being created in the first place.  I do note, however,
that the other plotting styles were already testing for (thisvertex<0);
it was only POINTSTYLE that failed to check.

--- gnuplot/src/hidden3d.c      2004-11-08 11:27:29.000000000 -0800
+++ gnuplot-cvs/src/hidden3d.c  2005-05-02 15:50:00.619201816 -0700
@@ -1287,6 +1287,8 @@
 
                case POINTSTYLE:
                default:        /* treat all the others like 'points' */
+                   if (thisvertex < 0) /* Ignore invalid vertex; but how does this happen? */
+                       break;
                    store_edge(thisvertex, edir_point, crvlen, lp, above);
                    break;
                } /* switch */



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

Re: auto-generate index for documentation

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

> I've uploaded a patch to SourceForge (#1192870) that modifies
> the generation of gnuplot.tex from .../docs/Makefile.
> It uses the makeindex utility to create an index, which then
> propagates into the TeX-derived documenation (dvi, PostScript, pdf).

That's good idea. The TeX docs gets the same index as those "hypertext" help
viewers.

---
PM

Re: OpenGL terminal driver

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

On Sun, 1 May 2005, Ethan Merritt wrote:

> Anyhow...
> I pursued it a little bit further using the debugger.
> The segfault came immediately upon attempting to call
> 	 int argc=0;
> 	 glutInit(&argc, NULL);
?
> My GLUT docs tell me that the arguments to this call
> *must* be the original (argc,argv) pair from the actual
> invocation of the running program.  And indeed if I hack
> those in then the program proceeds a little further.

ok. is there any clean way of passing the gnuplot argc,argv to this? I
couldn't see one, but I also know there isn't anything of interest to glut
there anyway. Perhaps I should pass argc=1, and argv[1]="gnuplot"?

> However, it then brings down the entire X-server before displaying 
> anything :=(   

So with a bit of work I might be able to erase the contents of your hard
drive too ;-) There are bugs in my GL_init() code, but I've never been
able to get worse than a segv out of it. I have however found that I get
different results/behaviour on my nVidia card at work than my ATI card at
home, so who knows what is possible.

> Perhaps that is due to the glutMainLoopEvent/glutMainLoop difference?

This approach really wont work.

glutMainLoopEvent takes a single pass through the glutMainLoop and
returns. This means everything stays in control of the calling program.

glutMainLoop transfers control of the program over to glut, and *NEVER
RETURNS*. Everything else is supposed to be done in callbacks. 

I guess if you make glutMainLoopEvent a no-op, and add a call to
glutMainLoop at the end of GL_text(), you would be able to do a single
plot, and then gnuplot would stop responding.

Rob



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: OpenGL terminal driver

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

On Sun, 1 May 2005, Ethan Merritt wrote:

> Mesa+GLUT is packaged as part of both XFree86 and X.org servers
> on current rpm-based linux distros, so anyone with either of these
> included in the base system would not normally go looking for separate
> GLUT impementations.  Both DU4 and Irix come with GLUT as part of the
> OS; I really have no idea exactly what versions (probably old!)

AFAICT, mesa is just redistributing the original GLUT. This reached
version 3.7 in 1998 or something, and hasn't been updated since. 

Freeglut and openglut exist because the non-free license of the original
prevents modified versions to be distributed.

I don't think its fair to criticise Debian for their choice, and it
certainly isn't them that is being "incompatible". Its my code that
doesn't work with your system.

Rob



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: auto-generate index for documentation

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

On Fri, 29 Apr 2005, Ethan Merritt wrote:

> For instance, is makeindex universally distributed with TeX?

Yes.

> Also please suggest procedures for identifying what keywords
> in the documentation are worth adding to the index.  Right now
> it's fully automated, but doesn't catch everything it should.

Maybe, we could introduce something like "\(word to index\)" then indexes
the thinks between \( and \). In my opinion, the indexed text should not
appear in the text itself because both can differ (due to plural,
genitive, etc.).

Best regards
Harald

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