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

Re: partly ignored TextSize in wgnuplot.ini

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

> Amazing. It really does work. Gee, I wish I had known to try this earlier.
> OK - so I downloaded  gp38k1cyg.zip from SourceForge and
> I am running it under Crossover/Wine in a KDE desktop.
>
> Things I notice that may or may not be bugs:
>
> - Rotated text doesn't rotate to angles other than 90 degrees.
> Was general text rotation never added to the windows code?

Never; see TODO file

> - (I will now display my great ignorance of the Windows world :-)
> I see that this windows build does not support enhanced text mode,
> yet I know that Petr has said it works under os2.  Is the os2
> environment so different  from windows that the same driver
> code cannot support both?

OS/2 implementation is like X11 -- an independent executable for terminal
driver and a pipe communication. Enhanced text support was added ages ago,
after postscript.

Windows has only 1 executable.

> > The only thing not available is "Save current settings to wgnuplot.ini" and
> > similar menu option which are located under the current window menu (of the
> > window manager), which obviously X11 does not allow.
>
> For me that menu works fine so long as I first say "unset mouse".
> Well, some fonts work and some don't, but I suspect that is a wine problem.

Aha, I was not clicking the proper area.

---
PM

Re: partly ignored TextSize in wgnuplot.ini

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

On Wednesday 07 April 2004 11:09 am, Ethan Merritt wrote:
> On Wednesday 07 April 2004 12:38 am, Petr Mikulik wrote:
> > (btw, wgnuplot.exe runs also under wine in linux),

Amazing. It really does work. Gee, I wish I had known to try this earlier.
OK - so I downloaded  gp38k1cyg.zip from SourceForge and
I am running it under Crossover/Wine in a KDE desktop.

Things I notice that may or may not be bugs:

- Rotated text doesn't rotate to angles other than 90 degrees.
Was general text rotation never added to the windows code?

- In 'fillstyle.dem' some of the box borders seem to be drawn
1 pixel off from the box interior fill. 

- (I will now display my great ignorance of the Windows world :-)
I see that this windows build does not support enhanced text mode,
yet I know that Petr has said it works under os2.  Is the os2
environment so different  from windows that the same driver
code cannot support both?

Petr Mikulik wrote:
> The only thing not available is "Save current settings to wgnuplot.ini" and
> similar menu option which are located under the current window menu (of the
> window manager), which obviously X11 does not allow.

For me that menu works fine so long as I first say "unset mouse".
Well, some fonts work and some don't, but I suspect that is a wine problem.
 
-- 
Ethan A Merritt       merritt@u.washington.edu
Biomolecular Structure Center
Mailstop 357742
University of Washington, Seattle, WA 98195

Re: possible missing entry in configure.in

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

James R. Van Zandt writes:
> 
> I'd like to see the following change in autoconfiguration.  It fixed a
> build problem I was having.  I don't remember the details now, but
> they involved my having two versions of automake installed, and
> without this change both versions were run for different parts of the
> build resulting in incompatible files.
> 
> I'd be glad to check this in, but don't want to break something this
> close to release.
 
 Please describe the problem in detail. The change is neither required,
 nor does it make sense, because lisp/Makefile is generated by
 lisp/configure.

Re: partly ignored TextSize in wgnuplot.ini

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

> > I tried to reproduce this (btw, wgnuplot.exe runs also under wine in
> > linux),
>
> But at this point I suppose I might as well wait for the version 4
> executable.  Does it require any dlls on the side? fonts?

Binary compiled by Mingw does not need any dll.

The only thing not available is "Save current settings to wgnuplot.ini" and
similar menu option which are located under the current window menu (of the
window manager), which obviously X11 does not allow. You have to get
wgnuplot.ini from Windows and edit it by hand to change fonts and startup
window sizes.

---
PM

possible missing entry in configure.in

[James R. V. Z. <jr...@co...>]

I'd like to see the following change in autoconfiguration.  It fixed a
build problem I was having.  I don't remember the details now, but
they involved my having two versions of automake installed, and
without this change both versions were run for different parts of the
build resulting in incompatible files.

I'd be glad to check this in, but don't want to break something this
close to release.

	 - Jim Van Zandt

Index: configure.in
===================================================================
RCS file: /cvsroot/gnuplot/gnuplot/configure.in,v
retrieving revision 1.142
diff -u -r1.142 configure.in
--- configure.in	31 Mar 2004 15:42:51 -0000	1.142
+++ configure.in	8 Apr 2004 01:27:38 -0000
@@ -820,6 +820,7 @@
            config/Makefile
            demo/Makefile
            docs/Makefile
+           lisp/Makefile
            m4/Makefile
            man/Makefile
            src/Makefile

Re: partly ignored TextSize in wgnuplot.ini

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

On Wednesday 07 April 2004 12:38 am, Petr Mikulik wrote:
> I tried to reproduce this (btw, wgnuplot.exe runs also under wine in
> linux),

Does it really?  Then I should install a copy for reference.
But at this point I suppose I might as well wait for the version 4
executable.  Does it require any dlls on the side? fonts?

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

Re: partly ignored TextSize in wgnuplot.ini

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

On Wed, 7 Apr 2004, Petr Mikulik wrote:

> A user of wgnuplot.exe is reporting that the width specified as
> 	TextSize=648 576
> item in wgnuplot.ini is ignored for large values of width (the first
> number). He cannot get window width larger than sth like 808 pixels.
> He is using font FixedSys, and then only 69 out of 80 characters can be
> placed on the command line for that width. He claims this as bug (of
> course).

This is a strange one indeed.  Walking through wgnuplot, here's what 
happens:

*) win/wtext.c:ReadTextIni() correctly set lptw->Size to the requested
size from wgnuplot.ini

*) win/wtext.c:TextIni() uses that size to initialize the window size of
the "Parent window" (the main text window, with the menu bar and the
actual text window inside)

*) Next, TextIni() calls GetClientRect() to determine the size of the
actual text window area, and that one comes out with a width of 640,
even though lptw->Size was 808.

Something's seriously fishy here.

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

Re: minor bug regarding time/date graphs

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

On Wed, 7 Apr 2004, Hans-Bernhard Broeker wrote:

> Consider yourself somewhat lucky, then.  I don't think sequence ticks
> have ever worked well in gnuplot.  

Duh.  An important part of that statement didn't make it from brain to
keyboard: it's only sequence tics on *time/date* axes that are this shaky.

> The crucial variable is axis_array[].format_is_numeric.  It's set
> to FALSE in the case at hand, and that's wrong.  I'll look into this.

Did that, found and fixed it in the CVS sources.  The bug was in
set.c:looks_like_numeric().  That function was utterly broken completely
at least since the default format was changed from '%g' to '% g'.

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

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.
 
 I thought I'd share this with all of you :)

----- Forwarded message -----
Lars,

It has been a long time!  Good to know you're still helping out with
Gnuplot.   It looks like the 4.0 features are great, I really like the
website Petr put together.  Look forward to hearing about the official
release!

-thaw-
Thomas Williams
GenSys Software www.gensys.com  
----- End forwarded message -----

Re: minor bug regarding time/date graphs

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

On Wed, 7 Apr 2004, Pieter-Tjerk de Boer wrote:

> If one gives the following commands in gnuplot (version 3.8k.3):
>   set xdata time
>   set timefmt x "%d %b %Y"
>   set xtics border mirror norotate "01 Jan 1999",3.1557e+07
>   set xra ["01 Oct 1998":"01 May 2004"]
>   p x
> one gets a (trivial) graph, with labels on the horizontal axis
> starting at 01/01/1999.

Consider yourself somewhat lucky, then.  I don't think sequence ticks have
ever worked well in gnuplot.  This has improved considerably, but I
wouldn't bet the farm on that stuff anytime soon.

> However, after saving this and then loading the resulting file
> into a freshly started gnuplot, the date axis labels starts
> at 01/01/2000.

That's indeed caused by the 'timefmt' being written to the save file
too late in the list.  Rearranging save_all() will fix that.

> Furthermore, the labels are all simply 'g' rather than numerical
> dates.

Hmm... this version here gives me a '9' instead.

That's because you didn't have an explicit "set format x" in your script.
So gnuplot had to invent a time/date format string for the x axis.  Such
invented format strings aren't written back into the 'set format'
variables, so after the commands you gave, 'show format' will still show
the default '% g' for all axes.

> - gnuplot puts the "set format x ...." line after the "set xdata time"
>   line, which apparently overrides the label format (implicitly?) set
>   by the latter.

No, that override only happens at 'plot' time, but it's sensitive to
whether you just never gave a 'set format' for that axis at all (i.e. it's
still in the default state), or you explicitly requested a particular
format.  Loading a saved file will look like an explicit request, and thus
will be honoured.

Using a script-reduction tool like the one Petr put on the gnuplot.sf.net
web pages will solve this mystery, by removing the 'set format x "% g"'
lines from the saved scripts.

The crucial variable is axis_array[].format_is_numeric.  It's set
to FALSE in the case at hand, and that's wrong.  I'll look into this.


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

minor bug regarding time/date graphs

[Pieter-Tjerk de B. <ptd...@cs...>]

Hello,

I'm sorry to interrupt the 4.0 release preparations, but this minor bug
may be easy to fix in time for the release.

If one gives the following commands in gnuplot (version 3.8k.3):
  set xdata time
  set timefmt x "%d %b %Y"
  set xtics border mirror norotate "01 Jan 1999",3.1557e+07
  set xra ["01 Oct 1998":"01 May 2004"]
  p x
one gets a (trivial) graph, with labels on the horizontal axis
starting at 01/01/1999.
However, after saving this and then loading the resulting file
into a freshly started gnuplot, the date axis labels starts
at 01/01/2000.
Furthermore, the labels are all simply 'g' rather than numerical
dates.

The causes seem to be that, when saving:
- gnuplot puts the "set xtics ...." line before the "set timefmt ..."
  line, so when reading, it doesn't yet know how to interpret the
  date appearing in the "set xtics ...." line.
- gnuplot puts the "set format x ...." line after the "set xdata time"
  line, which apparently overrides the label format (implicitly?) set
  by the latter.

Changing the order in which the lines are saved presumably would solve
this bug, but I don't know whether that could introduce any new problems.

Best regards,
  Pieter-Tjerk

partly ignored TextSize in wgnuplot.ini

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

A user of wgnuplot.exe is reporting that the width specified as
	TextSize=648 576
item in wgnuplot.ini is ignored for large values of width (the first
number). He cannot get window width larger than sth like 808 pixels.
He is using font FixedSys, and then only 69 out of 80 characters can be
placed on the command line for that width. He claims this as bug (of
course).

I tried to reproduce this (btw, wgnuplot.exe runs also under wine in linux),
and really, for some larger values of TextSize width, the number is ignored,
and it somehow depends on font ... someone knows what's going wrong?
---
PM

Re: gnuplot with libgd for Windows?

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

On Tue, 6 Apr 2004, Ethan Merritt wrote:

> On Tuesday 06 April 2004 10:24 am, you wrote:

> > So it seems we could withdraw to a position stated in INSTALL that says:
> >
> > gnuplot+Windows+(current GD built as DLL)+(no libfreetype) == NO GO
> 
> But even if freetype is present, we would still need conditional code in
> gd.trm so that it doesn't generate unresolved symbol errors at build time,
> right?

Right.  Oversight on my end.

> Is it easy to build libgd as static under windows?  

I say we leave that to Petr, since he's going to be doing the Windows
builds, and he said he's been using static libs all the time and it works.


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

OS X binaries [Was: Ready for wrap-up everyone?]

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

On Apr 6, 2004, at 13:15, Hans-Bernhard Broeker wrote:

> 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 ;-)

No problem, I can handle that. ;-)

>
>> OTOH, nobody is expecting a binary for Mac OS X, I think.
>
> They're not?

With the emphasis on _expecting_, from the gnuplot team, and right from 
day one: No.
I bet they would _like_ a binary though.

> That's a surprise to me.

Well, you know our chief weapon is surprise...surprise and fear...fear 
and surprise.... Our two weapons are fear and surprise... [1]

>  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?

You are pretty much right about this, although these days quite a few 
Mac users are from the Unix/Linux camp too.

>
> 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.

Yes, I agree.

> There were versions of gnuplot
> specially adapted to macintosh, but those changes were lost because 
> they
> never were brought back into the mainline sources.

I'd like to get this right and just throwing something together for 
friday or even next friday seems a bad idea. Just to get things 
started, I'll list the main options that comes to mind:


1) A static build of gnuplot.
	Standard double-clickable installer.
	Installs into /usr/local etc.
	Comes with a double clickable script[2] that can be freely moved 
around by the user.
	Static build may be trickier than it sounds, I don't know yet.	
2) A "normal" build of gnuplot.
	Standard double-clickable installer.
	Installs into /usr/local etc.
	Comes with a double clickable script[2] that can be freely moved 
around by the user.
	How do we solve deps?
	All the necessary libs in the installer?
	Better left for Fink, DarwinPorts etc.?

3) A "self contained" build of gnuplot.
	Drag'n drop install.
	All binaries and dependencies (libs) are wrapped up as a full 
application.
	The application can be freely moved around by the user.
	Hard to use with e.g. octave.

4) A full Gnuplot.app
	Drag'n drop install.
	All binaries and dependencies (libs) are wrapped up as a full 
application.
	Needs more code to fully behave like a "real" app, but not necessarily 
changes to the core code.
	Gnuplot.app can be freely moved around by the user.
	Hard to use with e.g. octave.

The last option (4) is what we had for 3.7, but that (carbonized) Mac 
gnuplot seem to have disappeared from the web.

For the "terminally-impaired", option (3) or (4) would be the most 
appropriate, as long as they don't need to interact with gnuplot from 
other programs.

To me, (2) is the preferred choice, but I suppose (1) is probably the 
least error-prone approach, should it work (I know it _sounds_ easy, 
but like I said, it could be tricky).

I'd appreciate feedback on this.

/Per




[1] http://www.ai.mit.edu/people/paulfitz/spanish/script.html

[2] To users, that script (proxy?) would in most respects act like a 
true application.

Re: gnuplot with libgd for Windows?

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

> Is it easy to build libgd as static under windows?

All my OS/2 and MS Windows (Mingw, Cygwin) builds are with static libraries.
No problems.

---
PM

Re: gnuplot with libgd for Windows?

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

On Tuesday 06 April 2004 10:24 am, you wrote:
> On Tue, 6 Apr 2004, Ethan Merritt wrote:
> > These minimal built-in fonts are provided as fall-backs in the case
> > that better ones are not provided by the operating environment.
>
> You need more than just the fonts --- you still need the freetype
> library to access them, too, I think.

Yes, that's probably true.

> So it seems we could withdraw to a position stated in INSTALL that says:
>
> gnuplot+Windows+(current GD built as DLL)+(no libfreetype) == NO GO

But even if freetype is present, we would still need conditional code in
gd.trm so that it doesn't generate unresolved symbol errors at build time,
right?
And also to make sure the default font was set to something reasonable.

> AFAICS, this problem will not happen as soon as one of these conditions
> is removed.  Having libfreetype around or just using a statically
> compiled GD would probably be the easiest alternatives.

Is it easy to build libgd as static under windows?  If that's a way out of the
bind let's do that.  INSTALL can simply say (leaving open the possibility
that dlls will work again in the future):  "If you get unresolved symbol errors
for the fonts, please link against a static libgd library instead of the dll".
Or whatever the proper wording is for windows linkage.


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

Re: gnuplot with libgd for Windows?

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

On Tue, 6 Apr 2004, Ethan Merritt wrote:

> These minimal built-in fonts are provided as fall-backs in the case
> that better ones are not provided by the operating environment.

You need more than just the fonts --- you still need the freetype
library to access them, too, I think.

So it seems we could withdraw to a position stated in INSTALL that says:

gnuplot+Windows+(current GD built as DLL)+(no libfreetype) == NO GO

AFAICS, this problem will not happen as soon as one of these conditions
is removed.  Having libfreetype around or just using a statically compiled
GD would probably be the easiest alternatives.

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

Re: gnuplot with libgd for Windows?

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

Discussion transferred from usenet:
--------------------------------------------------------

Newsgroups: comp.graphics.apps.gnuplot
Subject: Re: gnuplot with libgd for Windows?
Summary:
Expires:
References: <e13...@po...> <e13...@po...> <ad6...@po...> <c4ufmb$gi3$1...@ne...>
Sender:
Followup-To:
Distribution:
Organization:
Keywords:
Cc:

In article <c4ufmb$gi3$1...@ne...>,
Hans-Bernhard Broeker  <br...@ph...> wrote:
>
>I've finally budged and got me a copy of that GD DLL onto a Windows
>machine to look at it myself.  Turns out my initial suspicition was
>mostly right --- the global symbols for those fonts aren't being
>exported by the DLL, so they're not present in the import lib.
>
>Looks like we will have to use those getter functions, after all, *if*
>they're available.  And the static initializers will probably have to
>go, too ;-(

These minimal built-in fonts are provided as fall-backs in the case
that better ones are not provided by the operating environment.
Are there any Windows systems for which TrueType fonts would
not be available?  Maybe the fix is as simple as removing these
fall-back cases under Windows.

>Dammit --- why, oh why is it that this kind of fatal blow *always* has
>to occur so short before a planned release date?

One other thought - is it possible to build a tiny extra dll on
the side that exports the required symbols, even if this extra
dll is an ugly hack?  It could use the getter functions and then
turn around and export the pointers as expected by external apps.
That would allow the gnuplot source to stay in its current state for
a version 4 release, while still providing a working Windows binary.

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

Re: Ready for wrap-up everyone?

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

> > > A note about Atari, Lars can remove that?
> >
> >  Should probably go. Entry 8 should probably move to the FAQ.
>
> [Note: the Entry numbers were so riddled with holes in the sequence
> that I got rid of them....]

Caused by me few hours before your major clean-up -- I had guessed you do
so.

---
PM

Re: Ready for wrap-up everyone?

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

> > Is the information in README and INSTALL still up-to-date?
>
> There's a pending change to INSTALL that would summarize versions and
> download URLs for all the optional support libraries.  A user complained
> (rightfully, IMHO), that "hiding" that information in the various *.trm
> files is not a particularly good plan, at least not for a release version.

Yes, and these INSTALL* look a bit unorganized, that's why my inclination
towards html. Anyway, INSTALL should probably have a table of contents.

> > Should gnuplot.sf.net / Files be mentioned too?
>
> I guess it would also make sense to declare SF.net our primary download
> site.  They have significantly larger pipes than any of the alternatives.

I agree. All others can be "secondary" -- but still keep them, as they
contain all previous gnuplot releases.



> > I think that for OS/2 and Windows distributions, there will be FAQ.html.
> > Web browser is always on these platforms.
>
> A text file browser is, too.  So what?
>
> What about a compromise: keep FAQ.html on the web only (and in the
> separate "docs in all formats" tarball), and add a pointer to its URL to
> the plain-text edition of the FAQ.

FAQ are on web in all 3 (html, pdf, txt) formats.
Ok, for binary releases, we can put a copy of FAQ.txt and FAQ.html; that
will satisfy everybody.

***

Small problem: FAQ.txt is not nicely produced by "lynx -dump" as in
Makefile, at least by my "Lynx Version 2.8.4rel.1" -- there are some
spurious citations like [18] to table of links at the end of the text
document. Somebody knows how to remove that? Or how to use a "-dump" feature
by "links"?

***

Other thing: how will gnuplot homepage be maintained? Will it be a mirror
(automatic mirror by cron?) of gnuplot.sf.net, where more people have ssh
access to? That's better than redirect?

---
PM

Re: Ready for wrap-up everyone?

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

> >  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.

Thus, the release can be this Thursday (sources frozen Wednesday), or next
Wednesday (sources closed on Tuesday). I don't mind.

Petr

Re: Ready for wrap-up everyone?

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

On Mon, 5 Apr 2004, Petr Mikulik wrote:

> *) 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)

Why would we want to remove that?  We might want to remove the line
about INSTALL (because that file *is* in gnuplot, actually), but the
others are potentially important information.  I say we keep them.

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

No.  There are only three:

./INSTALL
./INSTALL.gnu
./lisp/INSTALL

INSTALL.gnu is a file provided by external sources, so it should be kept
separate.  If at all, we might want to remove lisp/INSTALL (from
gnuplot-mode).

-- 
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 Tue, 6 Apr 2004, Petr Mikulik wrote:

> Is the information in README and INSTALL still up-to-date? 

There's a pending change to INSTALL that would summarize versions and
download URLs for all the optional support libraries.  A user complained
(rightfully, IMHO), that "hiding" that information in the various *.trm
files is not a particularly good plan, at least not for a release version.

> Should gnuplot.sf.net / Files be mentioned too?

The sf.net site definitely has to be mentioned.  Both the new homepage
there, and esp. the project page with all the bug trackers and friends. 

I guess it would also make sense to declare SF.net our primary download
site.  They have significantly larger pipes than any of the alternatives.

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

A text file browser is, too.  So what?

What about a compromise: keep FAQ.html on the web only (and in the
separate "docs in all formats" tarball), and add a pointer to its URL to
the plain-text edition of the FAQ.

-- 
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, Ethan Merritt wrote:

> 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.

Well, as I understand the "PDFlib Lite" license, it says it's free for
*developers* of open-source applications, but not free for *use* by
commercial *users* of such programs.

> The only way to be certain is to ask them:
> 
> 	License inquiries: sa...@pd...

OK, I'll do that.

-- 
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:


> > *) 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.

I'm with Lars on that.  And unless there's a tool in place that generates
both files from a *single* source, having both README and README.html
would be a maintenance problem we don't need.

> > 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.

Having the FAQ in the sources, while not itself a necessity, makes it
easier to ensure that the FAQ goes into all *binary* packages, whether
prepared by ourselves or by others (Linux distributors, in particular).

So I say we should keep it.

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

[Note: the Entry numbers were so riddled with holes in the sequence
that I got rid of them....]

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