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

Re: Ready for wrap-up everyone?

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

On Mon, 5 Apr 2004, Per Persson wrote:

> Sorry, no time to do that now (I'm not really sure of the proper way to 
> do it). Will have to wait until after the release.

Well, if anyone complains, we'll just blame you, then ;-)

> OTOH, nobody is expecting a binary for Mac OS X, I think.

They're not?  That's a surprise to me.  I was under the impression Apple
users were pretty much like those of Windows concerning wielding a
compiler to get some program installed --- they consider it a dangerous
thing only to be undertaken by experts.  What would be the purpose of the
"fink" project then?

For releases before 4.0, MacOS users didn't have binaries provided by the
gnuplot team itself, and that was quite a mess which I think we really
should try to avoid, if possible.  There were versions of gnuplot
specially adapted to macintosh, but those changes were lost because they
never were brought back into the mainline sources.


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

Re: Ready for wrap-up everyone?

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

On Mon, 5 Apr 2004, Lars Hecking wrote:

> > *) Lars: contact Tom Williams (and whoever else you contacted last
> >    time) for the formal "blessing" according to the gnuplot Copyright
> >    statement.
>  
>  In progress - do we have some form of "what's new in 4.0" that I can
>  attach?

You could attach the head of "NEWS", or point at the What's New page at
gnuplot.sf.net by Petr.

> > *) Lars also seems to be the only person who can reliably generate a
> >    working 'gnuplot.texi' (my boxes are all either too old or
> >    too new to run doc2texi.el).  
>  
>  Strange, I usually keep XEmacs around here quite up to date.

Well, my private SuSE box barfs for some missing elisp function, and my
RedHat box generates a .texi that differs from yours in subtle ways.
Actually, since I routinely build outside the source tree, the build of
gnuplot.texi fails completely anyway.  It fails to pick up the entire
terminal driver section, and up until recently, the corresponding rule in
docs/Makefile.in was completely crazy.

Here's an excerpt from the cvs diff -uwp between what I get on RedHat
(Using RH's emacs 21.2-2) and the version currently in CVS, cut to the
differences not explainable by recent changes to gnuplot.doc:

@@ -692,7 +692,7 @@ The Atari version of readline defines so
       Ctrl Home       - same as ^E.
       Esc             - same as ^U.
       Help            - @ref{help} plus return.
-      Ctrl Help       - `help `.
+      Ctrl Help       - @ref{help}.

 @end example

@@ -9723,6 +9724,7 @@ to you, depending on its output format.
 * kyo::
 * latex::
 * linux::
+* linux_::
 * macintosh::
 * mf::
 * mp::
@@ -9743,7 +9745,6 @@ to you, depending on its output format.
 * regis_::
 * rgip::
 * sun::
-* sun_::
 * svg::
 * tek410x::
 * tek410x_::
@@ -12081,7 +12082,24 @@ environment variable GSVGAMODE for the d
 1024x768x256 as default mode or, if that is not possible, 640x480x16
 (standard VGA)."

-@node macintosh, mf, linux, terminal
+@node linux_, macintosh, linux, terminal
+@subsubsection linux
+
+@c ?commands set terminal linux
+@c ?set terminal linux
+@c ?set term linux
+@c ?terminal linux
+@c ?term linux
+@cindex linux
+@tmindex linux
+
+
+The `linux` driver has no additional options to specify.  It looks at the
+environment variable GSVGAMODE for the default mode; if not set, it uses
+1024x768x256 as default mode or, if that is not possible, 640x480x16
+(standard VGA)."
+
+@node macintosh, mf, linux_, terminal

My copy of gnuplot.texi actually has *two* copies of the 'linux'
node, and I have no idea whatsoever where it might be picking that
up from.

@@ -13365,22 +13383,7 @@ puts six graphs on a page in three rows
 The `sun` terminal driver supports the SunView window system.  It has no
 options."

-@node sun_, svg, sun, terminal
-@subsubsection sun
-
-@c ?commands set terminal sun
-@c ?set terminal sun
-@c ?set term sun
-@c ?terminal sun
-@c ?term sun
-@cindex sun
-@tmindex sun
-
-
-The `sun` terminal driver supports the SunView window system.  It has no
-options."
-
-@node svg, tek410x, sun_, terminal
+@node svg, tek410x, sun, terminal

... It appears your build makes the same kind of error, just in a
different place.

>  gnuplot.texi should be up to date, too. I'm running a make to see if
> there are changes.

The important thing is that this has to be done immediately before the
final source tarball is made.  I've just run "make dist" for the release
candidate, but a little careful checking of the result would be in order
for the real thing.

> >    All ready by, let's say, Friday this week?
> 
>  You forgot that Easter is coming up. I will be out of the office
>  from Friday to Monday, inclusive.

Hmmm... so I guess that means we'll miss the proclaimed release target
date by a day or two, and release next week.  Not a big problem I presume.


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

Re: Ready for wrap-up everyone?

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

> > Where do the released files go?
> > - sourceforge
> > - darthmouth??
> > - CTAN
>
>  I think all major sites (mirror.ac.uk, CTAN) are mirroring from UCC.

Is the information in README and INSTALL still up-to-date? Should
gnuplot.sf.net / Files be mentioned too?

> > *) FAQ vs FAQ.html:
> > I would prefer to enclose FAQ.html instead of the plain text FAQ.
>
>  Dto.

I think that for OS/2 and Windows distributions, there will be FAQ.html.
Web browser is always on these platforms.

> > *) BUGS:
> > A note about Atari, Lars can remove that?
>
>  Should probably go. Entry 8 should probably move to the FAQ.

already cleaned-up

---
PM

Re: Ready for wrap-up everyone?

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

On Monday 05 April 2004 12:02 pm, Petr Mikulik wrote:
>
> > *) Distribute work on binary packages for PCs.
> >
> >    One important note: I don't think we can provide binaries with
> >    the pdf driver compiled in.  It's "non-commercial use only".

I'm not so sure.  I think we are OK to include it ourselves since
gnuplot source code is available, and since gnuplot itself is not
a commercial product.   A problem could arise, however, if 3rd
parties used a gnuplot binary for commercial development.
I will not venture an opinion on 3rd party use of a gnuplot for
commercial non-development work.

The only way to be certain is to ask them:

	License inquiries: sa...@pd...


Here are is the license description from the readme of pdflib
version 4.0.3

Licensing and Copyright
=======================
THIS IS NOT PUBLIC DOMAIN OR FREEWARE SOFTWARE!

PDFlib is available under two different licensing terms which are
substantially different, and meet the needs of different developer groups.
Please take the time to read the short summaries below in order to decide
which one applies to your development.


The Aladdin Free Public License
-------------------------------
This license applies to the main PDFlib package, but not to the
ActiveX, .NET, and EBCDIC editions or any of our precompiled
binary versions (all of these are only
available under the terms of the commercial PDFlib license). The
complete text of the license agreement can be found in the
file aladdin-license.pdf. In short and non-legal terms:

- You may develop free software with PDFlib, provided you make your source
  code available.
- You may develop software for your own use with PDFlib, as long as you
  don't sell it.
- You may redistribute PDFlib non-commercially.
- You may redistribute PDFlib on digital media if the complete contents of
  the media are freely redistributable.
  
Only the text in the file doc/aladdin-license.pdf is considered to completely
describe the licensing conditions. Project managers please note: Using PDFlib
in your commercial projects is not covered by the Aladdin license, and
effectively means jeopardizing your project through unlicensed software!

License inquiries: sa...@pd...

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

Re: Ready for wrap-up everyone?

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

> Where do the released files go?
> - sourceforge
> - darthmouth??
> - CTAN
 
 I think all major sites (mirror.ac.uk, CTAN) are mirroring from UCC.

> *) README (several of them) vs README.html:
> I remember someone has contributed html-ized version of README, where is
> its end nowadays?
 
 I am strictly against replaing plain-text READMEs with html versions.

> *) FAQ vs FAQ.html:
> I would prefer to enclose FAQ.html instead of the plain text FAQ.

 Dto.

> I will please majority of users I guess.
> Anyway, should the FAQ file be in gnuplot sources anyway? Maybe it could be
> removed from there.
 
 I think it's good style to include it, but I'm not feeling strongly about it.

> *) BUGS:
> A note about Atari, Lars can remove that?
 
 Should probably go. Entry 8 should probably move to the FAQ.

Re: Ready for wrap-up everyone?

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

> *) HB or Lars make a source tarball.
>
>    Circulate that in private (Lars' ftp server?  Or the project home
>    directory at sf.net?) to check for last-minute glitches.

Where do the released files go?
- sourceforge
- darthmouth??
- CTAN

> *) Distribute work on binary packages for PCs.
>
>    One important note: I don't think we can provide binaries with
>    the pdf driver compiled in.  It's "non-commercial use only".

If someone proofs this, then binaries will be without this feature.

>    I would volunteer building the 32-bit DOS version (DJGPP).
>    Cygwin by Petr (both Unix gnuplot/X11 and Win32 wgnuplot/pgnuplot,
>                    in a single or two separate packages)?

I can organize the following:

1. OS/2 binary.

2. Mingw binary -- probably with two executables: one normal, the other with
PIPES defined for more unixish users

3. Cygwin+X11 by ./configure; make

>    'docs tarball' by Lars?

A prerelease of 1. and 2. is at www.sci.muni.cz/~mikulik/gnuplot/
I think FAQ should be replaced by FAQ.html
Any other thing proposed to be there?

>    All ready by, let's say, Friday this week?

Yes, till Friday.


Other comments:


*) File README.1st:

This text is to be deleted?

 Note 3
 ------
 some files from Bruce Ravel's gnuplot-mode distribution have
   not been included here, namely

   o INSTALL              (covered by gnuplot install instructions)
   o Win9x/INSTALL.Win9x
   o Win9x/pgnuplot.c     (already in src/win)
   o gnuplot.info         (can be created from docs/gnuplot.texi)
   o gpelcard.ps          (can be created from lisp/gpelcard.tex)
   o install-sh, mkinstalldirs  (provided by gnuplot)


*) README (several of them) vs README.html:
I remember someone has contributed html-ized version of README, where is
its end nowadays?

*) INSTALL (several of them):
Should be unified too.

*) FAQ vs FAQ.html:
I would prefer to enclose FAQ.html instead of the plain text FAQ.
I will please majority of users I guess.
Anyway, should the FAQ file be in gnuplot sources anyway? Maybe it could be
removed from there.


*) BUGS:
A note about Atari, Lars can remove that?


---
PM

Re: Ready for wrap-up everyone?

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

> The only problem/annoyance I have is that the 'make' process tries
> to update files in the system directory /usr/share/emacs/site-lisp/,
> which means that I get error messages if I'm not building as root.
> Seems to be harmless, though.
 
 I don't get that here either, and I never ever build as root.

Re: Ready for wrap-up everyone?

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

On Monday 05 April 2004 10:55 am, Lars Hecking wrote:
>On Monday 05 April 2004 10:35 am, Hans-Bernhard Broeker wrote:
>
> > *) Lars also seems to be the only person who can reliably generate a
> >    working 'gnuplot.texi' (my boxes are all either too old or
> >    too new to run doc2texi.el).
>
>  Strange, I usually keep XEmacs around here quite up to date.

I have never had any trouble generating gnuplot.texi locally,
but I cannot say whether once generated it works for everyone else. 

The only problem/annoyance I have is that the 'make' process tries
to update files in the system directory /usr/share/emacs/site-lisp/,
which means that I get error messages if I'm not building as root.
Seems to be harmless, though.


As to the rest of it - great!  I look forward to the release.

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

Re: Ready for wrap-up everyone?

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

> Sorry, no time to do that now (I'm not really sure of the proper way to 
> do it). Will have to wait until after the release.
> OTOH, nobody is expecting a binary for Mac OS X, I think.
 
 Nobody expects the Spanish Inquisition, either. That surprise worked
 pretty well ;-)

Re: Ready for wrap-up everyone?

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

On Apr 5, 2004, at 19:35, Hans-Bernhard Broeker wrote:

> *) Distribute work on binary packages for PCs.

[snip]

>    MacOS by Per?

Sorry, no time to do that now (I'm not really sure of the proper way to 
do it). Will have to wait until after the release.
OTOH, nobody is expecting a binary for Mac OS X, I think.

/Per

Re: Ready for wrap-up everyone?

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

On Apr 5, 2004, at 19:55, Lars Hecking wrote:

>
>> *) Lars also seems to be the only person who can reliably generate a
>>    working 'gnuplot.texi' (my boxes are all either too old or
>>    too new to run doc2texi.el).
>
>  Strange, I usually keep XEmacs around here quite up to date.
>
>  gnuplot.texi should be up to date, too. I'm running a make to see if 
> there
>  are changes.

Petr asked me to add aquaterm refs to the pm3d section etc., I'll do 
that ASAP but the connection to SF CVS is shaky right now.
I intend to touch NEWS and gnuplot.doc within the hour.

/Per

Re: Ready for wrap-up everyone?

[Daniel J S. <dan...@ie...>]

Lars Hecking wrote:

>>*) Lars: contact Tom Williams (and whoever else you contacted last
>>   time) for the formal "blessing" according to the gnuplot Copyright
>>   statement.
>>    
>>
> 
> In progress - do we have some form of "what's new in 4.0" that I can
> attach?
>  
>

Someone put a list of new items at:

http://gnuplot.sourceforge.net/docs/gnuplot.html#What_is_New_in_Version_4.0


Dan

Re: Troubles with recent GD on Win32

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

As best as I can make out by inspection of the libgd source, the
difficulty arises not from anything on our end, but from the 
environment at the time the libgd dll was built. 

The fonts are declared extern, or not, based on the following
hack in gd.h.  (This is not new to 2.0.22, by the way; it was
introduced several versions back)

/* Do the DLL dance: dllexport when building the DLL,
        dllimport when importing from it, nothing when
        not on Silly Silly Windows (tm Aardman Productions). */

/* 2.0.20: for headers */
#ifdef BGDWIN32
#define BGD_EXPORT __declspec(dllexport)
#else
#ifdef WIN32
#define BGD_EXPORT __declspec(dllimport)
#else
/* 2.0.19: should be 'extern', especially for font data pointers */
#define BGD_EXPORT extern
#endif /* WIN32 */
#endif /* BGDWIN32 */


So in a non-windows environment they are always declared extern,
and everything works.  In windows - well, I don't know.  Someone
who actually builds under windows can tell better than I.

My impression from reading the release notes is that this issue is one
that bit people building the dlls under windows, and the new routines
were added to bypass the problem.


On Monday 05 April 2004 10:11 am, Hans-Bernhard Broeker wrote:
> Hi, everyone,
>
> looks like user just found a gnuplot build problem with the latest
> version of GD used on Win32/MSVC++. The gdFontPtr variables for the 5
> builtin fonts of the gd library came back as undefined externals. 
> Looking into this revealed the following:
>
> 1) gd.trm (and gif.trm, too...) contains our own private "extern"
> declarations rather than #include's of the corresponding headerfiles
> provided by GD.  Does any of us see a reason we shouldn't just #include
> those?

I don't think that will fix it, though I could be wrong.  The problem is that
the dll is not exporting it properly in the first place.

> 2) Tom Boutell added getter functions for those globals to his library,
> specifically for the purpose of fixing problems of Win32 DLLs, but
> without going into details about those problems.  Does this ring any
> bell to any of us? Should we bother and patch gnuplot to use these (and
> introduce yet another version check on GD for this)?  Or should we just
> put a note into INSTALL that GD version 2.0.22 won't work with gnuplot?

I'm just going by inspection of the libgd source files, but so far as I can
see nothing changed in 2.0.22.   I conclude that this has been a problem
all along if the dll was not built correctly.  Rather than fixing the problem
directly, 2.0.22 adds these separate functions as a work-around that
bypasses the question of whether the font pointers are correctly exported.

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

Re: Ready for wrap-up everyone?

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

> *) Lars: contact Tom Williams (and whoever else you contacted last
>    time) for the formal "blessing" according to the gnuplot Copyright
>    statement.
 
 In progress - do we have some form of "what's new in 4.0" that I can
 attach?

> *) Lars also seems to be the only person who can reliably generate a
>    working 'gnuplot.texi' (my boxes are all either too old or
>    too new to run doc2texi.el).  
 
 Strange, I usually keep XEmacs around here quite up to date.

 gnuplot.texi should be up to date, too. I'm running a make to see if there
 are changes.

> *) HB or Lars make a source tarball.
> 
>    Circulate that in private (Lars' ftp server?  Or the project home
>    directory at sf.net?) to check for last-minute glitches.
 
 Ok.

>    'docs tarball' by Lars?

 Ok.

>    All ready by, let's say, Friday this week?

 You forgot that Easter is coming up. I will be out of the office
 from Friday to Monday, inclusive.

> *) For previous releases, Lars provided digital signatures.  I think
>    this should happen for this one, too.
 
 Ok.

Ready for wrap-up everyone?

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

Hello,

in case some of us forgot, the release target date I agreed us upon was
end of *this* week?

So, what's left to do that really has to be done before then?

*) Lars: contact Tom Williams (and whoever else you contacted last
   time) for the formal "blessing" according to the gnuplot Copyright
   statement.

*) Lars also seems to be the only person who can reliably generate a
   working 'gnuplot.texi' (my boxes are all either too old or
   too new to run doc2texi.el).  

*) HB: update Copyright years in all source files (!).

*) HB or Lars make a source tarball.

   Circulate that in private (Lars' ftp server?  Or the project home
   directory at sf.net?) to check for last-minute glitches.

*) Distribute work on binary packages for PCs.  

   One important note: I don't think we can provide binaries with
   the pdf driver compiled in.  It's "non-commercial use only".

   I would volunteer building the 32-bit DOS version (DJGPP).
   Cygwin by Petr (both Unix gnuplot/X11 and Win32 wgnuplot/pgnuplot,
                   in a single or two separate packages)?
   MacOS by Per?
   'docs tarball' by Lars?
   All ready by, let's say, Friday this week?

*) For previous releases, Lars provided digital signatures.  I think
   this should happen for this one, too.

*) Upload on Saturday, announcement ASAP.

If you spot major omission or want to reject assignments, please say so.

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

Troubles with recent GD on Win32

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

Hi, everyone, 

looks like user just found a gnuplot build problem with the latest version
of GD used on Win32/MSVC++. The gdFontPtr variables for the 5 builtin
fonts of the gd library came back as undefined externals.  Looking into
this revealed the following:

1) gd.trm (and gif.trm, too...) contains our own private "extern" 
declarations rather than #include's of the corresponding headerfiles
provided by GD.  Does any of us see a reason we shouldn't just #include
those?

2) Tom Boutell added getter functions for those globals to his library,
specifically for the purpose of fixing problems of Win32 DLLs, but without
going into details about those problems.  Does this ring any bell to any
of us? Should we bother and patch gnuplot to use these (and introduce yet
another version check on GD for this)?  Or should we just put a note into
INSTALL that GD version 2.0.22 won't work with gnuplot?

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

BUGS file

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

I've removed two obsolete entries from $Subj. Can somebody else have a look
to this file too and remove more?

Maybe those marked as "[Status: unknown]" could be removed too.

Link to gnuplot's sf bug tracker was added there too.
---
PM

Re: new line in labels (post enh)

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

On Friday 02 April 2004 01:30 am, Giuseppe G. N. Angilella wrote:
> Mmm. That does not work with keys, at least, e.g. with
>
> set term post enh
> set out 't.ps'
> plot x t "first line\nsecond line"
>
> (It does work with set label, on the contrary, as is indeed explained in
> help syntax.)
>
> Is that a bug?

Let's call it a "design decision" rather than a bug.

The key box layout is calculated, and space is reserved
for it, before any of the plots are actually generated.
The routine that does this size calculation doesn't know
exactly what is going to be printed for each plot title,
so it only reserves one line per plot.  Consistent with
this, when it is time to actually print out the plot key title
gnuplot calls term->put_text directly rather than calling
write_multiline().  Because of this, newline characters are
not  expanded into actual line breaks.

If you were to call write_multiline() instead, the first
title would indeed span multiple lines. But then the 
next title printed would be placed right on top of the
second line of your first title, which is no good.

If we were to allow multi-line plot key entries, we would
have to totally re-write the key generation code.
That would be a very large task, although if someone
wants a gnuplot development project to work on that
is a good candidate.  The key generation code has
built up into a horrible tangle, and starting over could
potentially make it much cleaner and extensible.  


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

Re: new line in labels (post enh)

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

On Fri, 2 Apr 2004, Giuseppe G. N. Angilella wrote:

> Hi,
> 
> > Writing the string in "double quotes" and using "one line \n next line"
> > should work, as explained in "help syntax".
> 
> Mmm. That does not work with keys, at least, e.g. with
> 
> set term post enh
> set out 't.ps'
> plot x t "first line\nsecond line"

This may be an artifact of the '{no}enhanced' option of 'set key'.
Or maybe plot key entries aren't subjected to "double quoted" string
processing.

> Is that a bug?

Maybe.

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

Re: new line in labels (post enh)

[Giuseppe G. N. A. <Giu...@ct...>]

Hi,

> Writing the string in "double quotes" and using "one line \n next line"
> should work, as explained in "help syntax".

Mmm. That does not work with keys, at least, e.g. with

set term post enh
set out 't.ps'
plot x t "first line\nsecond line"

(It does work with set label, on the contrary, as is indeed explained in 
help syntax.)

Is that a bug?

> You may want to upgrade to 3.8k.3, the current release candidate.
> 4.0 is imminent, and we can use all the testing we can get.

Thanks, I will. I am looking forward to 4.0, by the way!

Thanks again.

Giuseppe.

Re: Mac OS X driver.

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

On Wednesday 31 March 2004 04:22 am, Hans-Bernhard Broeker wrote:
> On Tue, 30 Mar 2004, Ethan Merritt wrote:
> > On Tuesday 30 March 2004 01:17 pm, Per Persson wrote:
> > > I was a little curious about the reason for the overlap between
> > > filled_polygon() and boxfill(), any particular reason?
> >
> > Two parallel projects that got incompletely merged.
>
> That's not the entire truth, though.  There's also the problem that
> doing cross-hatching pattern-fill of arbitrary polygons is at least an
> order of magnitude harder than either cross-hatching of axis-aligned
> rectangles or solid-colour filling of arbitrary polygons.

I worried about that originally, but it turns out not to be a problem
in practice.  Other people have already done the hard work, and
included the necessary support in the relevant libraries or languages.

The patch on SourceForge shows that pattern-fill of polygons
works with no special effort for pdf, png, svg and x11.

There is an issue with PostScript, but it's more a question 
of policy than of difficulty.  PostScript pattern-fill requires 
PostScript Level 2 language support. This is nearly universal
by now, but not quite.  The question is, what should we fall
back to if it is requested but not present?  It seems to me that
at worst we fall back to doing nothing at all, which is what
happens in the current version anyway. 

That leaves Windows as the largest gap in implementation.
Is pattern-fill so horribly difficult in Windows?  The current 
code in src/win/wgraph.c does this:
	idx = <expression that evaluates to pattern number>;
	SelectObject(hdc, pattern_brush[idx]);
That suggests to me that the pattern-fill support can be
applied to any sort of object, but I could be wrong.


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

Re: new line in labels (post enh)

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

On Thu, 1 Apr 2004, Giuseppe G. N. Angilella wrote:

> Hi,
> 
> is there any simple way to write a label (or a key etc) on separate lines, 
> within the enhanced postscript terminal?

Writing the string in "double quotes" and using "one line \n next line"
should work, as explained in "help syntax".


> I'm using gnuplot Version 3.8j patchlevel 0 on Linux 2.4.20-8.

You may want to upgrade to 3.8k.3, the current release candidate.
4.0 is imminent, and we can use all the testing we can get.

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

new line in labels (post enh)

[Giuseppe G. N. A. <Giu...@ct...>]

Hi,

is there any simple way to write a label (or a key etc) on separate lines, 
within the enhanced postscript terminal?

I'm using gnuplot Version 3.8j patchlevel 0 on Linux 2.4.20-8.

Thank you in advance.

Giuseppe.

Re: hidden3d very slow in gnuplot 3.8k

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

On Wed, 31 Mar 2004, Hans-Bernhard Broeker wrote:

> The root of this problem is 500x300 is a rather excessive number of 
> points to plot as a wireframe mesh.  You'll want to build gnuplot with
> the undocumented flag -DTEST_QUADTREE=1 in this case.

I've now renamed this flag and made it user-configurable in the CVS
version.

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

Re: hidden3d very slow in gnuplot 3.8k

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

> Hi, I have been plotting some data I have that has a large number of
> points say 500x300. I have noticed that this is considerably slower in
> gnuplot 3.8 that 3.7.3, so much so that i have reverted back to the
> previous version. Has anyone else come across this?

For such a large number of points, isn't it better to draw a color surface
using 'set pm3d' or 'set pm3d map'? The former has even its own hidden3d
functionality based on overwriting.

---
Petr Mikulik