gnuplot development

OK.  I think I have a working patch to configure.in to resolve the=20
--with-gd=3D issues.  The same problem was also present in the=20
--with-pdf section.  I was able to test the --with-gd stuff but not=20
the --with-pdf parts.  However, the same basic logic is used in=20
both.

Mike Sutton


=3D
Ruth's Chris Steak House
Serious steak and fine wines. Easy online reservations. Book your table now.
http://a8-asy.a8ww.net/a8-ads/adftrclick?redirectid=3Df68766c3b16c72099ff7c=
0eb075c04fd

I am not clear on what problem you are trying to fix exactly.
The version of libgd found during configuration does not have to be
the same one used at runtime. For instance, I have been working with several
libgd versions since I'be been trying to push fixes upstream to libgd.org.
I have seen no version-compatibility problems when running against any
libgd version from 2.0.29 to 2.0.34-cvs, all with the same gnuplot executable.

[pokes around a bit] OK, Mandrake 10.1 came with 2.0.27 so it didn't have
GIF support. Is that the issue?

Anyhow, even if you force ./configure to use some particular version 
when building gnuplot, at runtime it will still pick the libgd.so.2 
provided by the system setup or by LD_LIBRARY_PATH.  Wouldn't it be
easier just to upgrade the system's libgd?

	Ethan



On Sunday 28 January 2007 20:37, m sutton wrote:
> OK.  I think I have a working patch to configure.in to resolve the 
> --with-gd= issues.  The same problem was also present in the 
> --with-pdf section.  I was able to test the --with-gd stuff but not 
> the --with-pdf parts.  However, the same basic logic is used in 
> both.
> 
> Mike Sutton


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

> Anyhow, even if you force ./configure to use some particular version 
> when building gnuplot, at runtime it will still pick the libgd.so.2 
> provided by the system setup or by LD_LIBRARY_PATH.  Wouldn't it be
> easier just to upgrade the system's libgd?
 
 All Mike needs to do is prepend the directory that contains his local
 gdlib-config to PATH (assuming the local location is the resulty of a
 make install, not just the compile dir). No patch necessary.

Ethan A Merritt wrote:
> Anyhow, even if you force ./configure to use some particular version 
> when building gnuplot, at runtime it will still pick the libgd.so.2 
> provided by the system setup or by LD_LIBRARY_PATH.  

Not necessarily.  Shared libraries can be registered with an absolute 
path.  The don't have to be searched via LD_LIBRARY_PATH or related 
means, and the executable can influence its own effective search path to 
some extend.  Viz. 'ld' options -R, -rpath etc.

On Monday 29 January 2007 11:24, Hans-Bernhard Br=F6ker wrote:
> Ethan A Merritt wrote:
> > Anyhow, even if you force ./configure to use some particular version=20
> > when building gnuplot, at runtime it will still pick the libgd.so.2=20
> > provided by the system setup or by LD_LIBRARY_PATH. =20
>=20
> Not necessarily.  Shared libraries can be registered with an absolute=20
> path.  The don't have to be searched via LD_LIBRARY_PATH or related=20
> means, and the executable can influence its own effective search path to=
=20
> some extend.  Viz. 'ld' options -R, -rpath etc.

That is true, at least on some systems.  But so far as I know gnuplot's
configure script doesn't do any such thing.  =20

It may be that you can force this in the gdlib-config file; I don't know mu=
ch=20
about that mechanism. But if I understand Lars' comment correctly,=20
the needed fix is not a change to the ./configure script but rather a change
to the environmental variable PATH at the time ./configure is run. =20

> ----- Original Message -----
> From: "Ethan A Merritt" <merritt@...>
> To: gnuplot-beta@...
> Subject: Re: User specified location of GD not carried into Makefiles
> Date: Sun, 28 Jan 2007 21:18:17 -0800
>=20
>=20
> I am not clear on what problem you are trying to fix exactly.
> The version of libgd found during configuration does not have to be
> the same one used at runtime. For instance, I have been working with seve=
ral
> libgd versions since I'be been trying to push fixes upstream to libgd.org.
> I have seen no version-compatibility problems when running against any
> libgd version from 2.0.29 to 2.0.34-cvs, all with the same=20
> gnuplot executable.
>=20
> [pokes around a bit] OK, Mandrake 10.1 came with 2.0.27 so it didn't have
> GIF support. Is that the issue?
>=20
> Anyhow, even if you force ./configure to use some particular version
> when building gnuplot, at runtime it will still pick the libgd.so.2
> provided by the system setup or by LD_LIBRARY_PATH.  Wouldn't it be
> easier just to upgrade the system's libgd?
>=20

Let me try to explain this some more.  I work on some systems that=20
are locked down.  I cannot add packages as root.  So this means I=20
have to build and install in my local home directory.  Furthermore,=20
I often build only the static libraries for things like GD.  This=20
removes the LD_LIBRARY_PATH issues and it is now easier to move the=20
executable to another host on our network.

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 is=20
not respected then the wrong gd.h file will be included.

As for the link time options to remember the path (-R, -rpath),=20=20
implementing this gets trickier because there is not a standard=20
option across all compilers.  For now I would fore go trying to=20
implement this in the configure script.

I hope that makes my rationale clearer.

Mike Sutton


=3D
Low Cost Auto Insurance
Paying Too Much for Auto Insurance? Get Lower Ohio Quotes Today.
http://a8-asy.a8ww.net/a8-ads/adftrclick?redirectid=3D2c928adba226c84e2bc09=
e9f322e81b3

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

> ----- Original Message -----
> From: "Ethan A Merritt" <merritt@...>
> To: "m sutton" <mws115@...>
> 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

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

On Sunday 28 January 2007 12:58, Mike Sutton wrote:
> The comma in the offset specification confuses the command line parser.
>   plot 'mike3.dat'  with labels left offset 3,3 , 'mike4.dat' with points
>         duplicated or contradicting arguments in plot options

Yes, I had totally forgotten about that. Thanks for the reminder.
It is a known problem, but is probably fixable.

> A work around is to make sure the "with labels" is the last thing plotted.

Other work-arounds:
- Give a dummy z coordinate in the offset
	plot 'mike3' with labels left offset 3,3,0, 'mike4' with points
- put an attribute keyword after the offset
	plot 'mike3' with labels offset 3,3 left, 'mike4' with points
- even if it's a useless attribute
	plot 'mike3' with labels offset 3,3 nopoint, 'mike4' with points

> I think a note should be added to the 4.2 documentation about this limitation.

Yes, if no trivial fix is found.
The trick will be to put the note in a place that users will actually find.

 
> So I started playing around with the text color.  
>     plot 'mike3.dat' w labels left  tc rgb "blue"
> 
> This works for RC4 but not for the CVS HEAD (4.3).  I have not investigated 
> why "tc rgb 'color'" does not work for 4.3.  It always comes up black. 

Huh. You are right. That's a strange one.
I have absolutely no idea what has gone wrong.

> I have also thought that the addition of a label style, analogous to 
> linestyle,  would be useful.

I have a slightly different approach already on my TODO list.
Rather than using linestyle as a model, I was thinking that there should
be the equivalent of
	set style histogram
	set style fill
	set style object rectangle
Each of these defines a set of default properties for all instances of
the respective plot elements.  

In the case of labels, my idea was that if a specific label
command does not set a font, say, then its font field is set to DEFAULT
and inherits the current value in the generic label style. Thus if you
were to set 100 labels in advance, perhaps plotting to judge visual effect,
you could change all of them at once to use a smaller font by saying
	set style label font "Times,9"

I take it your idea is similar, except that there would be multiple
predefined label styles rather than a single default style. Right?

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

Ethan A Merritt wrote:
> On Sunday 28 January 2007 12:58, Mike Sutton wrote:
> 
>>The comma in the offset specification confuses the command line parser.
>>  plot 'mike3.dat'  with labels left offset 3,3 , 'mike4.dat' with points
>>        duplicated or contradicting arguments in plot options
> 
> 
> Yes, I had totally forgotten about that. Thanks for the reminder.
> It is a known problem, but is probably fixable.
> 
> 
>>A work around is to make sure the "with labels" is the last thing plotted.
> 
> 
> Other work-arounds:
> - Give a dummy z coordinate in the offset
> 	plot 'mike3' with labels left offset 3,3,0, 'mike4' with points
> - put an attribute keyword after the offset
> 	plot 'mike3' with labels offset 3,3 left, 'mike4' with points
> - even if it's a useless attribute
> 	plot 'mike3' with labels offset 3,3 nopoint, 'mike4' with points
> 

I wasn't aware this issue came up elsewhere.  I think this is the same problem as we skirted with a change in syntax to something else that used commas in the binary format string.  That is, we changed a comma to a colon, but in that case the comma wasn't used as a delimiter for something like coordinates.

Not sure this is fixable.  The problem is that one has to sort of advance the parse pointer a little too far and move on before making a final decision about how to treat the numbers.  For example, note the slight difference between these two lines, both of them valid:

	plot 'mike3' with labels left offset 3,3,0, 'mike4' with points

	plot 'mike3' with labels left offset 3,3,0 with points

Yes, it is clear that their is a second plot and it is zero as one looks at it, but that doesn't become clear until the "with" is interpreted which from a programming perspective is too far down the line.

The problem is that an "isolated" or "stand alone" comma has multiple meanings.  The only ways around this, it seems to me, is to change the syntax of end of line (difficult to deprecate something like that, but could allow new syntax that hasn't ambiguity) or restrict the use of comma somewhat (again, difficult to change at this point).

Unfortunately semicolon and backslash are already used.  There is a straight line "|"

	plot 'mike3' with labels left offset 3,3 | 'mike4' with points

also, ~ < > - & (actually "and" would be a not-so-illogical choice) and then possible double character use .. ;; \\.

The other approach would be to restrict coordinates to include parentheses, e.g.,

	plot 'mike3' with labels left offset (3,3), 'mike4' with points

Dan

Mike Sutton wrote:
> I was testing 4.2RC4 and noticed that my specified location for GD was =
not=20
> passed down through to the Makefile.  This is on Mandrake 10.1 and I us=
e a=20
> newer version of GD that is intalled in my user area.  I swear this has=
=20
> worked properly in the past.
>
> My configure line was:
>   ./configure --with-gd=3D/home/mike/tmp/gnu
>
> The GD directory does not make it to the compile step:
> if gcc -DHAVE_CONFIG_H -I. -I. -I..  -I../term -I../term=20
> -DBINDIR=3D\"/usr/local/bin\"=20
> -DX11_DRIVER_DIR=3D\"/usr/local/libexec/gnuplot/4.2\"=20
> -DGNUPLOT_PS_DIR=3D\"/usr/local/share/gnuplot/4.2/PostScript\"=20
> -DCONTACT=3D\"gnuplot-bugs@...
> -DHELPFILE=3D\"/usr/local/share/gnuplot/4.2/gnuplot.gih\" -I/usr/X11R6/=
include=20
> -I/usr/include  -g -O2 -MT term.o -MD -MP -MF ".deps/term.Tpo" -c -o te=
rm.o=20
> term.c; \
> then mv -f ".deps/term.Tpo" ".deps/term.Po"; else rm -f ".deps/term.Tpo=
"; exit=20
> 1; fi
>
>
> And the link step for gnuplot was:
> g++  -g -O2  -L/usr/X11R6/lib -o gnuplot  alloc.o axis.o breaders.o bit=
map.o=20
> color.o command.o contour.o datafile.o dynarray.o eval.o fit.o gadgets.=
o=20
> getcolor.o graph3d.o graphics.o help.o hidden3d.o history.o internal.o=20
> interpol.o matrix.o misc.o mouse.o parse.o plot.o plot2d.o plot3d.o pm3=
d.o=20
> readline.o save.o scanner.o set.o show.o specfun.o standard.o stdfn.o=20
> tables.o term.o time.o unset.o util.o util3d.o variable.o version.o   -=
lz=20
> -lgd -lXpm -lX11 -ljpeg -lfreetype -lpng12 -lz -lm   -lm
>
>
> As you can see my specification to GD was lost.  I'm guessing this is s=
ome=20
> kind of problem with the=20
>
> I also noticed that GD 2.0.33 links in the fontconfig library if availa=
ble. =20
> Gnuplot does not check for fontconfig.  Is this picked up when the prop=
er=20
> gdlib-config script is found?
>
> Mike Sutton
>  =20

Hi Mike,

The offending code in configure.in is:

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
(...)
fi

So what you gave to --with-gd is only used if gdlib-config cannot be=20
found in your $PATH. And then it doesn't even try to use the=20
gdlib-config in the custom path that you provided, but just appends=20
'include' and 'libs' to it. This could indeed be improved.

Best regards,

Timoth=E9e

On Sunday 28 January 2007 11:36, Per Persson wrote:
> 
> On Jan 25, 2007, at 22:09, Ethan Merritt wrote:
> 
> > On Thursday 25 January 2007 12:52, Per Persson wrote:
> 
> I've put a patch (#1646558) which makes configure look for  
> _remove_history rather than _readline.
> This works on OS X 10.4.x, but newer versions of libedit seems to  
> have that symbol, so this is likely not a future-proof test.
 
I have no way to test your fix, other than to confirm that ./configure
under linux can still successfully find gnu libreadline after
applying the patch.  

> Let me know if you think I should commit it to CVS.

You'll have to make that call yourself, or ask other  OSX users for
opinions.  It sounds better than the current ./configure behaviour
on OSX.  But remember that gnuplot releases seem to stick around for
several years, so looking ahead to likely compatibility with future
OS versions is a good idea.  

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

On Saturday 27 January 2007 07:29, Mojca Miklavec wrote:
> just a short question: how should a terminal properly set the bounding
> box of an image? 

I don't think that question is well-defined.  You may have to explain
in more detail what you are asking.

> I used to set it to (0,0) and (5in,3in), or whatever 
> the graphic size was, but then I figured out that the image is now too
> big if one sets a smaller size ("set size .5" for example).

Please define "graphic size" and "image size".  These are not the
terms that we have been using with regard to gnuplot, so I am not
sure what you mean.

> I would 
> like to set the image boundary only to the relevant part (in that case
> it would be (0,0) and (2.5in,1.5in)).

Please don't do that.  We are trying to make the scale of the plot, 
controlled by "set size", and the size of the 'canvas' (which I think
is what you mean by 'image' but I'm not sure), independent of each other.

This section of the current docs tries to explain, but maybe you can
suggest how to make the description more clear:

gnuplot> help canvas

 In earlier versions of gnuplot, some terminal types used the values from
 `set size` to control also the size of the output canvas; others did not.
 The use of 'set size' for this purpose was deprecated in version 4.2.
 In version 4.3 almost all terminals now behave as follows:

 `set term <terminal_type> size <XX>, <YY>` controls the size of the output
 file, or "canvas". Please see individual terminal documentation for allowed
 values of the size parameters.  By default, the plot will fill this canvas.

 `set size <XX>, <YY>` scales the plot itself relative to the size of the
 canvas.  Scale values less than 1 will cause the plot to not fill the entire
 canvas.  Scale values larger than 1 will cause only a portion of the plot to
 fit on the canvas.  Please be aware that setting scale values larger than 1
 may cause problems on some terminal types.

 The major exception to this convention is the PostScript driver, which
 by default continues to act as it has in earlier versions. Be warned that
 the next version of gnuplot may change the default behaviour of the
 PostScript driver as well.
 Example:
       set size 0.5, 0.5
       set term png size 600, 400
       set output "figure.png"
       plot "data" using lines

 These commands will produce an output file "figure.png" that is 600 pixels
 wide and 400 pixels tall. The plot will fill the lower left quarter of this
 canvas.  This is consistent with the way multiplot mode has always worked,
 however it is a change in the way the png driver worked for single plots in
 version 4.0.

 > How can I determine the bounds? I saw that "set size" sets "xsize" and
> "ysize" global variables,

Those are the scaling factors set by "set size".

> but then I also noticed the following: 
>     plot_bounds.xright = (xsize + xoffset) * t->xmax

plot_bounds was not intended for export to terminal drivers.
It is used by the generic drawing routines like draw_clip_line()
to perform terminal-independent clipping.

> Should the graphic boundary obey "plot_bounds" or something else?
> (Once again, I'm not sure about multiplots and such.)

The individual terminal drivers are not supposed to know or care about
this.  It is the responsibility of the core routines to decide how to
place things onto the canvas size reported by the current driver in
term->xmax and term->ymax.




> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share your
> opinions on IT & business topics through brief surveys - and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> gnuplot-beta mailing list
> gnuplot-beta@...
> https://lists.sourceforge.net/lists/listinfo/gnuplot-beta
> 

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

On 1/27/07, Ethan A Merritt wrote:
> On Saturday 27 January 2007 07:29, Mojca Miklavec wrote:
> > just a short question: how should a terminal properly set the bounding
> > box of an image?
>
> I don't think that question is well-defined.  You may have to explain
> in more detail what you are asking.

I'm sorry for not being clear enough, these are just different naming
conventions. What I mean with "bounding box" (term used in eps figures
for examples) is what you mean with canvas. You guessed it properly.

> > I used to set it to (0,0) and (5in,3in), or whatever
> > the graphic size was, but then I figured out that the image is now too
> > big if one sets a smaller size ("set size .5" for example).
>
> Please define "graphic size" and "image size".  These are not the
> terms that we have been using with regard to gnuplot, so I am not
> sure what you mean.

Both refer to "canvas size". (I wasn't use to that term either.)

> > I would
> > like to set the image boundary only to the relevant part (in that case
> > it would be (0,0) and (2.5in,1.5in)).
>
> Please don't do that.  We are trying to make the scale of the plot,
> controlled by "set size", and the size of the 'canvas' (which I think
> is what you mean by 'image' but I'm not sure), independent of each other.
>
> This section of the current docs tries to explain, but maybe you can
> suggest how to make the description more clear:

(The description seems clear, but I didn't pay enough attention to it.
I also didn't know that it's called canvas.)

> gnuplot> help canvas
>
>  In earlier versions of gnuplot, some terminal types used the values from
>  `set size` to control also the size of the output canvas; others did not.
>  The use of 'set size' for this purpose was deprecated in version 4.2.
>  In version 4.3 almost all terminals now behave as follows:
>
>  `set term <terminal_type> size <XX>, <YY>` controls the size of the output
>  file, or "canvas". Please see individual terminal documentation for allowed
>  values of the size parameters.  By default, the plot will fill this canvas.
>
>  `set size <XX>, <YY>` scales the plot itself relative to the size of the
>  canvas.  Scale values less than 1 will cause the plot to not fill the entire
>  canvas.  Scale values larger than 1 will cause only a portion of the plot to
>  fit on the canvas.  Please be aware that setting scale values larger than 1
>  may cause problems on some terminal types.
>
>  The major exception to this convention is the PostScript driver, which
>  by default continues to act as it has in earlier versions. Be warned that
>  the next version of gnuplot may change the default behaviour of the
>  PostScript driver as well.
>  Example:
>        set size 0.5, 0.5
>        set term png size 600, 400
>        set output "figure.png"
>        plot "data" using lines
>
>  These commands will produce an output file "figure.png" that is 600 pixels
>  wide and 400 pixels tall. The plot will fill the lower left quarter of this
>  canvas.  This is consistent with the way multiplot mode has always worked,
>  however it is a change in the way the png driver worked for single plots in
>  version 4.0.

I'm sorry, I have to read the documentation more carefully next time
before asking something.

This is how my terminal already works, but I thought that it needs to
be fixed. So, I thought that for the example above I should create an
image of 300x200 pixels (leaving so much blank space in the border
seemed somehow nonsense to me).

The terminal also supports "set size" syntax, but I cannot use it in
the middle of the document, because if I want to change the size with
"set context size 0.5,0.5", then the terminal is reset (which could be
expressed as \end{document}\begin{document}" in LaTeX dialect), so
it's useless.

But that's OK - in most cases one creates single plots anyway.

> The individual terminal drivers are not supposed to know or care about
> this.  It is the responsibility of the core routines to decide how to
> place things onto the canvas size reported by the current driver in
> term->xmax and term->ymax.

OK. So there's nothing more to care about.

Thanks a lot,
     Mojca

Ethan Merritt a =E9crit :
> On Friday 26 January 2007 11:30, Timoth=E9e Lecomte wrote:
>  =20
>> Petr Mikulik a =E9crit :
>>    =20
>>> 	http://sourceforge.net/projects/libharu/
>>> Haru is a free, cross platform, open-sourced software library for gen=
erating=20
>>> PDF written in ANSI-C.
>>>      =20
>
>  =20
>> Cairo can do it too, and we already have 90% of the code in gnuplot=20
>> right now thanks to the wxt terminal and gp_cairo.c.
>>    =20
>
> What would be the state of UTF-8 support through such a path?
> That is a big lack in PDFlib Lite.
>
> The other tricky bit is pattern-fill, but it's much less important.
>  =20
Well, I am not completely sure, but I would expect the text output to be=20
the same as the one from the wxt terminal. Actually, fonts are more of a=20
problem than encoding in my understanding of pdf.

As for pattern-fill, what are you afraid of ?

Timoth=E9e

On Friday 26 January 2007 11:41, Timoth=E9e Lecomte wrote:
> Ethan Merritt a =E9crit :
> >
> > What would be the state of UTF-8 support through such a path?
> > That is a big lack in PDFlib Lite.
> >  =20
> Well, I am not completely sure, but I would expect the text output to be=
=20
> the same as the one from the wxt terminal. Actually, fonts are more of a=
=20
> problem than encoding in my understanding of pdf.

I think the problem really is the encoding.  It's easy to specify
a font that contains a very large set of unicode glyphs, but PDFLib Lite
only allows you to select those glyphs that are indexed by a
single-byte coding table.  Full unicode table options, including UTF-8,
are only available in commercial versions of PDFLib.  Having the
glyphs in the font doesn't help if the encoding does not index them.

> > The other tricky bit is pattern-fill, but it's much less important.
> >
> As for pattern-fill, what are you afraid of ?

When I originally implemented pattern-fill in pdf.trm, I had to
try about 6 different ways of constructing the patterns before I
found a sequence of calls that worked.  The routines provided=20
by the PDF library did not parallel the PostScript routines as
closely as I would have expected.  It worked in the end, but
it was a bit tricky to find the right calls.

Ethan Merritt wrote:
> On Friday 26 January 2007 11:41, Timothée Lecomte wrote:
>>As for pattern-fill, what are you afraid of ?
> 
> 
> When I originally implemented pattern-fill in pdf.trm, I had to
> try about 6 different ways of constructing the patterns before I
> found a sequence of calls that worked.  The routines provided 
> by the PDF library did not parallel the PostScript routines as
> closely as I would have expected.  It worked in the end, but
> it was a bit tricky to find the right calls.

Would patterns composed of images rather than strokes be of any help?  I think there is now the necessary functions in PostScript to construct the ecodings.  PDFlib I don't know about.

Beats me what the issue is with sending patterns to the HP printer.  I don't see any complaints at the HP website about that.

Dan