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

Re: Key improperly placed for splot maps

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

Daniel J Sebald wrote:

> There is the issue of 3D zoom which complicates matters a bit.

In fact, I just tried 3D zoom.  When zooming in pretty close, there are some rounding problems where the axes do not draw in the correct direction.  (I think that is a known bug.)  But I'm wondering what the benefit is of zooming in 3D.  If it were for scaling and positioning on the screen in a way that could be useful (i.e., feedback so that someone doesn't have to do manual placement of the plot) I could see that.

The benefit of rotating feature is clear.

I guess this goes back to a discussion I recall with Hans, that 2D zooming could be accomplished without having to replot, but its usefulness isn't great without reploting the axes with new ranges, so on.  Well, this 3D zoom is sort of the same thing.  I'd think for 3D zoom to have the same behavior, the plot access should remain the same but the plotted range should shrink (zoom in) or expand (zoom out).  Even that is somewhat limiting without the ability to pan (i.e., move the plotted range to any arbitrary locations).

Dan

Re: pause mouse broken since v. 4.2?

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

> > Nobody took care about. I think that nobody will, as wgnuplot does not have 
> > stdout, so that reading the clicked point coordinates by e.g. Octave makes 
> > no sense.
> > 
> > The patch to could be trivial.

It was trivial, see
http://sourceforge.net/tracker/?func=detail&atid=102055&aid=1651350&group_id=2055

I think it can go to 4.2 and cvs.

---
PM

Re: Key improperly placed for splot maps

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

Mike Sutton wrote:
> The key is not properly placed for splot maps.  The simple test case below 
> shows that the key ends up obscuring the plot instead of being outside of the 
> plot.  This problem is present in 4.2RC4 and the CVS head.
> 
> set key outside right box
> set key title "FOODSLKF"
> set view map
> splot x,cos(x),sin(x)
> set key left
> replot
> set key outside bottom
> replot
> 
> I modified the key.dem demo.  I added 'set view map' and changed plot to splot 
> to see how all the options plotted.  All the automatic key placements seem to 
> be misplaced except for maybe outside bottom center.

Yes, there's no guarantees on the key placement for splot.  We may have made a conscious decision to hold off on fixing that.  There was a little bit of agreement that we should unify the key placement and color box placement for the two modes to avoid do twice the work with twice the number of bugs.  (Volunteer Mike?)  Something about screen border, plot border (i.e., region where the plot can appear, be it 2D or 3D).

The 2D key layout is pretty well organized (key placement in 3D isn't good, color box in both modes is marginal), so that would be the place to start in my opinion.  Then attempt to move the plot layout items from graph3d.c to graphics.c (or is it plot3d.c to plot2d.c?... note somehow we drop the 2d/3d name convention because they key and color box layout should be mode independent).

There is the issue of 3D zoom which complicates matters a bit.  However, Ethan was surmising a "clip()" function the other day.  Maybe this would be a place for using such a function.  It would ensure that 3D zoomed plot elements don't extend into the margins, interfering with keys, color boxes etc.

Also, note we've talked about the capability of multiple keys too.

Dan
 

Key improperly placed for splot maps

[Mike S. <mw...@us...>]

The key is not properly placed for splot maps.  The simple test case below 
shows that the key ends up obscuring the plot instead of being outside of the 
plot.  This problem is present in 4.2RC4 and the CVS head.

set key outside right box
set key title "FOODSLKF"
set view map
splot x,cos(x),sin(x)
set key left
replot
set key outside bottom
replot

I modified the key.dem demo.  I added 'set view map' and changed plot to splot 
to see how all the options plotted.  All the automatic key placements seem to 
be misplaced except for maybe outside bottom center.

Mike Sutton

Re: [RFC] Gradient fill options

[<HBB...@t-...>]

Pierre wrote:
> On 2/2/07, Hans-Bernhard Bröker <HBB...@t-...> wrote:
>> To give an example, from an RGB palette defined like this:
>>
>> 0.0: blue
>> 0.5: white
>> 1.0: red

> I'm not sure to understand the notion of palette in your example.

It's a (principally) continuous mapping from a numeric value (the number 
being displayed) to a colour.  In the case above, it consists of two 
linear paths, one from blue to white, the second from white to red.  The 
idea is to turn a data parameter into a colour, a.k.a. "false-colour 
diagram".  It's how altitude is often displayed on geographical maps 
(green lowlands, brown hills, white peaks, blue ocean).

> Which and how many colors do you have in the palette when you start to
> render a given triangle?

As many as the output terminal can supply --- potentially infinite. 
This "palette" is a data visualization thing, not the like-named 
property of paletted image file formats like GIF.  You may want to call 
our thing a "color map" or even a "false-color map" to distinguish the two.

Re: pause mouse broken since v. 4.2?

[dbionda <db...@bl...>]

Petr Mikulik <mikulik <at> physics.muni.cz> writes:
> 
> > > On Windows, there was always a window.
> > 
> > That makes some sense for "pause -1",
> > 
> > But it makes no sense at all for "pause mouse" or "pause key".
> > Can we get rid of it?
> >
> > OK. I've just tried the 4.0 Windows version. It's broken.
> > So "pause mouse" was not usable in 4.0 either, and this
> > bug report is not quite correct. It's not a regression,
> > since it never did work.
> 
> You are right.
> 
> > Why did no one ever file this as a bug report?
> > Do we have no Windows users?
> 
> Nobody took care about. I think that nobody will, as wgnuplot does not have 
> stdout, so that reading the clicked point coordinates by e.g. Octave makes 
> no sense.
> 
> > It should have been reported and fixed long ago.
> > Now it's probably too late for 4.2
> 
> The patch to could be trivial.
> But I don't see it.
> 
> ---
> PM

Thank you both for your replies. In version 4.0 (Win32) "pause mouse" puts a 
window on the screen with "ok" and "cancel" buttons, similarly to "pause -1". 
I was assuming this was the correct behaviour. Since version 4.1 the buttons 
are no longer there and the window cannot be dismissed. Clicking the mouse has 
no effect at all. Since this seems to be a Win32-specific issue, I think that 
for the moment I will stick with "pause -1", which actually does what I need.

Davide

Re: pause mouse broken since v. 4.2?

[dbionda <db...@bl...>]

Well, even if I click the mouse the window still stays there...

Petr Mikulik <mikulik <at> physics.muni.cz> writes:
> 
> > I noticed that since at least vers. 4.2rc2 the "pause mouse" command no 
longer 
> > works as expected: "ok" and "cancel" buttons are not displayed and there 
is 
> > actually no way to dimiss the dialog window. Is this a bug or a feature?
> 
> It is a feature: you really need to click the mouse.
> 
> Well, but there is still an unimplemented feature on "set term win":
> 	pause mouse key
> 	pause mouse any
> does not work.
> 
> ---
> PM

Re: [RFC] Gradient fill options

[Pierre <pie...@gm...>]

Hi,

On 2/2/07, Hans-Bernhard Br=F6ker <HBB...@t-...> wrote:
> Ethan Merritt wrote:
>
> > I noted out in my feature request for libgd that it was unclear what
> > sort of interpolation could be done with an indexed colormap. The usual
> > shading interpolation routines assume either RGB or CMY colorspace.
> > But I think you've answered that question.  The gnuplot PM3D grey
> > scale palette routines define a single scale within which interpolation
> > of the index value does make sense.
>
> ... for pm3d it does.  But the same need not apply for GD at large.
>
> PM3D doesn't interpolate colours, it interpolates indices, i.e. it
> interpolates along a polyline through colour space.  The idea being that
> all resulting colours should still be on that polyline.
>
> To give an example, from an RGB palette defined like this:
>
> 0.0: blue
> 0.5: white
> 1.0: red
>
> all colours interpolated by pm3d would currently be pure blue or red at
> various levels of saturation.  A triangle with these three values at its
> corners would have a pure white streak all along the edge from the white
> corner to the center of the opposite edge.
>
> Actual colour interpolation would yield all kinds of violet with pure
> white only around the original white vertex.

I'm not sure to understand the notion of palette in your example.
Which and how many colors do you have in the palette when you start to
render a given triangle?

About GD in general, it supports indexed colors, it is what we define
as palette based image (created by gdImageCreate). The indexes are
sequentially incremented:

> for(i=3D0;i<N;i++) png_smooth_color[i] =3D gdImageColorAllocate(...)

it will create a color from the last existing index.

About what Dan said later (sorry, I subscribed only this morning)
> I assume you are interested only in linear interpolation and not higher o=
rder
> approaches like 2D splines.

I wrote a sample code including the new shaded triangle function in
Ethan's request:

http://bugs.libgd.org/?do=3Ddetails&task_id=3D39

It uses a linear interpolation. Only true color images are supported
now (no palette, "unlimited" colors). I did not test all cases but the
colors on the edges seem to match (see the attached images, a
quadrilateral rendered using two triangles).

> Does gdlib have indexed colormaps?

Yes, see above :)

> If not, a gradient triangle fill shouldn't
> be too difficult to implement.  If we know the resolution of the PNG/JPEG
> then it should be straightforward.

In GD (or any other bitmap based library), the rendering is resolution
independent. It is pixel based. The DPI is  meta information to help
other applications to know the size in inches but the image itself
remains the same.

I have a question about the usage of indexed colors, as I understand
the need of an indexed intensity palette (well known method for
VGA-like devices for example). Is there a reason to keep using them
instead of a true color image?

True color image are faster to render and the image can be saved as
indexed PNG (if size matters). It makes little sense to use indexed
colors if JPEG is the target. JPEG output are true color.

Feel free to post comment in the issues tracker, our mailing lists or
here (privately too but I prefer to keep the process as open as
possible). As Ethan said, we have plenty of time to define our
respective needs.

Thanks for your feedbacks,

--Pierre

Re: [RFC] Gradient fill options

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

Ethan Merritt wrote:
> On Friday 02 February 2007 12:38, Hans-Bernhard Bröker wrote:
> 
>>Ethan Merritt wrote:
>>
>>>   gdImageShadedTriangle(gdImagePtr image, gdPoint *vertex, int *color);
>>
>>>That is, a filled triangle with interpolation of three separate colors
>>>specified for the three vertices. 
>>
>>Interpolation is quite a tricky business in color space, because there's 
>>no clear-cut idea what the curve to draw between two given points in 
>>colour space should be.  To properly specify an interpolation mechanism, 
>>one needs to specify at least the coordinate system in which the 
>>interpolated surface in color-space is supposed to be flat.
> 
> 
> That is an interesting point.
> 
> I noted out in my feature request for libgd that it was unclear what
> sort of interpolation could be done with an indexed colormap. The usual
> shading interpolation routines assume either RGB or CMY colorspace.
> But I think you've answered that question.  The gnuplot PM3D grey
> scale palette routines define a single scale within which interpolation
> of the index value does make sense.  The question then becomes, is
> this linear ordering of index values maintained internally in libgd?

I assume you are interested only in linear interpolation and not higher order approaches like 2D splines.  Does gdlib have indexed colormaps?  If not, a gradient triangle fill shouldn't be too difficult to implement.  If we know the resolution of the PNG/JPEG then it should be straightforward.

For this hidden surface thing I was messing around with I wrote some short routines to construct a 2D hyperplane in three dimensions given three points, then simply do a matrix multiply for all the points within the triangle, that gives the interpolated value.  Then take that value and lookup the value in the indexed colormap.  Then place that value in the PNG/JPEG image with some type of gdImage() routine (I assume).

Dan

Re: pause mouse broken since v. 4.2?

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

> > On Windows, there was always a window.
> 
> That makes some sense for "pause -1",
> 
> But it makes no sense at all for "pause mouse" or "pause key".
> Can we get rid of it?
>
> OK. I've just tried the 4.0 Windows version. It's broken.
> So "pause mouse" was not usable in 4.0 either, and this
> bug report is not quite correct. It's not a regression,
> since it never did work.

You are right.

> Why did no one ever file this as a bug report?
> Do we have no Windows users?

Nobody took care about. I think that nobody will, as wgnuplot does not have 
stdout, so that reading the clicked point coordinates by e.g. Octave makes 
no sense.

> It should have been reported and fixed long ago.
> Now it's probably too late for 4.2

The patch to could be trivial.
But I don't see it.

---
PM

Re: pause mouse broken since v. 4.2?

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

On Friday 02 February 2007 15:32, Petr Mikulik wrote:
> > What's an "ok" or "cancel" button?
> > I've never seen either one.
> 
> Try the Windows or OS/2 PM terminals.

OK. I've just tried the 4.0 Windows version. It's broken.  

So "pause mouse" was not usable in 4.0 either, and this
bug report is not quite correct. It's not a regression,
since it never did work.

Why did no one ever file this as a bug report?
Do we have no Windows users?

It should have been reported and fixed long ago.
Now it's probably too late for 4.2


-- 
Ethan A Merritt					Courier Deliveries: 1959 NE Pacific	
Dept of Biochemistry    M/S 357742
Health Sciences Building
University of Washington - Seattle

Re: pause mouse broken since v. 4.2?

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

On Friday 02 February 2007 15:32, you wrote:
> > What's an "ok" or "cancel" button?
> > I've never seen either one.
> 
> Try the Windows or OS/2 PM terminals.
> 
> > The existance of a dialog window sounds like the real bug.
> > There should be no separate dialog window, because termination of
> > the pause is explicitly a mouse or keyboard event in the plot window.
> 
> On Windows, there was always a window.

That makes some sense for "pause -1",

But it makes no sense at all for "pause mouse" or "pause key".
Can we get rid of it?


-- 
Ethan A Merritt					Courier Deliveries: 1959 NE Pacific	
Dept of Biochemistry    M/S 357742
Health Sciences Building
University of Washington - Seattle

Re: pause mouse broken since v. 4.2?

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

> What's an "ok" or "cancel" button?
> I've never seen either one.

Try the Windows or OS/2 PM terminals.

> The existance of a dialog window sounds like the real bug.
> There should be no separate dialog window, because termination of
> the pause is explicitly a mouse or keyboard event in the plot window.

On Windows, there was always a window.
On OS/2, you can configure whether you want the "x11" way, or a window, or a 
titlebar message.

---
PM

Re: pause mouse broken since v. 4.2?

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

> I noticed that since at least vers. 4.2rc2 the "pause mouse" command no longer 
> works as expected: "ok" and "cancel" buttons are not displayed and there is 
> actually no way to dimiss the dialog window. Is this a bug or a feature?

It is a feature: you really need to click the mouse.

Well, but there is still an unimplemented feature on "set term win":
	pause mouse key
	pause mouse any
does not work.

---
PM

Re: [RFC] Gradient fill options

[Pierre <pie...@gm...>]

On 2/2/07, Ethan Merritt <merritt@u.washington.edu> wrote:
> On Friday 02 February 2007 12:38, Hans-Bernhard Br=F6ker wrote:
> > Ethan Merritt wrote:
> > >    gdImageShadedTriangle(gdImagePtr image, gdPoint *vertex, int *colo=
r);
> >
> > > That is, a filled triangle with interpolation of three separate color=
s
> > > specified for the three vertices.
> >
> > Interpolation is quite a tricky business in color space, because there'=
s
> > no clear-cut idea what the curve to draw between two given points in
> > colour space should be.  To properly specify an interpolation mechanism=
,
> > one needs to specify at least the coordinate system in which the
> > interpolated surface in color-space is supposed to be flat.
>
> That is an interesting point.
>
> I noted out in my feature request for libgd that it was unclear what
> sort of interpolation could be done with an indexed colormap. The usual
> shading interpolation routines assume either RGB or CMY colorspace.
> But I think you've answered that question.  The gnuplot PM3D grey
> scale palette routines define a single scale within which interpolation
> of the index value does make sense.  The question then becomes, is
> this linear ordering of index values maintained internally in libgd?
>
> We define colors 1->N sequentially using
>      for(i=3D0;i<N;i++) png_smooth_color[i] =3D gdImageColorAllocate(...)
> Does this yield N successive color indices in libgd? I don't know.

It does.

> We should have plenty of time for testing, discussion, and
> feedback. Gnuplot is headed for an imminent 4.2 release;
> libgd for an imminant 2.0.34 release.  Any work on coordinating
> treatment of gradient-fill can proceed at leisure with an eye
> to much more distant major release targets (4.4/5.0 and 2.1).

I added a sample code in your report. It is a first shot but seems to work =
well.

--Pierre

Re: [RFC] Gradient fill options

[<HBB...@t-...>]

Ethan Merritt wrote:

> I noted out in my feature request for libgd that it was unclear what
> sort of interpolation could be done with an indexed colormap. The usual
> shading interpolation routines assume either RGB or CMY colorspace.
> But I think you've answered that question.  The gnuplot PM3D grey
> scale palette routines define a single scale within which interpolation
> of the index value does make sense.  

... for pm3d it does.  But the same need not apply for GD at large.

PM3D doesn't interpolate colours, it interpolates indices, i.e. it 
interpolates along a polyline through colour space.  The idea being that 
all resulting colours should still be on that polyline.

To give an example, from an RGB palette defined like this:

0.0: blue
0.5: white
1.0: red

all colours interpolated by pm3d would currently be pure blue or red at 
various levels of saturation.  A triangle with these three values at its 
corners would have a pure white streak all along the edge from the white 
corner to the center of the opposite edge.

Actual colour interpolation would yield all kinds of violet with pure 
white only around the original white vertex.

Re: [RFC] Gradient fill options

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

On Friday 02 February 2007 12:38, Hans-Bernhard Br=F6ker wrote:
> Ethan Merritt wrote:
> >    gdImageShadedTriangle(gdImagePtr image, gdPoint *vertex, int *color);
>=20
> > That is, a filled triangle with interpolation of three separate colors
> > specified for the three vertices.=20
>=20
> Interpolation is quite a tricky business in color space, because there's=
=20
> no clear-cut idea what the curve to draw between two given points in=20
> colour space should be.  To properly specify an interpolation mechanism,=
=20
> one needs to specify at least the coordinate system in which the=20
> interpolated surface in color-space is supposed to be flat.

That is an interesting point.

I noted out in my feature request for libgd that it was unclear what
sort of interpolation could be done with an indexed colormap. The usual
shading interpolation routines assume either RGB or CMY colorspace.
But I think you've answered that question.  The gnuplot PM3D grey
scale palette routines define a single scale within which interpolation
of the index value does make sense.  The question then becomes, is
this linear ordering of index values maintained internally in libgd?

We define colors 1->N sequentially using=20
     for(i=3D0;i<N;i++) png_smooth_color[i] =3D gdImageColorAllocate(...)
Does this yield N successive color indices in libgd? I don't know.
If so, interpolation using the color index stored for each
vertex should approximate the PM3D colors that would have been
assigned for each pixel.

Of course, for small changes across the face of the triangle
RGB interpolation is probably OK anyhow.  The results will only be=20
dramatically incorrect if the vertex values are so different that
they bracket a quite different color range on the PM3D color axis.
That can certainly happen, but it would mean that the grid
sampling is so course that important feature are likely to be
missed no matter what coloring scheme we use.

This is a general problem with interpolation schemes.
If the values assigned to the vertices are roughly the same,=20
but the "true" value in the middle of the face is different,
you won't get there by interpolation.

We should have plenty of time for testing, discussion, and
feedback. Gnuplot is headed for an imminent 4.2 release;
libgd for an imminant 2.0.34 release.  Any work on coordinating
treatment of gradient-fill can proceed at leisure with an eye
to much more distant major release targets (4.4/5.0 and 2.1).


=2D-=20
Ethan A Merritt					Courier Deliveries: 1959 NE Pacific=09
Dept of Biochemistry    M/S 357742
Health Sciences Building
University of Washington - Seattle

Re: pause mouse broken since v. 4.2?

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

On Friday 02 February 2007 01:29, dbionda wrote:
> Dear all
> I noticed that since at least vers. 4.2rc2 the "pause mouse" command no longer 
> works as expected: "ok" and "cancel" buttons are not displayed and 

What's an "ok" or "cancel" button?
I've never seen either one.

> there is actually no way to dimiss the dialog window. 
> Is this a bug or a feature? 

The existance of a dialog window sounds like the real bug.
There should be no separate dialog window, because termination of
the pause is explicitly a mouse or keyboard event in the plot window.

I assume this is some MSWin idiocy?  There should be no new
windows generated as a result of typing "pause mouse".


-- 
Ethan A Merritt					Courier Deliveries: 1959 NE Pacific	
Dept of Biochemistry    M/S 357742
Health Sciences Building
University of Washington - Seattle

Re: [RFC] Gradient fill options

[<HBB...@t-...>]

Ethan Merritt wrote:
>    gdImageShadedTriangle(gdImagePtr image, gdPoint *vertex, int *color);

> That is, a filled triangle with interpolation of three separate colors
> specified for the three vertices. 

Interpolation is quite a tricky business in color space, because there's 
no clear-cut idea what the curve to draw between two given points in 
colour space should be.  To properly specify an interpolation mechanism, 
one needs to specify at least the coordinate system in which the 
interpolated surface in color-space is supposed to be flat.

PM3D has such flexibility in principle, so if this new feature for libgd 
is to do us any good it should have it, too.

[RFC] Gradient fill options

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

I have requested that the next major release of libgd include a
gradient-fill routine.  The proposed mechanism is
   gdImageShadedTriangle(gdImagePtr image, gdPoint *vertex, int *color);
That is, a filled triangle with interpolation of three separate colors
specified for the three vertices.  Filled quadrangles are easily
produced by splitting each one into 2 triangles.

This would allow us to support gradient fill for the PNG/JPEG terminal.

My primary thought is to allow a PM3D shading mode that provides
smooth coloring.  

Are there other uses?  The colorbar?

Your thoughts and suggestions are welcome.


-- 
Ethan A Merritt					Courier Deliveries: 1959 NE Pacific	
Dept of Biochemistry    M/S 357742
Health Sciences Building
University of Washington - Seattle

pause mouse broken since v. 4.2?

[dbionda <db...@bl...>]

Dear all
I noticed that since at least vers. 4.2rc2 the "pause mouse" command no longer 
works as expected: "ok" and "cancel" buttons are not displayed and there is 
actually no way to dimiss the dialog window. Is this a bug or a feature?

cheers
Davide

Re: User specified location of GD not carried into Makefiles

[<HBB...@t-...>]

m sutton wrote:

> My reasoning is the configure script should examine a --with-gd 
> specified path before checking the $PATH.  

... except that --with-gd was invented long before gdlib-config, which 
is a way better solution to the underlying problem than any autoconf-fu 
we could come up with ourselves.  Just use it.

 > After all I just
> explicitly told configure where to look.  

You didn't tell it where to look for gdlib-config.  The optional path 
argument of --with-gd specifies paths for the library, not gdlib-config.

Ultimately, the mistake is to have installed libgd in a place where 
gdlib-config did not end up on your PATH.  Such installations are, by 
all practical means and purposes, unusable.

Re: User specified location of GD not carried into Makefiles

[m s. <mw...@us...>]

I'll try another approach to explaining what is broken with configure.  I'm=
 going use GD as the example case.

The configure help states the following:
  --with-gd=3DDIR         where to find Tom Boutell's gd library

This leads me to understand that a directory [DIR] can be specified.  Howev=
er, examining the actual configure.in file reveals that the specified direc=
tory is never used when a version of GD is found in $PATH.  From configure.=
in

> if test "$with_gd" !=3D no; then
>   AC_PATH_PROG([GDLIB_CONFIG], [gdlib-config])
>   if test -n "$GDLIB_CONFIG"; then
>     libgd_CPPFLAGS=3D`gdlib-config --cflags`
>     libgd_LDFLAGS=3D`gdlib-config --ldflags`
>   elif test -d "$with_gd"; then
>     libgd_CPPFLAGS=3D"-I$with_gd/include"
>     libgd_LDFLAGS=3D"-L$with_gd/lib"
>   fi

As you can see the first test is to try and find gdlib-config in $PATH.  Th=
e elif branch checks the user specfied directory if and only if there is no=
 other version of GD found in $PATH.  This means that configure ignored my =
request to use a particular location for the GD library.

I spent some time examining the GD configure script since it can include a =
wide variety of external libraries.  I found that GD does not properly loca=
te libpng when specified via --with-png.  However, --with-freetype does wor=
k properly.

So here is the patch to configure.in that I propose.  It will check the use=
r specified path first, then check $PATH.  Here is the result of my change =
followed by a diff.

if test "$with_gd" !=3D no; then
  if test -d "$with_gd"; then
    if test -x "$with_gd/bin/gdlib-config"; then
      GDLIB_CONFIG=3D"$with_gd/bin/gdlib-config"
    else
      libgd_CPPFLAGS=3D"-I$with_gd/include"
      libgd_LDFLAGS=3D"-L$with_gd/lib"
    fi
  else
    AC_PATH_PROG([GDLIB_CONFIG], [gdlib-config])
  fi
  if test -n "$GDLIB_CONFIG"; then
    libgd_CPPFLAGS=3D`$GDLIB_CONFIG --cflags`
    if test "$with_gd" =3D yes; then
      libgd_LDFLAGS=3D`$GDLIB_CONFIG --ldflags`
    else
      libgd_LDFLAGS=3D"-L"`$GDLIB_CONFIG --libdir`" "`$GDLIB_CONFIG --ldfla=
gs`
    fi
  fi


diff -u -u -r1.213 configure.in
--- configure.in	24 Jan 2007 05:22:11 -0000	1.213
+++ configure.in	29 Jan 2007 04:36:21 -0000
@@ -401,15 +401,24 @@
   with_gd=3Dyes)
=20
 if test "$with_gd" !=3D no; then
-  AC_PATH_PROG([GDLIB_CONFIG], [gdlib-config])
+  if test -d "$with_gd"; then
+    if test -x "$with_gd/bin/gdlib-config"; then
+      GDLIB_CONFIG=3D"$with_gd/bin/gdlib-config"
+    else
+      libgd_CPPFLAGS=3D"-I$with_gd/include"
+      libgd_LDFLAGS=3D"-L$with_gd/lib"
+    fi
+  else
+    AC_PATH_PROG([GDLIB_CONFIG], [gdlib-config])
+  fi
   if test -n "$GDLIB_CONFIG"; then
-    libgd_CPPFLAGS=3D`gdlib-config --cflags`
-    libgd_LDFLAGS=3D`gdlib-config --ldflags`
-  elif test -d "$with_gd"; then
-    libgd_CPPFLAGS=3D"-I$with_gd/include"
-    libgd_LDFLAGS=3D"-L$with_gd/lib"
+    libgd_CPPFLAGS=3D`$GDLIB_CONFIG --cflags`
+    if test "$with_gd" =3D yes; then
+      libgd_LDFLAGS=3D`$GDLIB_CONFIG --ldflags`
+    else
+      libgd_LDFLAGS=3D"-L"`$GDLIB_CONFIG --libdir`" "`$GDLIB_CONFIG --ldfl=
ags`
+    fi
   fi
-
   _cppflags=3D"$CPPFLAGS"
   _ldflags=3D"$LDFLAGS"
   CPPFLAGS=3D"$CPPFLAGS $libgd_CPPFLAGS"
@@ -461,7 +470,7 @@
     ])
=20
   if test -n "$GDLIB_CONFIG"; then
-    libgd_LIBS=3D`gdlib-config --libs`
+    libgd_LIBS=3D`$GDLIB_CONFIG --libs`
   fi
=20
   dnl piece it all together


-----
Mike Sutton


=3D
Ship Authentic Maryland Crabcakes Online
CrabcakeFactoryUSA.com is a purveyor of authentic Maryland Crabcakes. Made =
by hand in our Ocean City, Maryland location since 1996. Jumbo all lump Mar=
yland Crabcakes.
http://a8-asy.a8ww.net/a8-ads/adftrclick?redirectid=3Dc09333e12b3785217b22d=
b24988dbc30

Re: User specified location of GD not carried into Makefiles

[m s. <mw...@us...>]

> ----- Original Message -----
> From: "Ethan A Merritt" <merritt@u.washington.edu>
> To: "m sutton" <mw...@us...>
> Subject: Re: User specified location of GD not carried into Makefiles
> Date: Mon, 29 Jan 2007 19:21:52 -0800
>=20
>=20
> On Monday 29 January 2007 17:50, m sutton wrote:
> >
> > Let me try to explain this some more.  I work on some systems=20
> > that are locked down.  I cannot add packages as root.  So this=20
> > means I have to build and install in my local home directory.=20=20
> > Furthermore, I often build only the static libraries for things=20
> > like GD.
>=20
> Will that even work?
> libgd itself links to so many other libraries that a static build
> seems at best cumbersome, and at worst incompatible. In particular
> I would worry about dragging in a static version of libX11.

Works just fine. Here is what is in my local lib directory
>~/tmp/gnu/lib.171 %ls
libfreetype.a   libgd.a   libpng12.a   libpng.a   pkgconfig
libfreetype.la  libgd.la  libpng12.la  libpng.la

My Gnuplot configure
./configure --with-gd=3D/home/mike/tmp/gnu

After configuring (modified version) and making here is dependencies of the=
 final executable.
>~/tmp/gnuplot_cvs3/src.23 %ldd gnuplot
        linux-gate.so.1 =3D>  (0xffffe000)
        libz.so.1 =3D> /lib/libz.so.1 (0x40025000)
        libXpm.so.4 =3D> /usr/X11R6/lib/libXpm.so.4 (0x40036000)
        libX11.so.6 =3D> /usr/X11R6/lib/libX11.so.6 (0x40046000)
        libjpeg.so.62 =3D> /usr/lib/libjpeg.so.62 (0x40111000)
        libfontconfig.so.1 =3D> /usr/lib/libfontconfig.so.1 (0x40130000)
        libm.so.6 =3D> /lib/tls/libm.so.6 (0x4015c000)
        libstdc++.so.6 =3D> /usr/lib/libstdc++.so.6 (0x4017f000)
        libgcc_s.so.1 =3D> /lib/libgcc_s.so.1 (0x40251000)
        libc.so.6 =3D> /lib/tls/libc.so.6 (0x4025a000)
        libdl.so.2 =3D> /lib/libdl.so.2 (0x40379000)
        libexpat.so.0 =3D> /usr/lib/libexpat.so.0 (0x403e9000)
        /lib/ld-linux.so.2 =3D> /lib/ld-linux.so.2 (0x40000000)

Notice that libgd and libpng do not appear in the shared object list.  The =
linker finds only static libraries.  This means that there is no dependency=
 on those share libraries.



> > My reasoning is the configure script should examine a --with-gd=20
> > specified path before checking the $PATH.  After all I just=20
> > explicitly told configure where to look.  If the --with-gd path=20
> > is not respected then the wrong gd.h file will be included.
>=20
> See previous comments.
> This should not matter, as gd.h is not significantly version-dependent.

GIF animation is a recent addition and could be overlooked if the wrong gd.=
h is used.

> Gnuplot's ./configure mechanism was not designed for cross-compilation
> or for building an executable for running in a totally different
> environment.   I think you are expecting too much of it.

I'm not cross-compiling.  We have a few stand-alone RedHat clusters (4 clus=
ters 10 hosts each) all basically configured the same.  If I use static PNG=
 and GD libraries we can run the executable on any cluster/host without hav=
ing to fuss around with each user's LD_LIBRARY_PATH.

I'm just trying to improve configure's capability.

Mike Sutton


=3D
Christian Singles
Free Christian Personals Online. ""View Photos, Chat, Email & More."".
http://a8-asy.a8ww.net/a8-ads/adftrclick?redirectid=3De0d0ab51515a7fd87d3a4=
e150c412ad5

Re: User specified location of GD not carried into Makefiles

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

On Monday 29 January 2007 17:50, m sutton wrote:
> 
> Let me try to explain this some more.  I work on some systems that 
> are locked down.  I cannot add packages as root.  So this means I 
> have to build and install in my local home directory.  Furthermore, 
> I often build only the static libraries for things like GD.

Will that even work? 
libgd itself links to so many other libraries that a static build
seems at best cumbersome, and at worst incompatible. In particular
I would worry about dragging in a static version of libX11.

lascaux [806] ldd /home/local/lib/libgd.so.2.0.33
        linux-gate.so.1 =>  (0xffffe000)
        libXpm.so.4 => /usr/X11R6/lib/libXpm.so.4 (0xb7f80000)
        libX11.so.6 => /usr/X11R6/lib/libX11.so.6 (0xb7eb4000)
        libjpeg.so.62 => /usr/lib/libjpeg.so.62 (0xb7e94000)
        libfontconfig.so.1 => /usr/lib/libfontconfig.so.1 (0xb7e64000)
        libfreetype.so.6 => /usr/lib/libfreetype.so.6 (0xb7dfb000)
        libpng12.so.0 => /usr/lib/libpng12.so.0 (0xb7dd5000)
        libz.so.1 => /lib/libz.so.1 (0xb7dc1000)
        libm.so.6 => /lib/tls/libm.so.6 (0xb7d9c000)
        libc.so.6 => /lib/tls/libc.so.6 (0xb7c6e000)
        libdl.so.2 => /lib/libdl.so.2 (0xb7c6a000)
        libexpat.so.0 => /usr/lib/libexpat.so.0 (0xb7c4a000)
        /lib/ld-linux.so.2 (0x80000000)

> My reasoning is the configure script should examine a --with-gd 
> specified path before checking the $PATH.  After all I just 
> explicitly told configure where to look.  If the --with-gd path is 
> not respected then the wrong gd.h file will be included.

See previous comments.  
This should not matter, as gd.h is not significantly version-dependent. 

> As for the link time options to remember the path (-R, -rpath),  
> implementing this gets trickier because there is not a standard 

Yes, I agree. The -rpath mechanism is not widely used.
 
> I hope that makes my rationale clearer.

Gnuplot's ./configure mechanism was not designed for cross-compilation
or for building an executable for running in a totally different
environment.   I think you are expecting too much of it.
If I were you, I would just tweak src/Makefile after running
./configure.  You can add include and link paths as you please.
If you are already prepared to fiddle the compile flags to create a
static executable, the rest of the tweaking seems relatively minor.


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