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

Re: TODO

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

On Thu, 8 Apr 2004, Petr Mikulik wrote:

> BTW, the text written into ChangeLog is getting narrower and narrower. 

It's not getting "narrower and narrower; just narrower, i.e. it
only gets narrowed ones, not repeatedly.  

> It was 80 chars wide, but now people started to wrap it at 73 (?) chars.

Those "people" are actually me.  I do occasionally reformat ChangeLog
comment lines that are very long, by using (X)Emacs' M-q on them.

> Why? I propose to use full 80 chars width.

Why not?  That doesnt' make them any easier to read.

Generally, I'd be a lot happier if people could stick to GNU ChangeLog
style more strictly.  It's really helpful to be able to just grep the
Changelog for a function name and find (almost) all entries affecting it.

I think we should postpone this discussion until after the release.  We
should probably cycle the ChangeLog then (--> move the current one to
ChangeLog.1), which will be good point to discuss how to write entries in
the fresh one.

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

Re: partly ignored TextSize in wgnuplot.ini

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

On Thu, 8 Apr 2004, Ethan Merritt wrote:

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

Nope.

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

That could be caused by Windows' slightly strange idea of how
coordinates are interpreted.  If I find a fix quickly, I'll put it
in before the release, otherwise it says as-is.

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

Any actual similarities between OS/2 and Windows had better be seen as
mere coincidence.  These OSes both were originally written in the same
place, right, but that doesn't mean their gnuplot drivers have any
particular relation to each other.  The Windows driver is a couple of
years older, and there are some corners where that *still* shows.

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

To clarify this, there are *two * places this menu show up: as the
right-click (a.k.a. "context") menu of the graph window, and as a special
extension of the "system button" (in the top left corner of the GUI
window).  With mouse mode active, you can only access the latter --- but
most users won't find it there.  Yes, this is a violation of pretty much
every user interface tradition for MS Windows ever invented, but it works,
and it conserves screen real-estate by not using a menu-bar.

Most of the above is caused mainly by the fact that gnuplot hasn't had an
active maintainer of the MS Windows version for ages.  I reluctantly
stepped in a while ago to keep it working (and keep Petr off my back when
he wanted something *really* badly...), but that's about it.

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

Re: TODO

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

On Thursday 08 April 2004 09:46 am, Petr Mikulik wrote:
> Please have a look to that file...

BUGS - maybe just refer people to the bug-tracker on 
SourceForge.

I think all those docs/old/README.* files can be deleted.

The windows bugs/todo items I suppose should stay on the
TODO list.

The xlib project seems to be dead, so far as I can tell.
We don't need to mention it.

Per is taking care of aquaterm documentation, I hope anyway.

Unifying the point styles should remain on the TODO list.
Line types have been unified as much as practical already,
so far as I know.

The mention of an INF bug for binary files- I'm not sure.
I can't find any record of such a bug on the SourceForge bug list.

A linux rpm - hmm.  I think the distros will probably do that to
suit themselves.  If necessary I can make a Mandrake rpm.
that might or might not work under other rpm-based distros.

The long list at the end - I've a long list of my own as well,
but these have little to do with the Version 4 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?

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

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


I don't understand what this text tries to say nowadays. Therefore I propose
to delete it.



And what about this text:

First, tune term.h to choose which terminal drivers you wish to enable.
If you want to support gif output, you need to download, compile and
install the gd library : see term/gif.trm for details.


I don't think that's like that.

Also, README.1ST speaks only about GIFs. What about deleting this file and
reference from README to FAQ?

Note that the new gnuplot web page does neither speak about gifs.

---
PM

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

And Ethan, a portion thereof.

Dan

TODO

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

Please have a look to that file...

BTW, the text written into ChangeLog is getting narrower and narrower. It
was 80 chars wide, but now people started to wrap it at 73 (?) chars. Why?
I propose to use full 80 chars width.

---
PM

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