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

Re: Release critical or not? [was Re: strange box-offset]

[<tim...@en...>]

Hans-Bernhard Br=F6ker wrote:
> Ethan A Merritt wrote:
>
>  =20
>> The length in pixels of a line that starts at pixel x1 and ends at pix=
el x2
>> is (x2-x1)+1.   So this code looks correct to me.  It may well be that=
 some
>> terminals interpret w and h incorrectly, but that would be an error in=
 the
>> individual terminal driver, not the core code.=20
>>    =20
>
> It can't really be an error --- for the simple, if somewhat shameful=20
> reason that the terminal API fails to actually specify what the 'width'=
=20
> paramter of the fillbox call is supposed to mean.  In other words, we'r=
e=20
> staring directly into the face of a serious design flaw.  That'll need=20
> to be ironed out.  The only open question is: is it urgent enough to=20
> warrant delaying the release?  I don't think so, based on the ratio of
> exposure versus complaints about this feature.
>  =20
I agree that it's not worth a delay.
>  =20
>> IMHO an off-by-one-pixel error is not release-critical, however.
>>    =20
>
> On the GUI terminals, it rather probably isn't --- they all effectively=
=20
> oversample, so the error is actually smaller than one pixel.  The=20
> critical ones are the pure pixel formats (which don't oversample), and=20
> the vector-based ones (because they may get zoomed up uncontrollably,=20
> later).
>  =20
As far as I can tell, the X11 and Windows terminal are "pure pixel=20
formats". I think the offsets are not visible in the X11 terminal=20
because the default line style "-3" is two-pixel-thick. For sure, the=20
aqua and wxWidgets terminals oversample.
> Which reminds me: in a certain light, this is a re-play of that bug=20
> concerning microscopic gaps in pm3d maps and colourboxes caused by=20
> aliasing artefacts, in our PostScript output rendered by Ghostscript.
>  =20
That's another problem. Antialiasing is rocket science, and when it=20
comes to adjacent polygons, most coverage-based algorithms will give=20
visible seams (look at the pm3d output for the aqua terminal as an=20
example : http://aquaterm.sourceforge.net/aqt/img/gnuplot1.png). Those=20
algorithms need additional information to perform well in this=20
particular case. Others which are more brute force, like=20
full-scene-anti-aliasing, may give a satisfying result at the price of=20
being more computation intensive.

> This can become a first TODO list item for post-4.2.
>  =20
Ok. Post-4.2 will be exciting !

Best regards,

Timoth=E9e

Re: Release critical or not? [was Re: strange box-offset]

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

Ethan A Merritt wrote:

> The length in pixels of a line that starts at pixel x1 and ends at pixel x2
> is (x2-x1)+1.   So this code looks correct to me.  It may well be that some
> terminals interpret w and h incorrectly, but that would be an error in the
> individual terminal driver, not the core code. 

It can't really be an error --- for the simple, if somewhat shameful 
reason that the terminal API fails to actually specify what the 'width' 
paramter of the fillbox call is supposed to mean.  In other words, we're 
staring directly into the face of a serious design flaw.  That'll need 
to be ironed out.  The only open question is: is it urgent enough to 
warrant delaying the release?  I don't think so, based on the ratio of
exposure versus complaints about this feature.

> IMHO an off-by-one-pixel error is not release-critical, however.

On the GUI terminals, it rather probably isn't --- they all effectively 
oversample, so the error is actually smaller than one pixel.  The 
critical ones are the pure pixel formats (which don't oversample), and 
the vector-based ones (because they may get zoomed up uncontrollably, 
later).

Which reminds me: in a certain light, this is a re-play of that bug 
concerning microscopic gaps in pm3d maps and colourboxes caused by 
aliasing artefacts, in our PostScript output rendered by Ghostscript.

> If there's a simple fix to the core code that makes things more consistent,
> fine.

I doubt there can be.  Such a fix would almost certainly be wrong for 
about as many terminal drivers as it might help.

 > But if we need to poke about in all the individuals drivers, let's
> not do this for 4.2.

Good point.  This can become a first TODO list item for post-4.2.

Re: Windows gnuplot 4.1 libpng problems

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

Ethan A Merritt wrote:

> Hmm. And the problem Mojca was having with locale settings also seems to
> arise from using an earlier version of Visual Studio.  

If anything, it's more likely too *new* a version he's using.  VC++ 
version 6 is out of date, by MS's reckoning.  As far as they're 
concerned, no application developer is supposed to be programming in C 
any more.  We're all supposed to have switched from (their slight 
bastardization of) C to their much worse bastardizations of Java (C#) or 
C++, by now.

> Does this mean we should add a caveat somewhere in the docs that if
> you are building on Windows with the MicroSoft tool chain, it
> requires VS 6.0?

I don't think we have sufficient evidence to make the statement that 
strong.

> Can Windows users download updated C libraries, or do they have to buy
> a whole new package?

They'd have to download backdated C libraries --- and those cost more 
than the brand-new honey-trap versions.

Re: PlotWS software

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

>  I've been using the open source PlotWS software.
> http://www.soton.ac.uk/~ghydflex/plotws/ :
>
> "PlotWS provides a graph generation WebService. It is implemented as a
> wrapper around gnuplot and exposes a subset of gnuplot's
> functionality. The Web Service layer is implemented using Apache AXIS."
>
> Perhaps, PlotWS could be added to the links page,
> http://www.gnuplot.info/links.html under Java (where it says " Version
> for Java and others: please contribute.")

It's not for this category, but for
 	Gnuplot used for generating web pages

??

It would be useful to write down few more examples of this use of gnuplot.
If someone writes down such a review/short list, I will put it into gnuplot 
web pages.

---
PM

Re: PlotWS software

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

Kim Leng Goh wrote:
> "PlotWS provides a graph generation WebService. It is implemented as a
> wrapper around gnuplot and exposes a subset of gnuplot's
> functionality. The Web Service layer is implemented using Apache AXIS."

> Below, I like to share some steps I took to get the PlotWS software
> working on my Red Hat 9.0 system. Hopefully, they could be of help to others.

I don't think that this is the right place to post this.  This is the 
gnuplot mailing list.  It has nothing to do with PlotWS.   Any reports 
you want to make about that software should be addressed at its autors.

> 1) Modify GraphSoapBindingImpl.java and change
> exe.run(exeGnuPlot + " \"" + cmdsFile + "\"", _tempDir, null);
> to
> exe.run(exeGnuPlot + " " + cmdsFile, _tempDir, null);

I don't think that's a good change.  After your change, any use of a 
plot filename containing blanks would fail.  This change breaks more 
than it fixes

> Perhaps, PlotWS could be added to the links page,
> http://www.gnuplot.info/links.html under Java (where it says " Version
> for Java and others: please contribute.")

Does it actually offer two-way interaction, i.e. are clicks onto the 
plot fed back into gnuplot?

Re: PlotWS software

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

Tino Wildenhain wrote:

> why dont you use a popen() (pipe) call to feed
> your commands w/o the need for a tempfile
> into gnuplot? 

Well, last I looked Java didn't really have popen(), nor pipe().

Re: Copy to clipboard for Linux

[Dave D. <dde...@es...>]

Daniel J Sebald <dan...@ie...> writes:

> Ethan Merritt wrote:
>> On Friday 14 July 2006 03:23 pm, Daniel J Sebald wrote:
>> 
>>>I'm not an X-pert (the usual disclaimer), but I believe there is
>>>indeed some confusion here, and I think it is with the phrase
>>>"clipboard".  From what I'm seeing in the code, this feature of being
>>>able to copy the X11 gnuplot image is not using the clipboard.
>> 
>> 
>> It is.
>
> Not according to the little tests I've done here...  OK, same
> scenario, generating X11 plots in gnuplot, wanting to get those
> images over to OpenWriter. 
>
> To dump stuff into the clipboard, instead of 
>
> export_graph(struct plot_struct *plot)
>
> inside gplt_x11.c attempting to become owner of PRIMARY, I
> instructed it to attempt becoming owner of CLIPBOARD: 

[snip]

> And, as per documentation which indicated to be ready as soon as
> sending that command to get back an event, I've seen the event come
> without any outside client requesting. 
>

I used to be an expert in this ICCCM stuff, but it was a while ago.

Within an app such as gnuplot, there is no particular difference between
PRIMARY and CLIPBOARD selection. However, there is typically another
client on the system which wants to permanently own the CLIPBOARD
selection (eg xclipboard). So as soon as an app such as gnuplot
asserts ownership, that other client immediately asks the app for the
data, and then reasserts ownership of the selection, and serves the
data to anyone who asks for it. So there *is* a client asking for the
data, just not one that the user explicitly triggered. That's what
makes the data persistent.

The extra utility is not required : if there is no clipboard utility
running, other clients can ask for the data in the CLIPBOARD selection
and it will be served by the original owner transparently. But then
the data dies when the original app dies.

My knowledge in this predates gnome / gtk etc. I assume they provide
the helpers that do the clipboard stuff.


Incidentally, one way to monitor activity is to run xcutsel. I often
run two instances, one with -selection PRIMARY and one with -selection
CLIPBOARD. Then I can get text to move between them. You can also use
xclipboard to move data between them.  xcutsel shows you when it owns
the selection. If you have xclipboard running, then as soon as you
"copy 0 to clipboard" in xcutsel, it immediately loses the selection
again. But if you "copy 0 to primary" it will remain highlighted until
someone else takes the primary selection.

Eg if you have the xcutsel's owning both primary and clipboard
(assuming your window manager doesn't keep stealing clipboard).
In firefox, highlight some text - it should steal the primary
selection. Then choose copy from the menu - it should then also steal
the clipboard selection.


dd
-- 
Dave Denholm              <dde...@es...>       http://www.esmertec.com

Re: PlotWS software

[Tino W. <ti...@wi...>]

Kim Leng Goh wrote:
> Hi all,
>   I've been using the open source PlotWS software.
> 
> http://www.soton.ac.uk/~ghydflex/plotws/ :
> 
> "PlotWS provides a graph generation WebService. It is implemented as a
> wrapper around gnuplot and exposes a subset of gnuplot's
> functionality. The Web Service layer is implemented using Apache AXIS."
> 
> 
> Below, I like to share some steps I took to get the PlotWS software
> working on my Red Hat 9.0 system. Hopefully, they could be of help to others.
> 
> 1) Modify GraphSoapBindingImpl.java and change
> exe.run(exeGnuPlot + " \"" + cmdsFile + "\"", _tempDir, null);
> to
> exe.run(exeGnuPlot + " " + cmdsFile, _tempDir, null);

why dont you use a popen() (pipe) call to feed
your commands w/o the need for a tempfile
into gnuplot? It would also allow to read
stderr/stdout from gnuplot.

Regards
Tino

PlotWS software

[Kim L. G. <kim...@gm...>]

Hi all,
  I've been using the open source PlotWS software.

http://www.soton.ac.uk/~ghydflex/plotws/ :

"PlotWS provides a graph generation WebService. It is implemented as a
wrapper around gnuplot and exposes a subset of gnuplot's
functionality. The Web Service layer is implemented using Apache AXIS."


Below, I like to share some steps I took to get the PlotWS software
working on my Red Hat 9.0 system. Hopefully, they could be of help to others.

1) Modify GraphSoapBindingImpl.java and change
exe.run(exeGnuPlot + " \"" + cmdsFile + "\"", _tempDir, null);
to
exe.run(exeGnuPlot + " " + cmdsFile, _tempDir, null);

2) After deploying PlotWS.war, make sure that the gnuplot executable
has execute permissions. e.g.:
chmod +x PlotWS/WEB-INF/exe/gnuplot

Perhaps, PlotWS could be added to the links page,
http://www.gnuplot.info/links.html under Java (where it says " Version
for Java and others: please contribute.")


Regards,
KL
P/S I'm using jakarta-tomcat-4.1.31 and j2sdk1.4.2_11.

Re: clipboard musings

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

> Now that I see how the X11 term works, it would be easy to configure this so that gnuplot knows to indicate to the client "image/png", "image/jpeg", etc. based upon the most recent terminal type.  And to properly send a "None" if the current clipboarded plot format does not match what the client is asking for.

Of course, by "this" I mean write a little clipboard routine for the relevant file in the gnuplot core, not in the X11 terminal driver "gplt_x11.c".  They are two different things.

Dan

clipboard musings

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

I've been messing around with the clipboard a bit for the X11 term and understand things fairly well now.

Anyway, I've just got to thinking, maybe the true power in a clipboard is not in the X11 term window, but in the X11 window associated with the gnuplot command line.  Take for example what Abiword is sending to the X11 term window plot when I type CNTRL-V in Abiword.  In the list you will see png, jpeg, tiff, gif, etc.

selection request: text/rtf (421) for CLIPBOARD (377)
selection request: application/rtf (423) for CLIPBOARD (377)
selection request: image/png (424) for CLIPBOARD (377)
selection request: image/jpeg (425) for CLIPBOARD (377)
selection request: image/tiff (426) for CLIPBOARD (377)
selection request: image/gif (427) for CLIPBOARD (377)
selection request: image/bmp (428) for CLIPBOARD (377)
selection request: image/x-xbitmap (429) for CLIPBOARD (377)
selection request: image/x-xpixmap (430) for CLIPBOARD (377)
selection request: image/x-portable-anymap (431) for CLIPBOARD (377)
selection request: image/x-portable-pixmap (432) for CLIPBOARD (377)
selection request: image/x-portable-graymap (433) for CLIPBOARD (377)
selection request: image/vnd.wap.wbmp (434) for CLIPBOARD (377)
selection request: image/x-cmu-raster (435) for CLIPBOARD (377)
selection request: image/x-wmf (436) for CLIPBOARD (377)
selection request: image/svg (437) for CLIPBOARD (377)
selection request: image/svg+xml (438) for CLIPBOARD (377)
selection request: UTF8_STRING (230) for CLIPBOARD (377)
selection request: COMPOUND_TEXT (257) for CLIPBOARD (377)
selection request: STRING (31) for CLIPBOARD (377)
selection request: text/html (439) for CLIPBOARD (377)
selection request: application/xhtml+xml (440) for CLIPBOARD (377)

I believe I saw on the web that the above target strings are part of some quasi standard somewhere.

Well, consider we do the following.  Say we have a special output "file" which basically stores things internally.

gnuplot> set term png
gnuplot> set output clipboard

Or, we could also just store the contents internally automatically any time an output plot is created.

Now that I see how the X11 term works, it would be easy to configure this so that gnuplot knows to indicate to the client "image/png", "image/jpeg", etc. based upon the most recent terminal type.  And to properly send a "None" if the current clipboarded plot format does not match what the client is asking for.

I think that would be cool.  Just plot in any format and if your word processor doesn't understand that one, try another.

The X11 mousing is convenient for quick copy and that sort of thing, but again maybe adding a clipboard to the command line window is the real deal here.

Dan

PS:  BTW, could we add some more flexibility to the terminal function "set_clipboard"?  I mean, it only has a text string as an input so one can interpret a null string as meaning it should store a Pixmap instead of a text string.  However, there is no way to indicate if this should go to CLIPBOARD or PRIMARY or whether to do clear or fill (i.e., cut/paste).  I know set_clipboard() is generic and there may be some restrictions on generality, but we shouldn't limit future use.  I don't know, something like

set_clipboard(int destination, int action, char *text)

clipboard #<destination>
action  <fill> / <clear>
text  <non-null the text> / <null, the internal pixmap>

And the destination will be open to interpretation for the terminal type.  In X11, 1 might mean PRIMARY, 2 might mean CLIPBOARD, 3 might mean SECONDARY (or nothing), any other number means CLIPBOARD.  In Windows, maybe all numbers are mapped to the same thing, the clipboard.

It's always easier to limit things from the mouse.c side of things, or have term options, than it is to try adding functionality at a later time.

Re: Release critical or not? [was Re: strange box-offset]

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

Ethan A Merritt wrote:
> On Sunday 16 July 2006 12:05 pm, Daniel J Sebald wrote:
> 
>>>the fundamental question is whether "width" should be interpreted
>>>as "number of horizontal pixels" or "x_right - x_left".  These are not
>>>the same number.  The former makes sense if you are thinking in terms of
>>>terminal coords (pixels); the latter makes sense if you are thinking in 
>>>terms of a continuous variable (plot x coordinate).
>>
>>If you plot a series of rectangles to "cover" a range staying with 
>>x_right - x_left avoids there being an overlap of one pixel.   
> 
> 
> But then you have the discordance that if you simply draw the 
> rectangle bounded by (x1,y1) (x2,y2) with vectors, the bottom and
> left edges are part of the fill area, but the top and right edges
> are not.  Isn't that the problem being observed - that the fill
> area and the bounding lines do not agree?

Hmmm, yeah...

Well, maybe the bounding lines should also be drawn one less.  I'm getting this feeling of an analog with the bounding box issue of images.  We had that discussion (enlightening to me) a while back about how to deal with this sort of thing in images.  I recall the gist being that when one does computations translating the images, one should work with the bounding box values, not the location of the first and last pixel are... I think there was a one pixel difference.

Perhaps the same kind of thinking applies here.

Dan

Re: Release critical or not? [was Re: strange box-offset]

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

On Sunday 16 July 2006 12:05 pm, Daniel J Sebald wrote:
> > the fundamental question is whether "width" should be interpreted
> > as "number of horizontal pixels" or "x_right - x_left".  These are not
> > the same number.  The former makes sense if you are thinking in terms of
> > terminal coords (pixels); the latter makes sense if you are thinking in 
> > terms of a continuous variable (plot x coordinate).
> 
> If you plot a series of rectangles to "cover" a range staying with 
> x_right - x_left avoids there being an overlap of one pixel.   

But then you have the discordance that if you simply draw the 
rectangle bounded by (x1,y1) (x2,y2) with vectors, the bottom and
left edges are part of the fill area, but the top and right edges
are not.  Isn't that the problem being observed - that the fill
area and the bounding lines do not agree?

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

Re: Release critical or not? [was Re: strange box-offset]

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

Daniel J Sebald wrote:

> My initial preference would be to think along the lines of "plot x coordinate", perhaps for the simple reason of however this thread got started.  If you plot a series of rectangles to "cover" a range staying with x_right - x_left avoids there being an overlap of one pixel.
> 
> E.g., series of incremented ranges:
> 
> 0-9
> 10-19
> 20-29
> etc.
> 
> For histograms or whatever.  Saying that the width of the rectangle should be 11 instead of 10 would mean that there is going to be one rectangle of the bunch that is 9 pixels and one which is 11 pixels.

Of course, I should say this is the principle.  Gnuplot may have been done this way to address some rouding effects of the plotting operation.  That is, this +1 may fix the problem of sometimes dropping a pixel because of some floating point round of, which would result in a "blank pixel" or "blank line".  (However, this rounding issue should really should be addressed directly by the mathematics of the process, not by compensating via a line segment one pixel wider than it should be.)

For example, I haven't look closely at what is at issue here, but say gnuplot is drawing a series of line segments.  It should not recompute the start and finish points for each new segment.  Rather, it should use the previous computed finish point for the last segment as the start point for the next segment.  Again, not sure of what exactly is happening in this particular case.  Just making a point.

Dan

Re: Release critical or not? [was Re: strange box-offset]

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

Ethan A Merritt wrote:
> On Saturday 15 July 2006 01:04 am, Timoth=C3=A9e Lecomte wrote:
>=20
>>this one comes from graphics.c:3408 :
>>
>>x =3D xl;
>>y =3D yb;
>>w =3D xr - xl + 1;
>>h =3D yt - yb + 1;
>>(*t->fillbox) (style, x, y, w, h);
>>(*t->move) (xl, yb);
>>(*t->vector) (xl, yt);
>>(*t->vector) (xr, yt);
>>(*t->vector) (xr, yb);
>>(*t->vector) (xl, yb);
>>
>>I think these "+1" should be removed for consistency with the other use=
s.
>=20
>=20
> I'm not so sure.
> The length in pixels of a line that starts at pixel x1 and ends at pixe=
l x2
> is (x2-x1)+1.   So this code looks correct to me.  It may well be that =
some
> terminals interpret w and h incorrectly, but that would be an error in =
the
> individual terminal driver, not the core code.=20
>=20
> I guess the fundamental question is whether "width" should be interpret=
ed
> as "number of horizontal pixels" or "x_right - x_left".  These are not
> the same number.  The former makes sense if you are thinking in terms o=
f
> terminal coords (pixels); the latter makes sense if you are thinking in=
=20
> terms of a continuous variable (plot x coordinate).

My initial preference would be to think along the lines of "plot x coordi=
nate", perhaps for the simple reason of however this thread got started. =
 If you plot a series of rectangles to "cover" a range staying with x_rig=
ht - x_left avoids there being an overlap of one pixel.

E.g., series of incremented ranges:

0-9
10-19
20-29
etc.

For histograms or whatever.  Saying that the width of the rectangle shoul=
d be 11 instead of 10 would mean that there is going to be one rectangle =
of the bunch that is 9 pixels and one which is 11 pixels.

Dan

Re: Windows gnuplot 4.1 libpng problems

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

On Sunday 16 July 2006 11:43 am, Hans-Bernhard Br=F6ker wrote:
> Andrew Brampton wrote:
>=20
> > Now the only difference I seem to be doing to Bastian, is that I'm usin=
g=20
> > Visual Studio 2003, instead of Visual C++ 6.
>=20
> is the real problem.  IIRC, Boutell states rather strongly that his=20
> prebuilt DLL doesn't work on anything but VC++ 6.

Hmm. And the problem Mojca was having with locale settings also seems to
arise from using an earlier version of Visual Studio.  Does this mean we
should add a caveat somewhere in the docs that if you are building on Windo=
ws
with the MicroSoft tool chain, it requires VS 6.0?   =20
In "Known Bugs", maybe?  Or in the FAQ?

Can Windows users download updated C libraries, or do they have to buy
a whole new package?

=2D-=20
Ethan A Merritt
Biomolecular Structure Center
University of Washington, Seattle 98195-7742

Release critical or not? [was Re: strange box-offset]

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

On Saturday 15 July 2006 01:04 am, Timoth=C3=A9e Lecomte wrote:
> this one comes from graphics.c:3408 :
>=20
> x =3D xl;
> y =3D yb;
> w =3D xr - xl + 1;
> h =3D yt - yb + 1;
> (*t->fillbox) (style, x, y, w, h);
> (*t->move) (xl, yb);
> (*t->vector) (xl, yt);
> (*t->vector) (xr, yt);
> (*t->vector) (xr, yb);
> (*t->vector) (xl, yb);
>=20
> I think these "+1" should be removed for consistency with the other uses.

I'm not so sure.
The length in pixels of a line that starts at pixel x1 and ends at pixel x2
is (x2-x1)+1.   So this code looks correct to me.  It may well be that some
terminals interpret w and h incorrectly, but that would be an error in the
individual terminal driver, not the core code.=20

I guess the fundamental question is whether "width" should be interpreted
as "number of horizontal pixels" or "x_right - x_left".  These are not
the same number.  The former makes sense if you are thinking in terms of
terminal coords (pixels); the latter makes sense if you are thinking in=20
terms of a continuous variable (plot x coordinate).

Either way, we need to audit the code to be consistent.
IMHO an off-by-one-pixel error is not release-critical, however.
If there's a simple fix to the core code that makes things more consistent,
fine.  But if we need to poke about in all the individuals drivers, let's
not do this for 4.2.

=2D-=20
Ethan A Merritt
Biomolecular Structure Center
University of Washington, Seattle 98195-7742

Re: Windows gnuplot 4.1 libpng problems

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

Andrew Brampton wrote:
> Ok, maybe the description of my problem wasn't clear enough. I didn't 
> download libpng, but whenever I try plotting a PNG it crashes.

Actually you did download libpng --- but in such a way that it was hard 
to notice.  There's a full copy of libpng inside the DLL version of GD 
you downloaded.

> I then tried to plot with a different terminal type, so I type set terminal 
> to obtain a list, and voila gnuplot crashes again once we get to the end of 
> the list! 

That rather strongly suggests that GD has nothing to do with it either: 
GD isn't involved in printing the 'set term' list.  That's starting to 
look more like this:

> Now the only difference I seem to be doing to Bastian, is that I'm using 
> Visual Studio 2003, instead of Visual C++ 6.

is the real problem.  IIRC, Boutell states rather strongly that his 
prebuilt DLL doesn't work on anything but VC++ 6.

Re: Windows gnuplot 4.1 libpng problems

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

Andrew Brampton wrote:
> Bastian has kindly sent me his binaries, and they are working great. However 
> now I have a working copy I've noticed another difference. When I run my 
> wgnuplot, I do not get the menu and the buttons along the top!. I just 
> figured that had been removed for some reason, but now looking at Bastian's 
> copy they are there. So something else must also be wrong :/

That something else is the way you installed your own binaries.  Consult 
the Windows section of "INSTALL" again.  You forgot to bring along the 
wgnuplot.mnu file.

Re: Windows gnuplot 4.1 libpng problems

[Andrew B. <an...@br...>]

----- Original Message ----- 
From: "Daniel J Sebald" <dan...@ie...>
To: "Andrew Brampton" <an...@br...>
Cc: <gnu...@li...>
Sent: Sunday, July 16, 2006 12:29 PM
Subject: Re: Windows gnuplot 4.1 libpng problems


> Andrew Brampton wrote:
>
> This shouldn't make a difference, but try adding "set output" before 
> changing the terminal.  If the crash goes away, there may be a bug.
>
>> A nice sine wave window appears. Then I try
>>
>> set terminal pdf
>> set output "test.pdf"
>> plot(sin(x))
>
> set output
>
>> set terminal png
>> set output "test.png"
>> plot(sin(x))
>
> set output
>
>> set terminal gif
>> set output "test.gif"
>> plot(sin(x))
>
> set output
>
> Dan
>


Thanks for the suggestion Dan, I just tried that, and again it crashes.

Bastian has kindly sent me his binaries, and they are working great. However 
now I have a working copy I've noticed another difference. When I run my 
wgnuplot, I do not get the menu and the buttons along the top!. I just 
figured that had been removed for some reason, but now looking at Bastian's 
copy they are there. So something else must also be wrong :/

Here is a URL to my builds: http://me.bramp.net/gnuplot-vs2003.zip if anyone 
is curious in running them. I will try and compile a version with debug 
symbols ( I just need to figure out how to alter the makefile to do that).
I was also just looking for my VC6 CD so I could install that and test if 
that solves my problem. I'll report back when I've done that.

For the time being I'll be using Bastian binaries, but I'm happy to help 
figure out why my compile doesn't work.

Thankyou for everyone's help.
Andrew 

Re: Windows gnuplot 4.1 libpng problems

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

Andrew Brampton wrote:

This shouldn't make a difference, but try adding "set output" before changing the terminal.  If the crash goes away, there may be a bug.

> A nice sine wave window appears. Then I try
> 
> set terminal pdf
> set output "test.pdf"
> plot(sin(x))

set output

> set terminal png
> set output "test.png"
> plot(sin(x))

set output

> set terminal gif
> set output "test.gif"
> plot(sin(x))

set output

Dan

Re: Windows gnuplot 4.1 libpng problems

[Andrew B. <an...@br...>]

Ok, maybe the description of my problem wasn't clear enough. I didn't 
download libpng, but whenever I try plotting a PNG it crashes.

So, I'm starting again explaining each step I took. I firstly checked out 
the CVS tree using TortiseCVS, using the options I found for CVS listed 
here: http://www.gnuplot.info/development/index.html

Then reading the INSTALL file it tells me to run "nmake -f 
..\config\makefile.nt", however at that point I haven't downloaded the 
gdlib/pdflib libraries. So reading the instructions in the makefile.nt it 
says to download them both and place them in ..\src\gdwin32 and 
..\src\pdflib which I do. BTW I download 
http://www.boutell.com/gd/http/gdwin32.zip and 
http://www.pdflib.com/products/pdflib/download/603/PDFlib-6.0.3p1-Windows.zip

Now I run nmake -f ..\config\makefile.nt from the source directory. I'm 
using the Visual Studio 2003 Compiler. That compiles but fails at the 
linking, because \src\gdwin32 doesn't contain a bgd.lib file. After a quick 
google I realise I need to run \src\gdwin32\makevcimport.bat. I do that and 
try nmake again, and it finishes linking.

I now copy the pgnuplot.exe wgnuplot.hlp and wgnuplot.exe in to their own 
directory. As well as copying the pdflib.dll and bgb.dll.

Now when I run wgnuplot, the normal gnuplot window appears. I type the 
following lines
plot(sin(x))

A nice sine wave window appears. Then I try

set terminal pdf
set output "test.pdf"
plot(sin(x))

A PDF file appears with the correct graph in it. Then I try pngs:

set terminal png
set output "test.png"
plot(sin(x))

(and as soon as I hit enter on that last line, GNUPlot crashs, leaving me 
with a zero byte test.png file)

I then tried to plot with a different terminal type, so I type set terminal 
to obtain a list, and voila gnuplot crashes again once we get to the end of 
the list! But I see gif was a supported type, so I type the following:

set terminal gif
set output "test.gif"
plot(sin(x))

and again a crash!. So maybe my former statement about it being libpng was 
wrong, its more generally libgd.

Now the only difference I seem to be doing to Bastian, is that I'm using 
Visual Studio 2003, instead of Visual C++ 6.

Also in response to Peter Mikulik's question about typing "set out; set term 
pop" afterwards?
Well as soon as I type plot it crashes, so I'm unable to type it afterwards.

I'm happy to send my binary files for anyone to debug, or I could recompile 
with debugging enabled if that helps. Until then I will be using gnuplot on 
a linux machine, but it would be a great help for me if Bastian would send 
me his compiled executable in the mean time.

Thanks a lot
Andrew

P.S This post seems to outline what steps need to be done to compile the 
code, which is slightly more complex than listed in INSTALL, maybe some of 
these steps need to be added to INSTALL. thanks.

----- Original Message ----- 
From: "Bastian Maerkisch" <bma...@we...>
To: "Andrew Brampton" <an...@br...>
Sent: Saturday, July 15, 2006 6:24 AM
Subject: Re: Windows gnuplot 4.1 libpng problems


Andrew Brampton wrote:
> Hi,
> I recently started to use gnuplot 4.0, but found I needed some features in 
> 4.1.
>
> When I try the provided binaries the program crashes, when I try and use 
> this simple script:
> reset
> set terminal png
> set output 'temp.png'
>
> plot(sin(x))
>
> So I figured it was a bug so I tried compiling from the latest CVS source. 
> After many hours of compiling/recompiling, etc, I still have the same 
> crash. However if I use a different terminal (other than png) the image is 
> plotted fine. So I assume this is a problem with libpng?
>
> I found this old posting 
> http://sourceforge.net/mailarchive/forum.php?thread_id=9178285&forum_id=6027 
> stating the same problem, but looking the CVS is compiling with /MT.

Are you sure you are using a current CVS version? Support for binary version
of libgd was added in last december. config.nt in CVS uses the /MD switch.
No need to get libpng any more.

> Can anyone recommend how to compile the code? Or just give me a binary 
> that works with PNGs... thanks
>
> BTW I'm using Visual Studio .Net 2003, on Windows XP, with the gnuplot 
> code from CVS about 30minutes ago (as well as snapshots from April).

Well, I am using MSVC++ 6.0 on XP. And here's what I do:

- download gdlib to gnuplot\src\gdwin32 (binary version!)
- download pdflib to gnuplot\src\pdflib and compile it if you choose the 
source,
           (you can also remove all references to pdf in makefile.nt)
         - copy bgd.dll and pdflib.dllto a place in your path
- change to  gnuploit\src
- run
nmake -f ..\config\makefile.nt

Works out of the box for me. (last tested 14 days ago)
Hope that helps,

Bastian


>
> Thanks for any help
> Andrew

-- 
Bastian Märkisch
Physikalisches Institut, Universität Heidelberg

Re: "set decimalsign" for thousand separator

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

On Saturday 15 July 2006 11:00 am, you wrote:
> On 7/15/06, Ethan A Merritt wrote:
> > On Saturday 15 July 2006 10:30 am, Mojca Miklavec wrote:
> > > "%'.3f" prints '.3f instead of the number with thousand separator
> > Get a newer C library.
> 
> Newer C library? I have MS Visual Studio 2005.

So?

This Microsoft web site
  http://msdn2.microsoft.com/en-us/library/x99tb11d.aspx
claims that there is support for the thousands separator
via setlocale() in the C libraries for Visual Studio 6.0

I don't know whether that's newer or older than the ones you
have, but it sounds like maybe that's the versuib one you need.

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

Re: strange box-offset

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

Mojca Miklavec wrote:

> 32.09+18.03=50.12,

... only in a mathematically perfect world.  In the real world,  those 
numbers 32.09 and 18.03 just as probably are 32.086 and 18.026 (rounded 
for display) --- now you check beck if they really add up to 50.12.

One of the reasons the terminal interface uses integers, not 
floating-point numbers, is exactly this: that's virtually impossible to 
get floating-point numbers to equal each other exactly and avoid round-off.

Re: Copy to clipboard for Linux and others

[Bob F. <rob...@kn...>]

Oops! Sorry about the previous transmittal, I hit the wrong darn button!

All,

Wow, I am really impressed. You guys are extremely responsive and
helpful. I am not sure of the correct procedure for responding to
several different postings, so I am just going to try to do them all in
this one posting.

Ethan:
Yesterday, I mentioned that I had not been able to get the hot key
binding that you suggested to work properly and you asked for details:
(1) I had to include the output file name in quotes, which was no big
deal.
(2) I was surprised that after executing the hot key on the figure, the
gnuplot prompt did not return. I had to hit Enter. This seems different
from the other hot key operations.
(3) The process seemed slow. I was using Nautilus File Browser and often
the created file would not appear until I clicked on a newly created XML
file called .recently-used. This was very confusing to me. I finally
opened a terminal window and saw the the file was being created
properly. I guess this is something to do with the browser.


Several of you made very nice suggestions on the best way to get gnuplot
figures (in Windows) into, say, a MS Word document. I will definitely
consider them all. However, I am still a little puzzled. When running in
Windows and gnuplot Ver 4.1, I simply select the Option Copy to
Clipboard. Next, to insert the figure into a Word document, I select
Edit, Paste Special and am offered the following options: Windows
Metafile, Bitmap, Device Independent Bitmap, and Enhanced Metafile.
Typically I select EMF. The figure usually looks great and is
re-sizable, and the file is not that big. I am not sure how the copy is
made TO the Windows clipboard. Perhaps it is tied to my monitor
resolution (1600x1200) but it sure gives good results.

Dan:
I am eager to try out the Patch that you put on SourceForge - as soon as
I figure out how to do handle patches. Coming from a Windows world,
there sure are a lot of things that I don't understand.

Thanks again to all of you,

Bob